Specificații tehnice pentru modernizarea ventilației în institutul de cercetare. Specificații tehnice pentru modernizarea ventilației în centrul de cercetare Specificații tehnice pentru modificarea serverului de stocare

De ce este nevoie de specificația tehnică?

Exemplu de specificații tehnice pentru un programator

Dacă parcurgeți site-uri străine cu solicitarea „document de cerințe de produs”, puteți găsi articole creative și convingătoare despre faptul că specificațiile tehnice (TOR, PRD) sunt moarte. Trebuie să fim parțial de acord cu acest lucru - atunci când dezvoltăm un produs de la zero, prototipul pare mult mai interesant și eficient decât volumele de note ale clienților, care uneori sunt foarte neprofesioniste. Totuși, dacă vorbim despre finalizarea sistemului de bază, atunci lucrurile iau o cu totul altă întorsătură. Ne confruntăm atât cu modificări, cât și cu dezvoltarea personalizată, așa că specificația tehnică este un câine-mâncă-câine, dacă bucătarul nu ne minte. În general, astăzi vorbim despre acele sarcini tehnice clasice care sunt scrise pentru a finaliza cele achiziționate și instalate software. Pe scurt, despre lucruri dureroase.

Fațete ale interacțiunii

Resurse- oameni, mașini, echipamente, mediul de dezvoltare, timp și bani care trebuie utilizați în procesul de implementare a cerințelor. Resursele necesită o planificare și o evaluare clară în etapa de aprobare a specificațiilor tehnice. Stabilirea corectă a priorităților din partea clientului și distribuirea resurselor de muncă din partea vânzătorului permite evitarea depășirii termenelor limită și minimizarea altor riscuri.

Posibilitati- pe scurt, asta este ceea ce vânzătorul (interpretul) poate face de fapt. Să ne uităm la exemplul nostru RegionSoft CRM. Clientul cumpără sistemul și întocmește o specificație tehnică pentru modificare: este necesară crearea unei integrări cu site-ul web și legarea evenimentelor din CRM la numărul de comandă al magazinului online. Aceasta este o cerință realistă, avem resursa și capacitatea de a o face. De asemenea, trebuie să dezvoltați și să atașați un CMS, un sistem de gestionare a conținutului site-ului web, la CRM. Teoretic, putem face acest lucru, dar nu avem posibilitatea de a o face ieftin, iar clientul nu are posibilitatea de a ne plăti suficient pentru ca noi să alocam resurse umane și de timp sarcinii. Drept urmare, clientul refuză această cerință - și nu are nevoie cu adevărat de un CMS, totul este în regulă. Dar despre „lăcomia” TK mai târziu.

Restricții- un set de obstacole care fac dificilă sau imposibilă îndeplinirea sarcinilor din specificațiile tehnice: buget, stiva de tehnologie, probleme de licențiere, interdicții legislative, configurații hardware etc.

Astfel, toate cele patru esențe sunt strâns împletite și determină succesul proiectului în ansamblu. Să ne uităm la fiecare element și să încercăm să evidențiem punctele critice de care trebuie să ținem cont atunci când lucrăm la specificațiile tehnice.

Colectarea și analiza cerințelor

Nimeni nu îți cunoaște compania mai bine decât tine și angajații tăi. Aceasta înseamnă că colectarea și analiza cerințelor este exclusiv sarcina dvs., în care vânzătorul poate ajuta și ghida, dar în niciun caz nu interfera cu procesul. Întrebați dezvoltatorul despre astfel de implementări, aflați ce să căutați și începeți. Apropo, un asistent bun poate fi angajatul tău, care este bine versat în subiectul de specialitate și are o idee aproximativă despre arhitectura software și este familiarizat cu procesul de dezvoltare - el poate acționa ca analist și expert intern, supravegheând procesul de creare a specificațiilor tehnice și de comunicare cu vânzătorul.

Sunt foarte circuit simplu colectarea cerinţelor.

1. Creați un grup de lucru de manageri și specialiști cu experiență din departamente care vor folosi CRM. Spuneți-ne despre soluția pe care intenționați să o alegeți, oferiți acces la versiunea demo.
2. Membrii grupului de lucru ar trebui să transmită informații angajaților și să le ceară sugestiile pentru program nouîntr-o formă complet liberă. Dacă unul dintre angajați nu a întâlnit niciodată un astfel de software și nu este pregătit să vorbească despre utilizarea viitoare, trebuie să-i cereți să-și descrie sarcinile periodice; aceasta este o abordare universală.
3. Fiecare departament identifică apoi ceea ce CRM nu are sau nu măsoară și agregează informațiile.
4. Grupul de lucru analizează cerințele colectate, verifică și elimină intersecțiile. De exemplu, adesea departamentul de vânzări și departamentul de marketing comandă același raport, dar cerințele pot avea nume diferite pentru câmpuri și entități, deși datele din spatele lor sunt aceleași. În consecință, trebuie să ajungem la o formă unificată.
5. Grupul de lucru creează o listă de cerințe și stabilește prioritățile. În această etapă, puteți implica vânzătorul, deoarece el este responsabil pentru resurse. De exemplu, puteți cere să creați un raport personalizat pentru RegionSoft CRM sau puteți comanda integrarea cu site-ul. Acestea sunt sarcini cu termene limită complet diferite; prioritatea este foarte importantă aici.

Anatomia unei specificații tehnice

• Identificarea - definirea cerinţelor, găsirea problemelor care trebuie rezolvate.
• Analiza - analiza cerintelor, identificarea nevoilor cheie, generalizare.
• Adaptare - evaluarea cerințelor în contextul capabilităților CRM și al proceselor de afaceri existente.
• Documentatie - formala si descriere detaliata cerințe, aprobarea specificațiilor tehnice.
• Comunicare cu furnizorul (dezvoltatorul) - interacțiune iterativă cu vânzătorul privind îmbunătățirile în conformitate cu specificațiile tehnice compilate.
• Implementarea este munca furnizorului pentru a crea funcționalitatea necesară. Este mai bine dacă vânzătorul este în contact constant cu clientul - în acest fel produsul final va corespunde cel mai bine viziunii clientului.
• Testare - verificarea funcționalității de către angajații vânzătorului, experții interni ai clientului și utilizatorii finali pentru a stabili conformitatea cu modificările și specificațiile tehnice, precum și operabilitatea sistemului cu modificările.

Nivel de afaceri- cel mai global nivel la care sunt rezolvate sarcini complexe și prioritare. Acest nivel include integrarea, îmbunătățirile și modelarea proceselor de afaceri, dezvoltarea de noi module funcționale. De regulă, aceasta este o dezvoltare intensivă în resurse, cu consultări serioase și apropiate lucrand impreuna cu clientul. De exemplu, la un moment dat în RegionSoft CRM, astfel de modificări personalizate erau contabilitatea depozitului, casa de marcat și producția. Treptat, modificările au fost incluse în lansare, iar ulterior au făcut posibilă crearea unui nou produs pentru magazine cu ridicata, cu amănuntul și hipermarketuri - RegionSoft Retail.

Nivel de utilizator sau grup de utilizatori. La acest nivel sunt implementate sarcini de rafinare a interfeței existente. De exemplu, un utilizator ar putea dori o fereastră cu numărul și starea ultimei comenzi să apară atunci când trece cu mouse-ul peste un client sau un raport personalizat cu o grupare specială de date. Îmbunătățirile la acest nivel necesită mai puțin timp, dar pot fi multe dintre ele - de exemplu, mai multe cerințe din marketing, logistică și suport tehnic.

Nivel de funcționalitate. De multe ori este dificil să-l separăm de cel precedent; aici funcționează un criteriu formal - îmbunătățirea nu este la nivelul afișării a ceva în interfață, ci la nivelul finalizării logicii sistemului. Aceasta poate include cerințe pentru diferite tipuri de sortare, integrare prin chat și capabilități de telefonie.

Nivel de servicii- de fapt, cerințele acestui nivel ar trebui să fie primele incluse în noile build-uri cu remedieri. Acestea sunt sarcini legate de viteza de răspuns a sistemului, funcționarea sub sarcină mare și securitate. ÎN ideal Vânzătorul nu ar trebui să aibă astfel de modificări - software-ul corporativ nu ar trebui să încetinească, să piardă date, să restrângă formulare și să distribuie drepturi de acces de același nivel. Dar dacă apare o cerință și nu are legătură cu paranoia personală a clientului sau cu problemele laterale hardware, merită să-i acordăm o atenție deosebită.

