Întocmirea specificațiilor tehnice. Exemple de specificații tehnice. Cum să scrieți corect specificațiile tehnice

Deci, specificația tehnică, prescurtată ca TK, servește de ceva timp pentru a descrie în mod oficial ceea ce vrem de fapt să vedem în produsul final. Specificațiile tehnice pentru dezvoltarea unei resurse web nu fac excepție. În esență, aceasta este baza dezvoltării site-ului web. Acesta specifică toate prevederile direct sau indirect legate de site.

Specificația tehnică, de regulă, este atașată contractului principal pentru crearea unei resurse web, deoarece include o listă completă a tuturor lucrărilor care trebuie efectuate pentru a elimina eventualele dispute dintre client și antreprenor, care, după cum se știe, mai apar din când în când.

Există o opinie printre unii oameni, „bătuți” de experiență, că TK-ul ar trebui scris ca și cum ai fi prezent la proces cu el și îl vei folosi ca apărare. Aceasta poate fi o extremă, dar, totuși, este un motiv să ne gândim din nou despre importanța unei specificații tehnice bine scrise și detaliate .

În ceea ce privește volumul său, specificația tehnică poate fi un document destul de mare. Companiile web oferă adesea asistență în elaborarea specificațiilor tehnice ca un serviciu separat, de obicei 10-20% din costul dezvoltării întregului site web.

Pregătirea specificațiilor tehnice este efectuată de obicei de managerul de proiect sau direct de programator cu participarea clientului, care oferă informații de bază.

Cum specificatii tehnice mai detaliate (în limite rezonabile, desigur), cu atât mai bine pentru ambele părți - atât clientul, cât și executantul lucrării. Amândoi câștigă, ca să spunem așa:
— clientul va fi sigur că tot ceea ce a planificat în proiect este clar precizat și trebuie implementat în conformitate cu specificațiile tehnice.
- executantul este asigurat împotriva multor ajustări și modificări mici sau mari, bazându-se din nou pe aceleași specificații tehnice.

Există o părere că te poți descurca fără specificații tehnice. De exemplu, unul dintre argumente este că sarcina este prea creativă pentru a se încadra în cadrul specificațiilor tehnice. Această opinie maschează cel mai probabil lipsa de experiență și profesionalism în acest domeniu. Cred că această opinie este greșită, deoarece aproape totul în construirea site-ului web pot fi formalizate și prezentate în specificații tehnice iar compilarea lui este mai degrabă o chestiune de experiență.

  • Adevărul simplu este că cu cât proiectul este mai complex, cu atât specificațiile tehnice ar trebui să fie mai detaliate.
  • Printre opțiunile posibile se numără specificația tehnică, care descrie paginile principale ale interfeței cu întregul set de elemente pe ea și o descriere a comportamentului acestora. Sau ar putea fi o descriere laconică a mai multor pagini pentru un site web de cărți de vizită etc.
  • Specificațiile tehnice pentru programator nu trebuie să menționeze designul elementelor sau să exprime dorințele de proiectare. Sarcina este încă pentru programator..
  • Descrierile sarcinilor din părțile individuale ale specificațiilor tehnice ar trebui să fie limitate. Ce înseamnă? Este necesar să indicați în mod clar sfârșitul unui anumit articol de sarcină. Specificațiile tehnice nu trebuie să conțină expresii abstracte precum „ar trebui să existe o navigare ușoară”. Toate acestea sunt semne subiective - este convenabil pentru unii, nu este convenabil pentru alții și poate fi dificil de înțeles dacă acest punct a fost îndeplinit din cauza neclarității prevederilor specificațiilor tehnice. Adică trebuie controlat.
  • Pentru site-urile simple în care trebuie să descrii un modul funcțional, pentru a nu reinventa roata, trebuie să analizezi site-uri cu funcționalitate similară, ca să spunem așa, să faci o analiză a concurenților; salvați hyperlinkuri către pagini cu elementele și funcțiile de interfață necesare și includeți-le în declarația de lucru cu explicații extinse despre ce trebuie făcut exact. De asemenea, este necesar să faceți capturi de ecran din paginile necesare în cazul în care site-ul devine indisponibil după un timp. În același timp, puteți pune propriile mărci pe imagini (din fericire, există o mulțime de instrumente pentru asta acum - Clip2net, Joxi, Awesome Screenshot și altele).
  • Dacă nu există un design pentru pagini sau nu este atât de important în cadrul unui proiect, să zicem, clientul a decis să economisească bani pe designul panoului de administrare al site-ului, în acest caz, programatorul poate folosi prototipuri.

Referinţă

Un prototip este un aspect grafic al elementelor de interfață. În linii mari, o pagină desenată într-un program special cu toate elementele.

Există o mulțime de software pentru desenarea prototipurilor, inclusiv aplicații desktop și servicii online, precum și extensii pentru browsere cu capacități mai modeste. Software cu licențe gratuite și plătite.

Cele populare includ:
— printre cele gratuite: iPlotz, MockFlow, Mockup Builder, Cacoo;
- dintre cele plătite: Creately, ProtoShare, Adobe Fireworks, Axure. În general, există multe posibilități - alege, stăpânește, desenează...

Structura generală a specificațiilor tehnice. De la abstractizare la specificitate

Una dintre posibilele structuri ale site-ului, le subliniez pe cele posibile, ar putea arăta cam așa:

  1. Informații generale despre site.
  2. Scopul funcțional al site-ului.
  3. Concepte și termeni
  4. Descrierea modulelor site-ului
  5. Caracteristici funcționale
  6. Descrierea paginilor.
  7. Redundanță și fiabilitate.
  8. Gazduire pentru site.

1. Informații generale despre site
Câteva propoziții sunt suficiente aici pentru a vă prezenta ce fel de site sau modul va fi dezvoltat și scopul său în general. Scris în stil liber.

