Cum se scrie o specificație tehnică competentă pentru dezvoltarea site-ului

Vă amintiți legea lui Murphy? Dacă puteți fi înțeles greșit, veți fi înțeles greșit. Acest lucru este valabil nu numai în comunicarea dintre oameni, ci și în crearea de site-uri web. Clientul a dorit un al doilea Facebook și a primit un forum de crescători de câini tineri. Dezvoltatorul nu a ghicit dorința clientului - și-a pierdut timpul.

În acest ghid vă voi spune ce și de ce trebuie să scrieți în sarcina tehnică. În același timp, voi arăta cum să scrieți că nu este necesar ca crearea TK să nu se transforme în timp pierdut.

Pentru toți cei implicați în crearea site-urilor: dezvoltatori, designeri, designeri de layout.
Managerii de proiect.
Șefii studioului digital.
Antreprenorii care intenționează să comande dezvoltarea site-ului.

Care este sarcina și de ce este necesară?

Termenii de referință reprezintă un document în care sunt stabilite cerințele site-ului. Cu cât aceste cerințe sunt mai clare și mai detaliate, cu atât mai bine toți participanții la proces vor înțelege ce ar trebui să fie. Deci, există o șansă tot mai mare ca toți să fie mulțumiți de rezultat.

Obiectivul principal al Termenilor de Referință este de a vă asigura că clientul și interpretul s-au înțeles reciproc în mod corect.

Beneficiile alocării tehnice sunt multe. Pentru fiecare parte are propriile sale.

Înțelegeți ce plătește pentru bani și care va fi locul. Puteți vedea imediat structura, înțelegeți ce și cum va funcționa. Pentru a estima, dacă toate aranjează. Dacă nu - fără probleme să se schimbe chiar înainte de dezvoltare.
Pentru a vedea competența interpretului. Dacă specificația este clară și clară - credibilitatea dezvoltatorului este sporită. În cazul în care este scris terci - este posibil, este necesar să se execute și să nu se uite înapoi.
Să asigure împotriva necinstitului executorului. Când site-ul este gata, puteți să-l verificați pe termenii de referință. Există discrepanțe? Dezvoltatorul trebuie să le repare. Dacă cooperează oficial și contractat - puteți fi chiar forțat prin instanță.
Simplificați înlocuirea artiștilor interpreți sau executanți. Dacă clientul și dezvoltatorul s-au certat și au fugit, crearea site-ului poate dura mult timp. Atunci când există o specificație tehnică detaliată, aceasta poate fi transferată unei noi echipe - va fi atrasă de lucru de multe ori mai repede.
Aflați costul dezvoltării unui produs complex. Pentru a estima termenii exacți și costul dezvoltării unui serviciu web complex, este imposibil de îndată. Mai întâi trebuie să înțelegeți cum va funcționa serviciul și ce funcții va conține. Pentru a face acest lucru, trebuie să pregătiți o sarcină tehnică.

Beneficii pentru interpret:

Înțelege ce dorește clientul. Clienților li se adresează zeci de întrebări, arată exemple, oferă soluții. Apoi scriu totul într-un singur document și sunt de acord. Dacă totul e în regulă, ai dreptate.
Pentru a vă asigura de clienții buni bruscați. Uneori există clienți care doresc să schimbe sarcina la jumătate. Dacă ați convenit și ați semnat ROR, nu vă este frică de acest lucru. În acest caz, chiar instanța va fi de partea dvs.
Arătați-vă competența. O specificație tehnică bine pregătită va arăta clientului expertiza dezvoltatorilor. În cazul în care compania sa îndoit de încrederea dvs. în dezvoltarea site-ului, există îndoieli în legătură cu divorțul.
Câștigați bani. Unele studiouri și dezvoltatori oferă dezvoltarea TK ca serviciu separat.

Pentru a facilita și accelera procesul de dezvoltare. Bunul TK arată structura site-ului, funcțiile și elementele necesare pe fiecare pagină. Când toate cerințele sunt deja în fața ochilor dvs. - rămâne doar să proiectați și să scrieți codul.

Acum să vedem cum să compunem o specificație tehnică bună care să îndeplinească toate aceste funcții.

Specificația tehnică este executorul

În general, sarcina poate fi oricine. "Avem nevoie de un card de site pentru o clinică dentară" - aceasta este o sarcină tehnică. Dar își va îndeplini funcțiile? Cu greu.

Un TOR bun este întotdeauna executor: un manager de proiect sau un dezvoltator. Evident, dezvoltatorul de web înțelege mai mult în crearea site-urilor decât proprietarul unei cafenele sau clinici stomatologice. Prin urmare, va trebui să descrie proiectul.

