2 stemmer

God dag, kjære lesere. Å jobbe på en nettside med en klient er alltid vanskelig. Klienten vil som regel enten ha "noe kult" eller "ikke noe uvanlig, la det være som alle andre." Abstrakte konsepter, du vil være enig. Hvis dette er din første ordre, kan du til og med være fornøyd med lignende ord: "Kult, de gir meg kreativ frihet, jeg kan gjøre hva jeg vil." Jeg kan fortelle deg av erfaring, ingenting som det!

Kunden har sin egen forståelse av «kult» og «som alle andre». Du kan ikke gjette, være i feil humør, eller klienten vil ganske enkelt bestemme at "for den slags penger kan denne fyren (eller jenta) gjøre litt mer arbeid." For å forhindre at dette skjer, vil vi i dag diskutere hvordan tekniske spesifikasjoner for utvikling av nettsider er utarbeidet.

Handlingsplan for samarbeid med kunden

Du finner en klient. Han er klar til å betale pengene, og du kommer på jobb. Hvor skal man begynne og hvordan går man frem?

• Første kommunikasjon.

Så du har mottatt den første informasjonen: dette kan skje personlig (hvis du tilbyr tjenester selv) eller over telefon (når klienten finner deg på egen hånd). La oss si at du vet at kunden ønsker en nettbutikk fra deg, og han eier selv en kjede med smykker. Start aldri en samtale om nettstedet med en gang. Gjør en avtale slik at dere alle kan forberede dere sammen og unisont.

Prøv på en eller annen måte å motivere personen til å se på informasjonen slik at han har en klarere ide om hva han vil ha fra deg.

• Forberedelse og første brief.

Se på nettsteder som du tror vil passe for kunden. Last ned noen maler og si at nettstedet kan se akkurat slik ut. Jo flere materialer, jo bedre. La deg ha noe å vise kunden, ha en klar ide om hva han liker og hva han ikke liker. Unngå abstrakte konsepter fra serien: vakker, praktisk, høy kvalitet. Alle har sine egne ideer om disse kategoriene.

Ideelt sett er det bedre å forlate klienten med dette materialet for en dag eller sende dem med post noen dager før møtet. Selv om kunden på dette stadiet som regel ikke er spesielt interessert i portalen. Han er klar til å kutte sannheten rett på sak og tvinge deg til å gjøre om det og legge til noe nytt, men ikke diskutere noe på forhånd. Derfor er den eneste utveien å spørre så mye som mulig og skrive ned hvert ord.

• Utarbeide og signere tekniske spesifikasjoner.

Husk at jo flere papirbiter, desto renere blir baken. Skriv ned, tegn opp og signer alt mulig fra oppdragsgiver. Deretter vil du ha noe å vise frem. Generelt, når du skriver ut de tekniske spesifikasjonene, forestill deg umiddelbart at du og klienten ikke ser øye til øye og forsvarer saken din i retten.

Vi snakker ikke om superdyre prosjekter, og jeg håper at du vil ha lykke til med kundene. Men én omhyggelig klient kan ødelegge humøret ditt i lang tid. Du vil spytte, nekte penger, bare ikke møte ham lenger. Dette er forståelig, men hvis du først viser deg selv som en profesjonell, studerer alt grundig og viser deg selv som en respektabel person, trenger du ikke å gjøre dette.

En dag var jeg veldig heldig. Før han kom til møtet, studerte klienten problemet og utarbeidet selv ikke bare en kompetent teknisk spesifikasjon, men også en kunstnerisk oppgave. Det vil si litterære og Detaljert beskrivelse hvordan det skal se ut. Min overraskelse visste ingen grenser, som han svarte: "Jeg tror at kunden selv først og fremst burde vite hva han vil ha, og ikke plage spesialister." Dette er dessverre sjelden, så vi må stille spørsmål, foreskrive og godkjenne.

• Utvikling og mottak.

Når du har signert alt, kan du begynne å implementere prosjektet.

Hva skal ikke stå i den tekniske spesifikasjonen, og hva skal stå der

Den tekniske spesifikasjonen bør faktisk ikke inneholde instruksjoner angående selve designet. Du skriver at på et nettsted for en programmerer vil du tegne et tastatur, og så begynner det - det er ikke sånn, jeg vil at det skal være i tegneseriestil og så bevise at du ikke er et rådyr. Jo bedre du beviser deg selv som profesjonell, jo færre klager vil det være mot deg!

Du vet selv i hvilken stil og hva som skal tegnes. Du står overfor en oppgave: å forbedre merkekjennskapen eller motivere folk til å feriere på et slikt og et slikt sted. Hvordan du skal implementere denne oppgaven er ditt problem. Det som også manglet var at kunden skulle lære deg hvordan du skriver kode og fortelle deg hvilke verktøy du skal bruke.

La arbeidserklæringen din inneholde setningen: "Alt som ikke er avtalt, utføres etter utøverens skjønn." Og det er ikke nødvendig å lage denne linjen i liten skrift. La ham tenke på forhånd, og ikke begynne å drømme når prosjektet allerede er klart. Selvfølgelig kan og bør du gjøre små endringer. Et godt rykte er nøkkelen til fremtidige kunder, men noen ganger kan en kunde være så irriterende med sine ønsker at han ikke vil leve.

Nok en gang vil jeg rette oppmerksomheten mot det faktum at den tekniske spesifikasjonen ikke skal inneholde abstrakte konsepter: "praktisk", "vakker", "høy kvalitet", etc. La grensene være klare: i stedet for å søke bekvemmelighet, er det bedre å skrive filtrering etter dato eller materiale.

Og ikke glem signaturen. Alt er seriøst, dette må kunden forstå.

Generelt anbefaler jeg på det sterkeste at du tar hensyn til de små tingene. Tenk deg at en skummet kvinne kommer til deg og knepper raskt opp den enorme jakken sin slik at et overdimensjonert skjerf stikker ut av den. Han tar frem en krøllet lapp på 18 ark, brettet hundre ganger, og prøver å jevne den ut med gjenstander i nærheten. Rødt ansikt og uartikulert: "Her, jeg skrev og gjorde det kortere, dette er hvordan nettstedet ditt vil se ut, signer det."