2. Scopul funcțional al site-ului
Iată o scurtă listă cu ce mijloace tehnice sau instrumente ar trebui să aibă un site, în funcție de obiectivul general. Să explic cu un exemplu. Pentru un site web de cărți de vizită, acesta poate fi banal, un formular de feedback, o listă de pagini principale, de exemplu, „despre companie”, „contacte” și altele.

3. Concepte și termeni
Această secțiune ar trebui să se asigure că ambele părți înțeleg conceptele specifice domeniului care sunt importante pentru înțelegerea și dezvoltarea site-ului. Poate fi introdus de ambele părți.

4. Descrierea modulelor site-ului
Această secțiune include o listă de module care sunt utilizate pe site. De exemplu, acesta ar putea fi formularul de feedback (FOF) menționat mai sus. Dar, ceea ce este foarte important, nu poți scrie pur și simplu „FOS trebuie să fie prezent”. Fiecare entitate necesită definirea atributelor sale! În acest caz, atributele ar putea fi:

  • Câmpul „Numele tău”;
  • Câmpul „Adresa de e-mail”;
  • Câmpul „Întrebarea ta”;
  • Câmp de introducere Captcha pentru a proteja împotriva roboților de spam.

Și toate acestea ar trebui precizate clar, astfel încât întrebările să nu apară mai târziu: « ...unde este lista pentru selectarea unei categorii de întrebări?» sau ceva de genul asta.

5. Caracteristici funcționale
Aceasta ar putea include, de exemplu, o listă de browsere în care site-ul ar trebui să se afișeze și să funcționeze corect. De exemplu, unii clienți pot cere ca site-ul lor să funcționeze corect în binecunoscutul Internet Explorer 6, pentru a nu pierde, deși o mică, dar o cotă de posibili vizitatori.
Dacă intenționați să creați un site web cu încărcare mare, trebuie să indicați și acest lucru. Un site web foarte încărcat necesită o abordare diferită la dezvoltarea și configurarea serverului.

De asemenea, caracteristicile funcționale includ prezența sau absența unei versiuni mobile a site-ului, dar aceasta, de regulă, fie intră într-o secțiune separată a acestei specificații, fie este scrisă separat.

6. Descrierea paginilor site-ului
Acesta este un articol destul de extins în care sunt desenate toate paginile site-ului și sunt scrise comentarii la munca lor.
De asemenea, poate fi dată structura generală a paginilor site-ului. Așa-numitele prototipuri „la nivel înalt”. De exemplu, pentru un site de director simplu, acesta ar putea fi:

Pentru fiecare pagină specifică, pot fi desenate prototipuri cu comentarii detaliate despre fiecare dintre elementele interfeței și comportamentul acestora.
Paginile utilizate pentru panoul de administrare sunt de obicei listate separat de paginile publice. Aceste două secțiuni, la rândul lor, pot fi grupate în propriile subsecțiuni separate. Aici merită să vă asigurați că prototipurile nu intră în conflict cu descrierea lor și că nu apar contradicții. Un exemplu de prototip pentru o anumită pagină de site ar putea fi:

Alte pagini

Nu vom lua în considerare ultimele două secțiuni ale specificației tehnice în detaliu, voi spune pe scurt că una dintre cerințele de fiabilitate poate include crearea unei copii de siguranță a bazei de date.

Cerințele de găzduire pot include memoria fizică disponibilă pentru site, lățime de bandă, suport pentru baza de date utilizată și o serie de alte cerințe pentru ca site-ul să funcționeze corect.

La sfârșitul mandatului este obligatoriu să se includă informații despre toate lucrările care nu sunt descrise în acest mandat efectuate la discreția programatorului din motive evidente. Aceasta este „micuța noastră garanție” împotriva eventualelor modificări și modificări care depășesc domeniul de aplicare al specificațiilor tehnice.

Concluzii: Trebuie spus că această structură de secțiuni a specificațiilor tehnice nu se pretinde a fi complet completă (cel puțin pentru proiecte strategice mari), dar acoperă totuși punctele principale.

Trebuie subliniat faptul că toate cele de mai sus sunt doar recomandări bazate pe experiența oamenilor care lucrează în domeniul dezvoltării site-urilor web și nu reprezintă în niciun caz o cerință strictă pentru redactarea specificațiilor tehnice.

Succes cu proiectele și înțelegerea umană!

În specificația tehnică, clientul trebuie să indice toate cerințele sale pentru obiectul de achiziție propus. În special:

Sfat:Merită să începeți să pregătiți specificațiile tehnice din timp. Acest lucru va reduce riscul ca termenele limită pentru publicarea documentației de achiziții în Sistemul Informațional Unificat să fie ratate. La urma urmei, serviciul contractual (managerul contractului) are nevoie de la câteva zile la câteva săptămâni pentru a întocmi o specificație tehnică de înaltă calitate, în funcție de complexitatea tehnică a obiectului achiziției.

Sfat: La elaborarea specificațiilor tehnice, este logic să vă ghidați după:

  • GOST-uri. De exemplu, la crearea unui sistem automat - GOST 34.602-89 „Tehnologia informației. Un set de standarde pentru sisteme automate. Specificații tehnice pentru realizarea unui sistem automatizat”;
  • instrucțiuni metodologice (recomandări) ale fondatorului. De exemplu, Ministerul Culturii al Rusiei a elaborat Orientări privind procedura de elaborare a specificațiilor tehnice atunci când se efectuează achiziții în cadrul programului țintă „Cultura Rusiei (2012-2018)” (scrisoare a Ministerului Culturii din Rusia din ianuarie 25, 2013 Nr. 446-01-56/10-NM).

Crearea unei specificații tehnice este o sarcină creativă care necesită suficient efort și timp din partea clientului. Cu toate acestea, o abordare integrată a soluționării acesteia, precum și o atenție atentă la fiecare achiziție, este condiția principală pentru activități eficiente de achiziție.

1. Informații generale despre client

