Dacă parcurgeți site-uri străine cu cererea „document de cerințe ale produsului”, puteți găsi articole creative și convingătoare despre faptul că sarcina tehnică (TOR, PRD) este moartă. Parțial, trebuie să fim de acord cu acest lucru - atunci când dezvoltăm un produs de la zero, prototiparea pare mult mai interesantă și eficientă decât volumele de înregistrări ale clienților, uneori 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 revizuirea, cât și cu dezvoltarea personalizată, așa că câinele a fost mâncat la TK, dacă bucătarul nu ne minte. În general, astăzi - despre acele sarcini tehnice foarte clasice care sunt scrise pentru a finaliza software-ul achiziționat și instalat. Pe scurt, despre răni.

Fațete ale interacțiunii

Înainte de a trece la pregătirea procesului de creare a unei sarcini tehnice, să vorbim despre patrulater, în care se încadrează antreprenorul și clientul la începerea proiectului.

Cerințe- comportamentul dorit al sistemului, așa cum este descris de client sau deținătorul procesului, care urmează să fie implementat. De regulă, cerințele sunt formate pe baza experienței, reprezentarea 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 redundante etc.

Resurse- oameni, mașini, inventar, mediu de dezvoltare, timp și bani pentru a fi utilizați în procesul de implementare a cerințelor. Resursele necesită o planificare și o evaluare clară în etapa de aprobare a termenilor de referință. Prioritizarea competentă din partea clientului și distribuirea resurselor de muncă din partea vânzătorului fac posibilă evitarea depășirii termenelor limită și minimizarea altor riscuri.

Oportunități- pe scurt, asta este ceea ce poate face de fapt un furnizor (interpret). Luați în considerare RegionSoft CRM ca exemplu. Clientul cumpără sistemul și întocmește o sarcină tehnică de revizuire: este necesară crearea unei integrări cu site-ul și legarea evenimentelor în CRM la numărul de comandă al magazinului online. Aceasta este o cerință realistă, avem resursa și capacitatea de a o face. Și, de asemenea, trebuie să dezvoltați și să vă legați de CRM CMS, un sistem de management al conținutului site-ului. 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 a transfera resurse umane și de timp în sarcină. Drept urmare, clientul refuză această cerință - și nu are nevoie cu adevărat de un CMS, oricum totul este în regulă. Dar despre „lăcomia” TK – mai târziu.

Restricții- un set de obstacole care fac dificilă sau imposibilă finalizarea sarcinilor din TOR: buget, stiva de tehnologie, probleme de licențiere, interdicții legale, configurații hardware etc.

Astfel, toate cele patru entități sunt strâns legate între ele și determină succesul proiectului în ansamblu. Să luăm în considerare fiecare element și să încercăm să evidențiem punctele critice de care trebuie să ținem cont atunci când lucrăm la termenii de referință.

Colectarea și analiza cerințelor

Acesta este un proces intern corporativ foarte important, în timpul căruia rezultă ce doresc potențialii utilizatori de la program (în continuare vom lua CRM, dar metodele funcționează cu alte tipuri de software). Dacă contactați un furnizor mare precum SAP sau un integrator de sistem, atunci cu un grad mare de probabilitate vi se vor oferi serviciile unui consultant de afaceri (este și manager personal, este și manager de cont, este și „ acum reprezentantul dumneavoastră în compania noastră”). De fapt, în cele mai multe cazuri, acesta este un vânzător obișnuit, bine pregătit, care are două sarcini: să achite costul proiectului și să nu te lase să scapi.

E aici de o oră și nici măcar nu a atins tabla albă. Nu este un adevărat analist de sisteme

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, specificați ce să căutați și continuați. Apropo, angajatul dvs. care este bine versat în subiectul profilului și reprezintă aproximativ arhitectura software și este familiarizat cu procesul de dezvoltare poate fi un bun asistent - poate acționa ca analist și expert intern, poate închide procesul de creare a specificațiilor tehnice și comunicarea cu vânzătorul.

Există o schemă foarte simplă pentru colectarea cerințelor.

1. Creați un grup de lucru de manageri și specialiști cu experiență ai departamentelor care vor folosi CRM. Spuneți-ne despre soluția pe care o veți alege, oferiți acces la versiunea demo.
2. Membrii grupului de lucru trebuie să transmită informații angajaților și să le ceară urări pentru un nou program într-o formă absolut gratuită. 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ă-l cereți să-și descrie sarcinile periodice, aceasta este o abordare universală.
3. Fiecare divizie determină apoi ceea ce CRM nu se potrivește sau nu se potrivește și agregează informațiile.
4. Grupul de lucru analizează cerințele colectate, verifică și elimină intersecțiile. De exemplu, nu este neobișnuit ca un departament de vânzări și un departament de marketing să comande același raport, dar câmpurile și entitățile pot fi denumite diferit în cerințe, deși datele din spatele lor sunt aceleași. În consecință, este necesar să ajungem la o singură formă.
5. Grupul de lucru formează o listă de cerințe și stabilește prioritățile. În această etapă, puteți conecta furnizorul, 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 complet diferite din punct de vedere al timpului, prioritatea este foarte importantă aici.

După ce cerințele sunt colectate, analizate și convenite cu angajații și conducerea, puteți începe să creați termeni de referință. Puteți fie să cereți formularul de la furnizor, fie să îl creați singur - în orice caz, există câteva reguli absolute care vă vor scuti de bătaie de cap atât dvs., cât și furnizorului dvs. de CRM.

Anatomia unui termen de referință

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