Asta nu inseamna ca clientul dispare si apare la sfarsit pentru a scrie: "Zbs, eu aprob." El trebuie să participe și la acest proces:

Să cunoască performerul cu compania, produsele și publicul vizat.
Explicați de ce are nevoie de un site web.
Spune ce vrea, împărtăși idei.
Arătați exemple de bune site-uri din punctul său de vedere.
Răspundeți la alte întrebări din partea artistului.

Bineinteles, clientul poate sa-si contureze propria versiune a TOR. Poate că acest lucru va accelera procesul de creare a specificației tehnice finale. Și poate că aveți gunoi, care este aruncat în secret în gunoi.

Scrieți clar și corect

Acest sfat rezultă din obiectivul principal al sarcinii - "Asigurați-vă că clientul și interpretul s-au înțeles corect între ele".

În sarcina tehnică nu ar trebui să existe adjective calitative: frumoase, fiabile, moderne. Ele nu pot fi înțelese în mod clar. Toată lumea are propriile sale concepte de frumusețe și modernitate.

Uită-te. Cineva a considerat acest design frumos și a permis să-l folosească pe site-ul său:

Cum se scrie o specificație tehnică competentă pentru dezvoltarea site-ului

Același lucru - cu formulări vagi care nu înseamnă nimic în sine:

Site-ul ar trebui să-i placă clientului. Și dacă are o stare proastă?
Site-ul ar trebui să fie convenabil. Ce înseamnă asta? Convenabil pentru ce?
Situl trebuie să reziste la sarcini grele. 10 mii de vizitatori? Sau 10 milioane?
Conținutul de experți calitativi. Ei bine, înțelegi.

Verificați dacă există ambiguități în text. Dacă este, rescrieți-o. Limba dvs. ar trebui să fie clară și precisă:

Cu formularea ordonată, să trecem peste structura.

Introduceți informații generale

Toți membrii echipei trebuie să înțeleagă corect ce face compania și cine este publicul țintă. Pentru ca nimeni să nu se confunde, este mai bine să te înregistrezi chiar la începutul misiunii tehnice.

Și merită să specificați scopul site-ului și să descrieți funcționalitatea acestuia într-un cuvânt - pentru a nu obține un magazin online în loc de un blog.

Explicați termeni complexi

Prima regulă de atribuire tehnică - ar trebui să fie clară pentru toată lumea pentru care este destinată. Dacă intenționați să utilizați termeni pe care clientul dvs. nu le înțeleg - proprietarul unui magazin de jucării pentru copii - asigurați-vă că îi explicați. Într-un limbaj clar, nu o copie a Wikipedia.

Descrieți instrumentele și cerințele pentru găzduire

Imaginați-vă că 2 luni ați făcut un loc răcoros. Fiecare etapă a fost coordonată cu clientul - este încântat. Și acum este timpul să vă luați treaba. Arătați zona de administrare și clientul strigă: "Ce este asta? Modeks. Credeam că o vei face pe Wordpress! "

Pentru a evita astfel de probleme, descrieți instrumentele, motoarele și bibliotecile utilizate. În același timp, specificați cerințele pentru găzduire. Indiferent dacă o faceți în PHP - și clientul are un server .NET.

Listați cerințele pentru activitatea site-ului

Site-ul ar trebui să funcționeze în toate browserele versiunilor curente și pe toate tipurile de dispozitive. Da, este evident pentru orice dezvoltator și orice client. Dar este mai bine să scrie pentru a proteja clientul de o activitate lipsită de scrupule.

De asemenea, scrieți cerințele pentru viteza de încărcare a paginii, rezistența la încărcare, protecția împotriva atacurilor hacker și alte lucruri similare.

Specificați structura site-ului

Înainte de a începe desenarea design-ului și aspectului, trebuie să coordonați cu clientul structura site-ului.

Puteți arăta structura listei, puteți desena o diagramă. După cum preferați.

Aceasta este una dintre cele mai importante etape de lucru pe site. Structura este fundația. Dacă nu reușește, site-ul se va dovedi a fi o curbă.

Explicați ce va fi pe fiecare pagină

Clientul trebuie să înțeleagă de ce este nevoie de fiecare pagină și de ce elemente vor fi ele. Există două moduri de a arăta acest lucru.

Prototipul este un mod mai vizibil și mai clar. Artistul desena schițe din fiecare pagină și le aplică la sarcina tehnică. Clientul vede cum va arăta interfața site-ului său viitor și va spune ce îi place și ce trebuie schimbat.

Enumerarea elementelor este o alternativă leneșă la prototip. Doar scrieți ce blocuri ar trebui să fie pe pagină și ce fac.

Descrieți scenarii pentru utilizarea site-ului