În această secțiune ar trebui să indicați următoarele date despre clienți:

  • Nume;
  • localizarea clientului;
  • programul de lucru.

Indicarea locației și a orelor de funcționare ale clientului este relevantă atunci când, în conformitate cu termenii contractului, participantul trebuie să livreze bunuri (efectuează lucrări, prestează servicii) pe teritoriul clientului.

Această secțiune poate include și informații despre achizițiile comune sau centralizate, precum și despre implicarea unui expert (organizație de experți).

2. Informații generale despre achiziție

Aici merită precizat:

  • numele complet al obiectului achiziției,
  • metoda aleasă pentru determinarea furnizorului (antreprenor, executant),
  • sursa de finantare.

Această secțiune poate conține, de asemenea, informații despre termenii și abrevierile utilizate în specificațiile tehnice. Aceste informații pot fi prezentate, de exemplu, sub forma unui tabel.

Termeni și abrevieri

Definiţie

DE

Produsul software „Salariu-Buget”, care face obiectul achiziției

Client

Instituția de stat „Alpha”

Expert

Specialist care are cunoștințe speciale în domeniul contabilității și fiscalității în sectorul public, în materie de personal și juridic și are studii superioare de specialitate

3. Descrierea obiectului achiziției

Această secțiune ar trebui să descrie următoarele cât mai complet și corect posibil.

1. Caracteristici calitative, tehnice și funcționale. Calitatea produsului trebuie să respecte atât cerințele legale, cât și termenii contractului.

În acest caz, clientul trebuie să utilizeze indicatori standard (cerințe, simboluri și terminologie) atunci când descrie caracteristicile tehnice și de calitate. Pentru a face acest lucru, trebuie să fiți ghidat de cerințele obligatorii, în special de GOST, SNiP și legislația civilă (articolele 469, 721 din Codul civil al Federației Ruse). De exemplu, cerințele privind calitatea alimentelor sunt stabilite în Legea federală nr. 29-FZ din 2 ianuarie 2000.

Dacă indicatorii standard nu pot fi preluați din reglementări tehnice, standarde (alte acte legislative privind reglementarea tehnică), atunci este necesar să se justifice utilizarea altor indicatori (cerințe, denumiri, terminologie).

Sfat: Nu ar trebui să utilizați valori exacte ale indicatorilor. Este mai bine să le înlocuiți cu condiții cu valori maxime și/sau minime, precum și cu valori care nu se pot modifica. Adică, astfel de indicatori care vor permite participanților să determine dacă bunurile achiziționate (lucrări, servicii) îndeplinesc cerințele stabilite. De exemplu, atunci când achiziționați o unitate de sistem, ar fi mai corect să indicați în specificațiile tehnice „Capacitatea hard disk - nici mai puțin 500 GB” și nu „Capacitate hard disk - 500 GB”.

Acest lucru este menționat în partea 2 a articolului 33 din Legea nr. 44-FZ și explicat în scrisoarea Ministerului Dezvoltării Economice al Rusiei din 10 decembrie 2014 nr. D28i-2796.

2. Caracteristici de performanță (dacă este necesar).

3. Cantitatea totală de mărfuri (volum de muncă, servicii). Când acest lucru nu este posibil, clientul poate indica prețul unei unități de lucru (serviciu).

4. Cerințe de ambalare. Aceasta este o cerință suplimentară. În specificațiile tehnice, puteți indica, de exemplu, că ambalajul produsului trebuie să asigure siguranța acestuia în timpul transportului și depozitării.

5. Cerințe de securitate pentru obiectul achiziției.

6. Condiții și procedură de livrare a mărfurilor, efectuarea lucrărilor, prestarea serviciilor.În special, este necesar să se determine locul de livrare a mărfurilor (execuția muncii, prestarea serviciilor). În acest caz, puteți specifica:

  • adresa de livrare specifica;
  • interval (alternativ) de locații de livrare, în care participantul trebuie să indice o anumită adresă în aplicație (de exemplu, în limitele Moscovei).

Acest lucru este necesar pentru ca atunci când depun cererile, participanții să aibă o idee despre unde trebuie să livreze bunurile (în ce loc să presteze un serviciu sau să efectueze lucrări). Apoi, atunci când decid să depună o cerere, ei vor înțelege dacă pot îndeplini comanda în acest loc anume. Clientul, la rândul său, se va proteja de riscul ca ofertantul câștigător să refuze să execute.

7. Perioada de garanție și service în garanție(Partea 4 a articolului 33 din Legea nr. 44-FZ). Perioada de garanție trebuie stabilită în zile, luni și ani.

După aceasta, este important să specificați termenii serviciului de garanție, adică o listă completă de acțiuni ale furnizorului (antreprenor, executant) pentru a menține sau aduce obiectul achiziției în starea cerută de client.

De exemplu, la achiziționarea unui aparat de aer condiționat, merită să se stabilească o perioadă de garanție de cel puțin doi ani, timp în care furnizorul va fi obligat să inspecteze gratuit echipamentul în termen de trei zile de la momentul detectării avariei și să elimine orice identificat. încălcări în funcționarea sa.

8. Alte caracteristici care sunt importante atunci când descriem un anumit tip de produs, muncă, serviciu. Astfel, la achiziționarea unui produs, clientul trebuie să indice în specificațiile tehnice că acesta trebuie să fie nou și lipsit de drepturile terților. Adică nimeni nu a folosit sau reparat produsul înainte. În caz contrar, clientul riscă să primească un produs folosit. Acest lucru este menționat în paragraful 7 al părții 1 a articolului 33 din Legea nr. 44-FZ.

Dacă este necesar, termenii de referință ar trebui să includă și cerințe suplimentare pentru obiectul achiziției. Acestea ar putea fi:

  • instruirea angajaților;
  • cerințe de instalare și punere în funcțiune;
  • serviciu post-vânzare;
  • potrivirea probei etc.

Lista de informații și cerințe pot varia în funcție de fiecare articol specific de achiziție.

