Proză în IT: Requirements Engineering

Există în software development o meserie care, pe lângă cunoștințele de box (dacă clientul este mai pirpiriu) și cele obligatorii de cros (dacă acesta este mai bine clădit), necesită abilități de scriitor, detectiv, diplomat, și șoarece de bibliotecă. Este așa numitul Requirements Engineer sau, cum mai este el numit în unele companii, Business Analyst-ul, al cărui rol presupune identificarea poveștii de succes capabilă să pună un zâmbet larg pe chipul clientului lui.

Să aruncăm o privire lipsită de pretenții asupra unei tehnici de investigație bazată pe opt întrebări simple, ce poate fi utilizată cu succes în faza inițială de culegere a specificațiilor unui produs.

Începem cu o întrebare care pune produsul într-un context, ajutând clientul să spună povestea așa cum există în mintea lui:

Cum ți-a venit ideea?

Puneți această întrebare și fiți pregătiți să luați notițe. Riscuri, constrângeri, presupuneri nevalidate, bârfe folositoare, inamici declarați și alianțe posibile vor ieși la iveală, oferind un context de fundal produsului (obiectivul final), cât și proiectului (munca necesară obținerii obiectivului final).

Cine sunt ei, acele entități de care trebuie să țină cont produsul?

Mai exact, cine sunt:

  • Cei care vor utiliza produsul (consumatorii finali).
  • Cei care vor menține produsul odată ce el a fost finalizat (IT ops, application administrators etc).
  • Cei care vor finanța proiectul (investitorii).
  • Organismele statului implicate în derularea proiectului și/sau în exploatarea produsului (acordarea drepturilor de autor, prelucrarea datelor personale etc).
  • Partenerii comerciali, cei care vor factura pe proprietarul produsului (diferiți furnizori) sau vor fi facturați de către acesta (agregatori de servicii).
  • Competitorii, indivizi sau organizații pot influența negativ derularea proiectului sau exploatarea produsului.

Care sunt nevoile lor?

Ce le trebuie, exprimat în formă fizică (o interfață utilizator, acces la baza de date, rapoarte financiare, persoană de contact etc.) pentru fiecare dintre categoriile enumerate la punctul anterior.

Care sunt motivațiile lor?

Diferența între nevoi și motivații este un fină, dar foarte importantă. De exemplu, un client își poate dori un site de curierat perfect funcțional (pe care însă nu îl va exploata comercial) doar ca să îl aibă în portofoliul lui pentru a întruni condițiile de participare la o licitație – caz în care nevoia nu mai coincide cu motivația. La fel, un oficial guvernamental își poate folosi influența pentru a se opune unei inițiative din simplul motiv că nu îl suportă pe respectivul project manager.

Cum va satisface produsul motivațiile lor?

Adică, cum prin intermediul elementelor de natură fizică (nevoile) vor fi satisfăcute motivațiile:

  • Prin intermediul interfeței grafice, utilizatorul logat va trimite mesaje către prietenii lui.
  • Actualizarea prețurilor se va face direct prin modificarea înregistrărilor din baza de date.

Care sunt momentele în timp (ca zile/ore marcate în calendar) importante pentru produsul dezvoltat?

Când are loc petrecerea de lansare a produsului? Care sunt perioadele în care se acordă reduceri? Care este momentul din zi/ziua din săptămână/luna din an în care activitatea este cea mai intensă? sunt întrebări care pot scoate la lumină o mulțime de specificații non-funcționale (performanță, scalabilitate, siguranța datelor și a tranzacțiilor etc) care altfel ar putea scăpa neobservate.

Penultima întrebare (da, aproape am terminat) adresează dimensiunea fizică a produsului:

Care sunt locațiile fizice în care prezența produsului va fi (într-o formă sau alta) resimțită?

Punând acest gen de întrebări veți obține o imagine mai clară asupra diferitelor aspecte de natura geografică de care va trebui să țineți seama: În ce țări/orașe va fi folosit produsul? Unde vor exista fizic serverele de hosting? Dar cele de backup? Care este diferența de fus orar dintre echipa de dezvoltare și echipa de IT operations?

Ultima întrebare nu este o întrebare de sine stătătoare, ci vine și adaugă informații de natura cantitativă răspunsurilor deja existente:

Cât de mult, în ce cantitate?

Câte tipuri de administratori vor exista? Câți utilizatori concurenți pe secundă? Câte comenzi pe minut/oră? Cât spațiu de stocare este necesar per tranzacție? și așa mai departe. Încercați să obțineți pentru fiecare valoare numerică trei valori: cea ideală, valoarea acceptabilă și valoarea de supraviețuire (o unitate mai jos, iar situația ar deveni de nesuportat).

În încheiere, reluăm pe scurt întrebările ce pot fi utilizate în faza inițială de obținere a specificațiilor unui produs:

  • Cum ți-a venit ideea?
  • Cine sunt ei, acele entități de care trebuie să țină cont produsul?
  • Care sunt nevoile lor?
  • Care sunt motivațiile lor?
  • Cum va satisface produsul motivațiile lor?
  • Care sunt momentele în timp (ca zile/ore marcate în calendar) importante pentru produsul dezvoltat?
  • Care sunt locațiile fizice în care prezența produsului va fi (într-o formă sau alta) resimțită?
  • Cât de mult, în ce cantitate?

Aceste întrebări au fost obținute folosind o formă modificată a celebrei tehnici de interviu intitulată “Five Ws and one H” – pentru detalii, vezi wikipedia (se deschide într-o pagină nouă) și au fost alese în așa fel încât să așeze produsul într-un context multidimensional:

O ultimă notă de avertizare celor ce intenționează să folosească aceasta tehnică de interviu:

Lăsați discuția să decurgă liber, oferind cât mai mult spațiu clientului. Dacă începe să vă spună unde și-ar dori să fie amplasate serverele de backup nu îl întrerupeți cu o întrebare despre petrecerea de inaugurare a produsului doar pentru că When este în imaginea de mai sus înaintea lui Where. Nu fracturați procesul de gândire al clientului; oamenilor le place să spună povești, nu să răspundă la interogatorii.

Folosiți această suită de întrebări ca pe o listă de cumpărături care vă ajută să nu uitați să cumpărați tot ce vă trebuie, păstrându-vă libertatea de a lua din raft articolele în ordinea care vă satisface.

Share with your friends










Submit