Ahoj všichni! Jmenuji se Ludmila Makarova, jsem manažerka vývoje v UBRiR a třetina mého týmu jsou „univerzálové“.
Uznejte: každý Tech Lead sní o kros-funkčnosti ve svém týmu. Je to opravdu skvělé, když jeden člověk dokáže nahradit tři a ještě to udělat kvalitně, aniž by to zpozdilo termíny. A co je důležité, to zajišťuje úsporu zdrojů!
Zní to velmi lákavě, ale je to opravdu tak? Pojďme se na to podívat.
Kdo je náš předstihovač očekávání?
Pod pojmem „univerzál“ se obvykle chápou členové týmu, kteří kombinují více než jednu roli, například vývojář-analytik.
Interakce týmu a výsledek jeho práce závisí na profesních a osobnostních kvalitách účastníků.
O hard skills je jasno, ale soft skills si zaslouží zvláštní pozornost. Pomáhají najít přístup k zaměstnanci a nasměrovat ho k úkolu, ve kterém bude maximálně užitečný.
Existuje mnoho článků o různých typech osobností v IT průmyslu. Na základě svých zkušeností bych IT univerzály rozdělila do čtyř kategorií:
1. „Univerzál – všemocný“
Takoví jsou všude. Vždy vykazují velkou aktivitu, chtějí být ve středu pozornosti, neustále se ptají kolegů, jestli potřebují jejich pomoc, a občas mohou být i otravní. Zajímavé jsou pro ně jen významné úkoly, kterých se mohou účastnit a které budou plodné pro jejich kreativitu a potěší jejich ego.
V čem jsou silní:
- dokážou řešit složité úkoly;
- hluboce se noří do problému, „kopou“ a dosahují výsledku;
- mají zvídavou mysl.
Ale:
- jsou emocionálně labilní;
- špatně se dají řídit;
- mají svou neochvějnou optiku, kterou je velmi obtížné změnit;
- je těžké je donutit udělat jednoduchou věc. Lehká úkoly zasahují ego všemocných.
2. „Univerzál – poradím si a udělám to“
Těmto lidem stačí manuál a trochu času – a vyřeší problém. Obvykle mají za sebou velké záznamy jako DevOps. Takoví univerzálové se nenamáhají projektováním a dávají přednost vývoji na základě pouze své zkušenosti. Mohou se snadno dostat do sporu s techlead o zvolenou variantu realizace úkolu.
V čem jsou silní:
- jsou samostatní;
- odolní vůči stresu;
- kompetentní v mnoha oblastech;
- erudovaní – s nimi je vždy o čem diskutovat.
Ale:
- často porušují závazky;
- mají tendenci všechno komplikovat: při řešení násobilky volí integraci po částech;
- kvalita práce je nízká, vše se podaří až na 2-3 pokusy;
- neustále posouvají termíny, protože ve skutečnosti je všechno složitější, než by se mohlo zdát.
3. "Universal – dobře, tak já, když není nikdo jiný"
Zaměstnanec se rozumí v několika oblastech a má odpovídající zkušenosti. Ale nedokáže se stát odborníkem v žádné z nich, protože je často využíván jako záchranný kruh, když je potřeba řešit aktuální úkoly. Je přizpůsobivý, disciplinovaný, považuje se za žádaného, avšak takovým není.
Praxe ukazuje ideálního zaměstnance. Pravděpodobně má oblast, která ho baví více, ale kvůli rozmělnění kompetencí nedochází k žádnému rozvoji. V důsledku toho riskuje, že se stane nepřínosným a emocionálně vyčerpaným.
V čem jsou silní:
- odpovědní;
- zaměřeni na výsledky;
- klidní;
- úplně kontrolovaní.
Ale:
- ukazují průměrné výsledky kvůli nízké úrovni kompetencí;
- nedokáží řešit složité a abstraktní úkoly.
4. "Universal – mistr svého oboru"
Člověk se silným pozadím vývojáře, má systémové myšlení. Je pedantický, náročný na sebe i tým. Jakýkoli úkol, který se ho týká, se může neomezeně rozšířit, pokud se nevytyčí hranice.
Dobře zná architekturu, vybírá metodu technické realizace, pečlivě analyzuje vliv zvoleného řešení na aktuální architekturu. Skromný, neambiciózní.
V čem jsou silní:
- ukazují vysokou kvalitu práce;
- schopní vyřešit jakýkoli úkol;
- velmi pracovité.
Ale:
- netolerantní k názorům ostatních;
- maximalisté. Snaží se udělat vše správně, což prodlužuje dobu vývoje.
Co máme v praxi?
Podíváme se, jak se nejčastěji spojují role a kompetence. Za výchozí bod vezmeme standardní vývojový tým: PO, manažer vývoje (techlead), analytici, programátoři, testeři. Vlastníka produktu a techleada nebudeme počítat. Prvního – kvůli absenci technických kompetencí. Druhý, když má tým problémy, by měl být schopen dělat všechno.
Nejrozšířenější variantou kombinace dovedností je vývojář-analytik. Také se velmi často vyskytují analytik-testovač a "tři v jednom".
Na příkladu svého týmu ukážu, v čem jsou výhody a nevýhody univerzálních kolegů. V mém týmu jsou tvořeni z jedné třetiny a velmi je mám rád.
Od PO byla zadána urgentní úloha zavést nové tarify do stávajícího produktu. V mém týmu jsou 4 analytici. V tu dobu byl jeden na dovolené, druhý byl nemocný a zbytek se věnoval realizaci strategických úkolů. Kdybych je přetahoval, nevyhnutelně by to zpozdilo realizaci. Zůstala poslední možnost: využít "tajnou zbraň" – univerzálního vývojáře-analytika, který měl potřebné znalosti o dané oblasti. Řekněme, že byl Anatolij.
Jeho typ osobnosti je "univerzál – vše zvládnu a udělám". Samozřejmě se snažil dlouho vysvětlit, že má "plný backlog svých úkolů", ale mým rozhodnutím byl poslán na řešení urgentní úlohy. A Anatolij to zvládl! Zrealizoval úkol včas a zákazníci byli spokojeni.
Na první pohled se vše podařilo. Ale po několika týdnech se objevily nové požadavky na úpravy tohoto produktu. Teď úlohu řešil "čistý" analytik. V testovací fázi nové aplikace jsme dlouho nemohli pochopit, proč nám vznikají chyby při přiřazování nových tarifů, a až poté, když jsme rozmotali celé klubko, jsme se dostali k pravdě. Strávili jsme spoustu času a zpozdili jsme termíny.
Problém byl v tom, že mnoho skrytých detailů a úskalí zůstalo pouze v hlavě našeho univerzála a nebylo přeneseno na papír. Jak později vysvětlil Anatolij, příliš spěchal. Ale pravděpodobnější je, že narazil na problémy už při vývoji a jednoduše je obešel, nikde to neodrazil.
Byla také jiná situace. Aktuálně máme jen jednoho testera, takže některé úkoly musí testovat analytici, včetně univerzálů. Proto jsem jeden úkol svěřil hypotetickému Fedorovi – "univerzál – dobře, udělám to, protože není nikdo jiný".
Fedor je "tři v jednom", ale pro tuto úlohu už byl určen vývojář. To znamená, že se Fedor musel spojit pouze s analytikem a testovačem.
Požadavky byly shromážděny, specifikace byla předána do vývoje, je čas na testování. Fjodor zná zdokonalovaný systém "jako své vlastní pět prstů" a důkladně se zabýval aktuálními požadavky. Proto se nezatěžoval psaním testovacích scénářů, ale provedl testování na to, "jak by měl systém fungovat", a poté – předal to uživatelům.
Test byl ukončen, úprava byla poslána do produkce. Později se ukázalo, že systém nejenže pozastavuje provádění plateb na určité vyvážené účty, ale také blokuje provádění plateb z velmi vzácných interních účtů, které se neměly podílet na tomto.
K tomu došlo, protože Fjodor neprovedl kontrolu toho, jak "systém neměl fungovat", nepřipravil testovací plán, kontrolní seznamy. Rozhodl se ušetřit na časových termínech a spoléhal na svůj vlastní instinkt.
Jak pracujeme s problémy?
Podobné situace ovlivňují efektivitu práce týmu, kvalitu vydávaných verzí a spokojenost zákazníků. Proto je nelze ponechat bez pozornosti a analýzy příčin.
1. K každému úkolu, který způsobil potíže, prosím o vyplnění jednotné formy: karty chyb, která umožňuje identifikovat fázi, na které došlo k "útlumu":
2. Po identifikaci úzkých míst se s každým zaměstnancem, který měl vliv na problém, koná brainstorm "Co změnit?" (specifické případy neprobíráme na retrospektivě), na základě kterého vznikají konkrétní akce (pro každý typ osobnosti své) s termíny.
3. Zavedli jsme pravidla interakce uvnitř týmu. Například jsme se dohodli, že je nutné zaznamenávat všechny informace o průběhu úkolu v systému řízení projektů. Při změnách/odhalení artefaktů během vývoje je třeba to odrážet v databázi znalostí a konečné verzi technických specifikací.
4. Kontrola se začala provádět v každé fázi (zvláštní pozornost je věnována problematickým fázím v minulosti) a automaticky na základě výsledků provedení následujícího úkolu.
5. Pokud se výsledek následujícího úkolu nezměnil, nedávám posuzované univerzální osobě tu roli, se kterou si špatně poradila. Snažím se ocenit její schopnost a ochotu rozvíjet dovednosti v této roli. Pokud nenacházím odezvu, nechávám ji v roli, která jí je bližší.
Jaký byl výsledek?
Vývojový proces se stal průhlednějším. BUS faktor se snížil. Členové týmu, kteří pracují na chybách, se stávají více motivovanými a zlepšují svou karmu. Postupně zvyšujeme kvalitu našich vydání.
Závěry
Univerzální zaměstnanci mají své výhody a nevýhody.
Výhody:
- můžete kdykoliv uzavřít uvízlé úkoly nebo vyřešit urgentní chybu v krátkých lhůtách;
- komplexní přístup k řešení úkolu: vykonavatel se na něj dívá ze všech rolí;
- univerzální pracovníci mohou prakticky dělat všechno stejně dobře.
Nevýhody:
- roste BUS faktor;
- rozmazávají se hlavní kompetence dané role. Z toho vyplývá snížení kvality práce;
- zvyšuje se pravděpodobnost posunutí termínů, protože chybí kontrola v každé fázi. Také se objevují rizika vzniku "hvězdy": zaměstnanec je přesvědčen, že ví lépe, že je profesionál;
- zvyšuje se riziko profesionálního vyhoření;
- mnoho důležitých informací o projektu může zůstat pouze v "hlavě" zaměstnance.
Jak vidíte, nevýhod je více. Proto univerzální pracovníky využívám pouze v případě nedostatku zdrojů, pokud je úkol dostatečně urgentní. Nebo pokud má člověk kompetence, které ostatním chybí, a jde o kvalitu.
Pokud je při spolupráci na úkolu dodržováno pravidlo rozdělení rolí, pak kvalita práce roste. Na problémy se díváme z různých stran, pohled se nezatuhuje a vždy se objevují nové myšlenky. Každý člen týmu má přitom všechny možnosti pro profesní růst a rozšíření svých kompetencí.
Myslím si, že to nejdůležitější je cítit se součástí procesu, věnovat se své práci a postupně zvyšovat šířku svých kompetencí. Přesto univerzální pracovníci v týmu přinášejí užitek: hlavní je zajistit, aby efektivně kombinovali různé role.
Přeji všem samoorganizujícím se týmům "univerzálů-mistrů svého řemesla"!
Zdroj: habr.com