Un exemplu de descriere a unui obiect de achiziție

În conformitate cu programul Instituției de Stat „Alpha”, achiziția unui lot de hârtie pentru echipamente de birou este planificată pentru luna mai 2016. În pregătirea licitației electronice, managerul contractului A.S. Glebova a început să pregătească documentația de achiziție, în special, a compilat-o termeni de referință .

Atenţie! Participantul are dreptul de a nu lua în considerare și de a nu implementa date despre obiect care nu sunt reflectate în specificațiile tehnice.

In cazul in care produsul (lucrarea, serviciul) oferit de castigator nu se potriveste clientului, dar in acelasi timp corespunde specificatiilor tehnice, acesta nu are dreptul de a refuza incheierea contractului.

Sfat:Ca sursă de informații ar trebui să utilizați:

  • contracte încheiate anterior,
  • surse disponibile public (cataloage, liste de prețuri, broșuri publicitare etc.),
  • oferte comerciale,
  • informații de pe Internet.

Toate acestea vor ajuta la reflectarea in specificatiile tehnice exact a acelor caracteristici ale produsului (lucrare, serviciu) de care clientul are nevoie.

Atenţie! În cazul în care clientul indică în documentația de achiziție informații care pot duce la o limitare a numărului de participanți, va exista riscul asumării răspunderii administrative. Astfel, funcționarii (managerul contractului, angajații serviciilor contractuale) pot fi amendați în valoare de 1% din prețul contractual inițial (maxim) (NMCP), dar nu mai puțin de 10.000 de ruble. și nu mai mult de 50.000 de ruble. (Partea 4.1 a articolului 7.30 din Codul contravențiilor administrative al Federației Ruse).

Atenţie!Când descrieți obiectul achiziției, nu puteți indica numele organizațiilor de producție, mărci comerciale, mărci de servicii etc. Acest lucru va duce la o restrângere a concurenței și, în consecință, la încălcarea legislației privind achizițiile. Excepții - specificația tehnică poate conține o mențiune a mărcilor comerciale, dacă este necesar:

  • indicați mijloacele de muncă utilizate în executarea lucrărilor sau a serviciilor, dar nu ca obiect al contractului. În acest caz, o condiție obligatorie este indicarea mențiunii „sau echivalent”;
  • achiziționarea de bunuri necesare pentru a interacționa cu bunurile utilizate de client (de exemplu, actualizarea software-ului instalat);
  • achiziționarea de piese de schimb sau consumabile pentru mașinile și echipamentele clientului.

Acest lucru este menționat în paragraful 1 al părții 1 a articolului 33 din Legea nr. 44-FZ.

Atenţie! Este imposibil să achiziționați diverse produse (bunuri, lucrări, servicii) care nu au legătură între ele din punct de vedere tehnologic și funcțional în cadrul unei achiziții (un lot). Acest lucru va limita numărul de participanți. De exemplu, următoarele servicii nu pot fi combinate într-o singură achiziție:

  • pentru protecția instalației folosind sisteme de securitate și de alarmă împotriva incendiilor și
  • pentru întreținerea alarmei în sine.

FAS Rusia a clarificat că acest lucru se aplică diferitelor piețe de servicii. La urma urmei, organizațiile de securitate, de regulă, nu deservesc alarme. Și dacă includeți astfel de servicii într-o singură achiziție, acest lucru va duce la o limitare a numărului de participanți.

Acest lucru rezultă din partea 3 a articolului 17 din Legea federală din 26 iulie 2006 nr. 135-FZ și este explicat în scrisorile Ministerului Dezvoltării Economice din Rusia din 10 martie 2015 nr. D28i-442, FAS Rusia din mai 21, 2014 Nr AC/20578/14 .

Prin urmare, atunci când planifică o achiziție și întocmește documentația, clientul trebuie să analizeze acest punct și, dacă este necesar:

  • împărțiți achiziția în loturi separate,
  • Pentru fiecare lot, întocmește o specificație tehnică separată.

4. Cerințe pentru furnizor (antreprenor, executant)

Termenii de referință trebuie să includă o cerință conform căreia participanții la achiziții trebuie să respecte legislația rusă. Aceasta ar putea fi, de exemplu, informații despre disponibilitatea unei licențe pentru un anumit tip de activitate.

În plus, în unele cazuri, guvernul Federației Ruse poate stabili cerințe suplimentare pentru participanții la achiziții, în special, disponibilitatea resurselor financiare și materiale, experiență de lucru similară cu obiectul contractului (Partea 2 a articolului 31 din Legea nr. 44-FZ). Astfel, în Decretul Guvernului Federației Ruse din 4 februarie 2015 nr. 99, există cerințe suplimentare pentru participanții la achiziții pentru lucrări de conservare a siturilor de patrimoniu cultural. Participantul la o astfel de achiziție trebuie să furnizeze informații despre contractul pe care l-a executat fără penalități în ultimii trei ani. Cuantumul unui astfel de contract trebuie să fie de cel puțin 20 la sută din NMCC pentru a cărui încheiere se efectuează achiziția.

În majoritatea organizațiilor mari, relațiile dintre utilizator și IT sunt inevitabile, mai ales atunci când se creează aplicații de lucru de care utilizatorul are nevoie în mod continuu. Complexitatea acestei relații se poate datora multor factori, dar cel mai adesea este o neînțelegere care apare deoarece părțile vorbesc „limbi” diferite cu terminologie diferită. Utilizatorul înțelege ce vrea, dar nu îl poate formula specialistul IT înțelege utilizatorul, dar se teme că rezultatul va ieși altfel decât vede primul. Cel mai adesea, problema începe cu faptul că utilizatorul nu este pregătit pentru dialog: el cere „să funcționeze”, „pentru un raport cu un singur buton”, „să fie afișat într-un minut”, „pentru date să nu apară în Excel”, și așa mai departe. În același timp, nu este deloc interesat de cum se face acest lucru și de ce mecanisme funcționează. Utilizatorul nu răspunde la afirmațiile despre încărcarea de pe server, solicită să deseneze o diagramă a rezultatului dorit sau să discute soluții, crezând că un adevărat profesionist se va ocupa de totul. Rezultatele unei astfel de neînțelegeri dăunează întregului proces de producție: termenele limită pentru rezolvarea problemelor sunt întârziate, apar erori și lacune în sistemele de care utilizatorul are nevoie, un server supraîncărcat cu acțiuni incorecte suferă, iar viteza de lucru scade.