• Identificare - definirea cerințelor, căutarea 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.
• Documentație - o descriere formală și detaliată a cerințelor, aprobarea specificațiilor tehnice.
• Comunicarea cu furnizorul (dezvoltatorul) - interacțiune iterativă cu vânzătorul cu privire la îmbunătățiri în conformitate cu TOR compilat.
• Implementare - munca furnizorului de a crea funcționalitatea necesară. Este mai bine dacă vânzătorul este în permanență în contact cu clientul - astfel încât produsul rezultat se va potrivi cel mai bine cu viziunea 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 revizuirii cu TOR, operabilitatea sistemului cu modificări.

În general, termenii de referință pot fi creați pe baza cerințelor mai multor niveluri, care se pot suprapune și pot coopera la crearea proiectului sau să nu interacționeze deloc.

Nivel de afaceri- cel mai global nivel la care sunt rezolvate sarcini complexe și prioritare. Acest nivel include integrarea, rafinarea ș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 colaborare strânsă cu clientul. De exemplu, la un moment dat în RegionSoft CRM, contabilitatea depozitului, casa de marcat și producția erau astfel de modificări personalizate. Treptat, modificările au intrat în lansare, iar ulterior au permis crearea unui nou produs pentru magazine en-gros, retail și hipermarketuri - RegionSoft Retail.

Nivel de utilizator sau grup de utilizatori. La acest nivel, sunt implementate sarcini pentru a rafina interfața existentă. De exemplu, un utilizator poate 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 - de exemplu, mai multe cerințe de la departamentele de marketing, logistică și suport tehnic.

nivelul de funcționalitate. De multe ori este dificil să-l separăm de cel precedent, aici funcționează un criteriu formal - rafinamentul nu este la nivelul afișării a ceva în interfață, ci la nivelul rafinamentului logicii sistemului. Acestea includ 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 care intră în build-uri noi cu remedieri. Acestea sunt sarcini în ceea ce privește viteza de răspuns a sistemului, lucrul sub sarcină mare și securitatea. În mod ideal, vânzătorul nu ar trebui să aibă astfel de îmbunătățiri - 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ă a apărut o cerință și nu are legătură cu paranoia personală a clientului sau cu probleme din partea hardware, merită să-i acordăm o atenție deosebită.

Nivel de tehnologie- ultimul din listă, dar înaintea celorlalți ca importanță și complexitate. Acestea pot fi cerințe ale clientului legate de platformă, sistem de operare sau dispozitive. De exemplu, o cerere de compilare pentru MacOS. Este grozav dacă astfel de cerințe se dezvoltă treptat în versiuni, dar este necesar să existe remedieri ale acestora. Din solicitările clienților de la acest nivel am realizat un ansamblu de RegionSoft CRM pentru MacOS și am adăugat acces la distanță folosind tehnologia TRM ca soluție temporară la o solicitare rară, dar existentă, pentru o versiune mobilă.