En annen variant. En ung mann banker på kontoret ditt, kler av seg sakte, tar en mappe ut av kofferten, åpner den sakte og inviterer deg rolig til å se på bare ett lite stykke papir, holder frem en gyllen penn og inviterer deg til å signere dette dokumentet.

La den unge damen fra det første eksemplet gjøre en titanisk jobb, hun leste tusen bøker, tegnet 18 eksempler å velge mellom, og gjorde stort sett alt selv. Hun er i stand til å lage et utrolig kult prosjekt som vil føre din bedrift til velstand og verdensomspennende berømmelse. Og den unge mannen fra det andre eksemplet vet ikke hvordan han skal gjøre noe, han skrev ut en prøve fra Internett, som på ingen måte passer deg.

Jeg forsikrer deg om at enhver klient vil torturere den stakkars kvinnen med masing, ønsker og endringer, og vil akseptere den unge mannens prosjekt, om ikke umiddelbart, så for andre gang. Det handler ikke om hva du kan gjøre, men hvordan du handler og inntrykket du skaper.

Det er GOST, ifølge hvilken du kan lage tekniske spesifikasjoner for utvikling av nettsteder, og det er langsiktig praksis. Statlige standarder passer ikke alltid til livets realiteter. La oss prøve å kombinere begge disse delene.

Enten du skriver tekniske spesifikasjoner for byadministrasjonen eller den legendariske Vasily Pupkin, gjøres innholdet best i samsvar med GOST. Lær dette på forhånd.

Det ser slik ut:

1. Ordliste
2. Generelle bestemmelser
3. Utviklingsobjekt
4. Formålet med dokumentet
5. Krav til grafisk design nettstedet
6. Krav til nettsteddesign
7. Prosedyren for å godkjenne designkonseptet
8. Funksjonelle krav
9. Krav til nettsidepresentasjon
10. Krav til innholdsstyringssystem
11. Krav for å dele tilgang
12. Krav til typer sikkerheter
13. Krav til informasjonsstøtte
14. Programvarekrav
15. Tekniske krav
16. Krav til språklig støtte
17. Krav til ergonomi og teknisk estetikk
18. Krav til prosjektaksept og leveranse
19. Krav til utfyllingsinformasjon
20. Krav til personell
21. Distribusjonsbestemmelsesprosedyre
22. Prosedyren for å overføre et nettsted til tekniske midler kunde

Det er sant at du ikke trenger å lage dokumentet ditt med oppgaven i denne rekkefølgen, men for å gjøre det lettere å forstå, vil jeg fortelle deg i henhold til denne planen. På slutten av denne artikkelen legger jeg ved et eksempel som du kan laste ned og jobbe med, basert på transkripsjonen gitt i denne delen av artikkelen. Denne malen er bra fordi den har Alle, selv det du aldri trenger. Men du må behandle det selv og krysse ut all unødvendig dritt som du anser som unødvendig.

Ordliste

I følge GOST skal dokumentet begynne med en ordliste, men faktisk vil du skrive det på slutten. Her må du oppgi vilkårene du skal bruke når du jobber med kunden. Du forteller oss hva hosting, en nettside og annet tull er. Alt dette tullet kan lastes ned fra Internett.

Men i tillegg til dette kjetteriet, er det nødvendig å nevne vilkår, i forståelsen av hvilke du og kunden kan ha en meningsforskjell. Du mener én ting, men han legger en helt annen mening i ordene.

Generelle bestemmelser

På dette tidspunktet må vi svare på spørsmålet om hva vi faktisk skal gjøre og hvorfor.

Utviklingsobjekt

Hva vi skal gjøre er omtrent klart. Klienten gir denne informasjonen nesten umiddelbart. Det er viktigere å forstå det operative formålet med nettstedet, det vil si hvilken fordel som venter kunden. Det er tydelig at alle kunder ønsker å tjene penger gjennom siden. Denne formuleringen vil ikke fungere.

Tenk på hvordan kunden vil tjene penger, hva målet hans er. Hvis dette er en nettbutikk, bør den være engasjert i salg, hvis det er et firmanettsted, så liker de en vakker setning: "øke merkevarelojalitet," informere om selskapets aktiviteter, og så videre.

Formålet med dokumentet

Her forteller vi deg hvor viktig dette dokumentet er. Vi viser at dette ikke er et enkelt triks, men wow! Vi bruker juridiske termer. Denne delen kan kopieres fra Internett, men ikke glem å lese nøye det du skriver!

Forresten, i denne samme delen må du inkludere informasjon om at alt du ikke diskuterer med klienten på forhånd forblir på din samvittighet. Du er fri til å gjøre hva du vil hvis han "glemte", "ombestemte seg" eller "vil alt helt annerledes".

Krav til grafisk design av nettsider

Krav til nettsteddesign

Her må du beskrive i generelle termer nettstedets utforming, hva som skal være der og hvilke punkter som bør følges: bedriftsfarger, fonter og så videre. Generelt sett, ikke gå inn i detaljer.

Prosedyren for å godkjenne designkonseptet

I denne delen skremmer du igjen klienten ved å bruke juridiske termer. Du forteller ham at du skal gi ham et nettsteddesign i form av et bilde laget i Photoshop. Han er forpliktet til å se den innen den angitte perioden. Deretter vil vi gi deg redigeringene, og du vil på sin side tenke på om han er en hjort, og du vil koordinere og forstå hvor logiske disse endringene er og om du vil ta på deg "korreksjonen".

Funksjonelle krav

Her beskriver du hva vi faktisk skal gjøre. Vi beskriver den visuelle komponenten. Kapitlet utvikler seg i tre deler: vi beskriver hovedsiden, intern og nettstedsstruktur.

Vær forsiktig. Dette er et viktig punkt hvor det er bedre å skrive mer. Du bør for eksempel ha en «Relaterte nyheter»-seksjon. Hva vil du gjøre: skrive en algoritme som vil beregne hvilke artikler som er nærmest emnet, gi en liste over de fem siste artiklene som er lagt til siden, eller vil forfatteren av teksten ha mulighet til å sette inn lenker i denne blokken uavhengig?

Krav til nettsidepresentasjon