Una dintre modalitățile de a rezolva un astfel de conflict este redactarea unei sarcini de proiect - o specificație tehnică, care implică o declarație completă și precisă a cerințelor clientului intern și este un fel de instrucțiune pentru un specialist IT. Cu toate acestea, nu fiecare utilizator este capabil să-și exprime gândurile în mod competent și inteligibil.
Voi da cateva sfaturi pentru redactarea unei sarcini corecte pentru utilizator, la care se poate lucra si care sta la baza relatiei dintre clientul solutiei si specialist.

1. Înainte de a întocmi specificațiile tehnice, utilizatorul trebuie să înțeleagă exact ce vrea să primească. Ar trebui să determinați scopul sarcinii, caracteristicile cheie ale rezultatului dorit, să desenați (scrieți, să creați un tabel) pentru dvs. rezultatul dorit al lucrării.

2. Colectați documentația, conform căruia efectuați lucrări pentru care este nevoie de o aplicație (program). Citiți-l cu atenție, cu creionul, notând trăsăturile și subtilitățile.

3. Ar trebui înțeles ce parametri trebuie setati la intrare, care este frecvența de lucru cu programul dorit (raport, aplicație, utilitate), câte date vor fi obținute aproximativ ca rezultat și dacă toate acestea sunt necesare (de exemplu, dacă aveți nevoie de suma veniturilor din vânzări de cinci categorii de produse în categorii fără nume, nu ar trebui să solicitați crearea unui raport de un milion de rânduri care să arate fiecare vânzare cu caracteristici detaliate). Nu orice specialist are nevoie de cele mai detaliate informații, a căror prelucrare creează o sarcină semnificativă asupra sistemelor de calcul.

4. Descrieți în detaliu informațiile solicitate, indicați caracteristicile, excepțiile și nivelul de detaliu necesar. Ar trebui să vă gândiți la toate lucrurile mici: formatul numărului, rotunjirea, fracțiile, ratele etc.

6. Discutați sarcina scrisă cu executantul direct, încercați să rezolvați toate întrebările, ascultând cu atenție opinia interlocutorului. Nu uita ca iti cunosti mai bine domeniul de activitate si doar tu iti poti explica exact ce instrument ai nevoie pentru a lucra eficient. Un specialist IT își cunoaște afacerea și nu este obligat să cunoască nuanțele muncii fiecărui departament din organizație.

7. Transfer atribuirea de a lucra într-un timp rezonabilînainte de implementarea finală, astfel încât să existe posibilitatea de a testa rezultatul și de a corecta eventualele erori.

8. Dacă subordonații tăi vor folosi și aplicația creată de tine, încearcă să o folosești tu explicați caracteristicile lucrului cu aplicația– acest lucru va scuti un specialist IT de a fi nevoit să explice același lucru de o sută de ori.

9. Amintiți-vă că sarcina dvs. vă va servi drept referință - puteți oricând să vă uitați la descrierea informațiilor din ea și să vă amintiți o cerință uitată.

Desigur, doar capacitatea de a scrie o specificație tehnică nu va elimina toate problemele, dar va permite relațiilor cu departamentul IT să treacă la un nivel serios de cooperare, va permite utilizatorului să-și sporească cunoștințele tehnice și să obțină ceea ce are nevoie și salvați specialistul IT de o serie de probleme și întrebări inutile.

Oamenii interpretează diferit evenimentele și fenomenele și văd soluțiile la probleme în mod diferit. În situațiile în care există un plan clar, orice interpretare incorectă poate duce la rezultate neașteptate și, cel mai probabil, nu vei obține ceea ce ți-ai dorit.

Dacă, conform termenilor de referință pe care i-ați scris, oamenii fac ceea ce doriți să realizați, iar în procesul de lucru nu depuneți efort suplimentar pentru adăugiri și reformulare a propriilor gânduri, atunci știți să vă stabiliți bine sarcinile și ai multe de învățat.

Dacă, chiar și după ce a citit specificațiile tehnice, executantul face ceva greșit, atunci trebuie să vă reconsiderați abordarea de stabilire a sarcinilor. Nici cel mai tare interpret pe care îl angajezi pentru un proiect nu va face ceea ce ai nevoie dacă i-ai întocmit o specificație tehnică proastă.

Pentru a scrie o declarație tehnică bună, trebuie să vă imaginați în locul persoanei căreia i se adresează. Să ilustrăm această idee.

Facem videoclipuri și acum câteva luni era nou să folosim ilustratori. Primele noastre sarcini tehnice au dat naștere la o serie de întrebări din partea antreprenorului și a trebuit să ne sunăm și să explicăm persoanei la ce ne referim la un moment dat. La un moment dat eram obositi, iar ilustratorul era obosit. Era ceva de gândit.

Ni se pare că problema a fost că am formulat sarcina în fraze prea generale, ceea ce i-a dat ilustratorului un motiv să se gândească și să piardă timpul căutând informații care nu erau relevante pentru el.