Nivel de tehnologie- ultimul pe listă, dar înaintea celorlalți ca importanță și complexitate. Acestea ar putea fi cerințele clienților legate de platformă, sistem de operare sau dispozitive. De exemplu, o solicitare de construire pentru MacOS. Va fi grozav dacă astfel de cerințe se dezvoltă treptat în versiuni, dar este imperativ să existe remedieri pentru ele. Din solicitările clienților la acest nivel am construit și am adăugat RegionSoft CRM pentru MacOS acces de la distanță folosind tehnologia TRM ca soluție temporară la o cerere rară, dar existentă, pentru o versiune mobilă.

Anatomia unei specificații tehnice este simplă, cel puțin sub formă de schelet. Părțile obligatorii ale specificației tehnice ajută clientul să se concentreze asupra problemei și să formuleze sarcina corect, iar antreprenorul să înțeleagă ce vrea de la el. Apropo, despre înțelegere. Desigur, la începutul postării am mințit puțin, negând consultanții de afaceri ca clasă. Ideea este aceasta: fiecare furnizor lucrează pe piață de câțiva ani (nu vorbim de CRM-uri de o zi), sau chiar de decenii, ceea ce înseamnă că are un set de cazuri în aproape fiecare industrie. În consecință, inginerii, programatorii și oamenii de vânzări sunt familiarizați cu specificul implementării în fiecare tip de companie. Dar, din nou, este important să vă concentrați în mod special pe afacerea dvs.

Pentru cine?În această secțiune, trebuie să descrieți cine va fi utilizatorul final al îmbunătățirii, ce sarcini sunt planificate să fie rezolvate și cu ce frecvență.

Să vă dau un exemplu. O companie implementa CRM și trebuia să lucreze pe o gamă destul de mare de date (câteva zeci de milioane de înregistrări pe lună, câteva sute de mii de înregistrări pe zi). Șeful departamentului de vânzări a solicitat un raport privind încărcarea acestor înregistrări cu o frecvență „zilnică”. Desigur, un astfel de raport, cu sute de utilizatori lucrând simultan, a încărcat sistemul - s-au găsit soluții pentru optimizarea procesului. Deja în timpul lucrărilor, s-a dovedit că vânzătorul a jucat în siguranță și avea nevoie de raport abia la sfârșitul lunii, iar apoi putea fi rulat pe un program pe timp de noapte. Inutil să spun că s-au irosit timp și bani.

Pentru ce? Justificarea necesității de îmbunătățire și locul acesteia în procesul de afaceri. Acest punct este mai necesar pentru clientul însuși, dar este util și pentru vânzător să știe ce alte procese vor fi afectate. Uneori, acest lucru ajută la găsirea unei soluții alternative.

Ce ar trebui să facă? Cel mai informativ bloc - descrie cerințele și așteptările de la sistem. Și aici se întâmplă chiar perlele, miracolele și ciocnirile pe care trebuie să le trimită la bashorg și care, ei bine, îngreunează viața. Există un singur motiv - utilizatorul nu știe ce vrea, ce trebuie făcut. Există un alt submotiv mic - utilizatorul nu poate formula cerințe. Și aici sarcina dezvoltatorului (grup de lucru, analist, dacă există) este de a ajuta la formularea corectă a nevoii, de a selecta o cerință adecvată și de a adapta sarcina în contextul funcționării sistemului. În același bloc trebuie să menționați rezultatul așteptat.

Parametrii de specificație- termene limită, etape de implementare, responsabilitate din partea tuturor părților, contacte necesare etc. De fapt, acesta este un set de lucruri formale importante care fac din document o specificație tehnică. Termenii de referință trebuie conveniți și semnați de părți pentru a evita numeroase schimbări în timpul dezvoltării (se vor întâmpla în continuare, dar într-o măsură mai mică).

În mod ideal, specificația tehnică este întocmită cu participarea activă a vânzătorului, iar rezultatul acesteia este aproximativ următoarea structură:

1. Descrierea cerințelor fiecărui mecanism și a fiecărei funcționalități
2. Descrierea implementării acestei funcționalități
3. Costul lucrării pentru fiecare etapă separat
4. Costul total al lucrării pentru această specificație tehnică
5. Perioadele de timp pentru finalizarea lucrărilor, defalcate pe etape și cu indicarea priorității
6. Descrierea condițiilor de instalare și testarea modificărilor
7. Rezerve cu privire la caracterul exhaustiv al termenilor de referință și al altor condiții

10 reguli scrise în lacrimile unui dezvoltator

Specificația tehnică nu trebuie să fie lacomă. Adesea, o afacere își supraestimează capacitățile sau vrea să obțină „totul deodată”. Această abordare nu este justificată nici din punct de vedere financiar, nici din punct de vedere comercial. Un furnizor, de regulă, nu există de câteva săptămâni (în cazul RegionSoft - 15 ani), și îl puteți contacta după ceva timp, când înțelegeți cu adevărat ce lipsește în CRM.

Un exemplu izbitor de redundanță literalmente de ieri: un client a cumpărat un ERP de la unul binecunoscut firma ruseasca, gândindu-mă că din moment ce contabilitatea funcționează, atunci ERP-ul acestui furnizor va fi bun. ERP s-a dovedit a fi nu numai că nu foarte bun în sine, ci și foarte nepotrivit pentru afacere. Dar RegionSoft CRM cu contabilitatea depozituluiși potrivite pentru producție. Există o soluție: uitați de ERP, plângeți, integrați contabilitatea 1C cu noul CRM și bucurați-vă de implementarea convenabilă. Dar este păcat de banii irositi! Iar clientul necesită integrarea CRM cu ERP. Nu am făcut asta, dar de ce o astfel de risipă, de ce două sisteme relativ similare?

Termenii de referință trebuie să fie realiști și realizabili- atât în ​​ceea ce privește cerințele, cât și termenele limită. Aici este important să ascultați opinia vânzătorului, deoarece el știe exact cât timp va fi alocat cu aceasta sau cutare sarcină. Crede-mă, nu este benefic pentru un dezvoltator să piardă timpul și să mărească termenele - este benefic pentru el să finalizeze cât mai multe proiecte și să o facă bine, pentru a nu suferi o lovitură la adresa reputației sale. În ceea ce privește realismul, este ușor să evitați solicitările de actualizare a CRM la nivelul unui sistem de management al coliziunii: ar trebui să includeți în cerințe ceea ce este cu adevărat necesar pentru acest momentși în viitorul previzibil.

De exemplu, RegionSoft CRM este un program desktop; nu avem un client de browser. A ne cere să creăm o aplicație web pentru o singură companie este inutil, aceasta este o dezvoltare majoră, este în prezent în curs și nu este o dezvoltare posibilă pentru o singură companie. Nu, desigur, totul are prețul său, dar din nou - în cazul general, cerința este imposibil de îndeplinit.

Acest lucru nu trebuie confundat cu situația în care vorbim de dezvoltare personalizată și ideea și logica aplicației sunt schimbate radical; de fapt, crearea unui nou software „pentru tine” este sponsorizată. Dar asta e altă poveste.

Termenii de referință trebuie să fie detaliați. Este necesar să se indice toate detaliile semnificative ale viitorului proiect: de la frecvența de utilizare a programului până la dorințele pentru interfață. Cu cât cerințele sunt mai detaliate, cu atât implementarea și testarea vor fi mai ușoare și mai rapide. Merită în special să acordați atenție detaliilor dacă lucrați într-o anumită industrie (medicină, asigurări, bănci) - o prezentare detaliată a nuanțelor interacțiunii dintre afaceri și program va asigura că furnizorul înțelege sarcina și adaptează rapid sistemul la compania dvs.

Asigurați-vă că acordați atenție formatelor de numere, numelor de câmpuri, prezenței sau absenței listelor derulante, comportamentului butoanelor și sugestiilor și tipurilor de date. Dacă clientul folosește propriile formule, care trebuie incluse în logica operațiunii CRM ( de exemplu, calculul bonusurilor dealerilor), aceste formule trebuie scrise cu o explicație completă a denumirilor lor și a logicii de calcul.

