Dezvoltarea de software există în cele din urmă, pentru a rezolva probleme de business și pentru a aduce în această zonă de activitate cât mai multă valoare. Dacă rolul nostru este cel de "analist de business" într-o companie software, simțim că nu ne atingem scopul dacă nu putem să identificăm nevoile reale de business și să facem dovada valorii de business pe care o aduc aplicațiile sau funcționalitățile care urmează să fie dezvoltate.
Pentru analiștii de business din companiile ce dezvoltă produse proprii, acest articol s-ar putea să nu dea naștere la discuții, pentru că aceștia își cunosc clienții, au acces direct la clienții lor și se gândesc în permanență la tehnici creative pentru a demonstra valoarea de business a produselor sau funcționalităților pe care ei și echipele lor le pot livra.
Pentru acei analiștii de business care nu trăiesc în această "lume perfectă", a demonstra valoarea de business a funcționalităților pe care le livrăm este o mare provocare. La acest gen de provocare mă voi referi în cele ce urmează.
Este destul să avem un număr setat ca "Valoare de Business" pentru fiecare user story? Ar trebui să punem sub semnul întrebării valoarea de business reală ce se ascunde în spatele acelui număr? Ne-ar ajuta acest lucru să oferim cea mai bună soluție posibilă și să facem lucrurile mai bine chiar de la început?
Să ne imaginăm următorul scenariu: avem valoarea de business "cuantificată" într-un număr pentru o anumită funcționalitate și rolul nostru este să dăm cea mai bună soluție într-un sistem informatic existent. Situația ideală (sau poate, normală) este atunci când cunoaștem nevoile reale de business din spatele acestei solicitări venite din partea clientului nostru.
Voi face referire în continuare la situațiile care nu sunt nici ideale și poate nici normale...
Întrebarea care îi deranjează cel mai mult pe clienții noștri (și mă deranja și pe mine, când eu eram în poziția clientului) este: "De ce ai nevoie de această funcționalitate?". Când eu eram în poziția clientului, mă deranja această întrebare deoarece credeam că eu știu cel mai bine motivele pentru care am nevoie de o anumită funcționalitate și care este valoarea de business adusă de aceasta. Nu credeam că este nevoie să dau vreo explicație dezvoltatorului de software.
Abia în rolul meu de acum (de partea dezvoltatorului de software) înțeleg cu adevărat de ce avem nevoie să cunoaștem răspunsul la această întrebare. Încerc acum să obțin răspunsul înlocuind întrebarea "De ce ai nevoie de această funcționalitate?" cu întrebarea: "Care este valoarea de business pe care ar aduce-o această funcționalitate?". Scopul principal al acestei întrebări este să înțelegem această valoare din spatele unei solicitări venite din partea clientului, astfel încât să putem acorda o soluție care îi face fericiți atât pe colegii de echipă, cât și pe clienții noștri.
Răspunsul la întrebarea: "Care este valoarea de business pe care ar aduce-o această funcționalitate?" nu îl ajută doar pe analistul de business, ci ajută întreaga echipă și clientul.
Acest răspuns ajută clientul să-și clarifice dacă are nevoie cu adevărat de funcționalitatea cerută. Acest răspuns ajută echipa să rămână motivată și convinsă că livrează cea mai bună soluție, că a început bine și merge în direcția bună pentru a construi funcționalitatea necesară. Aceste răspunsuri sunt primele care ne provoacă să ne gândim la cele mai bune soluții.
După părerea mea, indiferent de care parte ne aflăm, dacă suntem conștienți și începem mereu având în minte obiectivele de business ale clienților noștri, putem să livrăm soluții mai bune și în final, să aducem cât mai multă valoare. În acest fel, putem să înțelegem cu adevărat ce se " ascunde" în spatele cerințelor venite din partea clienților noștri.
De cele mai multe ori, analistul de business este prima persoană care întâlnește provocarea de a afla ce se ascunde în spatele cerințelor unui client. Nu există nicio rețetă de a face acest lucru, iar rezultatul depinde foarte mult de contextul proiectului sau profilul clientului. Un bun început ar putea fi să căutăm "DE CE"-ul și să întrebăm mereu: "Care este valoarea de business pe care ar aduce-o această funcționalitate?". Nu este niciodată prea târziu să punem această întrebare.
Apoi, a clarifica obiectivele de business ale clienților noștri și a defini sau redefini funcționalitățile ce trebuie livrate, ținând cont de aceste obiective, sunt demersuri esențiale ale creșterii valorii.
De asemenea, este important să împărțim aceste funcționalități în unele mai mici și să le subordonăm obiectivelor de business pe care le-am identificat inițial. Am reuși poate să setăm numerele care cuantifică valoarea de business și să măsurăm impactul real pe care l-ar putea aduce soluțiile pe care le livrăm către Business.
Scopul acestui articol este de a genera discuții, de a semnala însemnătatea acestui aspect al valorii de business și nu de a prezenta soluții. Soluțiile, tehnicile sau metodele diferite pot fi folosite în funcție de contextul fiecărui proiect și de profilul clientului. Dacă te afli printre analiștii de business pentru care este o mare provocare să afli adevărata valoare de business din spatele cerințelor clientului, mi-ar plăcea să împărtășim noi idei în legătură cu acest subiect.
Cum scoți în evidență valorea de business a funcționalităților pe care tu și echipa ta le livrați? Cât de mult pui la încercare cerințele venite din partea clienților, astfel încât să te asiguri că funcționalitatea livrată acoperă nevoile reale de business?
de Iulia Bicu
de Vlad Vesa