Anatomia termenilor de referință este simplă, cel puțin sub forma unui schelet. Părțile obligatorii ale termenilor de referință îl ajută pe client să se concentreze asupra problemei și să formuleze sarcina corect, iar executantul să înțeleagă ce vrea de la el. Apropo, despre înțelegere. Bineînțeles, la începutul postării, eram puțin vicleni, refuzând consultanții de afaceri ca clasă. Ideea este aceasta: fiecare furnizor operează pe piață de câțiva ani (nu vorbim acum 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ță, atât inginerii, programatorii, cât și agenții de vânzări sunt familiarizați cu specificul implementării fiecărui tip de companie. Dar din nou, este important să vă concentrați pe afacerea dvs.

Pentru cine?În această secțiune, trebuie să descrieți cine va fi utilizatorul final al revizuirii, ce sarcini și cât de des este planificat să o rezolve.

Vă dau un exemplu. O companie a implementat CRM, 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ță de „zilnic”. Desigur, un astfel de raport, în timp ce sute de utilizatori lucrau simultan, a încărcat sistemul - s-au găsit soluții pentru optimizarea procesului. Deja în cursul lucrărilor, s-a dovedit că vânzătorul era în siguranță și avea nevoie de raport abia la sfârșitul lunii, iar apoi putea fi lansat conform programului noaptea. 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 articol este mai necesar clientului însuși, dar este util și pentru vânzător să știe ce alte procese vor fi afectate. Uneori ajută să găsiți o soluție alternativă.

Ce ar trebui făcut? Cel mai informativ bloc - descrie cerințele, așteptările de la sistem. Și aici se întâmplă chiar perlele, miracolele și ciocnirile, pe care trebuie să le trimiți 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 mic submotiv - utilizatorul nu poate formula cerințe. Și aici sarcina dezvoltatorului (grup de lucru, analist, dacă există) este să ajute la formularea corectă a nevoii, să selecteze o cerință adecvată și să încadreze sarcina în contextul sistemului. În același bloc, trebuie să menționați rezultatul așteptat.

Parametrii termenilor de referință- termene limită, etape de implementare, responsabil din toate părțile, contacte necesare etc. De fapt, acesta este un set de lucruri formale importante care fac din document o sarcină tehnică. Termenii de referință trebuie conveniți și semnați de către părți pentru a evita numeroase schimbări în timpul dezvoltării (vor fi în continuare, dar într-un volum mai mic).

În mod ideal, termenii de referință sunt întocmiți cu participarea activă a vânzătorului, iar rezultatul acestuia 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ă sarcină tehnică
5. Termenele de executare a lucrărilor cu defalcare pe etape și indicarea ordinii de prioritate
6. Descrierea condițiilor de instalare și de testare
7. Rezerve cu privire la caracterul exhaustiv al termenilor de referință și al altor condiții

10 reguli scrise în lacrimile dezvoltatorului

Termenii de referință pentru revizuire ar trebui să fie TOR pentru revizuire, și nu o descriere de 300 de pagini a CRM-ului de care are nevoie clientul. Înainte de a elabora cerințele, ar trebui să vă familiarizați cu interfața sistemului, capacitățile sale, documentația - cel mai probabil, cea mai mare parte a „Listei de dorințe” este deja în pachetul de bază. În al doilea pas, aș recomanda să acordați atenție instrumentelor de rafinare încorporate (designeri de rapoarte, configuratori etc.) - poate un programator full-time va putea face modificările necesare (multe companii le au).

Sarcina 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 al banilor, nici din punct de vedere al afacerilor. Un furnizor, de regulă, nu există de câteva săptămâni (în cazul RegionSoft - 15 ani), și îl puteți contacta chiar și după un timp, când înțelegeți cu adevărat ce lipsește în CRM.

Un exemplu viu de redundanță literalmente de ieri: un client a cumpărat ERP-ul unei companii ruse cunoscute, crezând că, deoarece contabilitatea funcționează, atunci ERP-ul acestui furnizor va fi bun. ERP s-a dovedit a nu fi prea bun în sine, dar foarte nepotrivit pentru afaceri. Dar RegionSoft CRM cu contabilitate de depozit și producție este potrivit. 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 banii umflați sunt păcat! Iar clientul cere să integreze 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 părerea vânzătorului, deoarece el știe exact cât timp va dura pentru o anumită sarcină. Crede-mă, nu este profitabil pentru un dezvoltator să joace timp și să încheie termenul - este benefic pentru el să finalizeze cât mai multe proiecte și să o facă bine pentru a nu primi o lovitură la adresa reputației sale. În ceea ce privește realismul, evitarea solicitărilor de finalizare a CRM la nivelul unui sistem de control 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 posibilă perfecționare pentru o singură companie. Nu, desigur, totul are prețul său, dar din nou - în cazul general, cerința este imposibilă.

Nu trebuie confundat cu situația când vine vorba de dezvoltare personalizată și ideea și logica aplicației se schimbă radical, de fapt, crearea de software nou „pentru sine” este sponsorizată. Dar asta e altă poveste.

Specificația trebuie detaliată. Este necesar să se indice toate detaliile semnificative ale viitorului proiect: de la frecvența utilizării 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ă 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 afacere și program va asigura că vânzătorul înțelege sarcina și adaptează rapid sistem către compania dumneavoastră.

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 CRM ( de exemplu, calculul bonusurilor dealerilor), aceste formule trebuie scrise cu o explicație completă a denumirilor lor și a logicii de calcul.

Da, software-ul corporativ arată cam așa și există o mulțime de lucruri mici importante în el.

Termenii de referință trebuie să fie clari și precisi. Formulare vagă, 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 TOR mai multe opțiuni pentru comportamentul sistemului, care sunt apropiate, dar nu echivalente. În acest caz, el este sigur că ajută, îl îndeamnă pe programator, 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 singur cum să o facă, pe baza caracteristicile sistemului și teancul de tehnologii utilizate.

Anul acesta vă puteți pune din nou o dorință. Doar te rog, nu-l irosește cu ceva ce nici măcar eu nu pot îndeplini, cum ar fi cerințe clare de afaceri!

Termenii de referință trebuie să fie redactați în limbaj uman.Și acest lucru este important, nu, IMPORTANT. Voi evidenția două situații în care problemele cu limbajul duc la o întârziere în implementarea proiectului.

1. Clientul încearcă să-și demonstreze cunoștințele tehnice și construcții de garduri precum: „implementați o fereastră cu un indiciu în corpul calendarului cu capacitatea de a reacționa la un apel de eveniment...” în loc de „ar trebui să apară o fereastră în calendar în care puteți marca sarcina ca finalizată”. Dacă dumneavoastră sau expertul dumneavoastră intern nu aveți abilitățile de a scrie texte tehnice, nu căutați pe google - scrieți în cuvinte obișnuite, le înțelegem.

   Termenii de referință nu ar trebui să fie o carte de reclamații. Trebuie să rezolvăm problema, nu să o descriem, acordând atenție fonturilor și uitând de descrierea cerințelor. TOR ar trebui să conțină nu numai problema în sine, ci și soluția acesteia la nivel de înțelegere - atunci dezvoltatorul o va rezolva deja la nivel de cod. Comparaţie „departamentul de vânzări planifică prost, pierde cifre, ne luptăm de un an”Și „este necesar să se creeze un raport care să salveze lunar valorile planului și faptul vânzărilor, în contextul grupelor de produse”.

   Termenii de referință ar trebui să poată privi spre 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 revizuirea de două ori.

   Termenii de referință nu trebuie să fie birocratici. Dacă ai întocmit vreodată acest document, trebuie să fi simțit cât de greu este să eviți tentația de a aluneca în birocrație, să adaugi cuvinte introductive, rânduri stricte și să descrii fiecare articol ca un articol din Codul Penal (de preferință cu pedeapsă pentru toată lumea pt. încălcare). Formularea birocratică maschează o înțelegere incompletă a obiectivelor creării TK. Responsabilitatea vânzătorului este precizată în contract, acolo este scris și bugetul. Nu trebuie să transferați aceste puncte către sarcina tehnică.

   Termenii de referință trebuie să fie termenii de referință. Sună paradoxal, dar adesea în loc de specificații tehnice citim scrisori, reclamații, contracte, instrucțiuni nou scrise pentru CRM sau procese-verbale de întâlnire. Desigur, este imposibil să lucrezi la un astfel de document. Pentru a nu scăpa de formă și conținut, folosește trucul din vechea școală: uită-te la termenul cuvânt cu cuvânt. Tehnic înseamnă că dictează rafinament, tehnică, are ca scop rezolvarea problemei prin schimbarea software-ului. Aceasta este sarcina în contextul software-ului și trebuie să vorbiți. O sarcină înseamnă a pune o întrebare, o problemă, fără sfaturi, indicii și estimări preliminare. Doar o declarație a problemei.

   S-au terminat poruncile, acum mustrarea

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

   Termenii de referință trebuie redactați rapid, chiar dacă vă confruntați cu sarcina de a automatiza procesele unui operator de telefonie mobilă sau unui mare hipermarket. 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 lansări majore (și, uneori, două) în șase luni sau un an, obține o nouă funcționalitate. Poate fi necesar să se reconsidere nevoia de îmbunătățiri și să se reia procesul.

   

   
   În cele din urmă, a găsit timp să termine TK-ul. 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 termenilor de referință. Clientul nu ar trebui să se aprofundeze în tehnologie și să întrebe fiecare virgulă dacă vânzătorul poate face asta sau acela. Elaborați un TOR cuprinzător și dezvoltatorul va alege arhitectura potrivită - adesea chiar mai bună decât ați putea crede.

   Estimați-vă bugetul și evitați surprizele neplăcute- aproape sarcina comună numărul unu. Nu trebuie să trageți vânzătorul și să cereți de la el o evaluare aproximativă a lucrării (bine, cel puțin aproximativ, de la mână, cu ochii, dar ca și alții, ei bine, în proiecte de acest tip, dar din experiență, bine, bine, în cadrul marja de eroare). O estimare a bugetului complet este posibilă numai după citirea, analiza și aprobarea finală a termenilor de referință. Dacă dezvoltatorul dvs. face altfel, pregătiți-vă pentru faptul că revizuirea va costa cel puțin de două ori mai mult.

   Porniți de la nevoia obiectivă 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 vise CRM / ERP, nu solicitați de la vânzător butonul „Totul funcționează în timp ce beau cafea” - lucrați în sistem, identificați comentariile critice pentru dvs. și începeți să colectați cerințe și să redactați specificații tehnice .

   Puteți scrie la nesfârșit despre sarcini tehnice, acesta este un adevărat generator de meme și povești, ci și o durere de cap. Puteți vorbi despre priorități și reguli de proiectare, despre GOST 1989, care face TK inuman, despre standardele IEEE, care sunt puțin mai bune, despre prototipuri și TK care le completează. Dar, în cele din urmă, aș dori să mă limitez la una, cea mai importantă regulă: termenii de referință nu sunt o regulă de drept, nu GOST și nu o dogmă, prin urmare, dacă poți îmbunătăți - îmbunătăți, poți simplifica - simplificați, o puteți face cu grație și astfel încât tuturor să placă - fă-o. Sunt sigur că după asta nimeni nu își va băga nasul în TK și nu va spune că asta nu este scris acolo. Sau aproape nimeni.

   Pe tot parcursul lunii decembrie, oferim reduceri pentru RegionSoft CRM și pentru toate software-urile dezvoltate de noi. De la 1 decembrie până la 15 decembrie - 15% și condiții de rate și închiriere cool. Nu avem -70% și -90%, pentru că păstrăm un preț justificat economic pentru licențe, și nu-l luăm din plafon.

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

   Și da, căutăm mereu parteneri care sunt gata să vândă CRM și alte produse, să îmbunătățească și să vândă CRM, să vândă software și să formeze utilizatori. Împărțirea veniturilor este corectă și benefică partenerului. Arată, spune, învață. Scrie la [email protected]

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

Experții noștri au ajutat clientul să creeze Termeni de referință pentru modernizarea sistemului de ventilație.

Mai multe detalii sub croiala...

Sarcina tehnică

pentru modernizarea echipamentelor tehnologice pentru sistemele de ventilație a clădirii laboratorului nr. 451.452, clădirea 17 la adresa: Moscova

1. Dispoziții generale

1.1. Acest cadru de referință prevede implementarea lucrărilor de modernizare a echipamentelor tehnologice, sistemelor de control și automatizării unităților de ventilație ale clădirii, laboratoarele nr. 451.452 din clădirea 17.

1.2. Pentru a efectua lucrări, dezvoltați documentația de lucru pentru secțiunile mărcilor AOV, EM, KhS, AHS, AK, care ar trebui convenite în modul prescris.

1.3. Efectuați lucrările în conformitate cu cerințele documentației tehnice și de reglementare.

1.4. La finalizarea lucrărilor, trimiteți documentația așa cum este construită, realizată în conformitate cu cerințele GOST și SNiP.

1.5. Trimiteți clientului lucrarea finalizată.

1.6. Anumite prevederi ale acestor Termeni de referință pot fi specificate în procesul de lucru, de comun acord cu Clientul.

2. Cerințe tehnice

2.1. Modernizarea unitatilor de control pentru alimentarea cu caldura si rece a unitatilor de ventilatie.

2.1.1. Noduri de reglare a alimentării cu căldură.

Modernizarea este supusă:

· unități de control al alimentării cu căldură pentru prima încălzire a unităților de ventilație K1, K2, K2a, K4 ale clădirilor MIK-V, P2, P6 ale laboratorului nr. 452, P1 al laboratorului.

· unități de control al alimentării cu căldură pentru a doua încălzire a unităților de ventilație K1, K2, K2a a clădirii MIK-V.

Unitatile de control al energiei termice existente sunt supuse demontarii, in timp ce o parte din echipamentele unitatilor de control (pompe de circulatie, supape de inchidere), corespunzatoare ca stare si caracteristici tehnice, urmeaza a fi utilizata in unitatile de control montate.

Compoziția echipamentelor unităților de comandă montate, precum și a echipamentelor utilizate este indicată în Anexa nr. 1.

Efectuați încercări hidraulice ale circuitelor de încălzire și încălzitoarelor unităților de ventilație cu executarea unui proces verbal de încercare hidraulică.

Efectuați vopsirea conductelor și lucrări de izolare termică.

2.1.2.Noduri pentru reglarea alimentării frigorifice a unităților de ventilație.

Unitățile frigorifice pentru unitățile de ventilație K1, K2, K2a, K4 ale clădirilor MIK-V, P2, P6 ale laboratorului „452, P1 ale laboratorului nr. 451 sunt supuse modernizării.

Scopul muncii:

· înlocuirea supapelor termostatice ale unităților de control frigorific;

Demontarea/montarea ventilatorului agregatului compresor-condens K1;

· demontarea/montarea filtrelor-uscător blocuri compresor-condensare K1, K2;

Demontarea/montarea evaporatorului unitatii de ventilatie K4;

· testarea presiunii in mediu cu gaz inert, aspirarea, reumplerea circuitelor frigorifice cu freon;

Refacerea izolației termice a conductelor.

2.1.3. Unități de alimentare pentru circuitele de umidificare.

Instalați filtre de purificare a apei rece la unitățile de alimentare ale camerelor de irigare ale aparatelor de aer condiționat K1, K2, K2a.

2.2. Dulapuri pentru controlul si automatizarea instalatiilor de ventilatie.

Dulapuri de control pentru unități de ventilație K1, K2, K2a, K4, RU3, V1, V2, V3, V6, V7, V8 ale laboratorului MIK-V, P2, P6, V1, V2, V3 Nr. 451, P1, V1 laborator nr. 452.

Dispunerea panourilor de control nou instalate:

SHUA K1 - dulap de control și automatizare a unității de ventilație și a unității de compresor și condensator (KKB) a aparatului de aer condiționat K1 (MIK-V);

SHUA K2 - dulap de control și automatizare a unității de ventilație și a aparatului de aer condiționat KKB K2 (MIK-V);

SHUA K2 - dulap de control și automatizare a unității de ventilație și a aparatului de aer condiționat KKB K2a (MIK-V);

SHUA K4 - dulap de control și automatizare a unității de ventilație și a aparatului de aer condiționat KKB K4 (MIK-V);

SHUV - dulap de comandă pentru unități de evacuare RU3, V1, V2, V3, V6, V7, V8 (MIK-V);

ShUA P2, P6 - dulap de comandă și automatizare a unităților de ventilație și a unităților compresoare și condensatoare P2, P6 (laborator nr. 452);

SHUV - dulap de comandă pentru unități de evacuare V1, V2, V3 (laborator nr. 452);

SHUA P1, V1 - dulap de control și automatizare a unităților de ventilație P1, V1 (laborator Nr. 451).

Cabinetele de control modernizate ar trebui să ofere:

selectarea, din panoul frontal al dulapului, a modului de control al unității de ventilație (manual/automat);

· semnalizare luminoasă a modurilor de funcționare regulate și de urgență a echipamentelor tehnologice ale unităților de ventilație (funcționare/accident);

oprirea sistemelor de ventilație în caz de incendiu;

functionarea automata a protectiilor si blocarea functionarii echipamentelor in caz de urgenta.

Convertizoarele de frecvență pentru controlul motoarelor electrice ale ventilatoarelor și pompelor vor fi utilizate în continuare.

2.3. Sistem de automatizare si dispecerat

Sistemul de automatizare și dispecerare este conceput pentru a gestiona și controla funcționarea unităților de ventilație, precum și pentru a colecta, procesa, prezenta și stoca informațiile primite.

2.3.1. Sistem de automatizare.

Sistemul de automatizare trebuie să asigure, în general, funcționarea autonomă a unităților de ventilație, care nu necesită intervenția personalului de întreținere și trecerea, dacă este cazul, la modul de control manual. Cu orice opțiuni de control și indiferent de starea controlerului local, trebuie menținută condiția de oprire automată a sistemului general de ventilație în caz de incendiu. Oprirea trebuie efectuată individual pentru fiecare sistem, menținând alimentarea cu energie a circuitelor antiîngheț.

Automatizarea locală a sistemelor de ventilație ar trebui să includă:

reglarea temperaturii aerului de alimentare la ieșirea unității de ventilație sau, dacă este necesar, a temperaturii aerului evacuat din spațiile deservite;

reglarea umidității aerului de alimentare;

opriți ventilatoarele și închideți supapele de aer atunci când este declanșată o alarmă de incendiu;

Oprirea umidificarii aparatului de aer conditionat atunci cand ventilatorul acestuia se opreste;

Deschiderea și respectiv închiderea supapei de aer la pornirea și oprirea ventilatorului;

· încălzirea automată a radiatoarelor înainte de pornirea sistemelor în regim de iarnă;

· protectie impotriva inghetului radiatoarelor prin aer si prin apa (oprirea ventilatorului, inchiderea clapetei de aer, deschiderea supapei de incalzire la 100%);

oprirea ventilatorului în absența diferenței de presiune;

· controlul poluarii filtrelor instalatiilor.

Impactul de la distanță asupra automatizării locale cu stațiile de lucru este determinat în următorul volum:

· modificarea setărilor regulatoarelor de temperatură și umiditate;

· activați/dezactivați setările.

Echipamentele periferice existente ale sistemului de automatizare sunt supuse verificării, curățării și utilizării ulterioare în următoarea ordine:

· senzorii de temperatura si umiditate ai unitatilor de ventilatie sunt supusi verificarii;

· Senzorii comutatorului de presiune diferențială trebuie verificați, curățați;

· Termostatele care protejează aerotermele de îngheț trebuie înlocuite.

· Actuatoarele supapelor de control ale unităților de control trebuie înlocuite în conformitate cu clauza 2.1.1.

actuatoarele supapelor de aer sunt supuse inspecției și utilizării ulterioare;

Pentru a controla recircularea aparatului de aer condiționat K1, înlocuiți actuatoarele de pornire-oprire ale supapelor de aer cu supape cu un semnal de control de 0..10V.

2.3.2. sistem de expediere.

Includeți următoarele componente în sistemul de expediere:

un complex de dispozitive de măsurare, actuatoare și instrumente de automatizare bazate pe instrumente software și hardware „Honeywell”;

· sistem de cabluri multifuncțional;

· un complex de mijloace software și hardware ale camerei de control.

Pentru dispecerizarea sistemelor de ventilație, asigurați-vă afișarea, arhivarea și înregistrarea următoarelor informații:

· reprezentarea grafica a instalatiilor cu senzori de temperatura si umiditate, termostate anti-inghet, presostate diferentiale, supape de control, umidificatoare de aer, supape de aer;

numere de instalare;

citiri ale senzorilor de temperatură și umiditate;

citiri ale senzorilor releului de presiune diferențială;

indicații de poziție a supapelor de control 0..100%;

modul de funcționare/oprire ventilator;

· modul „funcţionare/oprire” a pompelor;

pozitia supapelor de aer „deschis/inchis”;

oprirea sistemelor la declanșarea unei alarme de incendiu;

oprirea sistemelor atunci când există amenințarea de înghețare a încălzitorului;

oprirea unității în absența căderii de presiune pe ventilator;

Oprirea umidificatorului de aer atunci când ventilatorul aerului condiționat se oprește;

Funcționarea sistemelor conform unui orar dat sau fără acesta;

· semnalizarea accidentelor și situațiilor de urgență în caz de defecțiune a echipamentelor, precum și - ieșirea valorilor parametrilor de proces în afara intervalelor specificate;

înregistrarea accidentelor și situațiilor de urgență în jurnalul de mesaje;

· jurnalul de înregistrare a parametrilor pentru ora curentă indicând numele parametrilor controlați, unitățile de măsură, numărul controlerului și canalul de intrare/ieșire.

2.3.3. Alimentarea sistemului de automatizare și dispecerat trebuie alimentată de la rețeaua de curent alternativ cu o tensiune de 380/220 V, o frecvență de 50 Hz folosind surse de alimentare neîntreruptibile pe baterii și furnizată ca sursă de alimentare pentru consumatorii de energie din prima categorie.

Depinde direct de cât de exact sunt întocmiți termenii de referință pentru finalizarea 1C, dacă sarcinile atribuite dezvoltatorilor vor fi rezolvate. Cu toate acestea, atunci când lucrați cu un astfel de document, există unele dificultăți. În sens larg, TOR prescrie normele pentru crearea și modernizarea unui sistem automatizat (AS), precum și procedura de lucru. Aceasta include, de asemenea, un set de standarde de lansare a proiectelor. Această înțelegere a rolului termenilor de referință este dictată de cerințele GOST 19.201-78 și 34.602-89, conform cărora TOR pentru 1C este în curs de dezvoltare. Există o altă interpretare a sensului acestui document, mai apropiată de practică.

Conform unei alte definiții, termenii de referință pentru finalizarea 1C este un document care reglementează scopul și parametrii viitorului sistem, precum și procesul de elaborare a documentației și lista acesteia. Această interpretare permite luarea în considerare a intereselor programatorilor și ale clientului.

Care ar trebui să fie TK?

Orice sarcină tehnică pentru dezvoltarea programului 1C este creată de antreprenor. Dar acesta nu este un programator, ci un analist. Acesta este un punct important, deoarece documentul trebuie redactat într-o limbă pe care clientul o înțelege, fără termeni tehnici de înaltă specializare. Atunci când toate nuanțele proiectului sunt luate în considerare și informațiile sunt formulate corect, TOR este convenit cu toți clienții. Dacă este acceptat, programatorii sunt implicați în lucru. În același timp, rezultatul dorit ar trebui să fie subliniat clar în document. Acest lucru îi ajută pe dezvoltatori să stabilească obiectivul potrivit și să-l verifice în diferite etape. De asemenea, atunci când se elaborează termenii de referință pentru finalizarea 1C, trebuie acordată multă atenție formulării. Trebuie avut grijă ca acestea să fie suficient de specifice și să nu implice alte interpretări. Acesta este primul lucru de reținut când lucrați cu TK. De asemenea, trebuie să adoptați o abordare responsabilă a designului. Acest lucru este valabil și pentru pagina de titlu a documentului.

Principalele greșeli în termenii de referință pentru dezvoltarea 1C

Structura termenilor de referință este reglementată de GOST 34.602-89. Acest document conține cerințe clare pentru numărul și succesiunea blocurilor de informații din TOR. În același timp, nu există standarde stricte pentru metodele de prezentare. Această situație conține un potențial mare de rezolvare a unor probleme complexe și, în același timp, poate duce la multe erori în pregătirea documentului. Cele mai frecvente inexactități sunt:

1. Repetarea unor secțiuni în diferite interpretări.
2. Informațiile sunt date aleatoriu. În mod ideal, ar trebui să se refere la o structură specifică, cum ar fi procesele de afaceri sau modulele de sistem.
3. Informațiile din diferite secțiuni sunt prezentate cu diferite grade de detaliu.

Toate acestea împiedică clientul să înțeleagă informațiile care sunt prevăzute în TOR. Acest lucru complică procesul de cooperare, făcându-l mai consumator de timp.

După vizualizarea de către client, TOR eșantion pentru revizuirea 1C se poate modifica și nu întotdeauna în bine. Acest lucru, la rândul său, împiedică de obicei programatorii să perceapă corect informațiile. Acest lucru este valabil mai ales pentru specialiștii cu puțină experiență. În această etapă, apar adesea următoarele erori:

1. Cerințele diferitelor secțiuni se contrazic reciproc.
2. Formulele sunt inexacte.
3. În unele locuri, informațiile sunt prea detaliate.

A scăpa de toate aceste erori este ușor. Este necesar să ne concentrăm, în primul rând, pe rezultat, și nu pe prescrierea cu atenție a formulărilor. Merită să ne amintim că TOR descrie funcționalitatea proiectului, principalii parametri și scopul acestuia.

Cum să evitați greșelile în elaborarea specificațiilor tehnice?

Regula principală, care se aplică tuturor recomandărilor ulterioare, este că formularea trebuie să fie specifică. Pentru a face acest lucru, trebuie să utilizați link-uri către GOST, alte documente de reglementare. Acest lucru permite contractantului și clientului să perceapă informațiile în același mod.

Un exemplu de sarcină tehnică pentru finalizarea 1C implică utilizarea limbajului industriei de afaceri pentru care proiectul este implementat. Acest lucru este necesar, în primul rând, pentru client. În același timp, nu trebuie să utilizați nicio comparație în text, deoarece acestea pot fi interpretate în moduri diferite.

Reguli de bază la elaborarea termenilor de referință pentru elaborarea unui raport și a altor elemente ale 1C:

1. TK este creat în comun de către antreprenor și client.
2. Doar cerințele obiective ar trebui să fie prezentate muncii programatorilor. Pentru dezvoltarea cu succes a proiectului, viziunea subiectivă a clientului trebuie să fie menținută la minimum.
3. Este necesar să descriem în detaliu rezultatul de care are nevoie clientul. În același timp, în exemplul termenilor de referință pentru dezvoltarea configurației 1C, este necesar să se prescrie toți parametrii după care ar trebui să funcționeze elementul. În caz contrar, rezultatul poate fi foarte diferit de cel dorit.
4. Riscurile antreprenorului și ale clientului ar trebui să fie aproximativ egale și reduse la minimum.
5. Nu puteți folosi termeni care sunt folosiți în comunicarea de afaceri și nu sunt utilizați într-o anumită industrie.

Pentru a crea un TOR pentru elaborarea unui raport în 1C sau alt element, analistul trebuie să cunoască toate caracteristicile domeniului de activitate al clientului. În cerințe, trebuie să oferiți numai informații utile care sunt utile interpretului. Având în vedere că aici se acordă o atenție deosebită sarcinilor finale pe care software-ul trebuie să le rezolve, nu există un singur exemplu de sarcină tehnică.

Pericolul pregătirii incorecte a TOR

Erorile enumerate mai sus pot duce la o creștere a timpului necesar pentru a crea un sistem. Acest lucru implică costuri inutile și nemulțumire. Termenii de referință pentru dezvoltarea unei baze de date sau a unei alte configurații 1C ar trebui întocmiți de specialiști cu experiență. Beneficiul tuturor participanților depinde de modul în care acest document este înțeles. Clientul primește un sistem automat eficient pentru rezolvarea problemelor de afaceri. Totodată, antreprenorul are un alt client mulțumit. Proprietarii de afaceri trebuie să fie cât mai atenți posibil atunci când aleg companiile partenere 1C, deoarece eficiența organizației depinde în mare măsură de cât de bine sunt redactați termenii de referință pentru revizuire.

Pavel Molyanov

Îți amintești legea lui Murphy? Dacă poți fi înțeles greșit, ești obligat să fii înțeles greșit. Acest lucru este valabil nu numai în comunicarea între oameni, ci și în crearea de site-uri. Clientul a dorit un al doilea Facebook, dar a primit un forum pentru tinerii crescători de câini. Dezvoltatorul nu a ghicit Lista de dorințe a clientului - ș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 unei specificații tehnice să nu se transforme în timp pierdut.

Articolul va fi util:

• Toți cei care au legătură cu crearea de site-uri: dezvoltatori, designeri, designeri de layout.
• Manageri de proiect.
• Șefii studiourilor digitale.
• Antreprenorii care plănuiesc să comande dezvoltarea site-ului.

Pentru ca materialul să fie funcțional, am adunat comentarii de la mai mulți dezvoltatori, designeri, manageri de proiect și proprietari de studiouri digitale. Cele mai valoroase sunt adăugate la sfârșitul articolului. Hai să ne dăm seama.

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

Termenii de referință sunt un document în care sunt stabilite cerințele pentru site. 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 termenilor de referință este de a se asigura că clientul și interpretul se înțeleg corect.

Există multe avantaje ale specificațiilor tehnice. Fiecare parte are propria sa.

Beneficiu 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 - nicio problemă de schimbat înainte de începerea dezvoltării.
• Vedeți competența interpretului. Dacă termenii de referință sunt înțeleși și clari, încrederea în dezvoltator crește. Dacă acolo scrie terci, ar putea merita să alergi și să nu te uiți înapoi.
• Pentru a se asigura împotriva necinstei interpretului. Când site-ul este gata, acesta poate fi verificat conform termenilor de referință. Există inconsecvențe? Dezvoltatorul trebuie să le repare. Dacă cooperezi oficial și ai încheiat un acord, poți chiar să fii forțat prin instanțe.
• 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ă un termen de referință detaliat, acesta poate fi transferat unei noi echipe - se va implica în muncă de multe ori mai repede.
• Aflați costul dezvoltării unui produs complex. Este imposibil de estimat momentul exact și costul dezvoltării unui serviciu web complex imediat. Mai întâi trebuie să înțelegeți cum va funcționa serviciul și ce funcții va avea. Pentru a face acest lucru, trebuie să pregătiți o sarcină tehnică.

Beneficii pentru interpret:

• Înțelegeți ce își dorește clientul. Clientului i se adresează zeci de întrebări, sunt prezentate exemple, sunt oferite soluții. Apoi totul este scris într-un singur document și coordonat. Dacă totul este în regulă - noroc, ai înțeles corect.
• Pentru a se asigura împotriva listei de dorințe bruște a clientului. Uneori există clienți care doresc să schimbe sarcina la jumătate. Dacă ați fost de acord și ați semnat TOR, nu vă este frică de acest lucru. În acest caz, chiar și instanța va fi de partea dumneavoastră.
• Arată-ți competența. Un termen de referință 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, îndoielile sunt susceptibile să fie risipite.
• A castiga bani. Unele studiouri și dezvoltatori oferă pregătirea specificațiilor tehnice ca serviciu separat.

• Facilitează și accelerează procesul de dezvoltare. Un TOR 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, rămâne doar să proiectezi și să scrii codul.

Acum să ne dăm seama cum să scriem un TOR bun care să îndeplinească toate aceste funcții.

Termenii de referință sunt formulați de interpret

În general, oricine poate face o sarcină tehnică. „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 face treaba? Cu greu.

Un TOR bun este întotdeauna realizat de un interpret: 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”. De asemenea, el trebuie să participe la proces:

Desigur, clientul își poate schița propria versiune a TK. Poate că acest lucru va accelera procesul de creare a termenilor de referință finali. Și poate că se va dovedi a fi gunoi, care sunt aruncați în liniște la gunoi.

Scrieți clar și precis

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

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

Uite. La urma urmei, cineva a crezut că acest design este frumos și a permis să fie folosit pe site-ul său web:

Același lucru - cu o formulare neclară care nu înseamnă nimic în sine:

• Site-ul trebuie să fie apreciat de către client. Dacă este într-o dispoziție proastă?
• Site-ul trebuie să fie ușor de utilizat. 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 calitate. Ei bine, ai înțeles ideea.

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

• Site-ul trebuie să se încarce rapid → Orice pagină a site-ului trebuie să aibă mai mult de 80 de puncte în Google PageSpeed ​​​​Insights.
• Încărcături mari → 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 → Lăsați un câmp de e-mail și butonul Abonare → *schiță desenată*.

Ne-am dat seama de redactare, 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 ei țintă. Pentru ca nimeni să nu se încurce, este mai bine să o prescrieți chiar de la începutul termenilor de referință.

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

Explicați termenii dificili

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

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

Imaginați-vă că ați făcut un site web grozav de 2 luni. Fiecare etapă a fost coordonată cu clientul – acesta este încântat. Și acum este timpul să predăm 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, specificați cerințele pentru găzduire. Nu se știe niciodată, o vei face în PHP - iar clientul are un server în .NET.

Enumerați cerințele pentru site

Site-ul ar trebui să funcționeze în toate browserele versiunilor 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 efectuată necinstit.

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

Specificați structura site-ului

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

Discutați cu clientul, aflați de ce are nevoie. Adunați dezvoltatori, SEO, marketeri, redactor-șef - și decideți ce pagini sunt necesare pe site. Gândiți-vă la modul în care vor fi interconectate, de la care puteți trece.

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

Aceasta este una dintre cele mai importante etape de lucru pe șantier. 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- 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 arata interfata viitorului sau site si spune ce ii place si ce ar trebui schimbat.

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

Notaț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 implementare și clientul să înțeleagă cum vor folosi vizitatorii site-ul. Scripturile sunt grozave pentru asta. Structura scenariului este foarte simplă:

• Acțiunea utilizatorului.
• Răspuns pe site.
• Rezultat.

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

Citiți mai multe despre cazuri de utilizare pe Wikipedia.

Stabiliți cine este responsabil pentru conținut

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

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

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

Descrieți designul (dacă puteți)

Ca și în text, criterii obiective de evaluare proiectarea site-ului greu de venit. Dacă dvs. și clientul ați convenit asupra unei scheme de culori, notați-o. Dacă are o carte de marcă în care sunt înregistrate fonturi, indicați-le și pe acestea.

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

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

Pentru diferite sarcini, structura TOR va fi diferită. Este o prostie să faci aceleași specificații tehnice pentru o nouă rețea de socializare și o pagină de destinație pentru morcovi angro. Dar, în general, aveți nevoie de secțiuni ca aceasta:

• Informații despre companie și publicul țintă, scopurile și obiectivele site-ului.
• Glosar de termeni care ar putea să nu fie înțeleși de către client.
• Cerințe tehnice pentru amenajarea și funcționarea șantierului.
• Descrierea tehnologiilor utilizate și lista 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 termenilor de referință. Necesar pentru proiecte mari și complexe.
• Standarde și șabloane de TOR pentru dezvoltarea de 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 - comentariile experților care au ajutat la realizarea ghidului. Citește, este și interesant.

Comentariile dezvoltatorilor

Am vorbit cu mai mulți dezvoltatori pentru a afla cum scriu specificațiile. Le transmit microfonul.

În primul rând, clientul are nevoie de TK - pentru a înțelege cum va fi site-ul său și pe ce se cheltuiesc banii. Dacă ceva este greșit, el se poate referi la TK și poate cere să-l refacă.

TOR este întocmit de managerul de proiect după comunicarea cu clientul și discutarea sarcinii cu proiectantul.

Clienții mari solicită adesea specificații 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 pentru 10-15 pagini.

Indicăm:

• Informații despre companie și scopul site-ului.
• Cerințe de design, culori.
• Tehnologii utilizate și CMS.
• Cine este implicat în conținut - noi sau clientul.
• Structura site-ului până la fiecare pagină.
• Descrieri ale fiecărei pagini. 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. Ele oferă o înțelegere a 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. TK 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 comun și nu doar îndeplinește sarcini în flux. Dacă ceva nu este clar - este necesar să explicați, să discutați, să faceți comentarii detaliate.