Ce a fost rau:

  1. Am scris o listă de cerințe pentru ilustrații pentru animație, fără a însoți aceste cerințe cu exemple cu imagini și videoclipuri. Era doar un text de genul: „încercați să desenați elementele de îndoire în așa fel încât punctele de ancorare ale îmbinărilor să coincidă între ele”. Pentru că ne-a fost prea lene să o ilustrăm, ilustratorul nostru a făcut ceea ce trebuia abia a treia oară.
  2. Am completat specificațiile tehnice cu prea multe exemple. Ilustratorul se îneca literalmente în abundența de lucrări pe care o iubim. Nu exista un ghid stilistic clar.
  3. Mult text. Am scris informații inutile despre proiect. Aceste informații nu l-au putut ajuta în niciun fel pe ilustrator să-și facă treaba.
  4. Un storyboard cu explicații insuficiente despre ceea ce se va întâmpla în slide.
  5. Disponibilitatea specificațiilor tehnice doar online, pe Google Drive.
  6. Nu aveam o idee clară pentru cine scriem această specificație tehnică. Nu ne-am asumat rolul acestei persoane pentru proiectul nostru.

Desigur, se poate presupune că persoana angajată pentru proiect este el însuși atât de lent și îngust la minte. Renunțăm imediat la acest gând. Scopul TK nu este de a testa abilitățile intelectuale ale unei persoane și de a nu juca jocuri de ghicire cu el. Când angajezi pe cineva pentru un proiect, de obicei nu sunt cei mai proști oameni, nu? Ați văzut munca anterioară a persoanei, ați vorbit cu el înainte de a începe proiectul.

După ce ne-am analizat greșelile, ne-am schimbat abordarea de a scrie specificațiile tehnice. Ultimul nostru proiect s-a dovedit a fi foarte ușor de urmărit, în mare parte datorită faptului că am început să stabilim sarcinile mai clar și mai atent. Am început să petrecem mult mai puțin timp pentru explicații suplimentare. Specificația tehnică a constat din 43 de pagini. Poate că am exagerat puțin, dar primele cuvinte ale ilustratorului după citirea noii specificații tehnice au fost:

Esența noii noastre abordări de a scrie specificațiile tehnice se rezuma la următoarele:

1. Trebuie să descrieți foarte pe scurt și succint cui este acest proiect, ce sarcini trebuie rezolvate la sfârșitul proiectului și ce problemă specifică este rezolvată de persoana pe care o angajați pentru proiect. Astfel, nu va lucra orbește, înțelegerea „ce” și „de ce” îi va permite să-ți ofere cele mai bune soluții.

2. Oferiți interpretului toate materialele necesare lucrării: referințe, imagini și videoclipuri cu explicații. Cel mai recent proiect al nostru a fost despre cum funcționează un aparat de bucătărie. Puteți găsi cu ușurință mii de articole, imagini și videoclipuri despre munca lui pe Internet. Am economisit timp ilustratorului și am colectat cele mai evidente și mai ușor de înțeles imagini și videoclipuri. Ne-a luat 15 minute. Dar suntem siguri că am economisit mult mai mult timp la muncă.

3. Punct cu punct, notează clar și concis tot ceea ce trebuie făcut pentru a considera munca finalizată.

4. Acum ilustrăm orice cerințe tehnice și înregistrarea unui videoclip. Aici este important să vă puneți mai multe întrebări: ce este posibil să fie neclar? Ce ar putea ridica întrebări suplimentare?

5. Acum trimitem nu doar textul în format Google Docs, ci și un link pentru a descărca versiunea PDF a TK, astfel încât în ​​cazul unor probleme cu Internetul, TK-ul să fie la îndemână.

Unele dintre aceste lucruri pot părea naturale, dar realizarea acestei naturalețe vine odată cu experiența. Sperăm că informațiile din acest articol au fost utile. Aș dori să aud în comentarii despre înțelegerea dvs. despre o specificație tehnică ideală.

Definirea domeniului proiectului, elaborarea specificațiilor tehnice

Această secțiune discută pe scurt problema dezvoltării specificațiilor tehnice (denumite în continuare TK). În primul rând, este dată o definiție a specificației tehnice, sunt descrise avantajele specificației tehnice atât pentru client, cât și pentru antreprenor și sunt enumerate principalele funcții ale specificației tehnice. În continuare, luăm în considerare care este esența TK, sunt dezvăluite structura și conținutul TK și sunt date exemple ale structurii TK. În concluzie, se notează caracteristicile specificațiilor tehnice ale proiectelor inovatoare.

Întrucât sarcinile de elaborare a specificațiilor tehnice pentru un proiect inovator, având propriile caracteristici, rămân în principiu aceleași ca atunci când se elaborează specificații tehnice, se ia în considerare mai întâi problema dezvoltării specificațiilor tehnice în ansamblu.

Definiţie

Trebuie menționat că în acest moment nu există o definiție standardizată a specificațiilor tehnice (TOR) ale unui proiect inovator. În baza de date actuală a standardelor naționale există trei standarde legate de TK. Toate se referă la domeniul tehnologiei informației:

GOST 19.201-78. Sistem unificat de documentare a programului. Specificatii tehnice. Cerințe pentru conținut și design.

GOST 25123-82. Mașini de calcul și sisteme de prelucrare a datelor. Specificatii tehnice. Ordinea de construcție, prezentare și proiectare.

GOST 34.602-89. Tehnologia de informație. Un set de standarde pentru sisteme automate. Termeni de referință pentru crearea unui sistem automatizat.

De exemplu, în „GOST 19.201-78. Sistem unificat de documentare a programului. Specificatii tehnice. Cerințe pentru conținut și proiectare” se dă următoarea definiție a specificației tehnice: „Specificații tehnice pentru un sistem automatizat - un document aprobat în modul stabilit care definește scopurile, cerințele și datele inițiale de bază necesare dezvoltării unui sistem automatizat și care conțin o evaluare preliminară a eficienței economice.”

