Ahoj všichni! Jmenuji se Ludmila Makarova, jsem manažerkou rozvoje v UBRD a třetina mého týmu jsou „generalisté“.
Přiznejte si to: každý technický vedoucí sní o křížové funkčnosti ve svém týmu. Je skvělé, když jeden člověk může nahradit tři, a dokonce to udělat efektivně, bez zdržování termínů. A co je důležité, šetří zdroje!
Zní to velmi lákavě, ale je tomu skutečně tak? Zkusme na to přijít.
Kdo to je, náš předchůdce očekávání?
Termín „obecný“ obvykle označuje členy 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 odborných a osobních kvalitách účastníků.
O tvrdých dovednostech je vše jasné, ale zvláštní pozornost si zaslouží měkké dovednosti. Pomáhají najít přístup k zaměstnanci a nasměrují ho k úkolu, kde bude nejužitečnější.
Existuje mnoho článků o všech typech osobností v IT průmyslu. Na základě svých zkušeností bych IT generalisty rozdělil do čtyř kategorií:
1. „Univerzální – Všemohoucí“
Ty jsou všude. Jsou vždy velmi aktivní, chtějí být středem pozornosti, neustále se ptají kolegů, zda nepotřebují jejich pomoc, a někdy dokážou být i otravní. Zajímají je pouze smysluplné úkoly, jejichž účast dá prostor kreativitě a může pobavit jejich hrdost.
V čem jsou silní:
- jsou schopni řešit složité problémy;
- ponořit se hluboko do problému, „kopat“ a dosahovat výsledků;
- mít zvídavou mysl.
Ale:
- emočně labilní;
- špatně spravované;
- mít svůj vlastní neotřesitelný úhel pohledu, který je velmi těžké změnit;
- Je těžké někoho přimět udělat jednoduchou věc. Snadné úkoly zraňují ego všemohoucího.
2. „Univerzální – přijdu na to a udělám to“
Takovým lidem stačí manuál a trochu času – a problém vyřeší. Obvykle mají silné zázemí v DevOps. Takoví generalisté si s designem hlavu nelámou a raději používají vývojovou metodu založenou výhradně na svých zkušenostech. Mohou snadno diskutovat s technickým vedoucím o zvolené možnosti realizace úkolu.
V čem jsou silní:
- nezávislý;
- odolný vůči stresu;
- kompetentní v mnoha otázkách;
- erudovaní - vždy je s nimi o čem mluvit.
Ale:
- často porušují povinnosti;
- mají tendenci vše komplikovat: řešit násobilku integrováním po částech;
- kvalita práce je nízká, vše funguje 2-3krát;
- Neustále posouvají termíny, protože ve skutečnosti není všechno tak jednoduché.
3. „Univerzální – dobře, nech mě to udělat, protože tu není nikdo jiný“
Zaměstnanec se dobře orientuje v několika oblastech a má relevantní zkušenosti. Ani v jednom z nich se mu ale nedaří stát se profesionálem, protože je často používán jako záchranné lano, které ucpává díry v současných úkolech. Poddajný, výkonný, považuje se za žádaný, ale není.
Praktický ideální zaměstnanec. S největší pravděpodobností má směr, který má nejraději, ale kvůli rozostření kompetencí k rozvoji nedochází. Výsledkem je, že člověk riskuje, že se stane nevyžádaným a emocionálně vyhořel.
V čem jsou silní:
- jsou zodpovědní;
- orientovaný na výsledky;
- uklidnit;
- zcela ovládán.
Ale:
- vykazují průměrné výsledky z důvodu nízké úrovně kompetencí;
- neumí řešit složité a abstraktní problémy.
4. „Všestranný je mistr svého řemesla“
Člověk se seriózním pozadím jako vývojář má systémové myšlení. Pedantický, náročný na sebe i svůj tým. Jakýkoli úkol, který se ho týká, může růst donekonečna, pokud nejsou definovány hranice.
Dobře se orientuje v architektuře, volí způsob technické realizace, pečlivě analyzuje dopad zvoleného řešení na současnou architekturu. Skromný, ne ambiciózní.
V čem jsou silní:
- ukázat vysokou kvalitu práce;
- schopen vyřešit jakýkoli problém;
- velmi efektivní.
Ale:
- netolerantní k názorům druhých;
- maximalisté. Snaží se dělat všechno správně, a to zvyšuje dobu vývoje.
Co máme v praxi?
Podívejme se, jak se nejčastěji kombinují role a kompetence. Vezměme si jako výchozí bod standardní vývojový tým: PO, vývojový manažer (tech lead), analytici, programátoři, testeři. Nebudeme brát v úvahu vlastníka produktu a technického vedoucího. První je způsoben nedostatkem technických kompetencí. Ten druhý, pokud jsou v týmu problémy, by měl umět všechno.
Nejběžnější možností kombinace/sloučení/kombinace kompetencí je vývojář-analytik. Velmi běžné jsou také testovací analytik a „tři v jednom“.
Na příkladu svého týmu vám ukážu klady a zápory mých kolegů generalistů. V mém týmu jich je třetina a mám je moc rád.
PO dostala naléhavý úkol zavést nové tarify do stávajícího produktu. Můj tým má 4 analytiky. V té době byl jeden na dovolené, druhý nemocný a zbytek se věnoval plnění strategických úkolů. Kdybych je vytáhl, nevyhnutelně by to narušilo termíny realizace. Existovala pouze jedna cesta ven: použít „tajnou zbraň“ - všestranného vývojáře-analytika, který zvládl požadovanou oblast. Říkejme mu Anatoly.
Jeho typ osobnosti je „univerzální – zjistím to a udělám to“. Samozřejmě se mi dlouho snažil vysvětlit, že má „plné nevyřízené úkoly“, ale mým rozhodným rozhodnutím byl poslán vyřešit naléhavý problém. A Anatoly to dokázal! Inscenaci provedl a realizaci dokončil v termínu a zákazníci byli spokojeni.
Na první pohled vše klapalo. Po pár týdnech se ale u tohoto produktu opět objevily požadavky na vylepšení. Formulaci tohoto problému nyní provedl „čistý“ analytik. Ve fázi testování nového vývoje jsme dlouho nemohli pochopit, proč máme chyby při propojování nových tarifů, a teprve poté, když jsme celou tu spleti rozmotali, jsme se dostali na dno pravdy. Promarnili jsme spoustu času a promeškali termíny.
Problém byl v tom, že mnoho skrytých momentů a úskalí zůstalo jen v hlavě našeho kombi a nepřeneslo se na papír. Jak Anatoly později vysvětlil, příliš spěchal. Nejpravděpodobnější variantou ale je, že na problémy narazil už při vývoji a jednoduše je obešel, aniž by se to někde projevilo.
Nastala jiná situace. Nyní máme pouze jednoho testera, takže některé úlohy musí testovat analytici, včetně generalistů. Proto jsem dal jeden úkol podmíněnému Fedorovi - "univerzální - dobře, nech mě to udělat, protože tu není nikdo jiný".
Fedor je „tři v jednom“, ale pro tento úkol již byl přidělen vývojář. To znamená, že Fedya musel spojit pouze analytika a testera.
Požadavky byly shromážděny, specifikace byla předložena vývoji, je čas na testování. Fedor zná upravovaný systém „jako své boty“ a důkladně propracoval aktuální požadavky. Proto se neobtěžoval psaním testovacích skriptů, ale testoval, „jak by měl systém fungovat“, a poté to předal uživatelům.
Test byl dokončen, revize šla do výroby. Později se ukázalo, že systém nejen pozastavil platby na určité bilanční účty, ale také zablokoval platby z velmi vzácných interních účtů, které se toho neměly účastnit.
Stalo se tak kvůli tomu, že Fedor nezkontroloval, jak „systém nemá fungovat“, nevypracoval plán testů ani kontrolní seznamy. Rozhodl se ušetřit na načasování a spolehnout se na vlastní instinkt.
Jak se vypořádáme s problémy?
Situace jako tyto ovlivňují výkon týmu, kvalitu vydání a spokojenost zákazníků. Nelze je proto ponechat bez pozornosti a analýzy důvodů.
1. Pro každý úkol, který způsobil potíže, vás žádám o vyplnění jednotného formuláře: mapy chyb, která vám umožní identifikovat fázi, ve které došlo k „čerpání“:
2. Po identifikaci úzkých míst se uskuteční brainstorming s každým zaměstnancem, který problém ovlivnil: „Co změnit? (zvláštní případy zpětně neuvažujeme), v jejichž důsledku se rodí konkrétní akce (specifické pro každý typ osobnosti) s termíny.
3. Zavedli jsme pravidla pro interakci v týmu. Například jsme se dohodli, že budeme nutně zaznamenávat všechny informace o průběhu úkolu v systému řízení projektu. Když jsou artefakty změněny/identifikovány během procesu vývoje, musí se to projevit ve znalostní bázi 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ů dalšího úkolu.
5. Pokud se výsledek na dalším úkolu nezměnil, pak dotyčného generalistu nestavím do role, ve které špatně zvládá. Snažím se zhodnotit jeho schopnosti a chuť rozvíjet kompetence v této roli. Pokud nenajdu odpověď, nechám ho v roli, která je mu bližší.
Co se stalo na konci?
Proces vývoje se stal transparentnějším. Faktor BUS se snížil. Členové týmu, kteří pracují na chybách, se stávají motivovanější a zlepšují svou karmu. Postupně zlepšujeme kvalitu našich vydání.
Závěry
Zaměstnanci Generalist mají svá pro a proti.
Doplňky:
- klesající úkol můžete kdykoli zavřít nebo v krátké době vyřešit naléhavou chybu;
- integrovaný přístup k řešení problému: performer se na něj dívá z perspektivy všech rolí;
- generalisté umí téměř vše stejně dobře.
Nevýhody:
- BUS faktor se zvyšuje;
- základní kompetence spojené s rolí jsou narušovány. Z tohoto důvodu klesá kvalita práce;
- zvyšuje se pravděpodobnost posunu termínů, protože v každé fázi neexistuje žádná kontrola. Existují také rizika růstu „hvězdy“: zaměstnanec je přesvědčen, že lépe ví, že je profík;
- zvyšuje se riziko profesního vyhoření;
- mnoho důležitých informací o projektu může zůstat pouze „v hlavě“ zaměstnance.
Jak vidíte, nedostatků je více. Generalisty proto používám pouze v případě, že není dostatek zdrojů a úkol je dosti naléhavý. Nebo má člověk kompetence, které ostatním chybí, ale hraje se o kvalitu.
Pokud se při společné práci na úkolu dodržuje pravidlo rozdělení rolí, pak se kvalita práce zvyšuje. Díváme se na problémy z různých úhlů pohledu, náš pohled není rozmazaný, vždy se objevují nové myšlenky. Každý člen týmu má přitom všechny možnosti profesního růstu a rozšiřování svých kompetencí.
Věřím, že nejdůležitější je cítit se zapojený do procesu, dělat svou práci a postupně zvyšovat šíři svých kompetencí. Generalisté v týmu však přinášejí výhody: hlavní věcí je zajistit, aby efektivně kombinovali různé role.
Přeji všem samoorganizující se tým „univerzálních mistrů svého řemesla“!
Zdroj: www.habr.com