Dacă în articolul precedent am răspuns la o întrebare frecvent întâlnită, astăzi voi încerca să adresez o întrebare pe care uităm s-o probăm când așezăm Scrum-ul în context: Cine decide ce funcționalități trebuie să conțină produsul?
Orice organizație își are propria structură ierarhică, asemănător organigramei de mai jos:
Concomitent, organizațiile au și o ierarhizare operațională special concepută pentru a structura regulile despre luarea deciziilor, în cazul Scrum, într-un proiect:
Atunci când creăm un proiect structurat după cadrul Scrum, trebuie să ținem cont de rolurile cu care acest cadru vine, deci, să adaptăm ierarhia operațională. Dacă nu facem acest lucru, ceea ce poate că într-adevăr are sens, nu mai putem vorbi despre Scrum.
Unul din motivele pentru care Scrum-ul funcționează este precizia distribuției responsabilităților:
Responsabilul de Produs poate să facă activitățile de mai sus, sau să ceară Echipei de Dezvoltare să o facă. Totuși, Responsabilul de Produs păstrează responsabilitatea. Responsabilul de Produs este o persoană, nu un comitet. Responsabilul de Produs poate să reprezinte dorințele unui comitet în Product Backlog, dar cei care doresc să modifice prioritatea unui element din Product Backlog trebuie să se adreseze Responsabilul de Produs. Pentru ca Responsabilul de Produs să reușească, întreaga organizație trebuie să-i respecte deciziile. Deciziile Responsabilul de Produs sunt vizibile în conținutul și ordonarea Product Backlog-ului. Nimeni nu are voie să ceară Echipei de Dezvoltare să lucreze dintr-un alt set de cerințe, și Echipa de Dezvoltare nu are voie să acționeze la ceea ce spune altcineva.
Altfel spus, când vine vorba de luarea deciziilor despre conținutul produsului, avem doar două niveluri ierarhice:
- Responsabilul de Produs, care definește așteptările și inspectează rezultatul
- Echipa de Dezvoltare, care se asigură că așteptările Responsabilului de Produs sunt întâlnite
Atât timp cât Responsabilul de Produs este în exercițiu, acesta decide dacă să țină cont sau nu de sugestiile managerului.
Managerul nu poate lua decizii privind produsul, ci doar să-și convingă Responsabilul de Produs, altfel, cel din urmă, nu mai poate fi numit „Responsabil”.
Foarte probabil că managerul poate destitui* Responsabilul de Produs din funcție, însă, atât timp cât vorbim de Scrum, va putea defini conținutul produsului doar dacă preia și rolul de Responsabil de Produs.
*Din multitudinea de proiecte pe care le-am văzut, în două cazuri destituirea a survenit pierderii încrederii sponsorilor principali ai proiectului. Am avut parte și de cazuri în care Responsabilul de Produs a fost schimbat din motive politice sau din motive de etică (a ascuns informații/mințit).
Bineînțeles că acest exercițiu de forțe poate duce la Responsabili de Produs marionetă. Aceasta este realitatea dată de lipsa de maturitate/agilitate a organizației respective, iar rezultatele slabe nu vor întârzia să apară. Pentru că, așa cum am mai scris la mine pe blog, nu poți fi responsabil dacă nu crezi în ceea ce faci, iar acea marionetă doar va intermedia și/sau va acumula frustrări. Nu există fundament experențial-științific care să demonstreze contrariul.
Concluzie
Cine decide ce funcționalități trebuie să conțină produsul?
Doar Responsabilul de Produs.
Cine răspunde pentru conținutul Produsului? Responsabilul de Produs sau Administratorul/Managerul companiei?
Dacă doriți să aflați mai multe despre mine, Cornel Fătulescu, sau proiectele în care sunt implicat, vă invit să mă descoperiți și ca Chief Platform Officer la Pentalog, să mă urmăriți pe Facebook, ca investitor la wanttolearn, să citiți unul dintre primele articole despre mine și să mă contactați urmând ghidul de pe pagina de contact.
Acest articol a fost citit de 1955 ori