Se spune că specificația tehnică permite:

    executantul - să înțeleagă esența sarcinii, să arate clientului „aspectul tehnic” al viitorului produs, produs software sau sistem automatizat;

    clientul – să înțeleagă exact de ce are nevoie;

    ambele părți - să prezinte produsul finit;

    antreprenorul - să planifice implementarea proiectului și să lucreze conform planului;

    clientul - cere de la antreprenor ca produsul să îndeplinească toate condițiile specificate în specificațiile tehnice;

    antreprenorul - refuză să execute lucrări nespecificate în specificațiile tehnice;

    clientul și antreprenorul - efectuează o verificare punct cu punct a produsului finit (testare de acceptare - efectuarea teste);

    evitați erorile asociate cu cerințele în schimbare (în toate etapele și etapele de creare, cu excepția teste).

Astfel, o specificație tehnică este un document care conține un set de cerințe și permite atât dezvoltatorului, cât și clientului să prezinte produsul final și, ulterior, să verifice conformitatea cu cerințele.

Cu cât specificațiile tehnice sunt mai detaliate, cu atât vor apărea mai puține situații controversate între client și dezvoltator în timpul testelor de acceptare.

TK îndeplinește patru funcții principale:

    Legal.

    Specificația tehnică este un document legal și este inclusă ca anexă în contractul dintre client și antreprenor.

    organizatoric.

    Cu ajutorul specificațiilor tehnice, puteți eficientiza munca ulterioară, o puteți transforma într-o coadă (schemă) de sarcini și nu pierdeți efort cu acțiuni inutile.

Informațional.

O specificație tehnică bine scrisă poate fi o bună sursă de informații necesare pentru finalizarea proiectului. Natura structurată a TK vă permite să aveți informații care sunt cu adevărat de interes, în forma care este cel mai ușor percepută și în cantitatea necesară pentru finalizarea lucrării.

Comunicativ. O specificație tehnică detaliată ajută antreprenorul să înțeleagă mai bine nevoile clientului și să efectueze lucrări care corespund tuturor gusturilor acestuia.

Ceea ce contribuie și la procesul de aprobare a proiectului.

Esența specificațiilor tehnice

Lucrul la specificațiile tehnice înseamnă că se așteaptă o soluție la o problemă și este descrisă pas cu pas în acest document.

Munca responsabilă asupra specificațiilor tehnice va permite dezvoltatorilor săi să vadă scenariul pentru finalizarea sarcinii. Înțelegeți clar punctele dvs. tari și punctele slabe, cum să trăiți procesul de îndeplinire a unei sarcini. Decideți asupra criteriilor, stabiliți indicatori, caracteristici, sume, evaluați resursele.

Specificațiile tehnice sunt convenite cu clientul sau dezvoltate în comun.

În ciuda importanței sale, conținutul și structura specificațiilor tehnice nu sunt practic reglementate de documentele de reglementare.

De obicei, clientul își stabilește un obiectiv (așa cum îl înțelege el) și limitări ale resurselor (timp, bani). Sarcina interpretului, în primul rând, este să traducă cerințele în limba domeniului subiectului, să formuleze problema cât mai complet și cât mai competent posibil, să justifice necesitatea soluționării acesteia, să înțeleagă și să clarifice datele inițiale. Conținutul TOR ar trebui să includă informații cu privire la obiectivele și performanța funcțiilor care implementează nevoi specificate, care sunt întotdeauna legate de satisfacerea anumitor cerințe.

Lucrul cu cerințe este supus managementului. Cerințele nedefinite cauzează incertitudine pentru toți participanții la lucru, deoarece permit interpretări diferite ale cerințelor și nu vor permite o evaluare obiectivă a calității produsului dezvoltat.

Atunci când se formează un sistem de cerințe, este necesar să se analizeze disponibilitatea resurselor la dispoziția clientului și dezvoltatorului: financiar, de producție, uman, de timp, precum și luarea în considerare a cerințelor autorităților de supraveghere și de licențiere, de exemplu, la proiectarea complexelor (producţiilor) tehnologice.

Cele mai des de control sunt organele regionale Rostekhnadzor, Rosstandart, Rospotrebnadzor, Rosprirodnadzor etc.

Mai jos sunt exemple ale structurii specificațiilor tehnice din diverse surse.

    De exemplu, o declarație de lucru poate conține secțiuni:

    subiectul specificațiilor tehnice;

    scopurile lucrării care se desfășoară;

    cerințe de raportare;

procedura de organizare a muncii;

    Un exemplu din GOST 19.201-78 de mai sus.

    introducere;

    motive de dezvoltare;

    scopul dezvoltării;

    cerințe pentru un program sau un produs software;

    cerințe pentru documentația programului;

    indicatori tehnico-economici;

    etape și stadii de dezvoltare;

    procedura de control si acceptare;

Aplicațiile pot fi incluse în specificațiile tehnice.

    Următorul exemplu de termeni de referință pentru furnizarea de servicii de consultanță

    prevederi generale;

    scopul muncii;

cerințele de calificare pentru candidați.

    Exemplu de cadru de referință pentru realizarea lucrărilor de cercetare „Elaborarea unui concept, strategie de dezvoltare și studiu de fezabilitate pentru crearea unui parc de inovare tehnologică în Perm” (denumit în continuare R&D)

    interpret și co-interpreți

  1. sarcini de cercetare

    date sursă

    cerinţele de bază pentru efectuarea cercetării

    program de cercetare

    utilizarea intenționată a rezultatelor cercetării

    procedura de livrare și acceptare a rezultatelor cercetării

Un exemplu de structură a unui șablon TOR pentru cercetare și dezvoltare

    Baza lucrării

    Executor testamentar

    Timpul de lucru

    Scopul lucrării

    Rezultatele cercetării și dezvoltării

    Produse în curs de dezvoltare

    Cerințe tehnice

    Principalii parametri care trebuie atinși ca rezultat al lucrării:

    Cerințe de bază de proiectare (dacă este cazul)

    Cerințe în funcție de tipul de garanție (dacă este cazul)

    Cerințe pentru standardizare, unificare, compatibilitate cu obiectele aferente și interschimbabilitate.

    Cerințe pentru asigurarea siguranței vieții și sănătății umane și protecția mediului

    Cerințe de fiabilitate (dacă este cazul)

    Cerințe de fiabilitate și durabilitate.

    Cerințe privind ergonomia și estetica tehnică (dacă este cazul)

    Cerințe pentru funcționare, ușurință în întreținere și întreținere (dacă este cazul)

    Cerințe de rezistență (dacă este cazul)

    Cerințe de performanță (dacă este cazul)

    Cerințe de certificare

    Alte cerințe și cerințe speciale ale industriei

    Cerințe privind puritatea și brevetabilitatea brevetului

    Cerințe de documentare

    Procedura de acceptare a lucrării.