1. Nettstedets struktur: vi beskriver hvilke kategorier (overskrifter) som vil være på nettstedet.
2. Hjemmeside: best med skjematisk bilde og beskrivelse av hovedelementene.
3. Interne sider: samme som i forrige avsnitt. Diagram og beskrivelse av interne sider.

Skal du lage nettbutikk kan du også legge inn et diagram over bestillingssiden, betalingsbekreftelse og så videre her. Beskriv eventuelle sider som vil avvike fra standardmalen.

Krav til innholdsstyringssystem

Bloggen min er ment for folk som lager nettsider ved hjelp av WordPress. Derfor vil jeg ikke legge særlig vekt på dette punktet. Vi opplyser at vi skal bruke denne motoren og det blir nok.

Hvis du skal lage et kontrollsystem selv, så er alt mye mer komplisert. Du må tegne diagrammer på nytt og beskrive generelle krav, styring av seksjoner, innhold og innstillinger. Tegn hvert element som vil være annerledes.

Krav for å dele tilgang

Her ønsker de i hovedsak å finne ut av oss når og hvorfor brukeren trenger registrering. Hvilke seksjoner vi stenger, og hvilke av dem leserne trygt kan bruke. Hvis dette er et visittkortside, informativt eller selgende, vil det være helt åpent, og på VKontakte får du for eksempel tilgang til personlig side har begrenset tilgang og kan kun utføres etter at du har skrevet inn pålogging og passord.

Krav til typer sikkerheter

Krav til informasjonsstøtte

Denne delen er laget ganske enkelt for å vise din egen bevissthet og nok en gang vise kunden hvilken profesjonell du er, hvilke sofistikerte termer du kjenner.

Du vil fortelle dem at du skal lagre dataene på et bestemt sted på serveren, og ikke på skrivebordet eller under puten. Bruk programmeringsspråk.

Du forplikter deg til kun å legge ut bilder i gif-format eller jpg, og sidene vil ikke overstige en viss vekt. Forresten, flott poeng. Så, hvis kunden buler øynene og sier at han trenger noe annet, kan du vise denne varen og si: "Vel, du skrev selv under på vekten, jeg vet ingenting, alt dette er umulig!"

En annen veldig nyttig ting som du også kan nevne her, er å begrense innholdet som tilbys. Du må definere omfanget - gjør du alt innholdet eller lager du regnskap administrator, gi kunden login og passord og la dem finne ut av det!

Programvarekrav

