Ahojte všetci! Volám sa Ludmila Makarova, som manažérka rozvoja v UBRD a tretina môjho tímu sú „všeobecní“.
Priznajte sa: každý technický vedúci sníva o vzájomnej funkčnosti v rámci svojho tímu. Je úžasné, keď jedna osoba dokáže nahradiť troch, a dokonca to urobiť efektívne, bez oneskorenia termínov. A čo je dôležité, šetrí zdroje!
Znie to veľmi lákavo, ale je to naozaj tak? Skúsme na to prísť.
Kto je on, náš predchodca očakávaní?
Pojem „všeobecný“ sa zvyčajne vzťahuje na členov tímu, ktorí kombinujú viac ako jednu rolu, napríklad vývojár-analytik.
Interakcia tímu a výsledok jeho práce závisí od profesionálnych a osobných kvalít účastníkov.
O tvrdých zručnostiach je všetko jasné, ale mäkké zručnosti si zaslúžia osobitnú pozornosť. Pomáhajú nájsť prístup k zamestnancovi a nasmerujú ho k úlohe, kde bude najužitočnejší.
Existuje veľa článkov o všetkých typoch osobností v IT priemysle. Na základe mojich skúseností by som IT generalistov rozdelil do štyroch kategórií:
1. „Univerzálny – Všemohúci“
Tie sú všade. Sú vždy veľmi aktívni, chcú byť stredobodom pozornosti, neustále sa pýtajú kolegov, či nepotrebujú ich pomoc, a niekedy vedia byť aj otravní. Zaujímajú ich len zmysluplné úlohy, ktorých účasťou dá priestor kreativite a dokáže pobaviť ich hrdosť.
V čom sú silné:
- sú schopní riešiť zložité problémy;
- ponoriť sa hlboko do problému, „kopať“ a dosahovať výsledky;
- mať zvedavú myseľ.
ale:
- emocionálne labilné;
- zle riadené;
- majú svoj vlastný neotrasiteľný pohľad, ktorý je veľmi ťažké zmeniť;
- Je ťažké prinútiť niekoho urobiť jednoduchú vec. Ľahké úlohy zraňujú ego všemohúceho.
2. „Univerzálny – prídem na to a urobím to“
Takýmto ľuďom stačí manuál a trochu času – a problém vyriešia. Zvyčajne majú silné zázemie v DevOps. Takíto generalisti si s dizajnom hlavu nelámu a radšej používajú metódu vývoja založenú výlučne na svojich skúsenostiach. Môžu ľahko diskutovať s technickým vedúcim o vybranej možnosti realizácie úlohy.
V čom sú silné:
- nezávislý;
- odolný voči stresu;
- kompetentný v mnohých otázkach;
- erudovaný - vždy je s nimi o čom hovoriť.
ale:
- často porušujú povinnosti;
- majú tendenciu všetko komplikovať: vyriešte násobilku integrovaním po častiach;
- kvalita práce je nízka, všetko funguje 2-3 krát;
- Neustále posúvajú termíny, pretože v skutočnosti nie je všetko také jednoduché.
3. „Univerzálne – dobre, nechaj ma to urobiť, keďže tu nie je nikto iný“
Zamestnanec sa dobre orientuje vo viacerých oblastiach a má relevantné skúsenosti. V žiadnej z nich sa mu však nedarí stať sa profesionálom, pretože sa často používa ako záchranné lano, ktoré upcháva diery v súčasných úlohách. Poddajný, efektívny, považuje sa za žiadaný, ale nie je.
Praktický ideálny zamestnanec. S najväčšou pravdepodobnosťou má smer, ktorý sa mu najviac páči, ale kvôli zahmlievaniu kompetencií k rozvoju nedochádza. Výsledkom je, že človek riskuje, že sa stane nevyžiadaným a emocionálne vyhorí.
V čom sú silné:
- zodpovedný;
- orientovaný na výsledok;
- pokojný;
- úplne kontrolované.
ale:
- vykazujú priemerné výsledky v dôsledku nízkej úrovne kompetencií;
- nedokáže riešiť zložité a abstraktné problémy.
4. „Všestranný je majstrom svojho remesla“
Človek so serióznym pozadím ako vývojár má systémové myslenie. Pedantický, náročný na seba a svoj tím. Akákoľvek úloha, ktorá sa ho týka, môže rásť donekonečna, ak nie sú definované hranice.
Dobre sa vyzná v architektúre, vyberá spôsob technickej realizácie, starostlivo analyzuje vplyv zvoleného riešenia na súčasnú architektúru. Skromný, nie ambiciózny.
V čom sú silné:
- preukázať vysokú kvalitu práce;
- schopný vyriešiť akýkoľvek problém;
- veľmi efektívne.
ale:
- netolerantný voči názorom iných;
- maximalisti. Snažia sa robiť všetko správne, čo zvyšuje čas vývoja.
Čo máme v praxi?
Pozrime sa, ako sa najčastejšie kombinujú roly a kompetencie. Zoberme si štandardný vývojový tím ako východiskový bod: PO, manažér vývoja (tech lead), analytici, programátori, testeri. Nebudeme brať do úvahy produktového vlastníka a technického vedúceho. Prvý je spôsobený nedostatkom technických kompetencií. Ten druhý, ak sú v tíme problémy, by mal zvládnuť všetko.
Najbežnejšou možnosťou kombinovania/zlučovania/kombinovania kompetencií je vývojár-analytik. Testovací analytik a „tri v jednom“ sú tiež veľmi bežné.
Na príklade môjho tímu vám ukážem klady a zápory mojich kolegov zo všeobecného lekárstva. V mojom tíme je ich tretina a mám ich veľmi rád.
PO dostala naliehavú úlohu zaviesť nové tarify do existujúceho produktu. Môj tím má 4 analytikov. Jeden bol v tom čase na dovolenke, druhý bol chorý a zvyšok sa venoval realizácii strategických úloh. Ak by som ich vytiahol, nevyhnutne by to narušilo termíny realizácie. Existovalo len jedno východisko: použiť „tajnú zbraň“ - všestranného vývojára-analytika, ktorý ovláda požadovanú oblasť. Volajme ho Anatolij.
Jeho typ osobnosti je „univerzálne – prídem na to a urobím to“. Samozrejme, dlho sa snažil vysvetliť, že „má plný počet nevybavených úloh“, ale mojím rozhodným rozhodnutím bol poslaný vyriešiť naliehavý problém. A Anatolij to dokázal! Inscenáciu a realizáciu zrealizoval načas a zákazníci boli spokojní.
Na prvý pohľad všetko klapalo. Ale po niekoľkých týždňoch sa opäť objavili požiadavky na zlepšenie tohto produktu. Teraz formuláciu tohto problému vykonal „čistý“ analytik. Vo fáze testovania nového vývoja sme dlho nevedeli pochopiť, prečo máme chyby pri prepájaní nových taríf, a až potom, keď sme celú spleť rozmotali, sme sa dostali na dno pravdy. Stratili sme veľa času a premeškali termíny.
Problémom bolo, že mnohé skryté momenty a nástrahy zostali len v hlave nášho kombi a nepreniesli sa na papier. Ako Anatolij neskôr vysvetlil, príliš sa ponáhľal. Najpravdepodobnejšou možnosťou však je, že na problémy narazil už počas vývoja a jednoducho ich obišiel bez toho, aby sa to niekde prejavilo.
Nastala iná situácia. Teraz máme iba jedného testera, takže niektoré úlohy musia testovať analytici vrátane všeobecných odborníkov. Preto som dal jednu úlohu podmienenému Fedorovi - "univerzálne - dobre, dovoľte mi to urobiť, pretože tu nie je nikto iný".
Fedor je „tri v jednom“, ale na túto úlohu už bol pridelený vývojár. To znamená, že Fedya musel spojiť iba analytika a testera.
Požiadavky boli zhromaždené, špecifikácia bola odovzdaná vývoju, je čas na testovanie. Fedor pozná upravovaný systém „ako vlastnú dlaň“ a aktuálne požiadavky má dôkladne prepracované. Preto sa neobťažoval písaním testovacích skriptov, ale testoval, „ako by mal systém fungovať“, a potom to odovzdal používateľom.
Test bol ukončený, revízia išla do výroby. Neskôr sa ukázalo, že systém nielen pozastavil platby na niektoré saldokonty, ale zablokoval aj platby z veľmi zriedkavých interných účtov, ktoré sa na tom nemali podieľať.
Stalo sa to preto, že Fedor neskontroloval, ako „systém nemá fungovať“, nevypracoval plán testov ani kontrolné zoznamy. Rozhodol sa ušetriť na načasovaní a spoliehať sa na vlastný inštinkt.
Ako sa vyrovnávame s problémami?
Situácie ako tieto ovplyvňujú výkon tímu, kvalitu vydania a spokojnosť zákazníkov. Preto ich nemožno nechať bez pozornosti a analýzy dôvodov.
1. Pre každú úlohu, ktorá spôsobila ťažkosti, vás žiadam o vyplnenie jednotného formulára: mapu chýb, ktorá vám umožní identifikovať fázu, v ktorej došlo k „čerpaniu“:
2. Po identifikácii úzkych miest sa uskutoční brainstorming s každým zamestnancom, ktorý ovplyvnil problém: „Čo zmeniť? (špeciálne prípady spätne neuvažujeme), v dôsledku ktorých sa rodia špecifické akcie (špecifické pre každý typ osobnosti) s termínmi.
3. Zaviedli sme pravidlá interakcie v rámci tímu. Napríklad sme sa dohodli, že všetky informácie o priebehu úlohy budeme nevyhnutne zaznamenávať do systému riadenia projektu. Keď sa artefakty zmenia/identifikujú počas procesu vývoja, musí sa to prejaviť v znalostnej báze a konečnej verzii technických špecifikácií.
4. Kontrola sa začala vykonávať v každej etape (osobitná pozornosť sa venuje problematickým etapám v minulosti) a automaticky na základe výsledkov ďalšej úlohy.
5. Ak sa výsledok v ďalšej úlohe nezmenil, potom dotyčného generalistu nestaviam do role, v ktorej sa zle vyrovná. Snažím sa posúdiť jeho schopnosti a túžbu rozvíjať kompetencie v tejto úlohe. Ak nenájdem odpoveď, nechám ho v úlohe, ktorá je mu bližšia.
Čo sa stalo na konci?
Proces vývoja sa stal transparentnejším. Znížil sa BUS faktor. Členovia tímu pracujúci na chybách sa stávajú viac motivovaní a zlepšujú si karmu. Postupne zlepšujeme kvalitu našich vydaní.
Závery
Všeobecní zamestnanci majú svoje pre a proti.
výhody:
- klesajúcu úlohu môžete kedykoľvek uzavrieť alebo v krátkom čase vyriešiť naliehavú chybu;
- integrovaný prístup k riešeniu problému: interpret sa naň pozerá z perspektívy všetkých rolí;
- generalisti zvládnu takmer všetko rovnako dobre.
Nevýhody:
- BUS faktor sa zvyšuje;
- základné kompetencie spojené s úlohou sú narušené. Z tohto dôvodu sa kvalita práce znižuje;
- zvyšuje sa pravdepodobnosť posunu termínov, pretože v každej fáze neexistuje žiadna kontrola. Existujú aj riziká rastu „hviezdy“: zamestnanec je presvedčený, že lepšie vie, že je profesionál;
- zvyšuje sa riziko profesionálneho vyhorenia;
- veľa dôležitých informácií o projekte môže zostať len „v hlave“ zamestnanca.
Ako vidíte, nedostatkov je viac. Preto používam generalistov len vtedy, ak nie je dostatok zdrojov a úloha je dosť naliehavá. Alebo má človek kompetencie, ktoré iným chýbajú, no v hre je kvalita.
Ak sa pri spoločnej práci na úlohe dodržiava pravidlo rozdelenia rolí, zvyšuje sa kvalita práce. Pozeráme sa na problémy z rôznych uhlov pohľadu, náš pohľad nie je rozmazaný, vždy sa objavia čerstvé myšlienky. Zároveň má každý člen tímu možnosť profesionálneho rastu a rozširovania svojich kompetencií.
Verím, že najdôležitejšie je cítiť sa zaangažovaný do procesu, robiť svoju prácu, postupne zvyšovať šírku svojich kompetencií. Generalisti v tíme však prinášajú výhody: hlavnou vecou je zabezpečiť, aby efektívne kombinovali rôzne úlohy.
Prajem každému samoorganizujúci sa tím „univerzálnych majstrov svojho remesla“!
Zdroj: hab.com