Astfel, analizând structura din exemplele date, se poate observa că structura și conținutul sarcinii tehnice sunt dictate de sarcina care trebuie îndeplinită.

Caracteristici ale elaborării specificațiilor tehnice pentru un proiect inovator

Proiectele de inovare sunt evenimente unice deoarece sunt asociate cu transformarea ideilor științifice și tehnice în produse noi sau îmbunătățite, precum și în procese tehnologice noi sau îmbunătățite utilizate în activități practice sau în noi abordări ale serviciilor sociale. Trebuie să facă ceva ce nu s-a mai făcut până acum. Și experiența trecută poate oferi doar îndrumări limitate cu privire la ce să te aștepți. Prin urmare, proiectele inovatoare au un grad ridicat de incertitudine și risc, iar aceasta este particularitatea lor.

Dezvoltarea unui proiect inovator are ca scop găsirea de soluții pentru a obține ideea finală dorită a proiectului și crearea unui set de sarcini și activități care vor lega împreună timpul, resursele și performanții pentru a implementa acest proiect inovator. În timpul implementării sale, orice proiect inovator parcurge o anumită cale: de la faza de dezvoltare a ideii până la faza de irelevanță a ideii. Etapa de elaborare a specificațiilor tehnice se referă la etapa inițială a proiectului de inovare.

Într-un proiect inovator, când se creează complet produs nou Este dificil să se planifice toți parametrii în avans, prin urmare se propune utilizarea specificațiilor tehnice extinse dinamice, care sunt în principal de natură descriptivă.

Primul pas după ce ideea unui produs nou este generată este crearea unui catalog de cerințe, care poate include cerințele clienților, segmentarea pieței pentru noul produs, norme, standarde, obiective generale (cota de piață, costuri), timpul de până la piață, durata ciclului de viață, evaluarea generală a riscurilor.

Indicatorii conturați în catalogul de cerințe sunt specificați într-un document numit specificație tehnică extinsă.

Dacă catalogul de cerințe este compilat în „limba clienților”, atunci specificația tehnică extinsă este compilată în „limba întreprinderii”. Specificația tehnică extinsă ar trebui să includă, în plus față de punctele tradiționale (sfera lucrării, raportare, date inițiale, cerințe pentru parametri etc.) și câteva elemente ale planului de afaceri pentru proiect (politica de prețuri propusă, cota de piață planificată, cifra de afaceri planificată). , etc.).

Întrucât catalogul de cerințe este creat din punctul de vedere al clientului, limbajul de redactare a catalogului de cerințe este și el ales pentru a fi înțeles de client (fără detalii tehnice specifice). Catalogul de cerințe reflectă propunerile întreprinderii ca răspuns la nevoile clienților.

Specificația tehnică extinsă poate include:

1. Descrierea proiectului

2. Obiectivele de piață și economice ale proiectului

3. Parametrii de sincronizare

4.Parametrii tehnici

5.Parametrii de producție

8. Cerințe de design și ergonomie

9. Standarde și reglementări

Astfel, sarcina principală a întocmirii unei specificații tehnice extinse este de a colecta informațiile cele mai complete despre produsul în curs de dezvoltare, care sunt utilizate ca bază pentru planificare.

Informațiile din TOR extins sunt specificate în continuare în ceea ce privește structura produsului, care este o listă a tuturor componentelor care vor alcătui rezultatul proiectului. Planul structurii rezultatului proiectului conține toate componentele, blocurile și nodurile produsului care este creat.

Cele mai importante elemente ale specificației tehnice sunt: ​​scopul lucrării, domeniul de aplicare a rezultatelor, conținutul lucrării, programul de implementare a acesteia, indicatori tehnici, economici și de altă natură, cerințele pentru lucrare, nivelul și metoda de implementare a acesteia, rezultatele muncii, valoarea științifică, tehnică și practică a rezultatelor așteptate; utilizarea preconizată a rezultatelor și tipul și forma de prezentare a materialelor de raportare.

Să luăm în considerare locul TK în structură proces de inovare în organizație(introducerea inovaţiilor în organizaţie) conform.

Inițial, este dezvoltat un concept de inovație. Care este precedată de o etapă de cercetare (sondajul organizației, selecția indicatorilor de performanță pentru activitățile sale viitoare de inovare, justificarea listei de activități necesare implementării inovațiilor).

Conceptul de inovare de către echipa formată de dezvoltatori este dezvoltat într-o sarcină (TOR) pentru dezvoltarea unui proiect inovator, care trebuie să conțină toate justificările, setările inițiale și parametrii necesari pentru proiectarea ulterioară.

Pe baza sarcinilor de dezvoltare a unui proiect inovator, se întocmește apoi un plan de acțiune detaliat pentru dezvoltarea și soluționarea sarcinilor individuale, precum și pentru monitorizarea implementării acestora (etape de referință, lista parametrilor controlați, criterii de control etc. ).

În esență, termenii de referință și planul evenimentului stau la baza dezvoltării unui proiect inovator.

  • Conținutul proiectului este descrierea și reglementările activităților planificate, calculele utilizării optime a resurselor, evaluarea rezultatelor așteptate ale implementării, aduse la valori cantitative. La baza unui proiect inovator se află părțile sale organizaționale și financiare.

    Urmează etapele de adaptare și implementare a proiectului și analiza rezultatelor proiectului.