Specificația tehnică trebuie să fie clară și precisă. Formulări vagi, opțiuni de implementare, cerințe neclare - toate acestea sunt o cale către o fundătură. Se întâmplă ca un client, din bune intenții, să scrie în specificația tehnică mai multe opțiuni pentru comportamentul sistemului, apropiate dar nu echivalente. În acest caz, el este sigur că ajută, îndemnând programatorul, dar, de fapt, drumul spre iad este pavat cu bune intenții, dezvoltatorul trebuie să înțeleagă exact de ce este nevoie și va alege el însuși cum să o facă, pe baza asupra caracteristicilor sistemului și stivei de tehnologii utilizate.

Specificația tehnică trebuie să fie scrisă în limbaj uman.Și acest lucru este important, nu, IMPORTANT. Voi evidenția două situații în care problemele lingvistice duc la întârzieri în implementarea proiectului.

1. Clientul încearcă să-și demonstreze cunoștințele tehnice și face construcții de genul: „implementați o fereastră cu un indiciu în corpul calendarului cu capacitatea de a reacționa la evenimentele de apelare...” în loc de „ar trebui să apară o fereastră în calendar. în care puteți marca sarcina ca finalizată.” Dacă dvs. sau expertul dvs. intern nu aveți abilitățile de a scrie texte tehnice, nu folosiți Google - scrieți în cuvinte obișnuite, le înțelegem.

   Termenii de referință nu ar trebui să fie o carte de plângeri. Trebuie să rezolvați problema, nu să o descrieți, acordând atenție fonturilor și uitând de descrierea cerințelor. Specificația tehnică trebuie să conțină nu numai problema în sine, ci și soluția acesteia la nivel de înțelegere - atunci dezvoltatorul o va rezolva la nivel de cod. Comparaţie „Departamentul de vânzări nu planifică bine, pierde cifre, ne luptăm de un an acum”Și „este necesar să se creeze un raport care să salveze lunar valorile vânzărilor planificate și reale, defalcate pe grupe de produse”.

   Termenii de referință trebuie să poată privi în viitor. Ei bine, nu tocmai asta, ci oamenii din spatele lui. Dacă se știe că în curând vor avea loc schimbări în procesele de afaceri, acest lucru trebuie luat în considerare pentru a nu plăti modificări de două ori.

   Termenii de referință nu trebuie să fie birocratici. Dacă ați întocmit vreodată acest document, probabil ați simțit cât de greu este să evitați tentația de a aluneca în birocrație, adăugați cuvinte introductive, fraze stricte și descrieți fiecare punct ca pe un articol al Codului penal (de preferință cu pedeapsă pentru toată lumea pentru încălcare). ). Formulările birocratice maschează o înțelegere incompletă a scopurilor creării specificațiilor tehnice. Responsabilitatea vânzătorului este specificată în contract, iar acolo este scris și bugetul. Nu trebuie să transferați aceste puncte în specificațiile tehnice.

   Termenii de referință trebuie să fie specificații tehnice. Sună paradoxal, dar adesea în loc de specificații tehnice citim scrisori, reclamații, contracte, instrucțiuni nou scrise pentru CRM sau procese verbale ale unei întâlniri. Desigur, este imposibil să lucrezi conform unui astfel de document. Pentru a rămâne la curent cu formă și conținut, folosiți un truc vechi: uitați-vă la termenul cuvânt cu cuvânt. Tehnic înseamnă că dictează modificarea, tehnologia și are ca scop rezolvarea unei probleme prin schimbarea software-ului. Despre asta trebuie să vorbim în contextul software-ului. O misiune înseamnă a pune o întrebare, o problemă, fără sfaturi, sfaturi sau evaluări preliminare. Doar o declarație a problemei.

   S-au terminat poruncile, acum mustrarea

   Pe lângă regulile enumerate, mai sunt câteva lucruri despre care merită să vorbim. Vorbim despre obiective, planuri și așteptări - toate acele elemente care fac ca proiectul să aibă succes, iar relația dintre vânzător și client aproape prietenoasă.

   Specificațiile tehnice trebuie scrise rapid, chiar dacă vă confruntați cu sarcina de a automatiza procesele operator mobil sau un hipermarket mare. Acest lucru se datorează faptului că tehnologiile se dezvoltă cu o viteză extraordinară și chiar și sistemul pe care îl implementați poate supraviețui unei versiuni majore (sau uneori două) în șase luni sau un an și să primească noi funcționalități. Este posibil să trebuiască să vă reconsiderați necesitatea modificărilor și să începeți din nou procesul.

   

   
   În cele din urmă și-a găsit timpul să termine misiunea tehnică. Dar, din păcate, nu au mai rămas dezvoltatori care să-l implementeze.

   Clientul nu cunoaște stiva și limitările tehnice.Și nu ar trebui să știe - aceasta este sarcina vânzătorului, el este cel care evaluează munca după întocmirea specificațiilor tehnice. Clientul nu ar trebui să se aprofundeze în tehnologie și să întrebe la fiecare virgulă dacă vânzătorul poate face asta sau acela. Elaborați o specificație tehnică cuprinzătoare și dezvoltatorul va alege o arhitectură potrivită - adesea chiar mai bună decât ați crede.

   Evaluează-ți bugetul și evită surprizele neplăcute- sarcina aproape comună numărul unu. Nu ar trebui să-l împingi pe vânzător și să-i ceri o evaluare aproximativă a lucrării (bine, cel puțin aproximativ, de la mână, cu ochii, dar ca și la alții, ei bine, în proiecte de acest tip, dar din experiență, ei bine, în cadrul marja de eroare). O evaluare completă a bugetului este posibilă numai după citirea, analizarea și aprobarea finală a termenilor de referință. Dacă dezvoltatorul tău acționează diferit, pregătește-te pentru faptul că revizuirea va costa cel puțin de două ori mai mult.

   Pe baza nevoii obiective de schimbări și extinderi- Am scris mai sus că dezvoltatorul nu dispare și este gata să facă oricând modificări și completări conform cerințelor dumneavoastră. Prin urmare, nu încercați să creați imediat CRM/ERP-ul viselor tale, nu cere de la furnizor un buton „Totul funcționează în timp ce beau cafea” - lucrează în sistem, identifică comentariile critice pentru tine și începe să colectezi cerințe și să desenezi sus specificațiile tehnice.

   Puteți scrie la nesfârșit despre sarcini tehnice; acesta este un adevărat generator nu numai de meme și povești, ci și de dureri de cap. Poți vorbi despre priorități și reguli de proiectare, despre GOST 1989, care face specificațiile tehnice inumane, despre standardele IEEE, care sunt puțin mai bune, despre prototipuri și specificații tehnice care le completează. Dar, în final, aș dori să mă limitez la una, cea mai importantă regulă: o specificație tehnică nu este o regulă de drept, nu GOST și nu o dogmă, prin urmare, dacă o poți îmbunătăți, îmbunătățește-o, dacă poți simplifica simplifică-l, dacă poți să o faci cu grație și ca să placă tuturor, fă-o. Sunt sigur că după aceasta, nimeni nu își va băga nasul la specificațiile tehnice și nu va spune că nu este scris acolo. Sau aproape nimeni.

   Pe tot parcursul lunii decembrie oferim reduceri la RegionSoft CRM și la toate programele noastre proprii. De la 1 decembrie până la 15 decembrie - 15% și termene abrupte pentru rate și închirieri. Nu avem -70% și -90%, pentru că păstrăm prețul licențelor justificat economic și nu îl scoatem din senin.

   Ei bine, dacă aveți nevoie de un sistem CRM (cu sau fără modificare), atunci accesați siteul nostru, există multe despre CRM, avantajele sale și alte software-uri corporative.

   Și da, căutăm mereu parteneri care sunt gata să vândă CRM și alte produse, să modifice și să vândă CRM, să vândă software și să formeze utilizatori. Împărțirea veniturilor este corectă și benefică pentru partener. Vă vom arăta, vă vom spune, vă vom învăța. Scrie la [email protected]

   Diapozitive, diapozitive. Benzi desenate preluate de pe http://www.modernanalyst.com/ și Pinterest. Dacă există o traducere mai bună, vom fi bucuroși să o includem în postare.