1. Her snakker vi om hosting eller servere. Siden bloggen min er rettet mot skapere som jobber på Timeweb ( https://timeweb.ru ) - alt er veldig enkelt. Hvis du ikke er en av "våre", må du se på spesifikasjoner. For eksempel, noen veldig smarte lager en kul nettside, og prøver deretter å koble den til hosting, men de tekniske spesifikasjonene er så høye at ingen hosting i Russland kan håndtere det. Elementet er nødvendig, men ikke for nybegynnere innen utvikling.
2. Her beskriver vi om portalen vil ha mobilversjon, tilpasset for bærbare enheter eller kan bare åpnes gjennom Google Chrome, og eventuelle forvrengninger i andre nettlesere plager oss ikke i det hele tatt.

Krav til språklig støtte

Vil siden bli laget på to språk eller trenger vi bare russisk?

Krav til ergonomi og teknisk estetikk

Nok en gang nevner vi kort hovedprinsippene for design. Alt vil være klart, enkelt og enhetlig. Logoen vil være synlig overalt og Kontaktinformasjon. Alt er supert, alt er fantastisk.

Krav til prosjektaksept og leveranse

Krav til utfyllingsinformasjon

På dette tidspunktet forteller vi deg hva vi forplikter oss til å gjøre, samt hva kunden må gi oss for at arbeidet skal gå raskere og bedre. Han trenger vanligvis informasjon og bilder.

Vi skriver også igjen at dersom han ønsker å rette eller endre noe, må han lage en lignende avtale på nytt, som du enten signerer eller ikke.

Krav til personell

Hvem kan bruke siden. For eksempel jobber noen selskaper med koder og bryr seg ikke engang med et kontrollsystem for vanlige mennesker. For grunnleggende handlinger på stedet vil det kreves betydelig kunnskap fra personalet. I dette tilfellet er poenget relevant, men i vårt tilfelle er det bare skriblet papir.

Distribusjonsbestemmelsesprosedyre

Hva vil du gi til kunden når arbeidet er ferdig: pålogging, passord, frem og tilbake.

Vi fyller ut prisen på den tekniske spesifikasjonen

Som du allerede forstår, er hovedoppgaven med tekniske spesifikasjoner ikke så mye å forstå, selv om dette er viktig. Og likevel er dens tilleggsfunksjon å skape det rette inntrykket av seg selv og beskytte mot alle slags endringer.

Alt om dette dokumentet burde være imponerende! Hvis du skal sende den til foreløpig gjennomgang per post, så husk å bruke PDF-format. Og klienten vil sannsynligvis ikke torturere seg selv med redigeringer, og han vil tenke på deg som en profesjonell. En liten ting, men en betydelig en. For å konvertere et Word-dokument kan du bruke tjenesten https://smalpdf.com/ru/ .

Ikke glem å sette inn logoen din i bakgrunnen eget selskap eller merkevaren din, og sett inn kontakter. De kan utstedes raskt og effektivt på nettsiden https://logaster.ru .

Vel, det er alt, alt du trenger å gjøre er å laste ned eksemplet som jeg laget spesielt for deg. Det vil hjelpe deg å forstå og ta utgangspunkt i noen malpunkter som ikke vil være annerledes, og du er ferdig.

Nå kan du trygt gå til kunden og ikke være redd for at du skal bli beskyldt for å være ufullstendig.

LAST NED TK MAL

Lykke til i dine bestrebelser og se deg igjen. Abonner på bloggen min og få det beste nyttig informasjon, som definitivt vil komme godt med når du jobber med å utvikle en god nettside for kundene dine.

Mandatet er viktig både for entreprenør og byggherre. Det hjelper entreprenøren til å bedre forstå hva kunden ønsker, å forsikre seg mot plutselige "ønsker" fra byggherrens side, og å fremskynde arbeidet med å fullføre oppgaven. Til klienten - å fortelle nøyaktig hva han vil, for å forenkle kvalitetskontroll, å motta eksakt kostnad tjenester. Vi vil snakke om hvordan du skal utarbeide tekniske spesifikasjoner og hva du skal gjøre med det senere.

Hva er en teknisk spesifikasjon

Tekniske spesifikasjoner er et dokument som gjenspeiler alle kravene til det fremtidige produktet. Den beskriver alle tekniske krav. Vanligvis er tekniske spesifikasjoner kompilert i skjemaet tekstdokument, sjelden - i andre formater.

TK brukes av alle nettstedutviklere. Det hjelper layoutdesignere, programmerere og designere til å bedre forstå kundens krav og skape en ressurs som oppfyller deres forventninger. I tillegg brukes tekniske spesifikasjoner på alle andre områder, for eksempel innen:

• applikasjonsutvikling;
• hus design;
• skrive tekster og annet.

Arbeider du etter tekniske spesifikasjoner, minimeres risikoen for tvister og langvarige rettssaker.

Hvordan utarbeide tekniske spesifikasjoner: struktur av tekniske spesifikasjoner for et nettsted

Før du begynner:

• Bestem hvem som skal utarbeide de tekniske spesifikasjonene
• Forklar begrepene
• Unngå subjektive termer

Ved første øyekast ser det ut til at de tekniske kravene til tomten bør utarbeides av byggherren, fordi han bestiller en ressurs og stiller krav til den. Faktisk bør begge delta i prosessen: klienten gir uttrykk for kravene, og utøveren skriver dem ned spesifikt, nøyaktig og tydelig. For eksempel sier en klient at han ønsker en nettside tilpasset alle brukere, og utvikleren spesifiserer krav til tilpasningsevne for 4 tilgjengelige størrelser – PCer, bærbare, nettbrett, smarttelefoner.

Avklaring av begreper er et svært viktig poeng. Det er tilrådelig å forklare alle høyt spesialiserte termer helt i begynnelsen - klienter vet ikke alltid hva en bunntekst, CMS eller fisk er. Jo enklere og tydeligere forklaringene er, jo klarere vil de tekniske spesifikasjonene være for begge parter.

Subjektive termer kan forårsake unødvendig kontrovers. Ikke skriv "design skal være vakkert" - alles skjønnhetsbegrep er forskjellig. Det samme gjelder kvalitative adjektiver "praktisk", "enkel å bruke", "stor". Bruk spesifikke tall og parametere: beskriv for eksempel fargeskjemaet eller arrangementet av elementer.

Strukturen til de tekniske spesifikasjonene kan være hvilken som helst. Som et eksempel tilbyr vi en enkel struktur av referansevilkår for et nettsted.

Beskriv nettstedet

Fortell oss hvilken type nettsted som trengs, hvem som skal bruke den og hvorfor den opprettes. Skriv for eksempel at du trenger en nettbutikk, en landingsside for å selge et produkt, eller et visittkortnettsted med 10 sider. Angi omtrentlig antall sider hvis du ikke vet det nøyaktige antallet.

Hvis prosjektet har en spesifikk målgruppen, Beskriv det. Dette vil hjelpe deg med å lage en ressurs som vil appellere til kunder - for eksempel ved å bruke passende språk i artikler eller et design som appellerer til unge mennesker eller eldre generasjoner.

Fortell oss om strukturen

Uten en ide om strukturen er det umulig å utvikle et normalt nettsted. Beskriv hvilke sider som vil være på nettstedet, og vis nivåene på hekkingen deres. Dette kan gjøres på forskjellige måter:

• Opplegg
• Bord
• Liste

Hovedsaken er at det til slutt er klart hvilke sider som skal ligge i menyen, hvor de skal lede, og hvilken overordnet side som er for hver seksjon. Vi anbefaler å bruke flytskjemaer – de er enklere og lettere å forstå enn lister og tabeller, og hjelper deg med å evaluere hele strukturen på nettstedet på noen få sekunder.

Et eksempel på en enkel struktur i form av et blokkskjema

Beskriv hva som skal stå på hver side

Fortell oss hvordan du ser sidene på nettstedet. Det anbefales å gjøre dette i prototypeformat for å tydelig demonstrere plasseringen av hvert element. Du kan beskrive kravene med en liste, for eksempel fortelle hva som vil stå i overskriften på nettstedet, hvor tilbakemeldingsskjemaet er plassert, hva som vil stå i den ledige sidekolonnen.

Hvis alle sidene på nettstedet er omtrent like - du for eksempel planlegger å lage et visittkortnettsted, kan du klare deg med to prototyper: for hjemmeside og andre seksjoner. Hvis det er flere grupper med lignende sider - for eksempel seksjoner i en nettbutikkkatalog, en blogg med artikler og en beskrivelse av leverings-/monterings-/installasjonstjenester, er det bedre å lage din egen prototype for hver gruppe.

Et eksempel på en prototype på en hjemmeside-hjemmeside: alt er enkelt, praktisk, forståelig

Sett designkrav

Hvis du har en utviklet layout, flott - du kan ganske enkelt sette den inn i de tekniske spesifikasjonene. Hvis ikke, må du beskrive kravene til fargeskjemaet, bildene som brukes og logoene. For eksempel:

• Angi hvilke bedriftsfarger som kan brukes i design og hvilke nyanser som absolutt ikke kan
• Oppgi en logo som må være til stede i sideoverskriften
• Spesifiser skriftene du vil bruke for sider, menyer, bunntekster og innhold

Hvis det ikke er klare krav - det vil si at klienten selv ikke kan formulere sin visjon om nettstedet, kan du tilby ham flere standardoppsett å velge mellom eller utvikle et oppsett individuelt, og deretter bli enige om det. Dette må gjøres før de tekniske spesifikasjonene godkjennes, ellers kan smaksforskjellen forsinke prosjektet betydelig.

Beskriv kravene til verktøy, kode, hosting, domene

Dette er nødvendig for å vite på forhånd hvilke verktøy du kan jobbe med og hvilke du ikke kan. Beskriv i en egen blokk:

• Hvilken side skal siden være på - WordPress, Joomla, Modex, etc.
• Hvilket programmeringsspråk kan brukes - PHP, JavaScript, HTML, andre
• På hvilken hosting og i hvilken domenesone skal siden ligge? Domenenavn kan bli brukt
• Hvilken programvareplattform kan brukes - .NET, OpenGL, DirectX
• Og så videre

Hvis klienten ikke forstår noe om begrepene som brukes, forklar forskjellen mellom WordPress og Modex, PHP fra HTML, et domene i zone.ru fra et domene i zone.com. Lag sammen kravene slik at de passer oppdragsgiver.

Spesifiser driftskravene til stedet

Som standard skal nettstedet fungere for brukere av alle enheter, inkludert forskjellige nettlesere, tåle hackerangrep og ikke gå ned når 1000 brukere besøker samtidig. Men det er bedre å skrive dette som en egen blokk. Vennligst oppgi:

• Nettstedets lastehastighet som er akseptabel for deg, eller standardverdien er 1–5 sekunder
• Kompatibilitet på tvers av nettlesere – spesifiser i hvilke nettlesere nettstedet skal åpnes
• Respons – spesifiser skjermstørrelsene som designet skal tilpasses og enhetene som brukes
• Motstand mot belastning - hvor mange personer bør være på siden samtidig slik at den ikke "går ned"
• Motstand mot hacker- og dDos-angrep: nettstedet må tåle små angrep

Skriv ned scenariene for drift av nettstedet

Beskriv hvordan brukeren skal samhandle med nettstedet, og hvilke handlinger på ressursen som skal skje som svar. Dette kan gjøres i form av en enkel nummerert liste eller en forgrenet algoritme hvis brukerne har et valg mellom handlinger. Hvis det er mange interaktive tjenester, skriv et scenario for hver av dem.

Et eksempel på det enkleste scenariet for et nettsted

Finn ut hvem som produserer innholdet.

Noen utviklere skriver tekster selv, noen bestiller dem fra tekstforfattere, andre bruker fisk. Vennligst avklar umiddelbart om levering av innhold er inkludert i utviklingstjenesten. Hvis ja, kan du umiddelbart spesifisere ytterligere krav, for eksempel for:

• - ikke mindre enn 95 % ifølge Advego, Text.ru, Content.Watch
• Kvalme (spamming) - ikke mer enn 10% ifølge Advego eller 65% ifølge Text.ru
• Poeng i følge Glavred - minst 6,5 eller 7 poeng

Selvfølgelig er ikke forskjellige tjenester et universalmiddel, men de minimerer risikoen for at de blir "vannaktig" eller overspammet. I tillegg er det slik presise kriterier for å vurdere kvaliteten på tekster fremstår.

Angi frister

Dette blir ofte glemt. De fleste tekniske oppdrag må spesifisere tidsfrister, ellers kan utviklingen trekke ut i flere måneder, seks måneder eller år. Ikke bruk feil ordlyd - for eksempel "om en måned." Skriv nøyaktig dato: 1. desember 2018, for eksempel.

Lifehack: det er bedre å utarbeide mandatet som et vedlegg til samarbeidsavtalen. På denne måten etablerer du alle krav til nettsideutvikling, og ved tvister vil du kunne vinne saken i retten.

Husk: hver teknisk spesifikasjon må inneholde flere hovedblokker:

• Mål og mål - om hvorfor du har laget de tekniske spesifikasjonene generelt, hva du ønsker å gjøre med produktet
• Hvordan skal produktet være - beskrivelse i generelle termer
• Tekniske krav- område av huset, volum av tekst, applikasjonsfunksjonalitet, etc.
• Frister – de er viktige for å unngå tvister.

Et eksempel på utarbeidelse av tekniske spesifikasjoner for programvare

Vi må lage programvare. Tekniske krav er nedenfor.

Beskrivelse: et program for å søke etter artikler etter nøkkelord på alle autoritative nettsteder må angis manuelt.

Hva programvaren skal gjøre:etter å ha gått inn nøkkelord finner artikler på nettsteder som har blitt lagt inn på forhånd som autoritative kilder, viser en liste over treff i dette formatet:

• Link
• Artikkeltittel
• Ledende avsnitt

Hvis det er mer enn 10 treff, må du dele det inn i sider - 10 på hver.

Tekniske krav:programmeringsspråk - uansett, det spiller ingen rolle. Hovedsaken er at programmet deretter kan modifiseres og utgis som en nettjeneste. Ideelt sett bør tjenesten søke på 10 sekunder.

Frister: til 15. september 2018.

Naturligvis kan denne tekniske spesifikasjonen forbedres - vi ga den som et eksempel. Hvordan tror du referansevilkårene kan forbedres for å gjøre det enda klarere, enklere og mer praktisk?

Hva er en teknisk spesifikasjon? Hvordan gjør man det og hva er det for? Eksempler, prøver, tips og anbefalinger.

Det virker hvor flott det er når noen forstår deg perfekt. Du ga ut noen setninger og her er den, akkurat det du forestilte deg. Dessverre fungerer det ikke slik.

Problemet med informasjonsoppfatning er evig. "Knust telefon"-effekten er en vanlig forekomst. Men hva med hvis du rett og slett ikke vet hvordan du skal sette en oppgave? Ja, dette skjer også, og du må jobbe med det på en eller annen måte, men hvordan? For å sikre at resultatene av oppgavene du setter oppfyller dine forventninger, skriv en teknisk spesifikasjon.

Hva er en teknisk spesifikasjon

Teknisk spesifikasjon (eller TOR) er et dokument som inneholder kundens krav til produktene eller tjenestene levert av entreprenøren. Med enkle ord: Jeg vil ha denne måten og den, slik at det er syv gjensidig vinkelrette linjer, og også noen i rødt, og noen i fargeløst (jeg anbefaler å se en video om dette emnet på slutten av materialet).

Design avdeling

Dette dokumentet kan ta opp enten én A4-side eller et helt volum, alt avhenger av oppgavene og ønsker som er inkludert i det. For eksempel kan du skrive en teknisk spesifikasjon for en liten destinasjonsside(én-sides nettsted) eller kompleks programvare med maskinlæring og andre funksjoner.

Hvorfor trenger du tekniske spesifikasjoner?

• Å tildele oppgaver til utøvere.
• For å beskrive i detalj hva du ønsker å få på slutten.
• Å bli enige om rekkefølgen på arbeidet.
• Å evaluere og akseptere arbeidet etter implementering.
• Til...(legg til alternativene dine i kommentarfeltet).

Faktisk er det mye flere formål og fordeler med den tekniske spesifikasjonen enn i listen ovenfor. For meg personlig er hovedoppgaven som tekniske spesifikasjoner løser implementeringen av det jeg trenger med minimale avvik fra forventningene (mine forventninger).

Takket være tekniske spesifikasjoner kan du alltid spørre om implementeringstid, penger og samsvar med de deklarerte egenskapene til det endelige produktet eller tjenesten.

Dette er faktisk et seriøst dokument som er utarbeidet av kunden og entreprenøren. I den grad det er fastsatt straffer og forpliktelser for partene. Det finnes en rekke GOST-er, les mer på Habré.

Utvikling av tekniske spesifikasjoner

Hvis vi snakker om et "voksen" spill, for eksempel tekniske spesifikasjoner for utvikling mobil applikasjon eller nettside, så dette separat arbeid, som det betales mye penger for. Du tiltrekker deg en person, vanligvis en tidligere eller nåværende Chief Technical Officer, og ber ham hjelpe deg.

Skjegg er ikke nødvendig

Avhengig av omfanget av prosjektet/oppgavene samler denne personen alle dine «ønsker», oversetter dem til fagspråk, utarbeider kanskje skisser (hvordan det omtrent skal se ut) og gir deg det ferdige dokumentet. Deretter overleverer du dette dokumentet til utøverne (et team i din bedrift eller outsourcet), blir enige om penger, tidsfrister og setter i gang.

Tips: CTO bør være med på laget ditt, ellers vil du mest sannsynlig gå glipp av noe under implementeringsprosessen. Du har rett og slett ikke nok kunnskap til alt. Den som har vært med på å skrive de tekniske spesifikasjonene kontrollerer den.

Hva består den tekniske spesifikasjonen av?

Alt vil avhenge av malen du velger (litt lenger vil jeg gi noen lenker til maler/eksempler), men det er grunnleggende blokker som er inkludert i de tekniske spesifikasjonene:

1. Beskrivelse av prosjektet/oppgaven. Vi skriver kort hva prosjektet eller oppgaven er som skal gjennomføres.
2. Formål og mål. Hva er målene for prosjektet?
3. Krav. Design, funksjoner, teknologier som trengs.
4. Arbeidsbeskrivelse. Hva, når og hvordan skal gjøres.
5. Kontroll og akseptprosedyre. Hvordan arbeidet vil bli akseptert, hva kan anses som fullført.
6. Applikasjoner. Skisser, skisser, prototyper.

Kostnaden for arbeidet er vanligvis inkludert i et eget vedlegg til kontrakten, men det skjer når partene selv spesifiserer beløpene i de tekniske spesifikasjonene.

Beklager å forstyrre lesingen. Bli med på telegramkanalen min. Ferske kunngjøringer av artikler, utvikling av digitale produkter og veksthacks, alt er der. Venter på deg! La oss fortsette...

Eksempler på tekniske spesifikasjoner

Til tross for at utviklingen av tekniske spesifikasjoner er en kompleks prosess, er den veldig interessant. Din oppgave er å gjenskape bildet av det endelige resultatet, og deretter beskrive det i deler.

Et eksempel på en av mine tekniske spesifikasjoner for en oppdatering Smarte apper TV. Oppgaver for mer komplekse og komplekse produkter ble satt sammen med hjelp av kolleger fra teknisk avdeling. Ikke nøl med å spørre lagkameratene dine om hjelp, involver dem i prosessen så ofte som mulig. Og ikke glem å gi tilbakemelding! Det er ingenting verre enn å legge krefter og tid på noe uten å vite resultatene. Fortell oss hvordan personens råd var nyttige i arbeidet ditt, ellers er det et ensidig spill.

Referansevilkår for utvikling av nettbutikk

Referansevilkår for utvikling av en mobilapplikasjon

Referansevilkår for nettstedet

Referansevilkår for tjenester/oppdateringer

Hvis du trenger flere prøver, er det bare å Google det.

Hovedanbefalingen er å gjøre dette. Problemet er at mors latskap overvinner alle, og det er ikke lett å motstå det. Samle all viljestyrken din og begynn å skrive tekniske spesifikasjoner, bare skriv og ikke stopp. Ikke bekymre deg for at det ikke fungerer "perfekt", jeg skal fortelle deg en hemmelighet, dette skjer aldri. Bare skriv, det blir bedre og bedre for hver gang.

Slik skal det være

Mine første rudimenter for å skrive tekniske spesifikasjoner begynte å dukke opp for flere år siden. Jeg jobbet med designere og satte i oppgave å lage kreative for reklamekampanjer. Jeg ville ha det usammenhengende og det ble til mye bortkastet tid og forklaringer. Over tid begynte innstillingen av oppgaver å bli til en slags semantiske blokker, og deretter til noe som en teknisk spesifikasjon.

For eksempel, for oppgaven "Like-knapp på nettstedet":

1. Beskrivelse: du må opprette en "Liker"-knapp på nettstedet vårt.
2. Formål og mål: brukerinvolvering, utstedelse/vurdering av materiell basert på antall likes.
3. Krav: følgende design (eksempel: en lenke til noe lignende), funksjonalitet (enhver bruker kan rangere bildet og like det, nettstedsystemet tar hensyn til antall likes og endrer produksjonen av materialer), teknologi (tilgjengelig på skrivebordet og mobilversjoner av nettstedet).
4. Arbeidsbeskrivelse: tegne 3 alternativer for knappeoppsett (klardato: 10.01.17), utvikle et system for distribusjon av materialer basert på likes (dato: 14.10.17), funksjonstesting (dato: 16.10.17) ), utgivelse (dato: 17.10.17)
5. Aksept av arbeid: brukeren trykker på like-knappen, systemet teller klikket, og leveringen av materialer endres.
6. Bruksområder: skisser, skisser, eksempler på prosjekter hvor en lignende funksjon fungerer.

