O lectie de Gathering Requirements

Postat la octombrie 20, 2012

Sedinta operationala, care se tine in fiecare dimineata, dureaza intotdeuna trei ore in loc de una. De multe ori am senzatia ca aceasta sedinta se tine doar pentru a ne preface ca muncim (o parte din invitati intarzie, unii casca, altii isi verifica mailurile, altii conturile de Facebook). Bineinteles ca in cele trei ore de discutii, vorbim si despre lucruri serioase: planuri pe termen lung, programe de loializare, insa toate au ramas doar la stadiul de dorinte. Practic nu am reusit sa semnam nici un contract cu vreun partener strategic si nici sa vindem ceva. Desi suntem in rahat pana la gat, inca visam la “planuri care vor schimba lumea“…

CEO-ul imi cere sa gandesc in termeni precum “strategie”, “viziune”:

-Daca cel care a facut iphone-ul, D-zeu sa-l odihneasca, nu ar fi avut “viziune” acum nici noi nu mai fi aici!

Cu totii eram numai ochi si urechi  la vorbele de “duh” ale CEO-ului, ca la un duhovnic.

-Peste un an, se vor ruga  partenerii mari sa semneze contractele si noi nici nu o sa ne uitam la ei! adauga CEO-ul amenintator, in ciuda faptulului ca nu reusisem sa semnam nici un contract important. 

Apoi CEO-ul aratand cu degetul aratator catre cer a continuat euforic:

-Parca ii si vad, cum peste un an, or sa ne bata la usi partenerii, iar noi o sa le spunem: Nu ati vrut atunci, acum nu mai vrem noi…

(Adevarul e ca peste un an, s-ar putea ca startupul nostru nici sa nu mai existe…)

-Aduna te rog toate ideile de la toti si hai sa facem un plan pe termen lung! In momentul de fata ne lipseste o viziune de ansamblu

CEO-ul pune capat sedintei cu aceleasi vorbe de duh: “Get it done!”, “You lead it!” pe care le repeta ca un laitmotiv la sfarsitul fiecarui “speech” si care, in contextul ultimelor evenimente, a ajuns tinta glumelor tuturor angajatilor.

Procesul de “Gathering Requirements” (o viziune de ansamblu)

In ultimele 8 luni de zile de sedinte, reusisem sa adunam o tona de idei si cerinte din care 80% erau intrebari fara raspuns “Ce ar fi daca schimbam culoarea? De ce asa si nu altfel?” si 20% cerinte de tipul “Investigati cum putem modifica aplicatia noastra in asa fel incat sa o vindem. Totul e clar pana aici, nu? Get it done! You lead…

Inainte de a prezenta cum arata cerintele unui produs in F-Startup, iata cum arata stakeholderii care definesc cerintele:

requirements

Pentru a putea aduna si tria cerintele care vor face parte din scopul unui produs, am desenat urmatoarea Matrice a Stakeholderilor, in ordinea importantei lor:

Stakeholder Matrix

Am inceput sa colectez cerintele stakeholderilor pozitivi incepand cu cei din cadranul 1 (cei putere de decizie si cu interes mare fata de proiect), apoi am continuat cu cei din cadranul 2, 3, 4. Cand vine vorba de stakeholderii negativi, situatia se complica. De exemplu, unul din key stakeholderi a refuzat sa imi dea specificatiile, motivand ca “Eu nu sunt destul de bine platit sa fac asta“. Asadar, cerintele lui fiind incomplete nu au fost adaugate in plan, insa stiu sigur ca la finalul proiectului, va avea pretentia ca cerintele lui sa fie satisfacute. Un alt stakeholder negativ mi-a furnizat specificatii contradictorii, in mod intentionat, pentru a putea ulterior sa nege faptul ca el a cerut asa ceva si sa poata renegocia termenii cerintelor sale. Acest tip de stakeholderi eu ii consider a fi de tip  “terorist/kamikaze”, fiind in stare sa arunce in aer intreaga cladire numai ca proiectul sa nu iasa… In legatura cu stakeholderii de tip negativ, nu stii la ce sa te astepti de la ei, asadar asigurati-va ca purtati intotdeuna cu voi un pistol si aveti nevoie de ochi si la spate!

Dupa lungi dezbateri, la final am obtinut o lista cu urmatoarele cerinte:

product scope contains only formal requirements

Initial imi notasem peste o suta de cerinte, insa mai bine de jumatate au ramas neclarificate sau au fost eliminate din scop deoarece erau invalide fiind fie dorinte nerealiste (“Vreau sa ma imbogatesc de pe urma produsului”) fie cerinte nescrise (hidden agenda). La final au ramas doar cu acele cerinte “high-level”, care in teorie poarta numele de Product Scope Document (echivalentul temelor si epicilor din Agile). Din totalitatea cerintelor, doar cele scrise vor face parte din Product Scope!

Cerintele detaliate

Dupa ce am obtinut lista de specificatii “high level”, COO-ul ma ia deoparte si imi spune:

-Ei acum avem cerintele. Apuca-te sa le estimezi efortul!

Initial am crezut ca glumeste:

-Doar nu vorbesti serios? Cum sa fac estimari pe aceste notite? Ele reprezinta niste povesti spuse la betie. Ar trebui sa le analizez si sa le detaliez inainte sa le estimez.

-Pai ai cerintele… de ce nu poti sa le estimezi?

Ce anume e fundamental gresit in aceasta abordare?

Cerintele “high-level” (sau in Epics sau Theme) sunt uneori atat de vagi incat nu pot fi estimate. In urma unei analize simple, poate rezulta ca unele pot fi la randul lor proiecte in sine care nu pot fi estimate la nivel de cost, timp, resurse, etc. Intrucat detalierea tuturor cerintelor poate sa ia un timp nedefinit de mare, era util sa pot detalia initial doar o parte din cerinte.

Ce anume detaliem?

PMBOK spune ca detaliere amanuntita are loc la inceputul proiectului, in procesul de Planificare, dupa colectarea specificatiilor “high level” de proiect din procesul de Initiere, cand pe baza Project Charter-ului sau al documentului care defineste scopul produsului (Product Scope Document, Product Requirements Document, etc.) se colecteaza o specificatiile initiale ale proiectului. Desi in teorie detalierea tuturor cerintelor se realizeaza in procesul de Planificare, totusi, in cazul unui proiect al carui obiective si cerinte sunt neclare, detalierea se poate face si mai tarziu, in mai multe etape. Metoda detalierii in mai multe etape (sau “valuri”, “waves”) este foarte asemanatoare cu planificarea de tip “iceberg” din Agile sau mai poarta denumirea si de tehnica Rolling Wave Planning in PMBoK (detalierea pe masura ce proiectul inainteza si cerintele devin mai clare). Motivul pentru care nu este bine sa detaliem totul de la bun inceput, in faza de Planificare, este ca nu stim sigur daca cerintele definite acum vor mai fi relevante in viitor (ganditi-va ca firma poate sa isi schimbe domeniul de activitate sau pur si simplu sa dispara in viitor)… Avantajele detalierii in “valuri” (wave planning) sunt uriase: castigi timp detaliind doar cerintele care sunt importante in viitorul apropiat, iar acest lucru permite si dezvoltarea sa se inceapa mult mai inainte ca scopul proiectului sa fie pe deplin cunoscut. Cerintele care nu sunt importante in viitorul apropiat, vor ramane doar la stadiul de specificatii “high level”.

Totusi cum stim care sunt acele cerinte cu adevarat importante?

M-am gandit sa convoc adhoc o alta sedinta cu stakeholderii cheie, la doar 3 ore de la sedinta de dimineata, pentru a determina care sunt acele cerintele importante din punct de vedere al companiei. Reactia COO-ului a fost:

-Ce sedinta? Credeam ca ne-am inteles ce avem de facut… Unde ne sunt estimarile?

-Pai nu as putea face estimarile fara sa cunosc prioritatile.

-Lasa prioritatile, fa te rog mai intai estimarile. Daca un feature dureaza putin, atunci el devine prioritar…

Alegerea prioritatilor in functie de cat dureaza implementarea acestora, este o abordare nerealista. Se poate intampla ca lucrurile care dureaza putin sa nu fie importante din punct de vedere al afacerii, iar rezolvarea lor prematura ar putea sa impacteze negativ asteptarile clientilor. Asadar prioritatile nu se aleg doar in functie de timp, ci de toti factorii si constrangerile proiectului (anvergura, bani, timp, resurse, calitate, riscuri, satisfacerea clientilor).

