Managementul este într-o continuă evoluție. Noi framework-uri, noi metodologii sunt inventate, reinventate și adaptate pentru a satisface nevoile unei piețe foarte dinamice. De fiecare dată când apare ceva nou, la început luptăm împotriva schimbării pentru ca mai apoi, după ce câțiva temerari demonstrează valoarea noului concept suntem gata să-l adoptăm drept noua noastră religie. La fel s-a întâmplat în cazul Waterfall și Scrum și la fel se întâmplă în ultima vreme cu Kanban.
Business-urile evoluează într-un ritm amețitor iar framework-urile ce permit o adaptare rapidă și o lansare rapidă pe piață au fost grupate în ceea ce se numește conceptul Agile, cea mai în vogă și cea mai folosită sintaxă din domeniul IT din ultimii ani. Cu toate aceste framework-uri ce se învărt în jurul nostru managerii pot cădea rapid într-o stare de automulțmire uitând bazele și esența a ceea ce înseamnă management de proiect. Bazele managementului de proiect sunt bine definite, bine structurate și, în opinia mea, în ciuda a ceea ce crede multă lume, a cunoaște și a evolua pe baza unor cunoștințe structurate nu contravine deloc cu regulie jocului Agile. Din contră, aceste cunoștințe pot fi adaptate, devenind o unealtă puternică atunci când vrem să jonglăm cu framework-urile de genul Scrum, Kanban etc.
Ca și mulți alții din acest domeniu, evoluția mea spre management de proiect a trecut prin mai multe stadii, începând ca programator, mai apoi conducănd echipe din punct de vedere tehnic, pentru ca mai apoi să mă îndrept spre managementul de proiect. Am avut noroc să urmez un curs de management de proiect, dar cel mai mult am învățat în ‘focul luptei’. Absolut normal, procesul nu a fost unul liniar ci a fost unul cu suișuri și coborâșuri.Dar cu siguranță acelea au fost momentele care au dat roade mai târziu. Încetul cu încetul au început să apară așa numitele momente de conștientizare a experienței. Odata ce începem să fim tot mai siguri pe noi și să caștigăm tot mai multă experiență, căutăm o certificare care să ne ajute în noul nostru obiectiv. Acela a fost momentul pentru mine în care am devenit tot mai interesat de ceea ce înseamnă PMI și PMP. Ca să fim bine înțeleși, intenția mea nu e de a face reclamă celor de la PMI, încă nu am aplicat pentru a-mi lua certificarea. Este ceva ce vreau să fac anul acesta. Până în acest moment am participat la orele de curs necesare pentru a mă putea înscrie pentru examen. M-am hotărât să scriu acest articol deoarece atât în timpul orelor de curs cât și în multe alte discuții legate de certificarea PMP am auzit multe dezbateri dacă această teorie se aplică sau nu în proiectele Agile. După cum ați observat probabil chiar din primele rânduri, părerea mea este că acele cunoștințe necesare obținerii certificării PMP sunt un bun de mare preț (și obligatoriu în același timp) pentru orice manager de proiect ce se învârte în lumea Agile.
Certificarea PMI îți oferă informații structurate într-un anumit fel, o mulțime de documentație, o cale clară despre cum se gestionează un proiect de la începuturi și până la terminarea sa (și nu doar în industria IT). Principiile pe care se bazează sunt prinse într-o carte destul de voluminoasă numită PMBok. În același timp Agile nu prea ne obligă la tone de documentație, nu are legatură cu o cale și reguli bătute în piatră, dar obiectivul e același: terminarea cu succes a unui proiect. Voi justifica această opinie făcând o paralelă cu Scrum-ul pentru că cea mai mare parte din experiența mea cu framework-uri Agile merge înspre Scrum. Scrum-ul definește niște roluri printre care regăsim cel puțin unul care nu are legătură cu teoriile generale de project management și anume rolul de Scrum Master. Scrum Master-ul este un fel de super erou care are putere deplină asupra procesului și care trebuie să rezolve toate impedimentele astfel încât echipa să-și poată face treaba. Dacă ne luăm după manual, el deține drepturi depline asupra procesului dar nu are autoritate asupra echipei. Unele companii au rezolvat acest aspect folosind manageri de linie împreună cu Scrum Master-ii, alte companii au rezolvat acest aspect combinând rolul de Scrum Master cu cel de manager de linie (caz în care rolul de Scrum Master se identifică cu cel de manager de proiect). Nu există rețeta ideală, dar important este să se potrivească în contextul respectiv. Oricare ar fi contexul și rolurile, persoana care controlează procesul trebuie sa știe ce face. La fel și cu persoana care are responsabilitate asupra echipei. Pentru aceasta și nu numai, bazele managementului de proiect sunt foarte importante.
Structura PMBok-ului se bazează (cel puțin în ultima ediție, deoarece și PMI evoluează în continuare) pe 47 de procese. Acestea sunt grupate în 5 grupuri și 10 arii de cunoștințe. Pentru a fi în conformitate cu cerințele PMI trebuie să lucrăm cu structura care se potrivește în acest peisaj. Aici apare și dilema: învățând acest mod structurat de face lucrurile, avem vreun beneficiu în viața de zi cu zi din proiectele mele Agile? Normal că avem (zic eu).
Să începem cu cele 5 grupe de procese: Inițierea, Planificarea, Executarea, Monitorizarea și Controlul și Închiderea. Practic ne referim la ciclul normal de viață al unui proiect. Orice proiect trebuie să aibă un început. Nu putem să începem din mijlocul lui, trebuie să existe o fază inițială. Chiar și atunci când suntem în situația nu chiar de dorit de a continua munca începută de alții (situație de nedorit în mare parte din cauza ego-ului nostru deoarece ne simțim mult mai împliniți atunci când începem un proiect de la zero și-l ducem la linia de sosire; situație care de altfel e o oportunitate perfectă să dăm vina pe vechea ehipă de fiecare dată când apar probleme sau erori din momentul în care-l preluăm până la sfârșitul lui). Indiferent de framework-ul folosit pentru a duce la bun sfârșit proiectul, în faza de inițiere trebuie să identificăm stakeholder-ii. Iată că încep să apară părțile comune. Pentru a urma principiile din PMBok, în faza de planificare stabilim regulile jocului și definim cum vom face totul de la începutul până la sfârșitul proiectului, urmând a actualiza unele informații pe măsură ce înaintăm. Ca adepți ai metodologiei Agile nu planificăm totul de la început, dar recurgem la planificări pe tot parcursul proiectului în bucățele mai mici. Dacă suntem adepți ai Scrum-ului ne vom planifica iterațiile, ne vom planifica munca de zi cu zi si nu numai. Executarea, monitorizarea și controlul se referă la munca efectivă necesară pentru a termina proiectul. Ce face un manager de proiect sau un Scrum Master? Același lucru: gestionează munca în sine, comunicarea, stakeholder-ii, procesul de testare, riscurile, adică toate palierele unui proiect.
Așa cum afirmam mai sus, pe lângă cele 5 grupuri de proces, PMBok organizează informația în 10 arii de cunoștințe. Deși nu intenționez să le prezint integral, ar fi interesant de observat cum se mapează câteva din ele peste ceea ce se întâmplă în lumea Scrum-ului. Grupul magic al celor 3 (timp, scop, cost) rămâne esența a ceea ce facem. Dacă în lumea structurată a PMI-ului estimăm ceea ce vom face încă de la început când lucrăm cu Scrum facem același lucru dar în părți mai mici. Când planificăm o iterație ținem cont de aceeași parametri principali: scopul (care vine din backlog-ul prioritizat), scop pe care îl ajustăm în funcție de velocitate (velocitatea depinde bineînțeles de echipă care împreună cu alte date de intrare se traduce în cost). Trebuie să realizăm acest scop într-un timp bine definit dat de lungimea iterației. Foarte asemănător cu modul în care creăm WBS-ul realizăm și spargerea story-urilor în task-uri. Dacă ne gandim la un proiect care este manageriat după regulile PMI ca referință (proiectele conduse după metoda Waterfall se mulează perfect pe această structură) putem să vedem fiecare iterație în parte ca o reprezentare în miniatură a referinței: bine organizată, bine planificată și bine definită în timp.
O altă arie importantă din cele 10 este managementul riscului. În amândouă situațiile este un proces perpetuu. Evaluăm riscul după priceperea noastră și ca să fim eficienți trebuie să cunoaștem cel puțin bazele. Există câteva tehnici care ne vor ajuta să identificăm riscurile. Trebuie să știm care riscuri sunt mai importante, care au impactul mai mare și să definim care vor avea nevoie de acțiuni din partea noastră. Putem face un plan pentru a evita anumite riscuri, pentru a transfera către o terță parte anumite riscuri. Ce este important este să știm opțiunile noastre pentru a deveni mai eficienți. Aceasta nu depinde de framework-ul cu care lucrăm (Scrum, Kanban). De asemenea, realizăm ca informația structurată, bazele, esența, nu sunt deloc departe de lumea Agile.
Ca Scrum Master-i gestionăm procesul și vom face tot posibil pentru a înlătura impedimentele din calea echipei. Câteodată aceste impedimente se referă la nevoia integrării cu un serviciu oferit de altcineva. Câteodată poate fi ceva simplu precum achiziționarea unui set de controale, câteodată poate fi ceva mai complicat precum integrarea cu un provider pentru suport on-line pentru produsul nostru. Ceea ce trebuie să știm în calitate de Scrum Master-i este cum să facem managementul achiziților. Trebuie să știm cum să definim regulile pentru selectarea vendorului și cum să realizăm contractul cu vendorul.
Dacă ținând cont de teorie Scrum Master-ul nu are autoritate asupra echipei, acest lucru nu înseamnă că în echipă nu pot apărea conflicte. Nu înseamnă că nu vor exista persoane demotivate în echipă. Managementul resurselor umane ne învață să gestionăm astfel de situații. Toată lumea a auzit de piramida nevoilor lui Maslow, dar mai sunt multe teorii care ne pot ajuta. Un minim de cunoștințe despre această arie ne va da posibilitatea să ne adaptăm la context și să alegem soluția potrivită în funcție de situație.
Nu este nevoie să intru în toate detaliile fiecărei arii de cunoaștere dar dacă am face o analiză și mai detaliată, am constata că acele cunoștințe care ne ajută să gestionăm un proiect respectând calea PMI, se aplică și în framework-urile Agile. Evoluția noastră ca manageri nu ar trebui să se oprească la primul framework care funcționează. Cu cât știm mai multe, cu atât putem acționa mai eficient deoarece nu vorbim de lucruri bătute în piatră ci vorbim de adaptare. Vom putea să ne adaptăm, să mixăm și să folosim ceea ce știm pentru a crește eficiența lucrului făcut de noi. Esența poate să vină structurată în multe metodologii (PMI, PRINCE2 etc.). Framework-urile Agile nu ar trebui să ne îndepărteze de informația organizată. Chiar mai mult de atât aceste framework-uri ne dau posibilitatea de a jongla cu această informație cum vrem noi, ne dau posibilitatea să fim acei rebeli care nu fac o analiză de risc doar în momentele bine stabilite de la început ci realizează această analiză și ad-hoc dacă simt ei că trebuie. Depinde doar de noi cum aranjăm piesele acestui puzzle uriaș și cum ne jucăm cu el. Cu cât știm mai multe, cu atât mai multe sunt posibilitățile. Mai multe posibilităti de unde să alegem înseamnă automat și mai multe șanse de succes, dar câteodată și de eșec. Dar nu vom ști niciodată ce pierdem dacă nu vom continua să evoluăm.