Overlat til deg selv de delene og delene av strukturen som er nødvendig for oppgavene dine. For eksempel kan den sjette blokken "Applikasjoner" beskrives i funksjonskrav. Grunnleggende råd: på en eller annen måte, beskriv oppgaven i henhold til strukturen til de tekniske spesifikasjonene. På denne måten vil du ikke gå glipp av noe viktige poeng og spar deg selv fra unødvendige spørsmål, og gjør livet enklere for kollegene dine.

Værsågod

Vi så på hva en teknisk oppgave er og hvordan den skal gjøres. Nå har du muligheten til å sette oppgaver klart og tydelig, formidle tankene dine til andre mennesker og spare tid på tilleggsforklaringer. Jeg håper nå du vet hva du skal gjøre med alt dette.

Referansevilkår "TOR" er et dokument som legges til grunn for utviklingen av ethvert prosjekt. Og uansett hvor kompleks og stor oppgaven er, skal den alltid ledsages av en klar og forståelig teknisk spesifikasjon. Først og fremst trenger kunden dette for å få akkurat det han ønsket å se. Men det er tilrådelig for utøveren å alltid kreve en tydelig uttalt oppgave for å forstå hva de ønsker fra ham. Mange ignorerer det faktum å skrive detaljerte tekniske spesifikasjoner, noe som senere fører til misforståelser, tvister, konflikter og krangel.