Atașez adesea prototipuri de pagini pentru ca clientul să înțeleagă cum va arăta site-ul său. Apoi elaborez o sarcină separată pentru designerul de layout - cu detalii tehnice și explicații care vor ajuta în munca lui.

Cu cât sarcina este mai complexă, cu atât specificația tehnică ar trebui să fie mai detaliată. Când am participat la proiecte mari, am văzut specificații tehnice de 30 de pagini.

Guram Sipki, fondatorul studioului digital Udix Media

În primul rând, clientul are nevoie de specificații tehnice – astfel încât să înțeleagă cum va fi site-ul său și pe ce vor fi cheltuiți banii. Dacă ceva este greșit, se poate referi la specificațiile tehnice și poate cere să fie refăcut.

Specificația tehnică este întocmită de managerul de proiect după comunicarea cu clientul și discutarea sarcinii cu proiectantul.

Clienții mari solicită adesea specificații tehnice foarte detaliate, care descriu fiecare buton. Companiile mici, dimpotrivă, nu le plac documentele meticuloase de 100 de pagini.

Un exemplu de sarcină tehnică pentru îmbunătățirea site-ului web

Informații generale

Denumirea sistemului automatizat

„AS Sbyt”

Client

Executor testamentar

Baza lucrării

Datele planificate pentru începerea și sfârșitul lucrărilor la crearea sistemului

Început lucrări: 01.09.2010

Finalizarea lucrărilor: 31.12.2010

Scopul și scopurile creării sistemului

Scopul sistemului

In dezvoltare sistem automatizat conceput pentru a automatiza procesele de vânzări ale întreprinderii..

Obiectivele creării sistemului

Obiectivele creării unui sistem automatizat

Obiectivele dezvoltării „AS Sbyt” sunt:

1. 3. Caracteristicile obiectului de automatizare

3.1 Procesele de afaceri ale întreprinderii

3.1. 1 Proces de afaceri „Încheierea unui acord”

Va deveni scutul tău; în acest document, dacă se întâmplă ceva, vei putea să arăți cu degetul către un dezvoltator fără scrupule și să ceri ca site-ul tău să fie adus în conformitate cu acesta.

Sarcina tehnică(pe scurt, „TOR”) este un document care reflectă cerințele pentru viitorul dvs. site web cât mai detaliat și fără ambiguitate posibil.

Site-ul este creat tocmai pe baza unor specificații tehnice. Cu cât este mai detaliat și mai clar, cu atât noul dvs. site vă va satisface așteptările.

Termenii de referință pentru crearea unui site web - ca lege, nu ar trebui să permită interpretări și discrepanțe.

Dezvoltatorul face tot ceea ce nu este specificat în specificațiile tehnice la propria discreție.

· Ghidul Administratorului;

· Ghid pentru managerul de conținut;

· Ghid de instalare;

· Ghidul programatorului.

2.20. Organizarea și desfășurarea de formare pentru specialiștii Comitetului de anchetă din cadrul Procuraturii Federației Ruse

Se aplică următoarele cerințe de formare:

· Antreprenorul trebuie să desfășoare cursuri de formare pentru angajații Comisiei de anchetă de la Parchet Federația Rusă format din cel mult 10 persoane.

· Instruirea trebuie să se desfășoare în limba rusă.

· Locurile de instruire sunt asigurate de Client.

· Locul și ora instruirii trebuie convenite cu Clientul.

Instruirea trebuie efectuată pentru toate funcționalitățile Sistemului.

Ca parte a instruirii, este necesar să se desfășoare conținutul informativ al unui site pilot al Inelului de site-uri al Comitetului de investigație din cadrul Procuraturii Federației Ruse.

3.

Exemplu de specificații tehnice pentru îmbunătățirea site-ului web

Important

Pe parcursul procesului de implementare, Antreprenorul trebuie să ofere asistență Clientului în cadrul Programului de Implementare.

6.1.11. În cazul unei slabe pregătiri a personalului Clientului pentru implementare și al necesității de asistență suplimentară din partea Antreprenorului pentru implementarea cu succes a software-ului, trebuie întocmit un protocol suplimentar pentru convenirea prețurilor contractuale pentru furnizarea de informații și lucrări de consultanță.

6.2 Procedura pentru sprijinirea ulterioară a sarcinilor AS „VÂNZĂRI”.

Termenul de referință trebuie să indice complexitatea și costul lucrărilor pentru implementarea cerințelor suplimentare.

6.2.2. Antreprenorul se angajează să mențină o linie telefonică de asistență pentru software.

Fațete ale interacțiunii Înainte de a începe să disecăm procesul de creare a unei specificații tehnice, să vorbim despre patrulaterul în care se află antreprenorul și clientul atunci când demarează proiectul. Cerințe- comportamentul dorit al sistemului, descris de client sau deținătorul procesului, să fie implementat. De regulă, cerințele sunt formate pe baza experienței de muncă și a înțelegerii comportamentului corect al programului.

Aceasta este o informație cheie pentru dezvoltator (vânzător), totuși, în etapa de colectare a cerințelor, apar cel mai mare număr de coliziuni, erori, solicitări inutile etc.

Resurse- oameni, mașini, echipamente, mediul de dezvoltare, timp și bani care trebuie utilizați în procesul de implementare a cerințelor. Resursele necesită o planificare și o evaluare clară în etapa de aprobare a specificațiilor tehnice.

Aceasta poate include cerințe pentru diferite tipuri de sortare, integrare prin chat și capabilități de telefonie.

Nivel de servicii- de fapt, cerințele acestui nivel ar trebui să fie primele incluse în noile build-uri cu remedieri. Acestea sunt sarcini legate de viteza de răspuns a sistemului, funcționarea sub sarcină mare și securitate.

Atenţie

În mod ideal, vânzătorul nu ar trebui să aibă astfel de modificări - software-ul corporativ nu ar trebui să încetinească, să piardă date, să restrângă formulare și să distribuie drepturi de acces de același nivel. Dar dacă apare o cerință și nu are legătură cu paranoia personală a clientului sau cu problemele din partea hardware, merită să îi acordați o atenție sporită.

Nivel de tehnologie- ultimul pe listă, dar înaintea celorlalți ca importanță și complexitate.

Microsoft World sau Microsoft Excel.

Personal, folosim produse software speciale atunci când dezvoltăm o pagină de destinație.

Cu ajutorul lor, puteți crea rapid și ușor proiecte chiar și pentru site-uri complexe - de exemplu, Balsamiq. Cu toate acestea, modul în care realizăm întregul prototip a fost deja descris în articol.

Pe subiect: Prototiparea site-ului web: creare, instrumente și programe.

Proiectarea pre-proiect poate fi realizată împreună cu dezvoltatorul sau transferată complet pe umerii acestuia.
Principalul lucru, nu uitați, atunci este convenit și semnat de ambele părți.

LIFE HACKS PENTRU ELABORAREA TOR

Aceste puncte se aplică în mod egal atât pentru completarea brief-ului, cât și pentru întocmirea specificațiilor tehnice.

Și în ele vă voi spune mici trucuri despre cum să întocmiți specificații tehnice pentru un site web și să ușurați viața deja dificilă a unui antreprenor:

1.

Asigurați-vă că clientul și interpretul se înțeleg corect.”

Termenii de referință nu trebuie să conțină adjective de calitate: frumos, de încredere, modern. Ele nu pot fi înțelese clar. Fiecare are propriile concepte despre frumusețe și modernitate.

Uite. Cineva a crezut că acest design este frumos și a permis să fie folosit pe site-ul lor:

Același lucru se întâmplă cu formulările vagi care nu înseamnă nimic în sine:

• Clientului trebuie să-i placă site-ul. Dacă este într-o dispoziție proastă?
• Site-ul ar trebui să fie convenabil. Ce înseamnă? Convenabil pentru ce?
• Locația trebuie să reziste la sarcini grele. 10 mii de vizitatori? Sau 10 milioane?
• Conținut de experți de înaltă calitate. Ei bine, ai înțeles ideea.

