Cześć wszystkim! Nazywam się Ludmiła Makarowa, jestem menedżerem ds. rozwoju w UBRiR, a jedna trzecia mojej drużyny to „uniwersaliści”.
Przyznajcie: każdy Tech Lead marzy o cross-funkcjonalności w swoim zespole. To naprawdę niesamowite, gdy jedna osoba jest w stanie zastąpić trzy, robiąc to dobrze, nie opóźniając terminarzy. I co ważne, to zapewnia oszczędność zasobów!
Brzmi bardzo kusząco, ale czy to rzeczywiście prawda? Spróbujmy to zrozumieć.
Kim jest nasz wyprzedzacz oczekiwań?
Pod pojęciem „uniwersalista” zazwyczaj rozumie się członków zespołu, którzy łączą w sobie więcej niż jedną rolę, na przykład programista-analityk.
Interakcje w zespole i wyniki jego pracy zależą od cech zawodowych i osobowościowych uczestników.
Z skillsami technicznymi wszystko jest jasne, ale umiejętności miękkie zasługują na szczególną uwagę. Pomagają znaleźć podejście do pracownika i skierować go na zadanie, w którym będzie najbardziej użyteczny.
Istnieje wiele artykułów o różnych typach osobowości przedstawicieli branży IT. Opierając się na swoim doświadczeniu, podzieliłabym IT-uniwersalistów na cztery kategorie:
1. „Uniwersalista – wszechmocny”
Tacy są wszędzie. Zawsze wykazują dużą aktywność, chcą być w centrum uwagi, ciągle pytają kolegów, czy potrzebna jest ich pomoc, czasami mogą nawet irytować. Interesują ich tylko istotne zadania, w których uczestnictwo pozwala na twórczość i zaspokaja ich ambicje.
W czym są mocni:
- są zdolni do rozwiązywania skomplikowanych problemów;
- głęboko angażują się w problem, „kopią” i osiągają rezultaty;
- posiadają bystry umysł.
Ale:
- są emocjonalnie chwiejni;
- słabo poddają się zarządzaniu;
- mają swoją niezmienną opinię, którą jest bardzo trudno zmienić;
- trudno zmusić ich do wykonania prostego zadania. Łatwe zadania podważają ambicje wszechmocnych.
2. „Uniwersalista – poradzę sobie i zrobię”
Tym ludziom wystarczy podręcznik i trochę czasu – a rozwiążą problem. Zazwyczaj mają za sobą duże doświadczenie jako DevOps. Tacy uniwersaliści nie przejmują się projektowaniem i wolą korzystać z metody rozwoju na podstawie swojego doświadczenia. Mogą bez trwogi zakwestionować wybór techniczny szefa w sprawie realizacji zadania.
W czym są mocni:
- są samodzielni;
- są odporni na stres;
- są kompetentni w wielu kwestiach;
- Erudowani – zawsze jest z nimi o czym rozmawiać.
Ale:
- Często łamią zobowiązania;
- Są skłonni wszystko komplikować: rozwiązują tabelę mnożenia przez całkowanie częściowe;
- Jakość pracy jest niska, wszystko udaje się dopiero za 2-3 razem;
- Nieustannie przesuwają terminy, ponieważ w rzeczywistości wszystko okazuje się nie takie proste.
3. „Uniwersalny – dobrze, niech zrobię to, skoro nikt inny nie może”
Pracownik ma dobre rozeznanie w kilku dziedzinach i odpowiednie doświadczenie. Jednak nie udaje mu się stać profesjonalistą w żadnej z nich, ponieważ często jest wykorzystywany jako koło ratunkowe, zakrywając luki w bieżących zadaniach. Jest elastyczny, wykonawczy, uważa się za poszukiwanego, lecz nim nie jest.
Praktycznie idealny pracownik. Prawdopodobnie ma kierunek, który mu bardziej odpowiada, ale z powodu rozmycia kompetencji nie zachodzi rozwój. W efekcie osoba ryzykuje, że stanie się niepotrzebna i emocjonalnie wypalona.
W czym są mocni:
- odpowiedzialni;
- skoncentrowani na rezultacie;
- spokojni;
- całkowicie kontrolowani.
Ale:
- osiągają średnie wyniki z powodu niskiego poziomu kompetencji;
- nie potrafią rozwiązywać skomplikowanych i abstrakcyjnych zadań.
4. „Uniwersalny – mistrz swojego rzemiosła”
Osoba z poważnym doświadczeniem dewelopera, posiadająca myślenie systemowe. Jest pedantyczna, wymaga od siebie i zespołu. Każde zadanie, w które jest zaangażowana, może rozwinąć się w nieskończoność, jeśli nie wyznaczyć granic.
Dobrze zna architekturę, wybiera metodę realizacji technicznej, dokładnie analizując wpływ wybranego rozwiązania na obecną architekturę. Jest skromna, nieambitna.
W czym są mocni:
- osiągają wysoką jakość pracy;
- są w stanie rozwiązać każde zadanie;
- są bardzo pracowici.
Ale:
- nietolerancyjni wobec cudzych opinii;
- maksaliści. Starają się wszystko zrobić dobrze, co wydłuża czas realizacji.
Co mamy w praktyce?
Zobaczmy, jak najczęściej łączą się role i kompetencje. Weźmiemy za punkt wyjścia standardowy zespół deweloperski: PO, menedżer ds. rozwoju (techlead), analitycy, programiści, testerzy. Właściciela produktu i techleada nie będziemy liczyć. Pierwszy – z powodu braku kompetencji technicznych. Drugi, jeśli w zespole są problemy, powinien umieć robić wszystko.
Najbardziej powszechny sposób łączenia umiejętności to programista-analityk. Bardzo często spotkać można również analityka-testera oraz "trzy w jednym".
Na przykładzie mojego zespołu pokażę, jakie są plusy i minusy uniwersalnych kolegów. W moim zespole stanowią oni jedną trzecią, i bardzo ich lubię.
Od PO wpłynęło pilne zadanie dotyczące wprowadzenia nowych taryf do istniejącego produktu. W moim zespole jest czterech analityków. W tamtej chwili jeden był na urlopie, drugi chorował, a pozostali zajmowali się realizacją zadań strategicznych. Gdybym ich wyciągnęła, to niewątpliwie opóźniłoby realizację. Pozostało jedno wyjście: użyć "sekretnej broni" – uniwersalnego programisty-analityka, który znał potrzebną dziedzinę. Nazwijmy go Anatolij.
Jego typ osobowości to "uniwersalny – rozwiążę to i zrobię".. Oczywiście, długo próbował tłumaczyć, że ma "pełny backlog swoich zadań", ale moim zdecydowanym postanowieniem został wysłany do rozwiązania pilnego zadania. I Anatolij sobie poradził! Przeprowadził planowanie i zrealizował zadanie na czas, a zleceniodawcy byli zadowoleni.
Na pierwszy rzut oka wszystko się udało. Ale po kilku tygodniach pojawiły się nowe wymagania dotyczące tego produktu. Teraz planowaniem tego zadania zajmował się "czysty" analityk. Na etapie testowania nowego rozwiązania długo nie mogliśmy zrozumieć, dlaczego napotykamy błędy przy przypisywaniu nowych taryf, a dopiero później, rozwikłując zawiłość, dotarliśmy do prawdy. Straciliśmy mnóstwo czasu i przekroczyliśmy terminy.
Problem polegał na tym, że wiele ukrytych aspektów i pułapek pozostało tylko w głowie naszego uniwersala i nie zostało przeniesionych na papier. Jak później wyjaśnił Anatolij, zbyt się spieszył. Ale najbardziej prawdopodobne jest to, że natknął się na problemy już podczas rozwoju i po prostu ich uniknął, nigdzie tego nie odzwierciedlając.
Była też inna sytuacja. Mamy teraz tylko jednego testera, więc niektóre zadania muszą być testowane przez analityków, w tym – uniwersalnych. Dlatego jedno zadanie powierzyłam fikcyjnemu Fiodorowi – "uniwersalnemu – w porządku, zróbmy, skoro nie ma nikogo innego"..
Fiodor to "trzy w jednym", ale dla tego zadania już był przydzielony programista. Oznacza to, że Fiodor musiał połączyć w sobie jedynie rolę analityka i testera.
Wymagania zostały zebrane, specyfikacja przekazana do realizacji, nadszedł czas na testowanie. Fiodor zna rozwijaną system „jak własne pięć palców” i dogłębnie opracował bieżące wymagania. Dlatego nie obciążał się pisaniem scenariuszy testowych, a przeprowadził testy według tego, „jak system powinien działać”, a następnie przekazał to użytkownikom.
Test zakończony, poprawki trafiły na produkcję. Później okazało się, że system nie tylko wstrzymuje dokonywanie płatności na określone konta bilansowe, ale również blokuje płatności z bardzo rzadkich kont wewnętrznych, które nie powinny były w tym uczestniczyć.
Stało się to, ponieważ Fiodor nie przeprowadził weryfikacji tego, „jak system nie powinien działać”, nie opracował planu testowania ani list kontrolnych. Postanowił zaoszczędzić czas i zaufał swojemu instynktowi.
Jak radzimy sobie z problemami?
Podobne sytuacje wpływają na efektywność pracy zespołu, jakość wydawanych wersji i zadowolenie klientów. Dlatego nie można ich ignorować ani pomijać analizy przyczyn.
1. Dla każdego zadania, które sprawiało trudności, proszę o wypełnienie ujednoliconego formularza: karty błędów, która pozwala zidentyfikować etap, na którym wystąpił „spadek”:
2. Po zidentyfikowaniu wąskich gardeł, z każdym pracownikiem, który miał wpływ na problem, przeprowadzamy burzę mózgów „Co zmienić?” (nie analizujemy przypadków szczególnych na retro), po której rodzą się konkretne działania (dla każdego typu osobowości inne) z terminami.
3. Wprowadziliśmy zasady współpracy wewnątrz zespołu. Na przykład ustaliliśmy, że należy obowiązkowo zapisywać wszystkie informacje o postępie zadania w systemie zarządzania projektami. Przy zmianie/wykryciu artefaktów w procesie realizacji należy to odzwierciedlić w bazie wiedzy oraz w ostatecznej wersji specyfikacji.
4. Kontrola została wprowadzona na każdym etapie (szczególną uwagę zwraca się na problematyczne etapy w przeszłości) i jest automatycznie przeprowadzana na podstawie wyników realizacji następnego zadania.
5. Jeżeli wynik przy następnej realizacji się nie zmienia, to rozważanemu wszechstronnemu pracownikowi nie przydzielam roli, w której sobie nie radzi. Staram się ocenić jego zdolność i chęć do rozwijania kompetencji w tej roli. Jeżeli nie znajduję zrozumienia, pozostawiam go w tej roli, która jest mu bliższa.
Co w końcu udało się osiągnąć?
Proces rozwoju stał się bardziej przejrzysty. Zmniejszył się wskaźnik BUS. Członkowie zespołu, pracując nad błędami, stają się bardziej zmotywowani, poprawiają swoją karmę. Stopniowo podnosimy jakość naszych wydań.
Wnioski
Posiadanie wszechstronnych pracowników ma swoje plusy i minusy.
Zalety:
- można w każdej chwili zamknąć wiszącą sprawę lub rozwiązać pilny błąd w krótkim czasie;
- kompleksowe podejście do rozwiązywania problemu: wykonawca patrzy na niego z perspektywy wszystkich ról;
- wszechstronni pracownicy mogą praktycznie wszystko robić równie dobrze.
Wady:
- rośnie wskaźnik BUS;
- rozmywają się podstawowe kompetencje przypisane do roli. Z tego powodu jakość pracy maleje;
- zwiększa się prawdopodobieństwo opóźnienia terminów, ponieważ brakuje kontroli na każdym etapie. Pojawiają się również ryzyka związane z powstawaniem 'gwiazd': pracownik jest przekonany, że wie lepiej, że jest profesjonalistą;
- wzrasta ryzyko wypalenia zawodowego;
- dużo ważnych informacji o projekcie może pozostawać tylko „w głowie” pracownika.
Jak widać, jest więcej wad. Dlatego korzystam z wszechstronnych pracowników tylko w przypadku braku zasobów i gdy zadanie jest wystarczająco pilne. Lub gdy dana osoba ma kompetencje, których brakuje innym, a jakość ma kluczowe znaczenie.
Jeśli podczas wspólnej pracy nad zadaniem przestrzegane jest zasady podziału ról, to jakość pracy rośnie. Na problemy patrzymy z różnych perspektyw, spojrzenie się nie zamula, zawsze pojawiają się świeże pomysły. Przy tym każdy członek zespołu ma wszystkie możliwości do profesjonalnego rozwoju i rozszerzenia swoich kompetencji.
Uważam, że najważniejsze jest poczucie przynależności do procesu, wykonywanie swojej pracy, stopniowe zwiększanie szerokości swoich kompetencji. Niemniej jednak, wszechstronni pracownicy w zespole przynoszą korzyści: najważniejsze jest, aby efektywnie łączyli w sobie różne role.
Życzę wszystkim samoorganizującym się zespołom 'wszechstronnych mistrzów swojego rzemiosła'!
Źródło: habr.com
