Managementul este obsedat să măsoare totul, iar această obsesie sabotează soluțiile de calitate pe care echipele de inginerie software le pot dezvolta.
Liderilor de afaceri care gestionează firme de software development le place să vadă cifrele, metricile care pretind că cuantifică valoarea pe care acestea o crează. Deși este posibil să nu înțeleagă subtilitățile ezoterice ale refactorizării pentru a îmbunătăți lizibilitatea și concizia, ei pot aprecia când acoperirea codului crește de la 85% la 90%. Cifrele cresc! Deci ceva valoros trebuie să se întâmple, nu-i așa?
Problema este că atât de multe dintre aceste numere sunt o pierdere de timp și nici măcar măsurile valide nu funcționează bine ca instrumente de management. Metricile au locul lor, dar ar trebui să urmeze unde conduc echipele, pentru a cuantifica calitatea și valoarea soluțiilor pe care le creează. Când metricile conduc – când punctele poveștii dictează unde trebuie să se îndrepte dezvoltatorii – ele de fapt împiedică capacitatea echipelor de a inova, de a crea și de a rezolva probleme semnificative.
Pentru soluții software cu adevărat valoroase dezvoltate de echipe de inginerie eficiente, managerii ar trebui să gestioneze moralul, satisfacția dezvoltatorilor și focusul echipei, apoi să aibă încredere în acestea pentru a genera eficiență, calitate și o cultură a companiei în care toată lumea poate prospera. Managerii celor mai de succes echipe, atât din sport cât și din lumea afacerilor, gestionează starea de spirit, moralul echipelor. Până și tendințele economice ale unei națiuni se stabilesc peron măsurarea încrederii populației în economie. Starea națiunii, moralul ei, influențează succesul economic și al politicilor publice.
Gestionarea metricilor este ineficientă
Luați în considerare un exemplu destul de banal. O echipă de ingineri rezolvă în mod constant 20 de tichete în fiecare sprint. Valorile sunt grozave, echipa în mod clar performează, iar proprietarul produsului poate raporta progrese excelente părților interesate.
Dar apoi te uiți puțin mai atent și descoperi că această echipă a atins acele cifre lucrând un șir de săptămâni de 60 de ore. Sunt obosiți, arși, le lipsesc prietenii și familiile și nici măcar nu au clar valoarea a ceea ce creează. Cu ochi îngroziți și tunel carpian, sunt tratați și se simt ca niște roboți comercializați, automate care asamblează codul de-a lungul unei linii nesfârșite.
Cifrele arată grozav, dar moralul este groaznic.
Priviți mai atent și aproape sigur veți descoperi că calitatea codului lor suferă, iar valoarea potențială a soluțiilor lor este suprimată. Veți găsi puține teste automate sau deloc, puțină refactorizare și multe hack-uri. Veți găsi mai mult technical debt, probleme cu scalarea și deconectări între experiența dorită de utilizator și codul implementat.
Dacă inginerilor tăi le pasă de calitate – și nu ar trebui să angajezi pe cineva căruia nu-i pasă – ei știu că fac o muncă inferioară, iar moralul lor va scădea în continuare.
Lăsați acest lucru să continue suficient de mult și veți suferi în curând un alt cost: talent pierdut și întârzierile și dificultățile de a include noi ingineri în timpul unui proiect.
Dar pentru că gestionați metrici în loc de stare de spirit, nu veți vedea toate aceste probleme până când nu va fi prea târziu.
Pentru a gestiona moralul, concentrați-vă pe misiune, autonomie și măiestrie
Nu vorbesc aici despre prostii motivaționale toxice distribuite angajaților, acoperite cu carismă și întărite cu stimulente artificiale. Stimulente precum recompense pentru atingerea unor valori arbitrare. Vorbesc în schimb despre moralul care vă inspiră echipele să investească sustenabil în succesul fiecărui proiect.
După cum a scris Daniel Pink în cartea sa de succes din 2009, “Drive: The Surprising Truth About What Motivates Us”, adevărata motivație intrinsecă – am putea spune moralul investit – vine din autonomie, măiestrie și scop.
Recompensele tranzacționale legate de valori artificiale pot impune conformitatea de bază cu un proces arbitrar, dar nu vor dezlănțui niciodată întregul potențial concentrat al unei echipe eficiente de inginerie software pentru a inova, a rezolva probleme semnificative și a crea o valoare nouă substanțială. În schimb, aveți nevoie de inginerii dvs. să investească în scopul unui proiect, să preia proprietatea asupra soluției și să fie mândri de calitatea soluției pe care o creează.
Moralul este înrădăcinat în misiune (nu în metrici)
A dispărut de mult forța de muncă care stătea într-o birouaș, făcând cu respect orice lucru care le era cerut. Domeniul este acum dominat de Millennials și Generația Z, iar aceste generații au misiunea în miezul lor. Resping angajarea pur tranzacțională. Mulți doresc să lucreze pentru companii care sunt bazate pe principii și orientate spre scop.
Într-adevăr, toți programatorii buni, indiferent de generația lor, sunt oameni cu principii care doresc să abordeze probleme interesante, să creeze cod de calitate fără datorii tehnice și să producă soluții valoroase pentru cei cărora îi servesc. (Și din nou, nu angajați programatori care nu au aceste calități.)
Nu aveți nevoie de valori fără sens pentru a le stimula dorința. Trebuie să vă ajutați echipele să se conecteze cu misiunea fiecărui proiect, să eliminați orice obstacol în calea succesului lor și să le susțineți cu tot ce au nevoie pentru a-și face cel mai bun lucru.
Respectați-vă suficient inginerii pentru a explica și a discuta scopul proiectului. Ce încercăm să facem? De ce facem asta? Care e ideea? Care este filozofia?
Misiunea nu trebuie să fie despre salvarea lumii.
Cu toate acestea, misiunile nu trebuie să fie atât de mari pentru a inspira investiții. O misiune poate fi „implementarea unui software bun, etic, care rezolvă probleme interesante”. Este în regulă dacă problema este că „camionagii de distanțe lungi se chinuie să-și depună salariile pentru ca familiile lor să-și poată plăti facturile gospodăriei” sau „o infrastructură învechită înăbușă inovația pentru un sistem cheie de control pentru proprietățile rezidențiale multifamiliale”.
Problemele nu trebuie să fie globale atâta timp cât misiunea de a crea cod de calitate pentru a rezolva problemele valoroase este onorată și susținută în mod substanțial – și atâta timp cât valorile arbitrare nu au voie să compromită această misiune.
Moralul este activat în autonomie (nu în metrici)
Un simț comun al misiunii este grozav, dar puterea sa motivațională este anulată dacă apoi micro gestionați modul în care o echipă contribuie la îndeplinirea misiunii respective.
„Noi” putem transforma o industrie, să salvăm vieți sau să lărgim orizontul realizărilor umane. Dar dacă iei toate deciziile în consecință, atunci experiența zilnică a inginerilor tăi se reduce la închiderea cotei lor de tichete pentru a-și îndeplini cifrele. Sunt prea departe de misiune. Acest lucru este mult mai puțin motivant pentru ei și pierzi întregul potențial al gândirii lor critice și al creativității.
Echipele eficiente de programatori sunt în mare parte autonome. Îi ajutați să înțeleagă misiunea și nevoile particulare ale părților interesate și ale utilizatorilor. Stabilești câteva reguli de bază și balustrade de protecție pentru soluția tehnică. Apoi te dai la o parte din calea lor și îi lași să facă ceea ce fac cel mai bine, bazându-te pe credința lor orientată spre calitate pentru a-i ghida către cea mai bună abordare.
O echipă autonomă are nevoie în continuare de supraveghere inteligentă și de o bună conducere. Anarhia dezvoltatorilor nu funcționează, iar haosul nu este motivant. Dar ai încredere în inginerii tăi pentru a rezolva problemele la care lucrează. Ai încredere în ei că vor identifica provocările potențiale și vor găsi soluții mai bune. Ai încredere în ei că vor gestiona îndeplinirea misiunii proiectului.
Și dacă nu poți oferi echipei tale această încredere, verifică-te dacă ai angajat oamenii nepotriviți sau poate nu îi conduci bine pe cei potriviți sau dacă permiți proceselor arbitrare să stea în calea ingineriei. Metricile nu vor rezolva aceste probleme. Un accent pe autonomie în cadrul unui angajament comun față de voința calității, da.
Moralul se îmbunătățește prin măiestrie (nu cu metrici)
Când vorbim despre măiestrie, este vorba adesea despre seturile de abilități ale inginerilor individuali și despre oportunitățile pe care le au de a dezvolta aceste abilități. Dar măiestria este și sistemică. Deciziile și procesele organizaționale pot fie să susțină, fie să împiedice capacitatea inginerilor și a echipelor de a face o muncă de calitate de care pot fi mândri.
Inginerii dumneavoastră au un simț clar al direcției? Au instrumentele de care au nevoie și timp neîntrerupt pentru a le folosi bine? Au o voce în stabilirea termenelor și au autoritatea de a lua decizii importante? Au timp suficient pentru a face treaba corect? Să exploreze și să învețe? Să se odihnească, să reflecteze și să se refacă? Pentru a implementa și măsura soluțiile în mod corespunzător?
Sau tirania cifrelor îi determină să livreze ceea ce știu că este un cod neglijent și să se grăbească către următorul tichet? Ori sunt distrași de întâlniri inutile și procese arbitrare? Sau sunt suprasolicitați și în burnout?
Acești factori sistemici adunați sub umbrela „experienței dezvoltatorului”, influențează direct eficacitatea programatorilor și succesul în afaceri. Este un subiect cercetat Dr. Michaela Greiler, Margaret-Anne Storey și Abi Noda, în lucrarea „An Actionable Framework for Understanding and Improvement Developer Experience” publicată în Journal of Transaction on Software Engineering. Autorii afirmă că nici valorile de ieșire, nici cele de proces nu pot măsura cu exactitate experiența programatorului.
Într-o cultură a încrederii și a respectului, liderii încep cu presupunerea că echipele lor doresc să creeze software de calitate. Ei nu folosesc valori pentru a măsura sau a impune această stăpânire. În schimb, au conversații deschise, sigure și sincere cu echipele lor. Ce încercăm să facem aici? (Misiune.) Ce îți stă în cale? (Autonomie.) Cum vă putem sprijini să faceți cel mai bun lucru? (Măiestrie.)
Aceste conversații sunt înrădăcinate într-o înțelegere comună a scopului și conduc la schimbări sistemice menite să sprijine fiecare inginer și fiecare echipă în satisfacția și succesul lor.
Gestionarea moralului duce la soluții mai bune, o retenție mai bună și, o mai bună cultură a organizației
Moralul înseamnă mult mai mult decât un mediu de lucru plăcut și scoruri bune de satisfacție a angajaților. Atunci când inginerii de software sunt investiți în misiunea unui proiect, au încredere în autonomie pentru a-l rezolva așa cum cred ei cel mai bine și li se acordă sprijinul de care au nevoie pentru a-și face cel mai bun lucru, ei livrează soluții mai bune și mai valoroase.
De asemenea, este mult mai probabil să rămână în companie. Pe măsură ce se duce vorba, recrutarea de talente suplimentare va deveni și mai ușoară.
Și da, gestionarea moralului duce și la o cultură a companiei mai bună, la o comunitate mai bună. Una din care tu și toată lumea din echipa ta vă veți bucura să faceți parte, deoarece, împreună, aplicați tot ce este mai bun din talentele voastre individuale și colective pentru a crea soluții software cu adevărat transformatoare.