Verificați dacă există ambiguități în text. Dacă există, rescrieți-l.

Te-ai decis să comanzi un site web (aka landing page)? După cum arată practica, nu este atât de simplu. Sute de clienți, după ce și-au văzut site-ul terminat, descoperă că nu le convine: designul este greșit, aspectul este șchiopăt, textele sunt greșite, au fost adăugate o grămadă de funcții inutile.

Pentru a evita astfel de consecințe, aveți nevoie de specificații tehnice pentru dezvoltarea site-ului web.

AM NEVOIE?!

Nu contează cine va conduce site-ul - tu însuți, ruda ta, freelanceri pentru o plată modestă, o companie specializată pentru o sumă imensă de bani...

Trebuie să existe specificații tehnice pentru site.

De exemplu, puteți cere să creați un raport personalizat pentru RegionSoft CRM sau puteți comanda integrarea cu site-ul. Acestea sunt sarcini cu termene limită complet diferite, prioritatea este foarte importantă aici. După ce cerințele au fost colectate, analizate și convenite cu angajații și managementul, puteți începe să creați o specificație tehnică.
Puteți cere formularul vânzătorului sau îl puteți crea singur - în orice caz, există câteva reguli absolute, a căror respectare vă va scuti pe dvs. și furnizorul dvs. de CRM dureri de cap.

Anatomia unei specificații tehnice

Dacă vorbim despre procesul de creare a unei specificații tehnice, există mai multe etape. Trecerea lor secvențială conduce clientul la îmbunătățirea dorită.
Aici sunt ei.

Aici este important să ascultați opinia vânzătorului, deoarece el știe exact cât timp va fi alocat cu aceasta sau cutare sarcină. Crede-mă, nu este benefic pentru un dezvoltator să piardă timpul și să mărească termenele - este benefic pentru el să finalizeze cât mai multe proiecte și să o facă bine, pentru a nu suferi o lovitură la adresa reputației sale.

În ceea ce privește realismul, evitarea solicitărilor de upgrade CRM la nivelul unui sistem de management al coliderului este simplă: ar trebui să includeți în cerințe ceea ce este cu adevărat necesar în acest moment și în viitorul apropiat.

De exemplu, RegionSoft CRM este un program desktop; nu avem un client de browser. A ne cere să creăm o aplicație web pentru o singură companie este inutil, aceasta este o dezvoltare majoră, este în prezent în curs și nu este o dezvoltare posibilă pentru o singură companie.

Numele complete și scurte ale sistemului informațional

Numele complet al sistemului este site-ul oficial al Comitetului de anchetă din cadrul Parchetului Federației Ruse.

Numele scurt al sistemului este „SKP Site”, „System”, „Site”.

1.2. Numele clientului sistemului și detaliile acestuia

Nume: Comitetul de anchetă din cadrul Procuraturii Federației Ruse

Locație:

Info

Moscova, strada Tekhnicheskiy, clădirea 2

Adresa reala: A

Persoana de contact cu clientul:

Telefon: (4, (4;

Adresa de e-mail

1.3. Lista documentelor pe baza cărora este creat sistemul

Contractul de stat Nr.________________ din data de ___ ___________ 2010

1.4.

Determinat în conformitate cu Acordul.

2. Cerințe de sistem

2.1.

Data de plată

Număr de plată

Numărul de plată în sistemul de plată

Suma de plata

1. Selectați liniile fișierului de transfer de date
2. Începeți să parcurgeți liniile fișierului de transfer de date
3. Citiți linia fișierului de transfer de date
4. Obțineți codul contractului din linia fișierului de transfer de date
5. Găsiți elementul corespunzător după cod în directorul „Acorduri contraparte”; dacă elementul nu este găsit, afișați mesajul „Nu a fost găsit un acord cu codul...”
6. Dacă elementul este găsit, adăugați o linie la tabelul de valori, unde: „Acord” - elementul găsit, „Data” - „Data_plat”, „Număr de plată” - „Nomer_plat”, „Suma” - „Summa_plat”
7. După ce ați primit ultima linie a fișierului de transfer de date, terminați ciclul
8. Pentru fiecare rând al tabelului de valori, creați un document „Ordin de plată pentru primirea fondurilor”.

Când completați un brief sau întocmiți termenii de referință pentru designul unui site web, nu lăsați niciun gol în acesta.

Trebuie să înțelegeți că „La latitudinea dezvoltatorului” înseamnă „fac tot ce vreau” sau „Tot ceea ce nu este specificat se face la discreția interpretului”. Și credeți-mă, aceasta nu este doar o lacună, ci o întreagă fereastră către Europa pentru dezvoltator.

Și, desigur, acest lucru nu se întâmplă întotdeauna.

Dacă întâlniți un specialist competent, atunci nu trebuie să vă faceți griji cu privire la rezultat.

Dar aici apare o altă problemă: el o poate face corect, dar nu vă va plăcea pur subiectiv. Și totul va fi ca în gluma cunoscută de mulți dezvoltatori:

SCURT DESPRE LUCRURILE PRINCIPALE

Cu siguranță nu veți regreta timpul petrecut cu elaborarea și acordul asupra termenilor de referință pentru crearea unui site web sau a unei pagini de destinație.

La urma urmei, acesta este cel mai bun instrument al tău pentru monitorizarea și rezolvarea dezacordurilor care apar în acest proces.

Când faceți clic pe un anumit district, acesta ar trebui să acceseze o pagină cu o descriere text a acestui district.

· Blocul „Blogul președintelui”- ar trebui să fie o listă cu cele mai recente trei subiecte create pe blog sub forma titlului subiectului și a datei publicării acestuia. Numele subiectului va fi un link care, atunci când dai clic, ar trebui să te ducă la o pagină de blog care descrie acest subiect. Acest bloc ar trebui să conțină și un videoclip care poate fi redat fără a părăsi pagina principala. Videoclipul ar trebui să aibă un link „Comentarii”, care reprezintă numărul de comentarii la imaginea video dată. Linkul „Comentarii” ar trebui să ducă la o pagină de blog cu comentarii la videoclipul trimis.

Subsolul trebuie să conțină o casetă de căutare, informații despre drepturile de autor etc.

2.3.

Scurt este un chestionar cu întrebări despre conținut, design, capabilități tehnice Viitorul tău site web.

Desigur, un brief detaliat semnat de ambele părți poate înlocui termenii de referință.

La urma urmei, acesta este practic același lucru, singura diferență este că brief-ul este viziunea ta, iar specificația tehnică este documentul final bazat pe brief-ul tău și pe comentariile dezvoltatorului în sine.

Dacă anumite puncte provoacă dificultăți, atunci nu ezitați să adresați dezvoltatorului întrebări precum „Ce înseamnă asta?”, „Cum va afecta acest lucru funcționarea site-ului meu?”, deoarece nu toți dezvoltatorii înțeleg același lucru ca și dumneavoastră.

Fie în coloana „ Informații suplimentare„Asigurați-vă că indicați toate dorințele dvs. care nu au fost incluse în răspunsurile la întrebări.

Dacă această coloană lipsește, adăugați-le pur și simplu la sfârșitul briefului.

VK, Google, Facebook.

3.2.2 V cont personalîn secțiunea comenzi, adăugați un câmp pentru a adăuga un cod promoțional.

3.2.3 În loc de pagina pe care utilizatorul o primește după o solicitare de recuperare a parolei (cum ar fi name.com/bitrix/admin/index.php?change_password=yes&lang=ru&USER_CHECKWORD=), creați o pagină (cum ar fi name.com/login/forgot /change_password=yes&lang =ru&USER_CHECKWORD=), care va afișa conținutul site-ului, va avea câmpul „E-mail la înregistrare”, o linie de control, o nouă parolă, confirmarea parolei și un buton de trimitere a datelor.

3.2.4 Când adăugați articole în coș, ar trebui să fie afișat un mesaj care indică faptul că articolul a fost adăugat în coș.

3.2.5 Adăugați un mesaj de ieșire care indică faptul că parola nu se potrivește cu parametrii de securitate la înregistrarea unui nou utilizator.

„_” ______________ 2010

Treptat, modificările au fost incluse în lansare, iar ulterior au făcut posibilă crearea unui nou produs pentru magazine cu ridicata, cu amănuntul și hipermarketuri - RegionSoft Retail.

Nivel de utilizator sau grup de utilizatori. La acest nivel sunt implementate sarcini de rafinare a interfeței existente. De exemplu, un utilizator ar putea dori o fereastră cu numărul și starea ultimei comenzi să apară atunci când trece cu mouse-ul peste un client sau un raport personalizat cu o grupare specială de date.

Relucrarea la acest nivel durează mai puțin, dar pot fi multe dintre ele - de exemplu, mai multe cerințe de la departamentele de marketing, logistică și suport tehnic.

Nivel de funcționalitate. De multe ori este dificil să-l separăm de cel precedent; aici funcționează un criteriu formal - îmbunătățirea nu este la nivelul afișării a ceva în interfață, ci la nivelul finalizării logicii sistemului.

Dacă scrie terci, poate că ar trebui să fugi și să nu te uiți înapoi.

• Asigurați împotriva necinstei interpretului. Când site-ul este gata, acesta poate fi verificat conform specificațiilor tehnice. Există neconcordanțe? Dezvoltatorul este obligat să le repare. Dacă colaborezi oficial și ai încheiat un acord, poți chiar să îl forțezi prin instanță.
• Simplificați înlocuirea interpreților. Dacă clientul și dezvoltatorul s-au certat și au fugit, crearea site-ului poate dura mult timp. Când există o specificație tehnică detaliată, aceasta poate fi transferată unei noi echipe - se vor implica în muncă de multe ori mai repede.
• Aflați costul dezvoltării unui produs complex. Este imposibil să estimați imediat momentul exact și costul dezvoltării unui serviciu web complex. Mai întâi trebuie să înțelegeți cum va funcționa serviciul și ce funcții va avea.

Există acces root, propriile adrese IP, porturi, reguli de filtrare și tabele de rutare.

Google PageSpeed ​​​​Insights este serviciu gratuit recomandări pentru site-uri web pentru a accelera afișarea paginilor în browserul utilizatorului (https://developers.google.com/speed/pagespeed/insights/).

Optimizarea pentru motoarele de căutare (sau SEO) este un set de măsuri de optimizare internă și externă pentru a crește poziția site-ului în rezultatele motoarelor de căutare pentru solicitările specifice ale utilizatorilor.

Optimizarea site-ului extern este înregistrarea unui site web în motoare de căutare, promovare în în rețelele sociale, link building prin atragerea de link-uri din alte resurse către site-ul promovat, publicitate banner, publicitate contextuală.

Optimizarea internă a site-ului este optimizarea textului, URL-urilor, editarea structurii site-ului, legarea, verificarea răspunsurilor serverului.

Materiale disponibile Link-uri către site-urile dvs. preferate, precum și broșuri, reviste, fotografii - orice, sau poate aveți o carte de brand gata făcută. Atașat ca arhivă separată. Rezoluție minimă și dispozitive de afișare În acest paragraf, indicați de pe ce dispozitive intenționați să vizualizați site-ul - PC-uri, laptopuri, smartphone-uri... Monitoare PC de la 19 la 27 inch; Laptop-uri de la 15,6 la 17,3 inchi; Smartphone-uri de la 3,5 la 6 inchi; Tablete de la 7 la 12 inci Am nevoie versiune mobila? Da CERINȚE FUNCȚIONALE Set aproximativ de module (pentru utilizatori) Această secțiune ar trebui să enumere toate funcţionalitate, pe care doriți să-l vedeți pe site.

Acesta ar putea fi un coș de cumpărături, filtre de catalog bazate pe diverși parametri, posibilitatea de a plasa o comandă online, a lăsa o cerere pentru apel înapoi, abonați-vă la newsletter și orice alte opțiuni Catalog filtre după preț, alfabetic, după producător.
CRUпtCj9B:s»XVzhb╟▌╤└u╟J_■E╘Dj»J■╛EХHJя(gTT┬Pb╟▌╤└u╟╛#╜┘al+Ka Kqяk3┐ⴐ┙┙²├ █ ts╜IWA▓BOь└vOZb╟▌╤└u╟╛#╜┘al+KaXG[ b:ьVzhb╟▌╤└u╟╛#╜┘al+KaXG[ b:ьVzhb╟▌╤└u╟╛#╜┘al+KaXG[ b:ьVzhb╟▌╤└u╟╛#╜┘al+KaXG[ b:ьVzhb┕ ╜ ┘al+KaXG[ b:bVzhb╟▌╤└u╟╛#╜│ts&V█7┬m3aqNYJy╕°Vzhb╟▌╤└u╟╛#╜┘b:+Vzhb┕u┕ ╛ #╜┘al+KaXG[ b:bVzhb╟▌╤└u╟╛#╜┘al+KaXG[ b:bVzhb╟▌╤└u╟╛#╜┘al+KaXG[ b:bVzhb╥u╬╥╥ ≈≈K&ОQТе╦▒'%[н╓≥Lк"[Ц(b╖~ы╚б╖~ы╚б╖~ы╚б╖~ы╚б╖~ы╚б╖~у╚б╖~у╖~ы╚б╖~ы╚б╖~ы╚б╖~ы╚б╖у╖ ╚b╖~y╚b╖~y╚b╖~y╚b╖~y╚b╖~y╚b╖~y╚b╖~y╚b╖~y╚bD'═\┘*Nл┐ ⌡ ©Tw╦|╒T⌠ZZA╙┼r≤⌠ьЧ≈D7i$╔≥ Н∙?БjЛ?Ч╜∙╤SQ≥╒°еНФх═с≈D7i$╔≥ Н∙?БjЛ?Ч╜∙╤SQ≥╒°еНФх═с┬├ы═с┬├ы═с┬├6L ЯE∙ rrмVC╪ ┬7 ┴+iSo(╦°rБ╒┴■E4SCg┬╨ z╖ ┘╤m°с÷Уm╦Wыmdр'%R^&╔gt╖yхDA]zт╪L╝i▌▀s)M²E+H ©OJ) %j ┼╖`СsА≈K▐ф²Yч▐Hd╟Fг╬lн∙╥е#⌡и<ТC▐╡И&d╨JГ!─Sj║·K,s┼#m ╓⌡JГн IOLЬ©h?ОeН╡▐┌ъHЙmwд$©aЗ$ёу°Н≤gт.bZ┐}Э1црn▄т≈фГ?TA<э:р▓T<кГ║2ic╖▀Иqf⌠Pсс▀32нЫ╘▌n-«÷0i╦▓Q:⌠^%5#⌡Н⌡│ вЬ└%N╙Оtб}8яца╨з≤[╖┐╕■╡╒4╞▄G√≥оЖNa╡vсM╔)9╘д≈ib╕╝■ i├{≈²5╨∙∙╣ф╒▓Цz²┌Ф╤I√HaО2┬б=└Б╦F∙P»гЙz&╔Р3{ ёS÷_н_g7⌡г$Н╜чk┐(ЗQэH▓З╨?.

Îți amintești legea lui Murphy? Dacă poți fi înțeles greșit, cu siguranță vei 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, dar a primit un forum pentru tinerii crescători de câini. Dezvoltatorul nu a ghicit ce dorea clientul - și-a pierdut timpul.

În acest ghid vă voi spune ce și de ce trebuie să scrieți în termenii de referință. În același timp, vă voi arăta cum să nu scrieți, astfel încât crearea specificațiilor tehnice să nu se transforme în timp pierdut.

Articolul va fi util:

• Pentru toți cei implicați în crearea site-ului web: dezvoltatori, designeri, designeri de layout.
• Manageri de proiect.
• Șefii studiourilor digitale.
• Antreprenori care intenționează să comande dezvoltarea site-ului web.

Pentru a face materialul util, am adunat comentarii de la mai mulți dezvoltatori, designeri, manageri de proiect și proprietari de studiouri digitale. Pe cele mai valoroase le-am adăugat la finalul articolului. Hai să aflăm.

Ce este o specificație tehnică și de ce este necesară?

O specificație tehnică este un document care stabilește cerințele pentru șantier. Cu cât aceste cerințe sunt mai clare și mai detaliate, cu atât toți participanții la proces înțeleg mai bine cum ar trebui să fie. Aceasta înseamnă că șansa ca toată lumea să fie mulțumită de rezultat crește.

Scopul principal al specificației tehnice este de a se asigura că clientul și antreprenorul se înțeleg corect.

Sunt multe beneficii din specificațiile tehnice. Este diferit pentru fiecare parte.

Beneficii pentru client:

• Înțelegeți pentru ce plătește bani și cum va fi site-ul. Puteți vedea imediat structura, puteți înțelege ce va funcționa și cum. Află dacă totul ți se potrivește. Dacă nu, nu este nicio problemă să îl schimbați înainte de a începe dezvoltarea.
• Vedeți competența interpretului. Dacă termenii de referință sunt clari și precisi, încrederea în dezvoltator crește. Dacă scrie terci, poate că ar trebui să fugi și să nu te uiți înapoi.
• Asigurați împotriva necinstei interpretului. Când site-ul este gata, acesta poate fi verificat conform specificațiilor tehnice. Există neconcordanțe? Dezvoltatorul este obligat să le repare. Dacă colaborezi oficial și ai încheiat un acord, poți chiar să îl forțezi prin instanță.
• Simplificați înlocuirea interpreților. Dacă clientul și dezvoltatorul s-au certat și au fugit, crearea site-ului poate dura mult timp. Când există o specificație tehnică detaliată, aceasta poate fi transferată unei noi echipe - se vor implica în muncă de multe ori mai repede.
• Aflați costul dezvoltării unui produs complex. Este imposibil să estimați imediat momentul exact și costul dezvoltării unui serviciu web complex. Mai întâi trebuie să înțelegeți cum va funcționa serviciul și ce funcții va avea. Pentru aceasta trebuie să pregătiți specificații tehnice.

Beneficii pentru interpret:

• Înțelegeți ce își dorește clientul. Clientului i se pun zeci de întrebări, sunt prezentate exemple și i se oferă soluții. Apoi ei notează totul într-un singur document și cad de acord. Dacă totul este în regulă - ură, ai înțeles corect.
• Asigurați-vă împotriva dorințelor bruște ale clientului. Uneori dai peste clienți care doresc să schimbe sarcina la jumătate. Dacă ați fost de acord și ați semnat termenii de referință, nu vă este frică de acest lucru. Dacă se întâmplă ceva, chiar și instanța va fi de partea ta.
• Arată-ți competența. O specificație tehnică bine pregătită va arăta clientului expertiza dezvoltatorilor. Dacă compania s-a îndoit dacă să aibă încredere în dvs. cu privire la dezvoltarea site-ului web, îndoielile vor fi cel mai probabil risipite.
• A castiga bani. Unele studiouri și dezvoltatori oferă pregătirea specificațiilor tehnice ca serviciu separat.

• Facilitează și accelerează procesul de dezvoltare. O specificație tehnică bună indică structura site-ului, funcțiile și elementele necesare pe fiecare pagină. Când toate cerințele sunt deja în fața ochilor tăi, tot ce rămâne este să proiectezi și să scrii codul.

Acum să ne dăm seama cum să creăm o specificație tehnică bună care să îndeplinească toate aceste funcții.

Caietul de sarcini este întocmit de executant

În general, oricine poate întocmi specificații tehnice. „Avem nevoie de un site web pentru cărți de vizită pentru o clinică dentară” - aceasta este deja o sarcină tehnică. Dar își va îndeplini funcțiile? Cu greu.

O specificație tehnică bună este întotdeauna pregătită de către executant: un manager de proiect sau un dezvoltator. Evident, un dezvoltator web înțelege mai multe despre crearea de site-uri web decât proprietarul unei cafenele sau al unei clinici dentare. Prin urmare, va trebui să descrie proiectul.

Asta nu înseamnă că clientul dispare și apare la sfârșit pentru a scrie: „Zbs, aprob.” El ar trebui să participe și la proces:

Desigur, clientul își poate schița propria versiune a specificațiilor tehnice. Poate că acest lucru va accelera procesul de creare a specificațiilor tehnice finale. Sau poate că rezultatul va fi gunoiul care va fi aruncat în secret la gunoi.

Scrieți clar și corect

Acest sfat rezultă din scopul principal al termenilor de referință - „Asigurați-vă că clientul și contractantul se înțeleg corect.”

Termenii de referință nu trebuie să conțină adjective de calitate: frumos, de încredere, modern. Ele nu pot fi înțelese clar. Fiecare are propriile concepte despre frumusețe și modernitate.

Uite. Cineva a crezut că acest design este frumos și a permis să fie folosit pe site-ul lor:

Același lucru se întâmplă cu formulările vagi care nu înseamnă nimic în sine:

• Clientului trebuie să-i placă site-ul. Dacă este într-o dispoziție proastă?
• Site-ul ar trebui să fie convenabil. Ce înseamnă? Convenabil pentru ce?
• Locația trebuie să reziste la sarcini grele. 10 mii de vizitatori? Sau 10 milioane?
• Conținut de experți de înaltă calitate. Ei bine, ai înțeles ideea.

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

• Site-ul trebuie să se încarce rapid → Orice pagină de pe site trebuie să aibă mai mult de 80 de puncte în Google PageSpeed ​​​​Insights.
• Încărcături grele → 50 de mii de vizitatori în același timp.
• Pagina principală afișează o listă de articole → Pagina principală afișează o listă cu ultimele 6 articole publicate.
• Interfață de abonament minimalistă și ușor de utilizat → Câmpul „Lăsați e-mailul” și butonul „Abonare” → *schiță desenată*.

Am rezolvat formularea, să trecem peste structura.

Vă rugăm să furnizați informații generale

Toți membrii echipei trebuie să înțeleagă corect ce face compania și cine este publicul ei țintă. Pentru ca nimeni să nu se încurce, este mai bine să scrieți acest lucru chiar la începutul termenilor de referință.

De asemenea, merită să indicați scopul site-ului și să descrieți funcționalitatea acestuia pe scurt - pentru a nu ajunge la un magazin online în loc de un blog.

Explicați termenii dificili

Prima regulă a termenilor de referință este că trebuie să fie înțeles de toată lumea căruia îi este destinat. Dacă urmează să folosiți termeni pe care clientul dvs., proprietarul unui magazin de jucării pentru copii, s-ar putea să nu îi înțeleagă, asigurați-vă că îi explicați. Într-un limbaj clar, nu copy-paste de pe Wikipedia.

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

Imaginează-ți că ai petrecut 2 luni creând un site web grozav. Fiecare etapă a fost coordonată cu clientul – acesta a fost încântat. Și acum este timpul să predați munca. Arăți panoul de administrare, iar clientul strigă: „Ce este asta? Modex?! Am crezut că o vei face pe WordPress!”

Pentru a evita astfel de probleme, descrieți instrumentele, motoarele și bibliotecile utilizate. În același timp, indicați cerințele dvs. de găzduire. Nu se știe niciodată, o vei face în PHP - iar clientul are un server în .NET.

Enumerați cerințele pentru funcționarea site-ului

Site-ul trebuie să funcționeze în toate browserele actuale și pe toate tipurile de dispozitive. Da, acest lucru este evident pentru orice dezvoltator și pentru orice client. Dar este mai bine să scrieți pentru a proteja clientul de munca făcută cu rea-credință.

Scrieți aici cerințele pentru viteza de încărcare a site-ului, rezistența la încărcare, protecția împotriva atacurilor hackerilor și lucruri similare.

Specificați structura site-ului

Înainte de a începe să desenați designul și aspectul, trebuie să conveniți asupra structurii site-ului cu clientul.

Discutați cu clientul și aflați de ce are nevoie. Adunați dezvoltatori, specialiști SEO, marketeri, redactor-șef - și decideți ce pagini sunt necesare pe site. Gândiți-vă cum vor fi conectați unul la altul, de la care puteți trece.

Puteți afișa structura cu o listă, puteți desena o diagramă bloc. După cum preferați.

Aceasta este una dintre cele mai importante etape ale lucrului pe site. Structura este fundația. Dacă nu are succes, site-ul se va dovedi a fi strâmb.

Explicați ce va fi pe fiecare pagină

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

Prototip- un mod mai vizual și lipsit de ambiguitate. Antreprenorul desenează schițe ale fiecărei pagini și le atașează la termenii de referință. Clientul vede cum va arăta interfața viitorului său site web și spune ce îi place și ce trebuie schimbat.

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

Descrieți scenariile de utilizare a site-ului

Dacă creați un fel de interfață non-standard, doar afișarea structurii și a miniaturilor paginii nu este suficientă. Este important ca întreaga echipă de execuție și clientul să înțeleagă cum vor folosi vizitatorii site-ul. Scripturile sunt grozave pentru asta. Diagrama scenariului este foarte simplă:

• Acțiunea utilizatorului.
• Răspunsul site-ului.
• Rezultat.

Desigur, dacă creați o carte de vizită standard sau o pagină de destinație, nu este nevoie să scrieți scripturi. Dar dacă există unele servicii interactive pe site, este foarte de dorit.

Citiți mai multe despre cazuri de utilizare în Wikipedia.

Stabiliți cine este responsabil pentru conținut

Unii dezvoltatori creează imediat un site web cu conținut. Alții pun pește. Alții pot scrie texte, dar pentru o taxă suplimentară. Acceptați acest lucru pe țărm și scrieți în termenii de referință ce conținut ar trebui să pregătiți.

Este destul de dificil să vină cu criterii obiective de apreciere a calității textelor. Este mai bine să nu scrieți altceva decât „Conținut de înaltă calitate, interesant și de vânzare, care este util pentru publicul țintă”. Este un gunoi, nimeni nu are nevoie de el.

Specificarea faptului că tot conținutul trebuie să fie unic este utilă. O altă protecție pentru client față de artiștii fără scrupule.

Descrieți designul (dacă puteți)

Ca și în cazul textului, este dificil să veniți cu criterii obiective pentru evaluarea designului site-ului web. Dacă dvs. și clientul ați convenit asupra unei scheme de culori, notați-o. Dacă are o carte de marcă în care sunt specificate fonturile, indicați-le și pe acestea.

Nu este nevoie să scrieți despre design frumos și modern. Nu înseamnă nimic, nu are putere și în general ugh.

În loc de o concluzie: structura termenilor de referință

Structura specificațiilor tehnice va fi diferită pentru diferite sarcini. Este o prostie să faci aceleași specificații tehnice pentru o nouă rețea de socializare și o pagină de destinație pentru vânzarea angro de morcovi. Dar, în general, aveți nevoie de aceste secțiuni:

• Informații despre companie și publicul țintă, scopurile și obiectivele site-ului.
• Un glosar de termeni care poate să nu fie clar pentru client.
• Cerințe tehnice pentru amenajarea și funcționarea șantierului.
• Descrierea tehnologiilor utilizate și o listă a cerințelor de găzduire.
• Structura detaliată a site-ului.
• Prototipuri de pagini sau descrieri ale elementelor care ar trebui să fie pe acestea.
• Scenarii pentru utilizarea unei interfețe non-standard (opțional).
• Lista de conținut pe care o creează dezvoltatorul.
• Cerințe de proiectare (opțional).

• Reguli pentru compilarea Specificației cerințelor software. SRS este următorul pas în evoluția specificațiilor tehnice. Necesar pentru proiecte mari și complexe.
• Standarde și șabloane de specificații tehnice pentru dezvoltarea software. Descrieri ale diferitelor GOST și metodologii pentru crearea specificațiilor tehnice.

Acesta este sfârșitul părții pe care am scris-o. Dar mai există unul - comentarii de la specialiști care au ajutat la realizarea ghidului. Citiți-l, este și interesant.

Comentariile dezvoltatorilor

Am discutat cu mai mulți dezvoltatori pentru a afla cum creează specificațiile tehnice. Le transmit microfonul.

În primul rând, clientul are nevoie de specificații tehnice – astfel încât să înțeleagă cum va fi site-ul său și pe ce vor fi cheltuiți banii. Dacă ceva este greșit, se poate referi la specificațiile tehnice și poate cere să fie refăcut.

Specificația tehnică este întocmită de managerul de proiect după comunicarea cu clientul și discutarea sarcinii cu proiectantul.

Clienții mari solicită adesea specificații tehnice foarte detaliate, care descriu fiecare buton. Companiile mici, dimpotrivă, nu le plac documentele meticuloase de 100 de pagini. Este o lectură lungă și este ușor să ratezi ceva important. Mai des facem specificații tehnice concise de 10-15 pagini.

Indicăm:

• Informații despre companie și scopul site-ului.
• Cerințe pentru design, schemă de culori.
• Tehnologii și CMS utilizate.
• Cine produce conținutul - noi sau clientul.
• Structura site-ului până la fiecare pagină.
• Descrieri pentru fiecare pagină. Nu facem prototipuri, dar precizăm ce elemente ar trebui să fie pe pagină și cum ar trebui să funcționeze.

Ultimele 2 secțiuni sunt cele mai importante. Ei sunt cei care oferă o înțelegere despre cum va fi site-ul și cum va funcționa.

Un punct foarte important - nu puteți doar să oferiți termenii de referință dezvoltatorilor și să sperați că vor face totul bine. Specificația tehnică este o listă de cerințe pentru site; nu poate înlocui comunicarea. Este important să vă asigurați că fiecare membru al echipei înțelege obiectivul general și nu face doar sarcini din mers. Dacă ceva nu este clar, este necesar să explicați, să discutați și să faceți comentarii detaliate.

În viață, se întâmplă adesea ca o persoană să nu poată explica ce vrea, chiar și în lucrurile de zi cu zi. Când vine vorba de explicarea „dorințelor” tale unui programator, o persoană cade pur și simplu într-o stupoare.

În mod ideal, specificațiile tehnice ar trebui întocmite de către client - doar el știe de ce are nevoie. Dar, în practică, din cauza competenței scăzute a clientului în domeniul 1C, acest lucru trebuie să fie deseori făcut de către antreprenor. Clientul își exprimă verbal nevoile, iar programatorul (consultantul) o pune în scris.

De ce aveți nevoie de specificații tehnice?

Orice, în mod ideal, ar trebui să fie însoțit de specificații tehnice. Aceasta este, în primul rând, o definiție clară a sarcinii, a termenelor limită și a metodei de implementare. În al doilea rând, acesta este un document cu ajutorul căruia sunt rezolvate toate problemele controversate din viitor. Dacă să scrii sau nu specificații tehnice este, desigur, treaba ta; pentru mine personal, specificațiile tehnice îmi fac munca și comunicarea cu clientul mai ușoară.

Obțineți 267 de lecții video pe 1C gratuit:

Ce ar trebui să conțină termenii de referință?

Acestea. sarcina trebuie să conțină:

• ţintă— problema pe care o vom rezolva prin implementarea acestei specificații;
• Descriere— un rezumat al îmbunătățirilor viitoare;
• metoda de implementare— o descriere detaliată a metodelor de rezolvare a scopului. În acest moment, este necesar să descriem toate nuanțele sarcinii în limbajul programatorului: ce fel de sarcini creăm/edităm, cum ar trebui să arate interfața etc. Dacă nu vorbiți „limbaj de programare”, dar „ați auzit ceva”, este mai bine să nu încercați să scrieți într-un limbaj tehnic - se dovedește a fi destul de distractiv. Descrierea ar trebui să fie clară și să nu ridice întrebări. Poate conține, de asemenea, un exemplu de implementare a unei soluții similare într-o altă zonă;
• Evaluarea performanței- un punct foarte important, o descriere a costurilor forței de muncă.

Există, de asemenea, standarde de stat pentru scrierea specificațiilor tehnice - GOST-uri. În practică, acestea sunt rar folosite, dar uneori clientul insistă asupra acestui lucru.

Din experiență, la predarea muncii, de foarte multe ori apar situații de genul „ți-am spus atunci...”, ceea ce nu este foarte plăcut și de multe ori trebuie să refaci întreaga lucrare. Prin urmare, o specificație tehnică bine scrisă face viața mult mai ușoară ambelor părți.

Exemple și mostre de specificații tehnice pentru 1C

O mică selecție pe care am găsit-o disponibilă gratuit pe Internet. Pornind de la cele mai simple și mai accesibile documente destul de complexe.