Exista in software development o meserie care, pe langa cunostintele de box (daca clientul este mai pirpiriu) si cele obligatorii de cross (daca acesta este mai bine facut), necesita abilitati de scriitor, detectiv, diplomat si soarece de biblioteca. Este asa numitul Requirements Engineer sau, cum mai este el numit in unele companii, Business Analyst-ul. Rolul lui presupune identificarea acelei povesti de succes capabila sa puna un zambet larg pe chipul clientului lui.
In continuare, va propun sa aruncam o privire lipsita de pretentii asupra unei tehnici de investigastie bazata pe zece intrebari simple, ce poate fi utilizata cu succces in faza instiala de culegere a specificatiilor unui produs.
Incepem cu o intrebare scurta, simpla, care pune produsul intr-un context, ajutand clientul sa spuna povestea asa cum exista in mintea lui:
Cum ti-a venit ideea?
Dupa atatia ani de consultanta in requirements engineering si inca ma mir cate lucruri poti afla punand aceasta intrebare simpla. Riscuri, constrangeri, presupuneri nevalidate, barfe folositoare, inamici declarati si aliante posibile, ies toate la iveala. Tot ce ai de facut este sa iti iei cat mai multe notite si sa il lasi pe client sa vorbeasca.
Urmatoarea intrebare vine si atinge latura umana (sociala, in unele cazuri) a produsului:
Cine sunt ei, acele entitati (oameni sau organizatii) care vor interactiona in mod activ cu produsul?
Am subliniat expresia „in mod activ” deoarece trage linia de demarcatie intre stakeholders (parti interesate, in limba romana) si utilizatori, acele entitati care vor exploata produsul. Cel mai simplu aceasta diferenta se poate explica daca ne gandim la construirea unei case, unde, desi autoritatea locala reglementeaza prin norme regimul de inaltime al cladirii, adancimea fundatiei (si daca pot, sau nu, sa imi vopsesc gardul de la strads in roz-bombon), nu urmeaza sa locuiasca in respectiva casa (normal, cu conditia sa nu fie vorba despre noul sediu al primariei, moment in care se schimba socoteala).
Tot aici, obisnuiesc sa pun o intrebare de completare:
Cine sunt ei, cei care vor aplauda sau vor fi nemultumiti de aparitia acestui produs? Are produsul nevoie de vreo aprobare din partea organismelor oficiale?
Astfel, sporesc sansele de identificare a celor ce nu se vor feri sa ne puna piedica daca se iveste ocazia. Stiti cum se spune, tine-ti prietenii aproape, iar pe dusmani si mai aproape.
Intrebarea care urmeaza adauga noi detalii la lista obtinuta:
Care sunt nevoile lor?
Acordati atentie maxima acestor raspunsuri, deoarece ele reprezinta ratiunea de a exista a produsului.
Imediat dupa aceasta mai fac o trecere:
Care sunt motivatiile nevoilor lor?
Diferenta intre nevoi si motivatii este un fina, dar foarte importanta. De exemplu, un client isi poate dori un site de curierat perfect functional (pe care insa nu il va exploata comercial) doar ca sa il aiba in portofoliul lui pentru a intruni conditiie de participare la o licitatie – caz in care nevoia nu mai coincide cu motivatia. La fel, un oficial guvernamental isi poate folosi influenta pentru a se opune unei initiative din simplul motiv ca nu il suporta pe respectivul project manager.
In continuare, urmatoarea intrebare adreseaza aspectul functional al produsului – de la distanta partea cea mai complicata de identificat si explicat:
Cum urmeaza sa satisfaca produsul nevoile partilor implicate (stakeholders)?
Ideal, raspunsurile la aceasta intrebare se constituie sub sub forma de fluxurilor de lucru (workflows), care explica cum sunt satisfacute nevoile partilor interesate (stakeholders). Nu va multumiti sa intrebati „Ce trebuie produsul sa faca?”; asigurati-va, inca de la inceput, ca exista o legatura directa intre functionalitatile cerute si nevoile existente.
Pentru produsele informatice, intrebare care urmeaza este una de o importanta maxima, deoarece clarifica „cine ce face”, cat si diferitele niveluri de acces necesare:
Ce roluri (vizitator, utilizator autentificat, moderator, backup operator, administrator etc.) sunt necesare?
Din experienta va pot spune ca o multime de functionalitati apar datorita acestor diferentieri: necesitatea unui sistem de autentificare, posibilitatea de a sterge anumite comentarii, o interfata specifica de administrare etc.
Dimensiunea temporala a produsului este cercetata cu ajutorul urmatoarei intrebari:
Care sunt momentele in timp (ca zile/ore marcate in calendar) importante pentru produsul dezvoltat?
Cand are loc petrecerea de lansare a produsului? Care sunt perioadele in care se acorda reduceri? Care este momentul din zi/ziua din saptamana/luna din an in care activitatea este cea mai intensa? sunt intrebari care pot scoate la lumina o multime de specificatii non-functionale (performanta, scalabilitate, siguranaa datelor si a tranzactiilor etc) care altfel ar putea scapa neobservate.
Penultima intrebare (da, aproape am terminat) adreseaza dimensiunea fizica a produsului:
Care sunt locatiile fizice in care prezenta produsului va fi (intr-o forma sau alta) resimtita?
Punand acest gen de intrebari veti obtine o imagine mai clara asupra diferitelor aspecte de natura geografica de care va trebui sa tineti seama: In ce tari/orase va fi folosit produsul? Unde vor exista fizic serverele de hosting? Dar cele de backup? Care este diferenta de fus orar dintre echipa de dezvoltare si echipa de IT operations?
Ultima intrebare nu este o intrebare de sine statatoare, ci vine si adauga informatii de natura cantitativa raspunsurilor obtinute pana acum:
Cat de mult, in ce cantitate?
Cati administratori vor exista (un singur super admin sau mai multi avand drepturi egale)? Cati utilizatori concurenti pe secunda? Cate comenzi pe minut/ora? Cat spatiu de stocare este necesar? si asa mai departe. Incercati sa obtineti pentru fiecare valoare numerica trei valori, valoarea ideala, valoarea acceptabila si valoarea de supravietuire (o unitate mai jos si situatia devine de nesuportat).
In incheiere, va propun sa revedem succint intrebarile ce pot fi utilizate in faza initiala de obtinere a specificatiilor unui produs:
- Cum ti-a venit ideea?
- Cine sunt ei, acele entitati (oameni sau organizatii) care vor interactiona in mod activ cu produsul?
- Cine sunt ei, cei care vor aplauda sau vor fi nemultumiti de aparitia acestui produs? Are produsul nevoie de vreo aprobare din partea organismelor oficiale?
- Care sunt nevoile lor?
- Care sunt motivatiile nevoilor lor?
- Cum urmeaza sa satisfaca produsul nevoile partilor implicate (stakeholders)?
- Ce roluri (vizitator, utilizator autentificat, moderator, backup operator, administrator etc.) sunt necesare?
- Care sunt momentele in timp (ca date/ore marcate in calendar) importante pentru produsul dezvoltat?
- Care sunt locatiile fizice in care prezenta produsului va fi (intr-o forma sau alta) resimtita?
- Cat de mult, in ce cantitate?
Aceste intrebari au fost obtinute folosind o forma modificata a celebrei tehnici de interviu intitulata „Five Ws and one H” – pentru detalii, vezi wikipedia (se deschide intr-o pagina noua) si au fost alese in asa fel incat sa aseze produsul intr-un context multidimensional:
O ultima nota de avertizare celor ce intentioneaza sa folosesca aceasta tehnica de interviu. Lasati discutia sa decurga liber, oferind cat mai mult spatiu clientului sa isi exprime dorintele (aveti doar grija sa ramana la obiect, sa nu inceapa sa bata campii). Daca se apuca sa va spuna unde si-ar dori sa fie amplasate serverele de backup nu il intrerupeti cu o intrebare despre petrecerea de inaugurare a produsului doar pentru simplul fapt ca When este in imaginea de mai sus inaintea lui Where. Altfel spus, nu fracturati procesul de gandire al clientului; oamenilor le place sa povesteasca, nu sa li se ia un interogatoriu.
Folositi aceasta suita de intrebari ca pe o lista de cumparaturi (in fond, acesta este motivul pentru care va aflati acolo, pentru a cumpara informatii), care va ajuta sa fiti sigur ca nu ati uitat ceva, fara sa specifice ordinea in care trebuie sa navigati prin supermarket.
Articol scris de Dan Radoiu, trainer
