Salut tuturor! Mă numesc Liudmila Makarova, sunt manager de dezvoltare la UBRiR și o treime din echipa mea sunt «universali».
Recunoașteți: fiecare Tech Lead visează la cross-funcționalitate în cadrul echipei sale. Este atât de grozav când o singură persoană poate înlocui trei și o face bine, fără a afecta termenele. Și, ceea ce este foarte important, asta asigură economisirea resurselor!
Sună foarte atrăgător, dar este într-adevăr așa? Hai să încercăm să înțelegem.
Cine este, de fapt, anticipatorul așteptărilor noastre?
Prin termenul «universal» se înțelege de obicei membrii echipei care îmbină mai multe roluri, de exemplu, dezvoltator-analist.
Interacțiunea echipei și rezultatul muncii acesteia depind de calitățile profesionale și personale ale participanților.
La hard skills e clar, dar soft skills merită o atenție specială. Ele ajută la găsirea unei abordări potrivite pentru angajat și la îndrumarea acestuia spre sarcina în care va fi cel mai util.
Există multe articole despre diverse tipuri de personalitate din industria IT. Bazându-mă pe experiența mea, aș împărți universalii IT în patru categorii:
1. «Universal – atotputernicul»
Aceștia există peste tot. Întotdeauna arată o mare activitate, vor să fie în centrul atenției, întreabă constant colegii dacă au nevoie de ajutorul lor, uneori chiar pot deveni enervanți. Sunt interesați doar de sarcini semnificative, participarea cărora le va permite să fie creativi și să-și hrănească vanitatea.
Între ce sunt puternici:
- sunt capabili să rezolve sarcini complicate;
- se adâncesc profund în problemă, «sapă» și obțin rezultate;
- au o minte curioasă.
Dar:
- sunt emoțional labili;
- sunt greu de gestionat;
- au un punct de vedere ferm, pe care este foarte greu să-l schimbi;
- este greu să-i determini să facă o activitate simplă. Sarcinile ușoare le rănesc vanitatea atotputernicilor.
2. «Universal – mă descurc și fac»
Acestor oameni le ajunge un ghid și puțin timp – și vor rezolva problema. De obicei, au un background mare ca DevOps. Acești universali nu își pierd timpul cu proiectarea și preferă să utilizeze metode de dezvoltare bazate exclusiv pe experiența lor. Se pot certa ușor cu tech lead-ul în legătură cu opțiunea aleasă pentru implementarea sarcinii.
Între ce sunt puternici:
- sunt independenți;
- sunt rezistenți la stres;
- sunt competenți în multe probleme;
- sunt erudiți – întotdeauna au cu cine să discute.
Dar:
- adesea nu își respectă angajamentele;
- tind să complice lucrurile: rezolvă tabela de înmulțire prin integrare prin părți;
- calitatea lucrărilor este scăzută, totul reușește după 2-3 încercări;
- întârzâie constant termenele, pentru că de fapt totul se dovedește a fi nu atât de simplu.
3. „Universal – bine, hai să fac eu, că nu mai este nimeni”
Angajatul are o bună înțelegere în mai multe domenii și are experiența corespunzătoare. Dar nu reușește să devină un profesionist în niciunul dintre ele, deoarece este adesea folosit ca o plasă de siguranță, acoperind lacunele în sarcinile curente. Este maleabil, executiv, se consideră dorit, dar în realitate nu este.
Practic, angajatul ideal. Cel mai probabil, are o direcție care îi place mai mult, dar din cauza neclarității competențelor, nu are loc dezvoltarea. Ca rezultat, individul riscă să devină inutilizabil și emoțional epuizat.
Între ce sunt puternici:
- responsabili;
- orientați spre rezultat;
- calmi;
- complet controlați.
Dar:
- dau rezultate medii din cauza unui nivel scăzut de competență;
- nu pot rezolva sarcini complexe și abstracte.
4. „Universal – maestru în meseria sa”
O persoană cu un fundal solid ca dezvoltator, are gândire sistemică. Este pedant, exigent cu sine și echipa. Orice sarcină la care participă poate crește la nesfârșit, dacă nu sunt stabilite limite.
Este bine familiarizat cu arhitectura, alege metoda de implementare tehnică, analizând cu grijă impactul soluției alese asupra arhitecturii curente. Este modest, nu are ambiții.
Între ce sunt puternici:
- dau o calitate înaltă a muncii;
- capabili să rezolve orice sarcină;
- foarte muncitori.
Dar:
- intoleranți față de opinia altora;
- maximaliști. Încercând să facă totul corect, acest lucru prelungește termenele de dezvoltare.
Ce avem în practică?
Să vedem cum sunt adesea unite rolurile și competențele. Să luăm ca punct de plecare o echipă standard de dezvoltare: PO, manager de dezvoltare (tech lead), analiști, programatori, testeri. Nu îl vom considera pe proprietarul produsului și pe tech lead. Pe primul – din lipsa competențelor tehnice. Pe al doilea, dacă există probleme în echipă, ar trebui să știe să facă tot.
Cea mai comună variantă de combinare/îmbinare/a competențelor este dezvoltator-analist. De asemenea, se întâlnesc frecvent analist-testare și "trei în unu".
În exemplul echipei mele, voi arăta care sunt avantajele și dezavantajele colegilor universali. În echipa mea, o treime dintre ei sunt universali, și îi apreciez foarte mult.
De la PO a venit o sarcină urgentă de implementare a noilor tarife în produsul existent. În echipa mea sunt 4 analiști. În acel moment, unul era în concediu, altul era bolnav, iar ceilalți se ocupau de implementarea sarcinilor strategice. Dacă i-aș fi scos pe aceștia, acesta ar fi dus inevitabil la întârzieri. A existat o singură soluție: să folosesc "arma secretă" – un dezvoltator-analist universal care cunoștea domeniul necesar. Să-i spunem Anatolii.
Tipul său de personalitate este "universal – mă descurc și fac".Bineînțeles, a încercat mult timp să explice că are "o punga plină de sarcini proprii", dar, printr-o decizie fermă, a fost trimis să rezolve sarcina urgentă. Și Anatolii a reușit! A realizat planificarea și a efectuat implementarea la timp, iar clienții au fost mulțumiți.
La prima vedere, totul a reușit. Dar după câteva săptămâni, la acest produs au apărut din nou cerințe pentru modificări. Acum planificarea acestei sarcini era făcută de un "pur" analist. În etapa de testare a noii dezvoltări, nu am putut înțelege mult timp de ce apareau erori în legătura cu noile tarife și abia apoi, desfăcând toată încâlceala, am ajuns la adevăr. Am pierdut o grămadă de timp și am întârziat termenele.
Problema consta în faptul că multe momente ascunse și capcane au rămas doar în mintea universalei noastre și nu au fost transmise pe hârtie. Așa cum a explicat mai târziu Anatolii, s-a grăbit prea tare. Dar este cel mai probabil că s-a lovit de probleme în timpul dezvoltării și pur și simplu le-a ocolit, fără a le reflecta nicăieri.
A fost și o altă situație. Acum avem doar un singur testor, așa că unele sarcini trebuie testate de analiști, inclusiv – universali. Așa că o sarcină i-am dat-o lui Fedor – "universal – bine, hai să o fac eu, că nu mai e nimeni"..
Fedor este "trei în unu", dar pentru această sarcină deja fusese desemnat un dezvoltator. Asta înseamnă că Fedor trebuia să îmbine în sine doar rolurile de analist și testor.
Cerințele au fost adunate, specificația a fost transmisă dezvoltării, acum a venit timpul să testăm. Fiodor cunoaște sistemul în dezvoltare „ca pe propriile degete” și a lucrat aprofundat la cerințele actuale. Prin urmare, nu s-a obosit să redacteze scenarii de testare, ci a realizat teste pe baza a „cum ar trebui să funcționeze sistemul”, apoi – a transmis utilizatorilor.
Testul s-a încheiat, îmbunătățirea a fost trimisă în producție. Ulterior, s-a descoperit că sistemul nu doar suspendă efectuarea plăților pe anumite conturi de sold, ci și blochează efectuarea plăților din conturi interne foarte rare, care nu ar fi trebuit să participe la această activitate.
Acest lucru s-a întâmplat pentru că Fiodor nu a efectuat o verificare privind „cum nu ar trebui să funcționeze sistemul”, nu a întocmit un plan de testare sau liste de verificare. El a decis să economisească timp și a mizat pe intuiția sa.
Cum abordăm problemele?
Astfel de situații afectează eficiența echipei, calitatea livrărilor și satisfacția clienților. De aceea, nu pot fi lăsate fără atenție și analiză a cauzelor.
1. Pentru fiecare sarcină care a ridicat dificultăți, vă rog să completați un formular unificat: o hartă a erorilor, care permite identificarea etapei la care a avut loc „scăderea”:
2. După identificarea blocajelor, se organizează o sesiune de brainstorming cu fiecare angajat care a contribuit la problemă, întrebând „Ce să schimbăm?” (cazurile particulare nu sunt discutate în retro), iar în urma acesteia se dezvoltă acțiuni concrete (pentru fiecare tip de personalitate altele) cu termene.
3. Am introdus reguli de interacțiune în cadrul echipei. De exemplu, ne-am convenit să înregistrăm toate informațiile despre progresul sarcinii în sistemul de gestionare a proiectelor. Atunci când există modificări sau descoperiri de artefacte în procesul de dezvoltare, acestea trebuie reflectate în baza de cunoștințe și în versiunea finală a specificației.
4. Controlul este efectuat la fiecare etapă (o atenție deosebită este acordată etapelor problematice din trecut) și automat pe baza rezultatelor următoarei sarcini.
5. Dacă rezultatul următoarei sarcini nu a fost schimbat, nu mai plasez universala respectivă în rolul în care s-a descurcat prost. Mă străduiesc să evaluez capacitatea și dorința sa de a dezvolta competențele în acel rol. Dacă nu găsesc un răspuns favorabil, o las în rolul care îi este mai apropiat.
Ce a rezultat în final?
Procesul de dezvoltare a devenit mai transparent. Factorul BUS s-a redus. Membrii echipei, lucrând la erori, devin mai motivați, își îmbunătățesc karma. Creștem treptat calitatea lansărilor noastre.
Conclusions
Angajații universali au avantaje și dezavantaje.
Avantaje:
- poate fi închisă oricând o sarcină neglijată sau poate fi rezolvată o problemă urgentă într-un timp scurt;
- abordare complexă în soluționarea sarcinii: executantul o analizează din perspectiva tuturor rolurilor;
- universalii pot face practic totul la fel de bine.
Dezavantaje:
- crește factorul BUS;
- competențele principale specifice rolului se estompează. Din această cauză, calitatea muncii scade;
- crește probabilitatea întârzierilor, deoarece nu există control asupra fiecărei etape. De asemenea, există riscuri de a crea o „vedetă”: angajatul este convins că știe mai bine, că este profesionist;
- crește riscul de burnout profesional;
- multe informații importante despre proiect pot rămâne doar "în mintea" angajatului.
După cum vedeți, dezavantajele sunt mai multe. Prin urmare, folosesc universalii doar dacă nu dispun de suficiente resurse și sarcina este destul de urgentă. Sau persoana are competențe care lipsesc altora, iar calitatea este pe masă.
Dacă în colaborarea asupra sarcinii respectăm regula distribuirii rolurilor, calitatea muncii crește. Privim problemele din perspective diferite, viziunea nu este blurată, întotdeauna apar gânduri noi. Fiecare membru al echipei are toate oportunitățile pentru dezvoltarea profesională și extinderea competențelor sale.
Consider că cel mai important este să simți apartenența la proces, să te ocupi de munca ta, crescând treptat lărgimea competențelor tale. Cu toate acestea, universalii din echipă aduc beneficii: important este să-i faci să combine eficient diferite roluri.
Îmi doresc tuturor echipelor auto-organizate „universali-măistri ai meseriei lor”!
Sursa: habr.com
