O echipă hiperproductivă este visul oricărui lider de echipă. Ce simplu ar fi să aplicăm un algoritm în zece pași prin care să ajungem la o echipă de zece ori mai productivă. Sau să îmbunătățim puțin comunicarea și echipa să ajungă singură în stadiul de nirvana al productivității. Cum bine știm cu toții, lucrurile nu sunt atât de simple. Acest articol își propune să prezinte câteva modalități prin care putem crea o echipă echilibrată și motivată care își cunoaște atât punctele forte cât și pe cele slabe.
Înainte de a începe aș vrea să punctez câteva idei pentru a selecta corect așteptările asupra conținutului. Cum ziceam mai sus, nu o să găsiți în acest articol rețete gen 10 pași către o echipă super-productivă. Dacă aș fi avut un astfel de algoritm, aș fi fost mult mai celebru decât acum. Și cel mai important de precizat, acest articol este destinat liderilor și nu managerilor. (Pentru cine are dubii despre diferența dintre cele două concepte, observați explicațiile vizuale de mai jos.)
Nu știu dacă mai țineți minte serialul Lost care era în mare vogă acum 8-10 ani. Fiecare episod începea cu următoarea precizare: Viewer discretion is advised. Aceasta însemna că show-ul ce urma, avea conținut care putea fi considerat ofensator de anumite persoane și aceștia luau o decizie conștientă și informată de a continua să se uite la episodul respectiv sau nu.
Același lucru îl voi spune și eu despre conținutul acestui articol: Reader discretion is advised. Articolul de față va conține limbaj explicit precum performanță, productivitate, lipsa anumitor abilități, metrici, etc., care poate fi considerat din categoria "așa ceva nu se discută" de anumite persoane.
Când vorbim despre calitate în proiectele software, vorbim de obicei de calitate din mai multe perspective. Putem vorbi de calitatea procesului de livrare în sine, putem vorbi despre calitatea testării, despre calitatea codului, arhitecturii, etc. . De foarte puține ori însă discutăm deschis despre calitatea persoanelor din echipă. Și aceasta pentru că în cazul performanței individuale, lucrurile devin foarte personale. E mult mai simplu să atacăm subiectele abstracte și impersonale precum cele enumerate anterior legate de proces, testare, cod - deși sunt tipuri de persoane care consideră codul o prelungire a propriei ființe- , dar foarte greu să ajungem la discuții punctuale legate de abilitățile individuale.
Una dintre cele mai revelatoare cărți pe care am citit-o, din zona performanței în domeniile creative, cum este cel al dezvoltării software, este Drive a lui Daniel H. Pink. Pe scurt, cartea face o paralelă între Motivation 1.0 aka Carrots and Sticks - modalitatea cea mai simplă și cea mai folosită de-a lungul timpului pentru motivarea indivizilor: dacă faci ceva bine primești o recompensă, dacă faci ceva greșit ești penalizat, și Motivation 2.0 care este mult mai complexă ca mecanism și are la baza trei concepte: Mastery, Autonomy(DETAIL) and Purpose. În esență, pentru lucrul creativ, de la un anumit punct încolo, indiferent cât de mare devine recompensa, rezultatele nu mai sunt pe măsură, ba chiar mai mult, recompensa tinde să aibă efecte negative asupra rezultatelor. Așa că atenția ar trebui orientată spre crearea unui mediu de lucru care încurajează colaborarea, recunoașterea nivelului de expertiză, încrederea că fiecare poate rezolva autonom diverse tipuri de taskuri și oferirea unui înțeles muncii pe care o depune fiecare. Deși cartea descrie foarte bine diferențele dintre cele două tipuri de motivare cu exemple concrete, bine documentate, nu relatează foarte concret și modul de creare a unui mediu de lucru favorabil pentru Motivation 2.0.
Un alt concept legat de performanța echipelor de această dată este The Bus Factor: câți membri din echipă trebuie să fie loviți de un autobuz pentru ca proiectul să ajungă în impas. Cu cât factorul tinde mai mult către 1, cu atât riscul de a nu livra proiectul la timp este mai ridicat.
În continuare, vom discuta despre cum putem crea un mediu de lucru propice pentru Motivation 2.0 astfel încât să ajungem la un Bus Factor cât mai departat de 1. Dar în loc să discutăm despre percepții subiective și modalități euristice de aplicare, vom analiza modalități concrete și obiective prin care putem face acest lucru.
Anul trecut la Qcon am asistat la o prezentare foarte interesantă numită Treat your code as a crime scene. Autorul prezentării (există si o carte pe baza subiectului), Adam Tornhill, afirmă că ar trebui să tratăm sistemul de versionare a codului (git, svn, tfs) ca un loc al unei crime și să extragem informații valoroase legate de comportamentul codului de-a lungul unei perioade de timp definite, informații care ne vor folosi apoi pentru diverse decizii legate de: zonele din care să începem o refactorizare, în ce direcție se îndreaptă codebase-ul sau modalitatea în care echipa influențează designul codului. Toată prezentarea a fost strict legată de comportamentul codului. Însă eu cred că sistemul de versionare ascunde informații la fel de prețioase legate de comportamentul membrilor din echipă.
Mai mult decât atât, cred că avem în momentul de față o mulțime de sisteme pe care le folosim (jira, sonarqube, crucible, jenkins, etc.) care oferă metrici valoroase pe care, dacă le-am corela, am avea informații și mai clare despre aptitudinile și comportamentul membrilor din echipă.
Articolul de față se va focaliza exact pe modul în care putem corela metrici din aceste sisteme și cum putem determina disfuncționalități ale echipelor și membrilor echipelor astfel încât să influențăm dezvoltarea personală în direcția corectă. Am numit aceste disfuncționalități sindroame, pentru a le prezenta și într-o forma clinică ușor de urmărit.
Simptome:
(Limbajul de specialitate psihiatrică are conotații ironice!)
Diagnostic:
Vom oferi un exemplu care să demonstreze cât de important este contextul, precum testele unitare. Vom considera și o echipă fictivă: Transformers.
Identificarea numărului de teste unitare adăugate de un membru al echipei se poate face simplu pe baza convențiilor de denumire: clasele de test încep sau se termină cu Test în denumire. Făcând mining în sistemul de versionare descoperim că Bumblebee a scris 6 teste unitare în ultimele 4 săptămâni. Ce spuneți? Este bine sau rău?
Cum afirmam și mai sus, contextul este esențial. La prima vedere, am putea spune ca 6 teste unitare în 4 săptămâni este foarte, foarte puțin. E undeva la un test la fiecare trei zile. Dar dacă ceilalți membri ai echipei nu au scris niciun test? Atunci Bumblebee este campionul testelor unitare?
La fel putem aplica și pentru CSS, Javascript, SQL, scripturi de configurare, sau orice altă activitate particulară.
Revenind acum la Bus Factor. Dacă tot codul de SQL este scris doar de o persoană din echipă, ce credeți că se va întâmpla când persoana respectivă pleacă din echipă?
Aceleași principii se pot aplica și pentru interacțiuni mai complicate cum ar fi specializarea pe anumite componente sau zone de business.
Monitorizarea metricelor nu trebuie să fie mereu în zona de lipsuri. Putem să ne concentrăm și înspre zone pozitive cum este cazul sindromului curent.
Simptome:
Diagnostic:
Considerăm că Bumblebee a adăugat 200 de linii de cod (LOC) în ultimele patru săptămâni. Poate fi considerat un membru al echipei productiv sau nu? Cum deja ne-am învățat lecția, totul depinde de context. Dacă toți ceilalți membri ai echipei au adăugat peste 700 de linii de cod, atunci Bumblebee nu mai e chiar într-o poziție favorabilă.
Sau este? Dacă ceilalți membri ai echipei au adăugat doar boilerplate code și cele 200 de LOC ale lui Bumblebee sunt doar logică de business?
Dar cum putem măsura aceasta? Destul de simplu. Putem interoga sisteme de monitorizare a calității codului precum Sonarqube care oferă acest gen de informații. Așa că adăugăm și aceasta pe lista de diagnosticare.
Simptome:
Diagnostic:
Dacă luăm iarăși exemplul lui Bumblebee. Considerăm că Bumblebee este un adept al refactorizării. Făcând mining în sistemul de versionare descoperim că majoritatea comiturilor din ultimele 4 săptămâni implică și numeroase refactorizări. Credeți că acest lucru este benefic pentru proiect? La prima vedere am putea spune că da. Prin refactorizările făcute, calitatea codului crește, codul devine mai ușor de înțeles, de extins, etc. Dar, iarăși, haideți să vedem contextul. Dacă în ultimele 4 săptămâni numărul de bug-uri s-a triplat și aceasta este principala cauză? Sunt suficient de multe teste automate care să valideze scenariile din zonele refactorizate? Avem suficient de multe cunoștințe de business din zonele afectate de refactorizare? Contextul este esențial!
Simptome:
Diagnostic:
Să presupunem că în ultimele două săptămâni codul scris de Bumblebee a primit 20 de defecte în Crucible și 40 de violations în Sonarqube, iar ceilalți membri ai echipei niciunul? Evident nu pare un lucru bun. Însă luând în considerare contextul, dacă motivul pentru care codul celorlalți arată așa de bine este pentru că au adăugat doar boilerplate code, iar codul scris de Bumblebee conține doar logică de business? Măcar Bumblebee își dă silința!
Cel mai mare adversar a lui Great este Good. Zona de confort este plăcută și foarte multe persoane evită să iasă din ea și să învețe lucruri noi.
Simptome:
Diagnostic:
Dacă Bumblebee face toate merge-urile în echipă și un decepticon malefic îl elimină, proiectul va avea serios de suferit. La fel putem considera și alte activități similare: deployment, testare de performanță, folosirea anumitor tool-uri, etc. .
Simptome:
Diagnostic:
Câteva exemple care surprind supra-încrederea:
Simptome:
Diagnostic:
Să presupunem că echipa Transformers a livrat 6 story points în sprint-ul curent. Cum vi se pare?
Un manager pentru care 6 este doar un număr ar spune că s-a livrat destul de puțin. La urma urmei, echipa cealaltă a livrat 25 de story points în aceeași perioadă de timp. Cu toții știm că motivul pentru care folosim story points, o unitate de măsură abstractă, este tocmai acela de a face să nu existe termeni de comparație cu velocitatea altor echipe. Însă managerul poate avea dreptate. Dacă echipa Transformers livrează constant 20 de story points și în sprint-ul curent doar 6, atunci e clar că este o problemă. Încă o dată, contextul este esențial.
Simptome:
Diagnostic:
Puține echipe se uită retrospectiv la acuratețea estimărilor date. Mai ales în contextul în care story point-urile sunt ceva abstract ca unitate de măsură. Poate nu de fiecare dată merită să intrăm în detalii foarte fine să vedem dacă un user story are 3 sau 5 story points, dar cred că e important să țintim un anumit nivel de predictibilitate.
Să presupunem că avem două user story-uri, ambele estimate la 5 story points. Primul user story a presupus modificarea a două scripturi de DB, adăugarea de trei clase CSS și o clasă Java, iar pentru al doilea am adăugat doar un IF. Oare cum se compară cele două? Poate fi cazul când adăugarea acelui IF a presupus o muncă de investigare laborioasă care este comparabilă cu efortul depus în implementarea celuilalt user story, dar și acest lucru poate ascunde diverse lipsuri: echipa nu are suficient de multă experiență cu anumite tehnologii, nu are cunoștințe de business suficiente sau poate membrul echipei care a implementat task-ul nu a beneficiat de ajutorul celorlalți membri din echipă. Mereu există o explicație și cred că e o conversație care ar trebui să existe în echipă din când în când.
Simptome:
Diagnostic:
Acest sindrom este în zona pozitivă. Acest tip de comportament ar trebui recunoscut și încurajat pentru toți membrii echipei. Dacă Bumblebee a modificat toate tipurile de fișiere în ultimul sprint (SQL, UI, deployemnt, etc.) și a comis modificări pe majoritatea componentelor proiectului, este în mod clar o persoană de valoare care merită încurajată să continue acest comportament și în același timp să fie un exemplu și pentru ceilalți membri ai echipei.
Simptome:
Diagnostic:
Odată identificate zonele fragile se pot lua diverse acțiuni pentru remediere. Clasele respective pot fi marcate cu prioritate ridicată în timpul review-urilor de cod, se pot lua decizii de a crește acoperirea de teste unitare pe zona respectivă sau acoperirea de teste funcționale pe zonele de business care folosesc acele clase. Aceasta ar trebui să fie o decizie de echipă și orientată spre zona care aduce beneficiile cele mai multe.
Cam aceasta ar fi lista celor 10 sindroame patologice la care m-am gândit că pot fi diagnosticate relativ ușor folosind informații din tool-urile folosite de echipe. Poate vă întrebați ce legătură au toate acestea cu Mastery, Autonomy and Purpose? Cu siguranță nu recomand folosirea acestor metrici pentru măsurarea performanțelor membrilor echipei. Se poate ajunge la discuții interminabile despre ce înseamnă un număr de teste normal într-o perioadă de două săptămâni, planuri de dezvoltare personală și alte lucruri manageriale. Aceste metrici ar trebui să servească liderilor pentru a influența diverse acțiuni în echipă.
Folosind acești indicatori obiectivi, liderii echipelor pot crea mediul propice în care membrii echipelor să devină cât mai autonomi și să le ofere și ocazia să exceleze în zonele ce le cunosc cel mai bine. Să luăm spre exemplu zona de teste unitare. Observăm ca doi membri ai echipei nu sunt foarte confortabili cu a scrie astfel de teste și avem un membru al echipei care pare să se descurce foarte bine în zona aceasta. În loc să avem discuții nu tocmai plăcute în care să le explicăm cât de greu se descurcă, mai bine rugăm persoana care excelează să pregătească un training practic. Recunoaștem astfel drept expert pe cel care organizează trainingul (Mastery) și creștem autonomia celorlalți doi (Autonomy). Toată lumea are de câștigat.
Pentru partea de purpose lucrurile stau puțin mai complicat. Pentru companiile de outsourcing este foarte dificil să conectezi echipa la scopul final. Sunt prea multe nivele între . Chiar dacă nu cred că se poate ajunge într-o zonă asemănătoare cu ce se întâmplă într-un start-up, cred că putem face acțiuni care să conecteze echipa cât mai mult la end goal. E important ca echipa să primească o viziune asupra proiectului din partea product owner-ului și să fie continuu conectată la această viziune. De asemenea, e și mai important ce se întâmplă după ce proiectul merge live. Câteva detalii periodice legate de modul în care este folosită funcționalitatea vor aduce cu siguranță impuls de încredere echipei și vor avea cu toții sentimentul că efortul depus are un scop.
Bineînțeles că în practică lucrurile nu vor sta atât de simplist, dar este o bază pe care puteți construi și care vă poate oferi indicii clare și obiective cu ajutorul cărora puteți alege o direcție sau alta.
În final, totul se rezumă la genul de echipă pe care vreți să îl creați.
de Diana Costa
de István Nagy