Vi anbefaler å lese:

Jeg, forfatteren av denne artikkelen, har i mitt liv klart å være både kunde for flere store prosjekter verdt titusenvis av dollar, og utfører av ikke mindre kostbare bestillinger. Før jeg nådde et seriøst nivå, måtte jeg lese hundrevis av "Tekniske spesifikasjoner" på nytt og komponere flere dusin av mine egne forklaringer for utøveren. Hver gang ble de tekniske spesifikasjonene klarere og tydeligere, noe som gjorde det mulig å få den endelige versjonen av verket slik jeg hadde sett for meg. I denne artikkelen vil jeg gjerne snakke om hvordan du skriver en teknisk spesifikasjon, hva du skal være oppmerksom på først. Jeg skal også fortelle hvorfor det er lurt at kunden og entreprenøren ikke jobber med et godt ord, men dokumenterer alt.

Hvorfor trenger kunden tekniske spesifikasjoner?

Du som kunde har en ide om den endelige versjonen av bestillingen din. Bare livet er slik at hver person kan tolke de samme ordene forskjellig. På grunn av dette oppstår det ofte problemer, spesielt blant kunder og utøvere. Den første forklarte ikke alt, den andre forsto det ikke riktig, og sluttresultatet er helt annerledes enn det alle trodde. En teknisk spesifikasjon er et dokument som du vil akseptere utført arbeid i henhold til. Og hvis noe er gjort feil, noe ikke er sluttført, noe ikke er fullført i sin helhet, så kan du alltid peke på et punkt fra de tekniske spesifikasjonene og underbygge kravet ditt om å fullføre det innsendte prosjektet. Hvis det ikke er noen teknisk spesifikasjon, vil det være praktisk talt umulig å bevise at du sa, skrev, nevnte det. Vi kan si at den tekniske spesifikasjonen er en slags prototype på en serviceavtale. Hvis du jobber med et stort prosjekt, bør mandatet være et tillegg til hovedkontrakten. Når du signerer akseptbeviset for det fullførte arbeidet, må du sammenligne alt med mengden arbeid som ble angitt i den opprinnelige arbeidsoppgaven.

