Cum de a scrie cerințe

Una din principalele sarcini ale proiectului-manager (PM) - este colectarea de cerințe și de a le proiecta în sarcina de proiectare. Clientul aduce descrierea unui anumit domeniu subiect pentru care doriți să program de punere în aplicare. În cazul nostru, este, de obicei, un proiect web. În cazul în care pentru a începe? Cum să transmită la dezvoltator, mai degrabă, la echipa de dezvoltare, esența problemei și că acestea trebuie să facă? Aceasta simplifică procesul arată astfel: cerințe colectarea, specificarea lor caietul de sarcini cerințele de scris, punerea în aplicare. Să vorbim despre prima parte a lanțului - cerințe de colectare și rafinament.

În mod ideal, aș dori să primesc PMU - un document în care clientul a descris tot ceea ce el știe despre domeniu, modul în care proiectul ar trebui să fie utilizat de către utilizator ca și în cazul în care clientul a dorit să gestioneze un proiect, am arătat un design, gândit la dezvoltarea viitoare. Vis, cum se spune, nu este dăunătoare. Pentru că niciodată nu se întâmplă.

Ca de obicei cerințele primite

Cerințele pot veni printr-un sistem de management de activitate, prin e-mail, Skype, la o întâlnire într-o conversație. calitate și detaliu descrierile sunt de obicei limitate și trebuie să fie clarificate. Nu este nimic special, clarificarea cerințelor - acesta este un proces normal de lucru. Adesea, cei care se confruntă cu cerințele de scris pentru prima dată, puteți auzi următoarea propoziție: „Eu nu pot scrie TK, asa ca nu-mi cere să cerințe.“ Aici este necesar să se împartă termenii de referință și cerințe.

Clienți - nu un programator, TK nu poate scrie, de la el nu este obligatorie. Ceea ce se cere de la client, care a venit cu locul de muncă - este de a cunoaște zona dvs. subiectul și să răspundă la întrebări pentru a clarifica cerințele. Se întâmplă că răspunsul este destul de problematică pentru a atinge.

Ce sunt conectați

Clientul nu are cunoștință sau nu pe deplin conștient de ceea ce vrea de la angajator managerul / senior, și, în consecință, nu pot formula cereri pentru o sarcina. În acest caz, dezvoltatorii cu sarcina mai bine să nu vină, nici o voință bună într-un astfel de proiect. Mai bine pentru a merge în direcția opusă și de a primi informații de la sursă. Clientul nu competentă în domeniul dezvoltării și timid să-și exprime gândurile într-un limbaj simplu. Aceste dificultăți sunt rezolvate rapid, ca pMa sarcină - pentru a vorbi cu interlocutorul, pune întrebări de sondare și de a extrage informații. De altfel, descrierea cerințelor într-un limbaj „civil“ simplu - este binevenit. Mult mai rău, atunci când termeni tehnici care nu se aplică în cazul.

De ce nu putem „face într-un fel“

Dacă un client cu cele de mai sus conectându-l propune să facă o „oarecum“, „la discreția ta.“ pete albe în cererile și propunerile „sa faca ceva“ - este rău. Algoritmul este „într-un fel“ nu scrie în ea totul ar trebui să fie strict. Tanarul designer de, uita la o astfel de descriere, face ochii mirați, și dezvoltator experimentat va programa în felul lor. În primul caz, sarcina nu va fi efectuată în al doilea - se va efectua nu așa cum doriți de afaceri.

Cum ne asigurăm că totul a fost bine

Aveți nevoie de un feedback rapid pentru a clarifica cerințele și de a lua decizii. În viața reală nu obține întotdeauna feedback-ul rapid, de exemplu, atunci când un client - un top și este dificil să se ajungă.

Cerințe pentru detaliu într-o asemenea măsură, încât nu va fi nici o întrebare din partea dezvoltatorilor. Desigur, acestea vor apărea în procesul de codificare, dar cerințele o vom repara într-un stat în cazul în care dezvoltatorul pentru prima dată, a devenit clar pentru el. Detalierea cerințe - este o colaborare între client și PMA. exemplu de viață: pretențiile inițiale primite de la client pe aceeași pagină (cu două imagini pe ea încă), după actualizarea sa transformat în 19 pagini. Aceasta este de 18 de pagini de informații a fost tras de la client în procesul de aprobare a cerințelor care au fost aduse la un grad de detaliu care este necesar pentru a începe dezvoltarea.

Nu aveți nevoie pentru a proiecta cerințele de arhitectură. Există 80 de niveluri de clienți prin pompare. care se îngropa în subiect, astfel încât cerințele încep să proiecteze o aplicație sau pentru a construi schema bazei de date. Acest lucru este prea mult. Pe partea echipei de dezvoltare există întotdeauna omul care a inventat arhitectura și va fi responsabil pentru ea. Dar responsabilitatea pentru care le sunt impuse de către acești oameni nu le place partea a arhitecturii.

Asigurați-vă că pentru a înregistra acordul. Informații verificate viață pe termen lung în diferite capete de proiect congestionate - două săptămâni. piese După aceea, sarcina nefixate este uitat sau pierdut, noi fantezii, sarcina începe să sune diferit. Un bun instrument de a stabili cerințe - Documente Google, există întotdeauna o versiune vizibilă actualizată, puteți configura dreapta, vizualiza istoricul modificărilor.

Adu cerințele dumneavoastră, vom clarifica cu ei :)