Când discutăm despre proiecte, discutăm şi despre managementul de proiect care este o adevărată artă şi ştiintă de a duce la bun sfârşit proiectul. Pornind de la binecunoscuta relaţie Calitate, Timp, Cost, supranumită şi triunghiul de fier, avem încă de la început provocări care ne influenţează munca şi definesc rezultatele ei.
Istoric vorbind, managementul de proiect şi-a început evoluţia în proiecte industriale şi construcţii, iar in ultimele decenii a fost aplicat şi în domeniul IT pentru a duce la bun sfârşit viziunea antreprenorilor curajoşi sau a investitorilor care au văzut în sistemele IT un "commodity" la fel cum sunt azi petrolul, energia electrică sau mai recent Internetul.
Mergând mai specific spre proiecte agile de dezvoltare a aplicaţiilor web, m-am gândit să punctez în acest articol o serie de aspecte, momente şi activităţi cheie pe care eu le-am întâlnit ca manager de proiect (PM) în ciclul de viaţă al proiectelor, în contextul ISDC - companie IT care oferă servicii şi soluţii software pe piaţa europeană.
În cele ce urmează voi parcurge acele aspecte importante ce merită atenția deosebită a PM-ului într-un proiect agile și nu numai: de la un scurt istoric legat de evoluția metodelor de development la pornirea unui proiect agile, identificarea stakeholder-ilor, faza de fundamentare, definirea cerințelor funcționale și non-funcționale, managementul schimbării, planificarea, comunicarea, managementul riscurilor, monitorizarea progresului, QA, managementul vizitelor, demo/UAT la client și concluzionând cu retrospectiva.
Din momentul în care eşti implicat ca PM într-un proiect, porţi o mare responsabilitate: satisfacţia clientului, care poate fi o întreagă organizaţie cu o serie de factori decizionali implicaţi sau doar un grup restrâns de persoane. Cred cu tărie că acesta este vectorul esenţial în controlul triunghiului de fier şi în dezvoltarea unei relaţii de continuitate cu acel client.
Totul începe încă înainte de pornirea proiectului. Procesul de pre-sales şi sales este deseori lung şi plin de provocări. Odată setaţi parametrii colaborării cu clientul şi parafaţi printr-un contract, PM-ul preia aceşti parametri şi începe rafinarea lor.
Agile sau non-agile, un proiect trebuie în aşa fel condus încât să-şi atingă ţinta în condiţiile stabilite de comun acord cu clientul şi să livreze produsul dorit de client la momentul dorit şi în buget, respectând o serie complexă de parametri funcţionali şi tehnici ce definesc calitatea produsului. Dar să vedem cum s-a ajuns la agile. De-a lungul timpului informaticieni şi ingineri, specialişti şi oameni de business au încercat diferite formule de lucru pentru a finaliza cu succes proiecte informatice şi de a colabora impreună. Foarte cunoscutul waterfall a fost folosit din plin în proiectele IT cu secvenţierea fazelor de descriere de cerinţe funcţionale şi tehnice, cu analiza şi designul, iar în final implementarea, integrarea şi testarea. Au urmat alte formule intermediare, incrementale cu spargerea monoliticului model waterfall în segmente/iteraţii mai mici, dar tot waterfall. În final modelul de dezvoltare software care s-a impus global a fost cel agile prin flexibilitatea sa, dar şi printr-un time-to-market mult redus.Vorbind de agile, mă voi referi în continuare la Scrum în calitatea sa de cadru de dezvoltare software, dar desigur sunt şi altele (de exemplu: DSDM, Extreme Programming).
În majoritatea proiectelor am lucrat cu clienţi externi în conjuncturi organizaţionale complexe, ceea ce a făcut dificilă, uneori imposibilă, participarea tuturor stakeholder-ilor principali la sedinţele de început de proiect (project kick-off). De aceea, un ţel important pentru un PM este să-şi cunoască toţi partenerii interesaţi direct/indirect de proiectul de care este responsabil şi pe lângă acesta să le cunoască şi interesele legate de proiect sau produsul livrat de proiect. Una dintre cele mai neplăcute situaţii este când un stakeholder este identificat prea târziu, în faza finală a proiectului. Această situație neplăcută vă poate da peste cap planurile şi acceptanţa finală a produsului dezvoltat.
În proiectele din ISDC am optat în ultimii ani să propunem clienţilor o fază de fundamentare înaintea începerii efective a sprinturilor de dezvoltare. În această fază, putem identifica şi relaţiona cu stakeholder-ii direct implicaţi. Beneficiile acestui pas preliminar începerii proiectului propriu-zis sunt imense, echipele de lucru (client şi furnizor) se vor cunoaşte şi se vor alinia legat de modul de lucru (way of working) şi de alte aspecte importante ale proiectului. Cu siguranţă acest pas trebuie foarte bine organizat cu un plan şi o agendă clară în aşa fel încât timpul să fie folosit eficient şi să acopere aspectele prioritare pentru începerea dezvoltării.
În momentul alinierii cu clientul pot ieşi la iveală o serie de diferenţe de aşteptări de ambele părţi, ce apar încă din etapa de vânzări. PM-ul trebuie să aibă în vedere identificarea şi clarificarea acestor diferenţe şi stabilirea unor acorduri cu clientul. Aici intervin şi aspectele legate de planificare, definirea fazelor de lucrări, numărul de sprinturi ce vor fi folosite, mărimea echipei şi modul de lucru. Practic la pornirea proiectului, trebuie acoperite în discuţiile cu clientul subiecte care pornesc de la cerinţele funcţionale şi non-funcţionale care influenţează arhitectura şi atributele de calitate aşteptate până la felul în care se va face implementarea şi testarea în proiect. În cazul în care totuşi rămân puncte deschise sau neclarificate atunci recomand definirea unei liste de acţiuni pe care PM-ul să o urmărească.
Există cazuri în care trebuie revenit de mai multe ori asupra unor aspecte când proiectul este complex şi de lungă durată. Un caz pe care l-am întâlnit a fost revenirea şi clarificarea Non-Functional Requirements (NFR): printre care se număra performanţa, mentenabilitatea, robusteţea şi securitatea sistemului software dezvoltat. Atenţie însă, acestea pot avea un impact foarte mare asupra sistemului după cum arhitectul vostru vă poate spune. Modificări ale NFR-urilor în timpul dezvoltării sistemului software, vor impacta planificarea şi bugetul proiectului pentru că au un potenţial mare de a genera re-work sau refactoring. În cazul unui proiect cu preţ fix aceasta vă va da şansa să vă exersaţi talentul de a convinge clientul să plătească suplimentar pentru modificările făcute.
Definirea, clarificarea și atribuirea rolurilor încă de la începutul proiectului sunt de asemenea esenţiale, începând de la guvernanţa la nivel de Project Board până la clarificarea rolurilor în echipa/echipele de Scrum: Product Owner (PO), Proxy-Product Owner (PPO), Scrum Master (SM) sau Team leader (TL), Arhitect, PM etc. Există multe configuraţii de roluri care funcţionează, aspect care depinde şi de felul în care se desfăşoară acel proiect: cu echipe de development mixte (furnizor şi client) sau doar de partea furnizorului sau în colaborare cu sub-contractori sau consultanţi ai clientului. Sunt roluri care se pot cumula, uneori un PM este şi SM/TL, uneori SM este şi PPO etc.. La modul general, cumularea acestor roluri implică responsabilități importante precum evitarea conflictelor de interese care pot apărea și luarea în considerare a particularității organizării interne a companiei software.
O alta lecţie învăţată în timp este că sunt clienţi care ştiu exact ce vor şi foarte mulţi care nu pot indica cu exactitate şi trebuie ghidaţi. În fond, în calitate de furnizor de servicii software, una dintre provocări este să ghidăm clientul spre cea mai bună soluţie care să-l ajute să-şi dezvolte sau îmbunătăţească afacerea. Aici intervine definirea cerinţelor funcţionale, care fie este realizată de oamenii de business ai clientului în colaborare cu consultanţi specializați, fie de furnizorul software în colaborare cu clientul. Odată cu trecerea de la waterfall la agile definirea cerinţelor funcţionale se face în paşi, în care echipa de dezvoltare este implicată înainte de fiecare sprint în acele sesiuni numite (Scrum) de pre-grooming sau grooming. Rareori avem documentaţii complete funcţionale şi chiar şi atunci când ele există la momentul implementării sunt deja învechite. De aceea o prioritizare preliminară cu clientul a cerinţelor funcţionale majore (epics) din product backlog este de dorit, pe sprinturi. PM-ul trebuie să se asigure că acea prioritizare este realistă şi abordabilă în context tehnic şi funcțional după consultarea cu SM/TL-ul şi architectul. În cazul unui contract/proiect cu preţ fix, pentru a realiza o delimitare clară a funcționalităților (project scope) poate fi necesară o detaliere în avans a tuturor acestor cerinţe majore (epics) în unele mai amănunţite (userstories) pentru toate sprinturile.Această delimitare reprezintă una dintre marile provocări ale unui proiect cu preţ/buget fix. Pentru a putea avea evidența schimbărilor funcționale, trebuie pus la punct managementul schimbărilor (change management) care constă în definirea un proces de raportare și aprobare a cererilor de schimbare a specificațiilor funcționale (change management flow) și în identificarea actorilor cu responsabilitățile lor în acest proces (client, echipă, PO, PM, Project Board, etc.). E important ca echipa de dezvoltare să aibă foarte clară definiția unei cereri de modificare (Change Request). Rolul PM-ului aici e esențial, de aceea o bună colaborare cu SM/TL-ul și o aliniere permanentă este necesară. Orice cerință ce vine de la client și care declanșează o potențială schimbare trebuie notificată de echipă către PM.
Bugetul alocat, rolurile necesare în echipă pe sprinturi pe săptămâni, defalcarea în timp a bugetului (în ore și bani) și o secvențiere a activităților și a reperelor (milestones) la finalizarea fazelor de lucrări- sunt aspectele de care trebuie să țină cont o planificare de ansamblu a proiectului ( high-level planning). Planificarea trebuie să aibă în vedere ipotezele de lucru (assumptions) de la care echipa de dezvoltare pornește, care pot să fie tehnice, funcționale etc.. Diversitatea lor este surprinzătoare. Ele vin la pachet cu constrângerile (constraints) proiectului: bugetul, data livrării, atributele de calitate, disponibilitatea membrilor echipei furnizor și client. Nu în ultimul rând planificarea este legată de riscurile identificate la începutul proiectului. Această planificare trebuie pusă în acord cu clientul încă de la începutul proiectului, menționând validitatea ei doar în contextul listei de ipoteze, constrângeri, riscuri. În cazul modificărilor ulterioare apărute în cadrul ipotezelor de lucru, PM-ul trebuie să ia în considerare impactul asupra planificării deja agreate.
Comunicarea este unul din factorii decisivi în succesul unui proiect. Iar PM-ul este un dirijor care orchestrează această comunicare. Deseori comunicarea este neglijată și problemele de comunicare împiedică bunul mers al proiectului, dar există câteva lucruri care pot preveni astfel de probleme dacă sunt de la bun început stabilite:
De asemenea, sunt și lucruri care ar trebuie evitate:
Într-adevăr este vorba de managementul riscurilor. Gândiți-vă la riscuri ca la ceva cu capacitate distructivă pentru proiectul vostru. Nu ați vrea să le tratați cu atenție? "Dezamorsarea" acestor riscuri ar trebui să fie printre principalele griji ale PM-ului.
Noi am făcut acest lucru permanent în proiectele în care am fost implicat, cu scopul de a reduce probabilitatea și impactul lor prin diferite acțiuni. Împreună cu echipa și SM-ul, PM-ul trebuie să identifice și să găsească mijloace de a reduce pagubele în caz că riscurile se manifestă. E nevoie de transparență în echipă pentru ca aceste riscuri să fie puse pe masă de echipă. Și apoi de consecvență din partea PM-ului pentru a le documenta, monitoriza și mitiga. Sunt cazuri în care riscurile trebuie puse pe masa Project Board-ului. E important ca aceste riscuri să fie colectate de PM/SM/Arhitect permanent în toate împrejurările. Nu vă rezumați doar a întreba membrii echipei în timpul daily-urilor. Participați din când în când ca observatori la ședințe tehnice, la sprint planning-uri și grooming-uri și veți identifica riscuri. Discutați periodic cu membrii echipei voastre, așa veți colecta pe lângă impedimentele zilnice și riscuri la care este expusă echipa și proiectul.
Măsurarea progresului este un factor cheie în a determina succesul unui proiect și a aplica acțiunile corective potrivite. La ora actuală există o multitudine de aplicații care facilitează echipele de dezvoltare în stocarea cerințelor funcționale, criteriilor de acceptanță, statusul activităților desfășurate și estimărilor lor inițiale, timpul petrecut pe activități, legătura cu codul sursă și altele.
În proiectele recente la care am lucrat am folosit JIRA (Atlassian) sau TFS (Microsoft). Cu ajutorul burn-down chart-urilor puteți identifica zilnic într-un sprint dacă progresul a fost conform sprint planning-ului inițial. În caz de devieri, împreună cu SM-ul puteți lua măsuri corective. Periodic, de exemplu o dată pe săptămână puteți verifica și starea bugetului (ore/bani). În cazul proiectelor cu preț fix este util să aveți o descriere a produsului, defalcată pe funcționalități, numită și PBS (Product Breakdown Structure), în care să marcați proporția de implementare pe o anumită funcționalitate și să aveți și o estimare în efort și durată a ceea ce a mai rămas de implementat. De cele mai multe ori puteți deriva acest PBS din product backlog.
Termenele de livrare, efortul și costurile nu sunt totul, sistemul software dezvoltat în proiect trebuie să aibă atributele de calitate dorite de client. În cadrul ISDC am avut șansa să pot apela la expertiza pe zona funcțională, pe zona architecturală/tehnică și cea de calitate a proceselor de dezvoltare și testare. Aceasta mi-a dat o indicație obiectivă a stării de sănătate a sistemului dezvoltat și a proceselor folosite. Pe lângă mecanismele implicite "built-in" de review a codului sursă și cel de testare funcțională, regăsit în practica echipelor de dezvoltare, care îți oferă siguranța că nu ți-au scăpat erori serioase tehnice sau funcționale, recomandabile în ciclul de viață al unui proiect sunt următoarele acțiuni:
Există impedimente și probleme care nu pot fi înlăturate de SM și atunci acestea vor ajunge pe masa PM-ului. În acest caz ca PM este necesar să identifici mijloace și alternative de a le rezolva: comunică tu direct cu clientul, rezolvă probleme legate de resurse sau dacă nu le poți rezolva singur, ai un instrument puternic și influent: Project Board-ul în fața căruia poți aduce acea problemă cu alternativele propuse de tine. Dar nu-l surprinde, pregătește din timp o agendă și comunică-o board-ului, fixează o dată când toți membrii se întâlnesc și clarifică ceea ce te astepți de la board.
Una dintre problemele majore în multe din proiecte este indisponibilitatea persoanelor cheie de la client. Pentru acestă problemă vă propun o sesiune comună de planificare cu persoanele în cauză de la client sau cu managerul lor.Practic o astfel de reconciliere a planificării făcute de echipa de dezvoltare împreună cu partenerii cheie de la client va duce la rezultate mai bune.
O altă cauză comună a impedimentelor și problemelor ne-rezolvate este lipsa sau raritatea contactelor directe dintre echipa de dezvoltare (sau a reprezentanților ei: PM, SM, Architect, PPO) și client (sau a reprezentaților lui: PM omolog la client, PO, Key User, Test Manager). PM-ul este cel în măsură să propună clientului ca parte din planul de comunicare: un plan de vizite reciproce care să elimine barierele de comunicare și să stimuleze comunicarea dintre membrii ambelor echipe.
Ori de câte ori aveți posibilitatea, planificați accesul clientului la un demo sau o perioadă de acceptanță User Acceptance Testing (UAT) on-site la client sau la voi. E vital pentru succesul UAT-ului să fiți aproape de client. Planificați delegații la client în care să faceți demo la ultimele functionalități dezvoltate sau pentru a începe o perioada de UAT. E posibil să întâlniți rezistență din cauza costurilor de deplasare ,dar argumentați-le prezentând avantajele.
Cel puțin la finalul fiecărei faze de execuție (o nouă versiune de exemplu) constând dintr-o serie de sprint-uri, este indicat să aveți un moment de retrospectivă cu echipa și clientul în care să analizați parametrii proiectului: devierea pe estimări, gradul de re-work, calitatea userstory-urilor, calitatea codului, calitatea test-scripturilor. Este posibil să doriți să faceți aceasta în sesiuni separate, dar e bine să identificați cu echipa lucrurile care au funcționat și pe care vreți să le păstrați dar și pe acelea care nu vreti să se repete.
Din punctul meu de vedere un PM într-un proiect agile trebuie să fie dinamic, flexibil, receptiv la feedback-ul clientului/echipei și să aibă întotdeauna o privire de ansamblu asupra proiectului. Focusul PM-ului rămâne pe satisfacția clientului și calitatea sistemului dezvoltat în buget și la timp, lucruri care se obțin prin: comunicare susținută și managementul stakeholder-ilor, prezența la client periodică, evaluare constantă împreună cu clientul a sistemului dezvoltat până în momentul respectiv și decizia implementării de CR-uri, identificarea și ameliorarea impactului riscurilor conjugată cu un QA eficient.
de Ovidiu Mățan