Dacă faceți o interfață non-standard, nu este suficient să arătați pur și simplu structura și miniaturile paginilor. Este important ca toată echipa de artiști și clientul să înțeleagă modul în care vizitatorii vor folosi site-ul. Acest scenariu se potrivește perfect. Scenariul este foarte simplu:

Acțiune utilizator.
Acțiunea reciprocă a sitului.
...
Rezultatul.

Desigur, dacă faci o carte de afaceri standard sau împrumut, nu este nevoie să scrii scripturi. Dar dacă există servicii interactive pe site - este foarte de dorit.

Determinați cine este responsabil pentru conținut

Unii dezvoltatori fac imediat site-ul cu conținutul. Alții au pus peștele. Totuși, alții pot scrie texte, dar pentru o taxă suplimentară. Acceptați acest lucru pe țărm și stabiliți în cerințele tehnice, ce conținut trebuie să pregătiți.

Este destul de dificil să se prezinte criterii obiective pentru evaluarea calității textelor. Mai bine nu scrie nimic decât "conținut de calitate, interesant și de vânzare, util pentru publicul țintă". Acest gunoi, nu este necesar de nimeni.

Indicați că tot conținutul trebuie să fie unic, este util. O altă protecție a clientului față de artiștii fără scrupule.

Descrieți designul (dacă puteți)

Ca și în cazul textului, este dificil să se prezinte criterii obiective pentru evaluarea designului. Dacă tu și clientul ați convenit asupra unei scheme de culori - scrieți-o. Dacă are o carte de marcă în care sunt prescrise fonturile, specificați-le.

Scrie despre designul frumos și modern nu este necesar. Nu înseamnă nimic, nu are putere și în general fu.

În loc de ieșire: structura alocării tehnice

Informații despre companie și publicul țintă, obiectivele și obiectivele site-ului.
Glosar de termeni care pot fi de neînțeles pentru client.
Cerințe tehnice pentru amplasarea și funcționarea sitului.
Descrierea tehnologiilor utilizate și lista cerințelor de găzduire.
Structură detaliată a locației.
Prototipuri de pagini sau descrieri ale elementelor care ar trebui să fie pe ele.
Scenarii pentru utilizarea unei interfețe non-standard (opțional).
Lista de conținut pe care dezvoltatorul o face.
Cerințe pentru proiectare (opțional).

Vă recomand, de asemenea, să citiți

Reguli pentru compilarea Specificației privind cerințele software. SRS - următoarea etapă a evoluției misiunilor tehnice. Este necesar pentru proiecte mari și complexe.
Standarde și template-uri TK pentru dezvoltarea de software. Descrieri ale diferitelor GOST și metodologii pentru crearea sarcinilor tehnice.

Am vorbit cu mai mulți dezvoltatori pentru a afla cum fac misiunile tehnice. Îi trec microfonul.

Proiectul trebuie să fie scris de managerul de proiect, în timp util sau de dezvoltatorul însuși (dacă este un agent independent și lucrează singur). Clientul nu înțelege site-urile - nu poate lua în considerare toate aspectele importante.

Eu scriu TK pentru a face clar clientului. Explici termenii, descriu structura, designul, funcționalitatea, tehnologiile folosite. Adesea folosesc prototipuri de pagini, astfel încât clientul înțelege cum va arăta site-ul său. Apoi, creez o sarcină separată pentru designerul de layout - cu detalii tehnice și explicații care îi vor ajuta în munca sa.

Cu cât sarcina este mai complexă, cu atât mai detaliat este TOR. Când am participat la proiecte mari, am văzut lucrări tehnice și 30 de pagini.

În primul rând, TK are nevoie de un client - astfel încât el să înțeleagă ce va fi site-ul său și ce bani vor merge. Dacă se întâmplă ceva greșit - se poate face referire la TK și puteți cere un remake.

TK este managerul de proiect după ce a comunicat cu clientul și a discutat sarcina cu designerul.

Informații despre companie și scopul site-ului.
Cerințe pentru design, culoare.
Tehnologii utilizate și CMS.
Cine se ocupă de conținut - noi sau clientul.
Structura site-ului până la fiecare pagină.
Descrierea fiecărei pagini. Nu facem prototipuri, dar specificăm ce elemente ar trebui să fie pe pagină și cum ar trebui să funcționeze.

Ultimele două secțiuni sunt cele mai importante. Ele oferă o înțelegere a ceea ce va fi locul și cum va funcționa.

Dezvoltatorul sau managerul de proiect ar trebui să scrie proiectul. Este necesar să se indice numai formulări concrete finalizate care nu pot fi contestate. Și evitați adjectivele evaluative: frumoase, eficiente și așa mai departe.