CEO-ul a refuzat participarea la sedinta, motivand planificarea prea din scurt:

-Nu am cum sa particip. Pune si tu sedinta din timp. Nu se poate fara mine?

-Imi pare rau, nu se poate! Decizia ta e cea mai importanta! am incercat sa ii perii orgoliul.

Insa in ciuda insistentelor mele nu a acceptat invitatia. Incepe sedinta. In sala, grupul de experti si COO-ul.

-Imi pare rau ca am convocat aceasta sedinta din scurt. Dar consider ca este foarte important sa continuam cu prioritizarea functionalitatilor. As vrea ca la finalul acestei sedinte sa decidem, de comun acord, importanta specificatiilor.

COO-ul s-a aseazat confortabil in scaun, binedispus. In lipsa CEO-ului, fiind a doua persoana in firma cu putere de decizie, COO-ul facea legea:

-Ce e functionalitatea asta? Banuiesc ca toata lumea e de acord ca este putin importanta, da? Low importance. Urmatoarea: Very important, low importance, very low. (COO-ul incepuse frenetic sesiunea de alegere a prioritatile ca la un joc de Bingo)

In 5 minute, COO-ul decisese importanta a 50% din functionalitati. Apoi, neasteptat si-a facut aparitia si CEO-ul. S-a lasat tacere in sala, iar lucrurile au revenit la “normal”: dupa ce toata lumea si-a dat cu parerea, CEO-ul decide peste toti:

“-Very important. Urmatoarea!”

Ce sedinta mai e si asta? ma gandesc. Prioritatile alese nu aveau nici o justificare. Dupa terminarea sedintei, imi dadusem seama ca facusem o mare greseala: intrucat le spuseseram stakeholderilor ca va urma o sedinta de “alegere a priorititatilor de business”, toata lumea a ramas cu ideea ca in sedinta se va decide ordinea in care se vor implementa lucrurile (adica prioritatile) si nicidecum importanta functionalitatilor din punct de vedere al businessului. Iata ce am obtinut:

Business Values

Intrucat lista pe care o obtinusem nu era o lista de prioritati, ci o lista de importanta functionalitatilor din punct de vedere al stakeholderilor cheie, am rugat echipele de dezvoltare sa faca o estimare grosiera a efortului necesar implementarii lor (tinand cont de cost, timp, resurse, etc):

Business Values/Cost

Apoi pe baza unei analize de tip cost-beneficiu am stabili care sunt prioritatile (T1, T3, T4, T2). Se observa ca T4, care desi era considerata cu prioritate scazuta, din punct de vedere al businessului, practic devenise cu prioritate mare (pe baza indicelui Beneficiu/Cost, Benefit/Cost Ratio):

cost_benefit

Care este concluzia?

Daca avem un proiect cu specificatii vagi si obiective neclare, detaliere specificatiilor se realizeaza in pasi marunti:

1. Se porneste de la o detaliere partiala (o vedere de ansamblu; “high-level”) a tuturor functionalitatilor.

2. Se alege importanta/prioritatea fiecarei functionalitati din punct de vedere al organizatiei (Business Value sau Business Priority).

3. Se estimeaza Efortul (cost, timp, bani, resurse, etc) de implementare al functionalitatilor (fara a fi nevoie de o estimare precisa).

4. Pe baza valorilor Business Value si Efort, printr-o analiza analiza de tip cost-beneficiu (sau orice alta metoda) se prioritizeaza functionalitatile.

5. Pe baza listei de mai sus, ordonata fiind, se incepe detalierea completa doar a primelor functionalitati, urmand ca pe masura ce proiectul inainteaza sa se obtina o detaliere completa si a celorlalte cerinte (asemenea tehnicii Rolling Wave).

Toti pasii de mai sus pot fi rezumati intr-o singura imagine:

Product Icerberg - Only the top of the icerberg is known.
Planificarea de tip “Iceberg” (Numai varful iceberg-ului e cunoscut.)

Citeste mai departe despre: Factorii care pot influenta prioritatile, modelul Kano si o metoda logica de a alege prioritatile.

Anterior: Maestrul Papusar.

Fii primul care comenteaza

Leave a Reply

Your email address will not be published. Required fields are marked *