Vi anbefaler å lese:

Hvorfor trenger utøveren tekniske spesifikasjoner?

Først av alt er dette din guide til hva som må gjøres. Ofte kommer kunder på noe under utviklingsprosessen, og prøver å tvinge deg til å utføre unødvendige oppgaver. Vil du jobbe gratis? Det er jeg sikker på ikke. Vennligst presiser at beløpet som ble avtalt helt i begynnelsen, utelukkende gjaldt omfanget av arbeidet spesifisert i referansevilkårene. Noe mer betales separat. Ved levering av prosjektet vil du også kunne rapportere om de tildelte oppgavene og gjennomføringen av dem. Jeg har mer enn en gang støtt på øyeblikk hvor kunden ikke ønsket å akseptere arbeidet, og argumenterte for at det ikke ble fullført helt. Men da de første tekniske spesifikasjonene ble hevet, viste det seg at ingen hadde satt de aktuelle oppgavene i det hele tatt. Nok en gang understreker jeg - ikke arbeid uten tekniske spesifikasjoner, fordi kundens mening kan endre seg oftere enn været, og du må gjøre om alt dusinvis av ganger, kaste bort tiden din og ikke motta ekstra betaling for det.

Hvor skal man begynne å utarbeide en kompetent teknisk spesifikasjon

Så la oss gå videre til hovedtema denne artikkelen. Deretter vil vi snakke om hvordan du utarbeider tekniske spesifikasjoner og hvilke punkter du definitivt bør ta hensyn til. Som du forstår, er hver TK unik, og jeg vil ikke kunne dekke alle aspekter. Derfor vil jeg kun peke på hovedpunktene som bør være i enhver oppgave, uavhengig av prosjektet og kundens virkefelt.

• Generelle bestemmelser i de tekniske spesifikasjonene

Hvis du har et teknisk komplekst prosjekt, eller et veldig spesifikt, så sørg for å gjøre det generelle bestemmelser Det bør være en ordliste - en ordbok med begreper og definisjoner. Det er selvfølgelig veldig bra om kunden og entreprenøren forstår hverandre og forstår spesifikk terminologi uten problemer. Men dette er ikke alltid tilfelle, derfor er det bedre å skrive ned hva visse ord, setninger, betegnelser betyr. Det kan være verdt å forklare noen av setningene dine i ordlisten. La oss si at du bruker en bestemt setning, og tolker den litt annerledes. For å unngå forvirring, sett alt på plass umiddelbart.

Vi anbefaler å lese:

