Uncertainty of requirements

8 ian.

Requirements se referă la totalitatea documentelor (word, excel, visio, power point, etc) oferite echipei de dezvoltare la începutul și în timpul oricărui proiect. Acestea sunt discutate și analizate apriori sau nu cu clientul iar apoi prezentate departamentului de R&D pentru documentarea tehnică și arhitecturală. Dacă metodologia de lucru aleasă este waterfall atunci ar trebui să fie apriori, dacă este agile atunci e o muncă ongoing pe toată durata proiectului.

Și acum să trec la subiect.

Oare ce determină ca requirementurile primite ca dezvoltatori software să fie atât de ”incerte”? Ca o paranteză, un set de cerințe slab documentat este una dintre cauzele principale ale eșecurilor proiectelor software (am găsit statistica asta pe undeva dar nu mai știu pe unde). De multe ori procesul de culegere a cerințelor beneficiarilor lipsește cu desăvârșire sau dacă nu lipsește este atât de slab efectuat încât calitatea documentelor prezentate (SRS, mockup, diagrame de modelare) lasă foarte multe de dorit și nu surprind destul de mult esența proiectului. De ce se întâmplă asta? Trei dintre motive pot fi constrângerile de timp, persoana delegată să facă asta nu e up to the job și clientul are doar o viziune nu ceva concret.

Cel care adună cerințele (să-l denumim business analyst – BA) trebuie să documenteze și să înțeleagă câteva chestii foarte bine:

  • cine sunt clienții
  • cine sunt utilizatorii
  • cine sunt cei care plătesc
  • care sunt dorințele și necesitățile acestora
  • cât de bine este înțeles domeniul și problema ce se vrea rezolvată
  • care este return on investment
  • care este criteriul de succes al proiectului
  • documentația oferită oferă destule informații

BA de asemenea trebuie să fie conștient că pentru un nou software cerințele vor fi cunoscute mult mai bine (dacă nu chiar în totalitate) de abia după ce end-userii vor fi folosit ceea ce a fost livrat. Normal, sunt domenii unde cerințele sunt finalizate apriori (de exemplu domeniul bancar, automotive, etc). Din păcate (sau din fericire) incertitudinea este inerentă și inevitabilă în domeniul IT.

Ce se poate face în cazul ăsta? Simplu. Îmbrățișează cu putere incertitudinea și adaptează-te ei. Cum poți face asta? Rezolvarea este, din nou, una simplă.

  • evită pașii mari. fă totul iterativ. nu încerca să planifici tot proiectul de la început.
  • oprește-te, inspectează și adaptează
  • ia feedback de la client cât mai repede cu putință
  • după ce primești feedback decide care este următorul pas

Agile, frate! Integrarea filosofiei agile în procesul de culegere a cerințelor te poate salva de niște dureri de cap.

Nu fi egoist, dă mai departe să ajungă la tot poporul

3 Replies to “Uncertainty of requirements

  1. Pingback: Despre requirements — Felix Vătuiu

Lasă un răspuns

Acest site folosește Akismet pentru a reduce spamul. Află cum sunt procesate datele comentariilor tale.