Dacă ceva nu este specificat în termenii de referință - este necesar să se clarifice de la client sau să se pună în aplicare la discreția dezvoltatorului. Dar vă informăm despre acest moment separat față de client. Acest lucru ar trebui discutat în prealabil și chiar mai bine la sfârșitul caietului de sarcini.

Specificația tehnică este întotdeauna, fără ca aceasta să nu aibă loc. "Am nevoie de un magazin online" - aceasta este o sarcină tehnică. Problema este că aceasta este o TK foarte vagă, nu oferă aproape nici o înțelegere.

Sarcina managerului de proiect este să colecteze toate informațiile necesare, să gândească printr-o soluție, să creeze un site în capul tău. Și apoi descrie-o într-un document. De fapt, TK este deja la jumătatea drumului către produsul finit.

Specificația tehnică este standardul cu care dvs. și clienții dvs. veți compara site-ul. Este necesar pentru toți:

Dezvoltatorul este egal cu lucrurile descrise în ToR.
Testerul verifică dacă totul funcționează conform destinației.
Clientul înțelege ce va obține ca rezultat.
Managerul de proiect poate estima costul și calendarul dezvoltării.

Cu un card de vizită sau un magazin, totul este simplu. Este puțin probabil să fie ceva nou, deci este ușor să evaluați valoarea acesteia chiar și în faza de discuție. Dacă facem ceva de genul ăsta, atunci putem face fără TK deloc. Am discutat despre sarcină, am scris un document formal în contract și am făcut-o. Toată lumea este fericită.

Dacă un client are nevoie de un produs complex, nimeni nu poate să estimeze imediat timpul și costul. Mai întâi trebuie să ne dăm seama exact ce este necesar. Apoi, cum va funcționa totul. Apoi, dați seama cum să faceți acest lucru. Și numai după aceea va deveni clar câte ore de muncă vor fi cheltuite pentru implementare.

În TOR, specificăm:

scopul site-ului;
cerințele serverului;
Descrierea site-ului și a elementelor sale individuale;
tehnologii și biblioteci utilizate;
aspectul designului de interfață;
structura și logica tranzițiilor interne;
roluri și scenarii pentru lucrul cu site-ul pentru fiecare dintre ele;
arhitectura bazei de date (opțional).

Sfatul meu pentru cititori este, în primul rând, de a stabili comunicarea. În cazul în care membrii echipei nu se pot înțelege reciproc și clientul - nu vă vor ajuta specificațiile.

Nu-mi place să lucrez la TK. Majoritatea TK-urilor pe care le-am văzut sunt excesiv de greoaie și ineficiente. Pentru mine, situația ideală este atunci când clientul într-un paragraf formulează sarcina site-ului și contextul în care acesta va fi utilizat.

Website pentru Teatrul de Papusi. Sarcina este de a spune vizitatorilor despre teatru și repertoriu, pentru a oferi o oportunitate de a rezerva un bilet on-line.

În acest caz, pentru mine principalul lucru este referința. Voi vedea ce au făcut studiile Lebedev, Nimax, RedCollar, ONY, Sibiriks și alte 10 companii în acest domeniu, voi alege 2-3 proiecte de succes, voi coordona cu clientul și voi fi ghidat de aceștia.

O pagină promoțională pentru vânzarea de henna pentru biotatuazha.

Aici principalul lucru este să faceți un site web cu care puteți ajunge la KPI-ul dorit. Ne uităm, ce site-uri face IT-Agenția și Convertiți Monster și faceți, de asemenea, nu este necesar să inventezi nimic.

Sarcina tehnică este necesară pentru orice proiect. Fiecare TK trebuie să includă:

Obiectivele și sarcinile pe care site-ul le va efectua.
Publicul țintă.
Proiectat pentru detalii, structura site-ului.
Elementele de interfață ale site-ului.

Clientul trebuie să prezinte în mod clar site-ul său în versiunea finită, aspectul său și strategia de dezvoltare ulterioară.

Termenii de Referință nu ar trebui să le spună dezvoltatorilor "cum să facă ce trebuie făcut și ce cod de inserat" - este fundamental greșit. În termeni generali, trebuie să descrieți ce site trebuie să fie, și nu cum să faceți acest lucru. Acest lucru ar trebui luat în considerare cel puțin pentru că clientul, cel mai adesea, nu are experiența necesară.

În ceea ce privește abordarea, ascultăm mereu opinia clientului, dar sunt momente când înțelegem că acest lucru nu trebuie făcut. În acest caz, încercăm să convingem clientul, bazându-ne pe datele experților. În general, salutăm orice viziune a clienților.

Cum pregătim sarcina:

Salvați acest articol și recitiți-l când decideți să comandați un site web. Apropo, o poți face în agenția noastră.

Articole similare

Pagina anterioară

Pagina următoare