by 
La granita dintre doua lumi, ai nevoie sa vorbesti ambele limbi. Sau sa ai un dictionar la indemana.
Am legaturi puternice cu doua lumi diferite. Ma adresez amandurora. Sunt Inginer ca formatie si mod de gandire. Sunt Project Manager ca activitate si experienta.
Din prima postura am lucrat in echipe de Software Development si am rezolvat cu ei probleme de logica, de flux de utilizare, de performanta sau de securitate.
Din cea de-a doua am planificat si raportat ca Project Manager catre Sponsori si Stakeholderi, am analizat cu ei avantaje de business, competitorii, piata, riscurile, bugetele si am comparat fezabilitatea mai multor propuneri de proiect.
De cele mai multe ori, par greu de transmis informatiile dinspre business spre tehnic sau viceversa. Pe cand Sponsorul vede doar riscuri materializandu-se, ineficienta in alocarea resurselor si bugete depasite in proiecte, echipele tehnice invoca tehnologii invechite, “technical debt”-ul sau lipsa unor informatii de baza pentru a continua lucrul. Cele doua moduri de exprimare a dificultatilor aparute par a nu avea un puct comun si totusi este vorba, de cele mai multe ori, de aceleasi probleme.
Cand “analiza riscurilor”, spre exemplu, nu inseamna nimic pentru echipa tehnica dar ei vorbesc despre iminenta unei probleme majore cu tehnologia care a fost aleasa pentru baza de date a aplicatiei, trebuie sa intelegem si una si alta, ca fatete ale aceleiasi situatii, nu una sau alta.
Cum punem informatiile cap la cap? Cum intelegem si ii facem pe toti sa vorbeasca o limba comuna? In cele din urma notiunile cu care jonglam, de o parte sau de alta, sunt doar niste instrumente care faciliteaza comunicarea. Realitatea este una singura oricum am numi lucrurile. Deci trebuie sa gasim echivalentele sau limbajul comun.
Intre cele doua lumi, cea de business si cea tehnica, am gasit un punct comun, un mod de a lega conversatia. Nu e nimic magic din pacate, ci este ceva ce necesita timp, concentrare si participare: este vorba de lucrul colaborativ. Lucrul colaborativ trebuie inteles ca un mod a desfasura proiectele si initiativele, nu doar ca intalniri periodice intre cele doua parti, cea de business si cea tehnica, facute doar atunci cand este planificat sa revizuim ce s-a mai intamplat cu proiectul. Nu. Lucrul colaborativ inseamna ca cei interesati de ambele parti sa lucreze zi de zi impreuna pentru a descoperi ce trebuie sa se intample mai departe. Prin participarea ambelor grupuri la procesul efectiv de lucru, de construire a produsului sau serviciului dorit, cuvintele ambelor grupuri isi capata intelesul.
Nu e ceva nou, bineinteles. Un principiu al Agile Manifesto spune inca doar din 2001:
“Business people and developers must work together daily throughout the project.”
Si ar mai fi ceva pe langa lucrul colaborativ. Dezvoltarea unui limbaj comun.
Un mod de a obtine acest limbaj comun, cu care sa patrundem dintr-o parte spre cealalta, este parcurgrea curriculei de certificare pentru examenul PMI-ACP (Agile Certified Practitioner), sustinut la PMI. Parcurgand titlurile materialelor de referinta pentru obtinerea certificarii PMI-ACP, putem vedea valoarea acestei “traduceri” de limbaj. Iata cateva exemple de beneficii pe care le vom avea, studiind aceasta curricula si avand un inteles comun intre principiile de Project Management si modul de lucru practicat de echipele agile de dezvoltare:
– Vom putea aborda din perspectiva echipei problematica de Management de Proiect, cu cuvintele cheie si problemele tehnice specifice dezvoltarii de produse.
– Vom intelege uneltele si tehnicile practice folosite de echipa pentru a atinge obiectivele de project management agile, ca de exemplu: tehnici de estimare, de prioritizare, de defalcare a cerintelor in user stories, rapoartele simple si grafice folosite de echipa, tablele de lucru (task boards).
– Vom stii cum sa masuram performanta echipei noastre si sa estimam timpului ramas pentru finalizarea proiectului, pe baza analizei unor grafice simple de productivitate (velocity charts).
– Vom cunoaste tehnici si metode de a mentine implicarea stakeholderilor proiectului nostru pe tot parcursul desfasurarii lui, nu doar in fazele initiale si in cele de finalizare.
– Vom putea sa analizam impreuna cu echipa cai de imbunatatire a procesului nostru de lucru, prin instrumente ca intalnirile retrospective sau ca analiza “value stream mapping”.
– Vom dobandi cunostintele si abilitatile necesare pentru a face coaching eficient cu echipa noastra si a crea medii de lucru agile performante.
– Vom recunoaste si vom face deosebirea intre cele mai comun raspandite metode si metodologii agile (Scrum, Kanban, Extreme Programming, Lean Software Development, Crystal, DSDM) analizand rolurile, valorile si principiile fiecareia dintre ele, practicile lor specifice si modurile in care pot fi adaptate sau combinate aceste metode
Asta reprezinta in primul rand certificarea PMI-ACP: un pas necesar catre eliminarea barierelor de comunicare si catre lucrul colaborativ. Un mod de a intelege cele doua lumi, problemele comune care le unesc si metodele la dispozitie pentru a le rezolva impreuna.
Salut Mihai,
inteleg idea, este interesanta dar am cateva nelamuriri si intrebari.
Cum poate un stackeholder important sau businees people ( fie sponsor, etc) sa tina legatura “in fiecare zi” cu developerii? Adica o diferenta de nivele destul de mare ( 203 cel putin)
Nu este cumva destul de greu sa se “traduca” partea tehnica la nivel de business? Lucru care necesita mult timp.
Si in ce mod sa fie facuta comunicarea?
Cum se va face tackingul concluziilor discutiilor?
Consider ca un plan de comunicare este necesar sa fie definit inca de la inceput in care sa se specifice clar cum se face comunicare , intre cine si cine, cand, cum.etc..ca in PMBoK.
Ori pentru acest lucru exista PM, TL, etc..
iar in sus directori, etc..care vor sa primeasca informatiile intr-un format anume pe care sa il inteleaga si sa il analizeze mai departe in luare unor decizii.
Salut Gabriel,
Multumesc pentru aprecieri, feedback si intrebari.
O sa le iau pe rand, incercand sa formulez cate un raspuns pentru fiecare din puntele din feedback:
Q: “Cum poate un stackeholder important sau businees people ( fie sponsor, etc) sa tina legatura “in fiecare zi” cu developerii?”
A: In primul rand, avantajele care decurg din legatura zilnica intre business si development sunt mai mari decat problema gasirii timpului necesar. in al doilea rand, e clar ca nu toti stakeholderii si Sponsorul propriu-zis pot face asta zilnic asa ca metodele Agile definesc de obicei un rol specializat pe decizia de Business, rol care lucreaza zi de zi cu developerii dar are toate legaturile de informatie si prioritizare si cu toate categoriile de stakeholderi. Acest rol, fie ca e numit “Product Owner” ca in Scrum, fie “Customer” fie “Business Representative”, se bucura de increderea tuturor stakeholderilor pentru ca le reprezinta interesul in proiect si face transferul informatiilor de business catre echipa: De ce e nevoie sa facem un anumit lucrul, care e beneficiul, care e valoarea asociata, care e riscul mitigat. In felul acesta echipa intelege, e motivata si isi doreste sa rezolve problema, nu doar sa termine un task.
Q: “Nu este cumva destul de greu sa se “traduca” partea tehnica la nivel de business?”
A: Ba da, este greu in termeni tehnici, dar poate fi “tradusa”in termeni strans legati de partea financiara a proiectului, ca si: “cost of change”, “technical debt”, “valoare negativa data de materializarea riscurilor”, “cone of uncertainty”. Daca ambele grupuri ii inteleg, e un pas spre clarificare.
Q: “Si in ce mod sa fie facuta comunicarea?”
A: Cel mai eficient cu putinta este prin comunicare directa: fata-in-fata.
Q: “Cum se va face tackingul concluziilor discutiilor?
Consider ca un plan de comunicare este necesar sa fie definit inca de la inceput in care sa se specifice clar cum se face comunicare , intre cine si cine, cand, cum.etc..ca in PMBoK.”
A: Trackingul adica trasabilitatea discutiilor in requirements si teste se poate face prin actualizarea “cerintelor” din backlog sau a taskurilor deja asumate de echipa. In general e adevarat ca in Agile se diminueaza importanta documentarii, ca volum de informatie scrisa. Asta conform principiilor “Lean” ar fi o forma de pierdere, de “waste”, dar in continuare exista nevoia si de a avea un “just enough” si “just in time” de informatie scrisa.
De acord si cu planul e comunicare. Unele metode ca Scrum il implementeaza direct in definitia metodei, prin intermediul “evenimentelor de echipa”: Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective. Stim prin definitia metodei cine participa la fiecare eveniment, care este timebox-ul alocat, care e rezultatul asteptat. La unele dintre aceste evenimente periodice sunt invitati stakeholderi diversi pentru a oferi feedback si a ghida dezvoltarea pentru mai departe.
Q: “Ori pentru acest lucru exista PM, TL, etc.”
A: Despre distributia responsabilitatilor de management in Agile iti mai recomand un post, de acum cateva saptamani:
http://www.pmcommunity.ro/2017/01/descentralizarea-atributiunilor-de-project-management-in-era-informationala/
Q:”iar in sus directori, etc..care vor sa primeasca informatiile intr-un format anume pe care sa il inteleaga si sa il analizeze mai departe in luare unor decizii”
A: Tocmai aici e problema pe care am sesizat-o eu in articol. Lipsa unui format comun de a transmite si a primi informatiile, intre cele 2 grupuri. Din fericire, exista un imbaj comun, si acela e recomandat si de PMI ca o curricula pentru certificarea ACP.
Multumesc inca o data pentru feedback, ma bucur ca tema este de interes pentru tine. 🙂