Salutare tuturor! Numele meu este Lyudmila Makarova, sunt manager de dezvoltare la UBRD și o treime din echipa mea sunt „generaliști”.
Recunoașteți: fiecare Tech Lead visează la funcționalitate transversală în cadrul echipei sale. Este atât de grozav când o persoană este capabilă să înlocuiască trei și chiar să o facă eficient, fără a întârzia termenele limită. Și, important, economisește resurse!
Sună foarte tentant, dar este chiar așa? Să încercăm să ne dăm seama.
Cine este el, precursorul nostru al așteptărilor?
Termenul „generalist” se referă de obicei la membrii echipei care combină mai multe roluri, de exemplu, dezvoltator-analist.
Interacțiunea echipei și rezultatul muncii sale depind de calitățile profesionale și personale ale participanților.
Totul este clar despre abilitățile hard, dar abilitățile soft merită o atenție specială. Ele ajută la găsirea unei abordări față de un angajat și îl direcționează către sarcina în care îi va fi cel mai util.
Există multe articole despre toate tipurile de personalitate din industria IT. Pe baza experienței mele, aș împărți generaliștii IT în patru categorii:
1. „Universal – Atotputernic”
Acestea sunt peste tot. Sunt întotdeauna foarte activi, vor să fie în centrul atenției, își întreabă constant colegii dacă au nevoie de ajutorul lor și, uneori, pot fi chiar enervanti. Ei sunt interesați doar de sarcini semnificative, participarea la care va da loc creativității și le poate amuza mândria.
În ce sunt puternice:
- sunt capabili să rezolve probleme complexe;
- scufundați-vă adânc în problemă, „sapă” și obține rezultate;
- ai o minte curios.
dar:
- labil emoțional;
- prost gestionat;
- au propriul lor punct de vedere de neclintit, care este foarte greu de schimbat;
- Este greu să faci pe cineva să facă un lucru simplu. Sarcinile ușoare rănesc egoul celui atotputernic.
2. „Universal – îmi voi da seama și o voi face”
Astfel de oameni au nevoie doar de un manual și de puțin timp - și vor rezolva problema. De obicei, au o experiență puternică în DevOps. Astfel de generaliști nu se deranjează cu designul și preferă să folosească o metodă de dezvoltare bazată exclusiv pe experiența lor. Aceștia pot avea cu ușurință o discuție cu responsabilul tehnic despre opțiunea aleasă pentru implementarea sarcinii.
În ce sunt puternice:
- independent;
- rezistent la stres;
- competent în multe probleme;
- erudit - întotdeauna există ceva de discutat cu ei.
dar:
- încalcă adesea obligațiile;
- tind să complice totul: rezolvați tabla înmulțirii prin integrare pe părți;
- calitatea muncii este scăzută, totul funcționează de 2-3 ori;
- Ei schimbă în mod constant termenele limită, pentru că în realitate totul se dovedește a nu fi atât de simplu.
3. „Universal – bine, lasă-mă să o fac, pentru că nu mai este nimeni altcineva”
Angajatul este bine versat în mai multe domenii și are experiență relevantă. Dar nu reușește să devină profesionist în niciuna dintre ele, pentru că este adesea folosit ca un colac de salvare, astupând găuri în sarcinile curente. Pliabil, eficient, se consideră solicitat, dar nu este.
Un angajat practic ideal. Cel mai probabil, are o direcție care îi place cel mai mult, dar din cauza estompării competențelor, dezvoltarea nu are loc. Ca urmare, o persoană riscă să devină nerevendicată și arsă emoțional.
În ce sunt puternice:
- responsabil;
- orientat spre rezultate;
- calm;
- complet controlat.
dar:
- arata rezultate medii datorita unui nivel scazut de competente;
- nu poate rezolva probleme complexe și abstracte.
4. „Un om polivalent este un maestru al meșteșugului său”
O persoană cu experiență serioasă ca dezvoltator are gândire sistemică. Pedant, exigent la sine și la echipa sa. Orice sarcină care îl implică poate crește la infinit dacă granițele nu sunt definite.
Cunoaște bine arhitectura, selectează o metodă de implementare tehnică, analizând cu atenție impactul soluției alese asupra arhitecturii actuale. Modest, nu ambițios.
În ce sunt puternice:
- arată calitatea înaltă a muncii;
- capabil să rezolve orice problemă;
- foarte eficient.
dar:
- intolerant la opiniile altora;
- maximalisti. Ei încearcă să facă totul corect, iar acest lucru crește timpul de dezvoltare.
Ce avem în practică?
Să vedem cum rolurile și competențele sunt cel mai adesea combinate. Să luăm ca punct de plecare o echipă de dezvoltare standard: PO, manager de dezvoltare (leader tehnologic), analiști, programatori, testeri. Nu vom lua în considerare proprietarul produsului și liderul tehnic. Prima se datorează lipsei de competențe tehnice. Al doilea, dacă sunt probleme în echipă, ar trebui să poată face totul.
Cea mai comună opțiune de combinare/combinare/combinare a competențelor este dezvoltator-analist. Analistul de testare și „trei într-unul” sunt, de asemenea, foarte frecvente.
Folosind echipa mea ca exemplu, vă voi arăta avantajele și dezavantajele colegilor mei generaliști. Sunt o treime din ei în echipa mea și îi iubesc foarte mult.
PO a primit o sarcină urgentă de a introduce noi tarife într-un produs existent. Echipa mea are 4 analiști. La acel moment, unul era în vacanță, celălalt era bolnav, iar restul erau angajați în implementarea sarcinilor strategice. Dacă le-aș scoate, inevitabil ar perturba termenele limită de implementare. Exista o singură cale de ieșire: să folosești „arma secretă” - un dezvoltator-analist versatil care stăpânește domeniul necesar. Să-i spunem Anatoly.
Tipul lui de personalitate este „universal – îmi voi da seama și o voi face”. Bineînțeles, a încercat multă vreme să explice că „are un total întârziat de sarcini”, dar prin decizia mea puternică a fost trimis să rezolve o problemă urgentă. Și Anatoly a făcut-o! A realizat montajul și a finalizat implementarea la timp, iar clienții au fost mulțumiți.
La prima vedere, totul a mers. Dar, după câteva săptămâni, au apărut din nou cerințe de îmbunătățire pentru acest produs. Acum formularea acestei probleme a fost efectuată de un analist „pur”. În stadiul de testare a noii dezvoltări, mult timp nu am putut înțelege de ce aveam erori în legarea noilor tarife și abia atunci, după ce am dezlegat întreaga încurcătură, am ajuns la fundul adevărului. Am pierdut mult timp și am ratat termenele limită.
Problema a fost că multe momente și capcane ascunse au rămas doar în capul break-ului nostru și nu au fost transferate pe hârtie. După cum Anatoly a explicat mai târziu, era prea grăbit. Dar cea mai probabilă opțiune este că a întâlnit probleme deja în timpul dezvoltării și pur și simplu le-a ocolit fără să reflecte acest lucru nicăieri.
Era o altă situație. Acum avem un singur tester, așa că unele sarcini trebuie testate de analiști, inclusiv de generaliști. Prin urmare, i-am dat o sarcină Fedorului condiționat - „universal – bine, lasă-mă să o fac, pentru că nu e nimeni altcineva”.
Fedor este „trei într-unul”, dar un dezvoltator a fost deja alocat pentru această sarcină. Aceasta înseamnă că Fedya a trebuit să combine doar un analist și un tester.
Cerințele au fost colectate, caietul de sarcini a fost supus dezvoltării, este timpul să testăm. Fedor știe că sistemul este modificat „ca dosul mâinii” și a rezolvat temeinic cerințele actuale. Prin urmare, nu s-a deranjat să scrie scripturi de testare, ci a efectuat teste despre „cum ar trebui să funcționeze sistemul”, apoi le-a transmis utilizatorilor.
Testul a fost finalizat, revizuirea a intrat în producție. Ulterior s-a dovedit că sistemul nu numai că a suspendat plățile către anumite conturi de sold, dar a blocat și plățile din conturi interne foarte rare care nu trebuiau să participe la acest lucru.
Acest lucru s-a întâmplat din cauza faptului că Fedor nu a verificat cum „sistemul nu ar trebui să funcționeze”, nu a întocmit un plan de testare sau liste de verificare. A decis să economisească timp și să se bazeze pe propriile sale instincte.
Cum ne descurcăm cu problemele?
Situații ca acestea influențează performanța echipei, calitatea lansării și satisfacția clienților. Prin urmare, ele nu pot fi lăsate fără atenție și analiza motivelor.
1. Pentru fiecare sarcină care a cauzat dificultăți, vă rog să completați un formular unificat: o hartă a erorilor, care vă permite să identificați stadiul în care a avut loc „retragerea”:
2. După identificarea blocajelor, are loc o sesiune de brainstorming cu fiecare angajat care a influențat problema: „Ce să schimbi?” (nu luăm în considerare cazuri speciale retrospectiv), în urma cărora se nasc acțiuni specifice (specifice fiecărui tip de personalitate) cu termene limită.
3. Am introdus reguli de interacțiune în cadrul echipei. De exemplu, am convenit să înregistrăm în mod necesar toate informațiile despre progresul unei sarcini în sistemul de management al proiectelor. Atunci când artefactele sunt modificate/identificate în timpul procesului de dezvoltare, acest lucru trebuie să se reflecte în baza de cunoștințe și în versiunea finală a specificațiilor tehnice.
4. Controlul a început să fie efectuat în fiecare etapă (se acordă o atenție deosebită etapelor problematice în trecut) și automat pe baza rezultatelor sarcinii următoare.
5. Dacă rezultatul la următoarea sarcină nu s-a schimbat, atunci nu-l pun pe generalist în discuție în rolul în care se descurcă prost. Încerc să-i evaluez capacitatea și dorința de a-și dezvolta competențe în acest rol. Dacă nu găsesc un răspuns, îl las în rolul care este mai aproape de el.
Ce s-a intamplat la final?
Procesul de dezvoltare a devenit mai transparent. Factorul BUS a scăzut. Membrii echipei, lucrând la greșeli, devin mai motivați și își îmbunătățesc karma. Îmbunătățim treptat calitatea lansărilor noastre.
Constatări
Angajații generaliști au avantajele și dezavantajele lor.
avantaje:
- puteți închide oricând o sarcină sălbată sau puteți rezolva o eroare urgentă într-un timp scurt;
- o abordare integrată a rezolvării unei probleme: interpretul o privește din perspectiva tuturor rolurilor;
- generaliştii pot face aproape totul la fel de bine.
Dezavantaje:
- factorul BUS crește;
- competenţele de bază inerente rolului sunt erodate. Din această cauză, calitatea muncii scade;
- probabilitatea unei schimbări a termenelor limită crește, deoarece nu există control în fiecare etapă. Există și riscuri de a crește o „stea”: angajatul este încrezător că știe mai bine că este un profesionist;
- riscul de burnout profesional crește;
- multe informații importante despre proiect pot rămâne doar „în capul” angajatului.
După cum puteți vedea, există mai multe deficiențe. Prin urmare, folosesc generaliști doar dacă nu sunt suficiente resurse și sarcina este destul de urgentă. Sau o persoană are competențe care le lipsesc altora, dar calitatea este în joc.
Dacă regula de distribuție a rolurilor este respectată în munca comună asupra unei sarcini, atunci calitatea muncii crește. Privim problemele din unghiuri diferite, vederea noastră nu este încețoșată, mereu apar gânduri proaspete. În același timp, fiecare membru al echipei are toate oportunitățile de creștere profesională și extindere a competențelor sale.
Consider că cel mai important este să te simți implicat în proces, să-ți faci munca, crescând treptat lărgimea competențelor tale. Cu toate acestea, generaliștii dintr-o echipă aduc beneficii: principalul lucru este să vă asigurați că îmbină eficient diferitele roluri.
Le doresc tuturor o echipă auto-organizată de „maeștri universali ai meșteșugului lor”!
Sursa: www.habr.com