Jeg hadde et tilfelle der manglende forståelse av vilkårene førte til overskridelser av frister i mer enn en måned. Som et resultat led kunden visse tap, men problemet var utelukkende på hans side. Tillat derfor ikke uenigheter. Bestem deg for terminologi før du starter prosjektet.

• Prosjektmål

Det er viktig at referansevilkårene angir hva målene for prosjektet ditt er, hvorfor det opprettes, hvordan det vil fungere og hva det endelige resultatet skal være. Selv om utøveren jobber med en liten del av prosjektet, må han fullt ut forstå strukturen, oppgavene, målene, tekniske løsninger. For hva? Det er ikke alltid det er mulig for entreprenøren å få råd og avklaring fra kunden, og det er ingen vits å be om tolkning av noen småting dersom man kan snu seg mot målene, forstå hva prosjektet går ut på og gjøre jobben sin basert på. på dette.

La meg gi deg et eksempel. Nylig utviklet stort internett prosjektet, og bestilte designet. Designeren ble fortalt hva nettstedet skulle handle om, hvilke funksjoner det skulle ha, hva det skulle gjøre og hvordan nettstedet ville hjelpe folk. Generelt tygget de alt ned til minste detalj, og ikke bare det som gjelder design. Som et resultat mottok vi en layout som praktisk talt ikke krevde noen modifikasjoner, samt et dusin ideer om hvordan vi kan forbedre nettstedet, hva vi skal legge til, hvordan vi kan gjøre det mer attraktivt.

• Funksjonelle krav

Alle kundekrav kan deles inn i to typer: funksjonelle og spesielle. Funksjonelle krav er de implementeringsalternativene du ønsker å se i produktet ditt. Hvis vi bruker eksempelet på en internettside, må du gi entreprenøren eksempler på funksjonelle løsninger fra andre prosjekter som du liker og som du ønsker å se i ditt. For eksempel så de et element de likte teknisk, beskrev det og ga umiddelbart en lenke slik at en person klart kunne forstå hva det handlet om og kunne legge det til grunn.

Vi anbefaler å lese:

Spesielle krav er krav ved hjelp av hvilke de tildelte oppgavene skal oppfylles. Hvis vi igjen legger nettstedutvikling til grunn, kan du spesifisere programmeringsspråket, spesielle parametere layout, koding, bruk av bestemte stiler og alt du vil se. Hvis det ikke er slike krav, la entreprenøren selv bestemme hva og hvordan han vil bruke når du utfører dine tekniske spesifikasjoner.

• Frister

Fristene for gjennomføring skal spesifiseres i kommissoriet. Ta alltid med liten margin slik at utførelseshastigheten ikke påvirker kvaliteten. Det skal i alle fall ikke være en klar frist, og sanksjoner ved manglende overholdelse av disse fristene er beskrevet. Entreprenøren må forstå at dette ikke bare er et punkt i de tekniske spesifikasjonene, men en reell installasjon, uten hvilken han risikerer å pådra seg økonomiske eller andre sanksjoner.

• Rapportering

Hvis prosjektet er stort og krever flere måneder å fullføre, så del opp arbeidet i etapper og sett klare tidsrammer for hver. Etter å ha fullført et bestemt trinn, kreve rapportering om utført arbeid. Dette vil holde utøveren i god form, slik at han ikke går rundt på flere måneder, spiser og drikker forskuddsbetalingen, og så om en uke gjør han alt i rasende fart.

Det skal også foreligge en rapport om det faktisk utførte arbeidet. Hva ble gjort, hvor mye tid som ble brukt på det, hvilke vanskeligheter utøveren møtte osv.

• Ansvar

Hvis du lager en kontrakt, vil det være en klausul om ansvar i den. Hvis du kun er begrenset til de tekniske spesifikasjonene, så er det verdt å beskrive der at entreprenøren er ansvarlig for manglende tidsfrister, ikke levere prosjektet, avsløre nyansene i arbeidet til tredjeparter, noe som medfører tap for deg. Hvilken? For det første i henhold til loven, men du kan også sette dine egne bøter og sanksjoner.

Vi anbefaler å lese:

Og på slutten av denne artikkelen vil jeg gi noen råd basert på min egen erfaring med å utarbeide og motta tekniske oppdrag.

1. De tekniske spesifikasjonene skal være detaljerte. Ikke vær redd for å beskrive hvert element, hvert element, hver knapp. Skriv alt, alt, så detaljert som mulig. Ikke vær redd for å virke grundig. Det er bedre å gjenta noe flere ganger og tygge det over enn å fullføre det senere, betale ekstra og endre det. Den siste tekniske oppgaven jeg skrev handlet om utvikling av en nettside. Det var et stort informasjonsprosjekt. Først utviklet vi et design, og beskrev deretter, basert på det, en funksjonell oppgave for programmerere. Så alle spesifikasjonene viste seg å være 54 sider A4 11 font. Oppdraget kom som et tillegg til hovedkontrakten, som også var på 7 sider. Men jeg vil si at selv i en så detaljert teknisk spesifikasjon kunne jeg ikke ta hensyn til alt, fordi det under utviklingsprosessen ble signert ytterligere tre tilleggsavtaler, som jeg gjorde visse justeringer av den opprinnelige versjonen av oppdraget med.
2. De tekniske spesifikasjonene skal være klare. Ikke nødvendig vann. Alt er til poenget. Hvis du skriver om fristen, så en spesifikk figur, hvis om funksjonalitet, så en liste over funksjonelle løsninger du trenger, etc.
3. Din tekniske spesifikasjon er ikke et dogme, men bare ett av mulige alternativer utførelse av oppgaver. For å være ærlig er jeg ingen programmeringsekspert. Ja, jeg kan tenke gjennom strukturen til prosjektet, dets funksjonalitet, noen tekniske løsninger, men alltid, når jeg utarbeider den endelige versjonen av de tekniske spesifikasjonene, rådfører jeg meg med utøverne. De kan se noe, si sin mening, gi råd optimal løsning henrettelse.

Det var nok alt jeg ville si i denne artikkelen. Å utarbeide tekniske spesifikasjoner er ikke så vanskelig hvis du tydelig forstår hva du ønsker fra entreprenøren. Du kan lese rådet mitt på nytt og bruke det til ditt spesifikke tilfelle. Lykke til!