„Uniwersalny” w zespole programistów: korzyść czy szkoda?

Cześć wszystkim! Nazywam się Ludmiła Makarowa, jestem menedżerem ds. rozwoju w UBRD i jedną trzecią mojego zespołu stanowią „generaliści”.

Przyznaj: każdy Tech Lead marzy o wielofunkcyjności w swoim zespole. Fajnie, gdy jedna osoba jest w stanie zastąpić trzy osoby i to nawet sprawnie, nie opóźniając terminów. I, co ważne, oszczędza zasoby!
Brzmi to bardzo kusząco, ale czy rzeczywiście tak jest? Spróbujmy to rozgryźć.

Kim on jest, naszym poprzednikiem oczekiwań?

Termin „generalista” zwykle odnosi się do członków zespołu, którzy łączą więcej niż jedną rolę, na przykład programista-analityk.

Interakcja zespołu i wynik jego pracy zależą od cech zawodowych i osobistych uczestników.

Jeśli chodzi o umiejętności twarde, wszystko jest jasne, ale na szczególną uwagę zasługują umiejętności miękkie. Pomagają znaleźć podejście do pracownika i nakierować go na zadanie, przy którym będzie najbardziej przydatny.

Istnieje wiele artykułów poświęconych wszelkiego rodzaju typom osobowości w branży IT. Bazując na moim doświadczeniu, podzieliłbym specjalistów IT na cztery kategorie:

1. „Uniwersalny – Wszechmogący”

Są wszędzie. Zawsze są bardzo aktywni, chcą być w centrum uwagi, stale pytają współpracowników, czy potrzebują pomocy, a czasami potrafią nawet być irytujący. Interesują ich tylko sensowne zadania, w których uczestnictwo da pole do kreatywności i może rozbawić ich dumę.

W czym są mocni:

• potrafią rozwiązywać złożone problemy;
• zagłębić się w problem, „kopać” i osiągać rezultaty;
• mieć dociekliwy umysł.

Ale:

• labilny emocjonalnie;
• źle zarządzany;
• mają swój własny, niezachwiany punkt widzenia, który bardzo trudno zmienić;
• Ciężko jest nakłonić kogoś do zrobienia prostej rzeczy. Łatwe zadania ranią ego Wszechmogącego.

2. „Uniwersalny – wymyślę i zrobię”

Takim osobom wystarczy instrukcja i trochę czasu - i rozwiążą problem. Zwykle mają duże doświadczenie w DevOps. Tacy generaliści nie zawracają sobie głowy projektowaniem i wolą stosować metodę rozwoju opartą wyłącznie na swoim doświadczeniu. Mogą łatwo porozmawiać z kierownikiem technicznym na temat wybranej opcji realizacji zadania.

W czym są mocni:

• niezależny;
• odporne na stres;
• kompetentny w wielu kwestiach;
• erudyta – zawsze jest o czym z nimi porozmawiać.

Ale:

• często naruszają obowiązki;
• mają tendencję do komplikowania wszystkiego: rozwiązują tabliczkę mnożenia poprzez całkowanie przez części;
• jakość pracy jest niska, wszystko działa 2-3 razy;
• Ciągle przesuwają terminy, bo w rzeczywistości wszystko okazuje się nie takie proste.

3. „Uniwersalny – ok, pozwól mi to zrobić, bo nie ma nikogo innego”

Pracownik jest dobrze zorientowany w kilku obszarach i ma odpowiednie doświadczenie. Ale w żadnym z nich nie zostaje profesjonalistą, bo często jest wykorzystywany jako lina ratunkowa, załatająca dziury w bieżących zadaniach. Giętki, wydajny, uważa się za poszukiwanego, ale tak nie jest.

Praktyczny idealny pracownik. Najprawdopodobniej ma kierunek, który najbardziej mu się podoba, ale z powodu rozmycia kompetencji rozwój nie następuje. W rezultacie dana osoba ryzykuje, że zostanie nieodebrana i wypalona emocjonalnie.

W czym są mocni:

• odpowiedzialny;
• zorientowane na wynik;
• spokój;
• całkowicie kontrolowane.

Ale:

• wykazywać przeciętne wyniki ze względu na niski poziom kompetencji;
• nie potrafi rozwiązywać złożonych i abstrakcyjnych problemów.

4. „Wszechstronny jest mistrzem w swoim rzemiośle”

Osoba z poważnym doświadczeniem jako programista myśli systemowo. Pedantyczny, wymagający wobec siebie i swojego zespołu. Każde zadanie, które go angażuje, może rosnąć w nieskończoność, jeśli granice nie zostaną określone.

Dobrze zna architekturę, dobiera sposób realizacji technicznej, dokładnie analizując wpływ wybranego rozwiązania na istniejącą architekturę. Skromny, niezbyt ambitny.

W czym są mocni:

• wykazywać się wysoką jakością pracy;
• potrafi rozwiązać każdy problem;
• bardzo wydajny.

Ale:

• nietolerancyjny wobec opinii innych;
• maksymaliści. Starają się zrobić wszystko dobrze, a to wydłuża czas rozwoju.

Co mamy w praktyce?

Przyjrzyjmy się, jak najczęściej łączone są role i kompetencje. Za punkt wyjścia weźmy standardowy zespół programistów: PO, menadżer ds. rozwoju (lider techniczny), analitycy, programiści, testerzy. Nie bierzemy pod uwagę właściciela produktu i kierownika technicznego. Pierwsza wynika z braku kompetencji technicznych. Ten drugi, jeśli w drużynie są problemy, powinien dać sobie radę ze wszystkim.

Najpopularniejszą opcją łączenia/łączenia/łączenia kompetencji jest programista-analityk. Analityk testowy i „trzy w jednym” są również bardzo popularne.

Na przykładzie mojego zespołu pokażę zalety i wady innych specjalistów. W moim zespole jest jedna trzecia z nich i bardzo ich kocham.

PO otrzymała pilne zadanie wprowadzenia nowych taryf na istniejący produkt. Mój zespół składa się z 4 analityków. W tym czasie jeden był na urlopie, drugi był chory, a reszta była zajęta realizacją zadań strategicznych. Gdybym je wycofał, nieuchronnie zakłóciłoby to terminy realizacji. Wyjście było tylko jedno: skorzystać z „tajnej broni” – wszechstronnego programisty-analityka, który opanował wymagany obszar tematyczny. Nazwijmy go Anatolij.

Jego typ osobowości to „uniwersalny – wymyślę i zrobię”. Oczywiście długo próbował tłumaczyć, że „ma pełne zaległości w swoich zadaniach”, ale moją stanowczą decyzją został wysłany do rozwiązania pilnego problemu. I Anatolij to zrobił! Terminowo przeprowadził inscenizację i zakończył realizację, a klienci byli zadowoleni.

Na pierwszy rzut oka wszystko się udało. Jednak po kilku tygodniach w przypadku tego produktu ponownie pojawiły się wymagania dotyczące ulepszeń. Teraz sformułowanie tego problemu zostało przeprowadzone przez „czystego” analityka. Na etapie testowania nowego rozwiązania przez długi czas nie mogliśmy zrozumieć, dlaczego popełniamy błędy w łączeniu nowych taryf i dopiero wtedy, po rozwikłaniu całej plątaniny, dotarliśmy do sedna prawdy. Straciliśmy mnóstwo czasu i nie dotrzymaliśmy terminów.

Problem w tym, że wiele ukrytych momentów i pułapek pozostało jedynie w głowie naszego kombi i nie zostało przeniesionych na papier. Jak później wyjaśnił Anatolij, za bardzo się spieszył. Ale najbardziej prawdopodobną opcją jest to, że natknął się na problemy już podczas programowania i po prostu je ominął, nie odzwierciedlając tego nigdzie.

Była jeszcze inna sytuacja. Teraz mamy tylko jednego testera, więc niektóre zadania muszą zostać przetestowane przez analityków, w tym generalistów. Dlatego dałem jedno zadanie warunkowemu Fedorowi - „uniwersalny – ok, daj mi to zrobić, bo nie ma nikogo innego”.
Fedor to „trzy w jednym”, ale do tego zadania przydzielono już programistę. Oznacza to, że Fedya musiała połączyć tylko analityka i testera.

Wymagania zostały zebrane, specyfikacja została przekazana do opracowania, czas na testy. Fedor zna modyfikowany system „jak własną kieszeń” i dokładnie opracował aktualne wymagania. Dlatego nie zawracał sobie głowy pisaniem skryptów testowych, tylko przeprowadził testy „jak system powinien działać”, a następnie przekazał je użytkownikom.
Test został zakończony, wersja trafiła do produkcji. Później okazało się, że system nie tylko zawiesił płatności na niektóre konta salda, ale także zablokował płatności z bardzo rzadkich rachunków wewnętrznych, które nie miały w tym uczestniczyć.

Stało się tak dlatego, że Fedor nie sprawdził, jak „system nie powinien działać”, nie sporządził planu testów ani list kontrolnych. Postanowił zaoszczędzić na czasie i polegać na własnym instynkcie.

Jak radzimy sobie z problemami?

Takie sytuacje wpływają na wydajność zespołu, jakość wydania i satysfakcję klienta. Dlatego nie można ich pozostawić bez uwagi i analizy przyczyn.

1. Dla każdego zadania, które sprawiało trudności, proszę o wypełnienie ujednoliconego formularza: mapy błędów, która pozwala zidentyfikować etap, na którym nastąpiła „wypłata”:

2. Po zidentyfikowaniu wąskich gardeł przeprowadzana jest burza mózgów z każdym pracownikiem, który miał wpływ na problem: „Co zmienić?” (nie rozważamy przypadków szczególnych z perspektywy czasu), w wyniku czego rodzą się określone działania (specyficzne dla każdego typu osobowości) z terminami.

3. Wprowadziliśmy zasady interakcji w zespole. Ustaliliśmy np., że wszystkie informacje o postępie zadania muszą być koniecznie rejestrowane w systemie zarządzania projektami. Jeżeli artefakty ulegną zmianie/zidentyfikowaniu w procesie opracowywania, należy to odzwierciedlić w bazie wiedzy i ostatecznej wersji specyfikacji technicznych.

4. Kontrolę zaczęto przeprowadzać na każdym etapie (szczególnie zwracano uwagę na etapy problematyczne w przeszłości) i automatycznie na podstawie wyników kolejnego zadania.

5. Jeśli wynik w kolejnym zadaniu się nie zmienił, to nie kwestionuję generalisty w roli, w której radzi sobie słabo. Staram się ocenić jego możliwości i chęć rozwijania kompetencji w tej roli. Jeśli nie znajduję odpowiedzi, zostawiam go w roli, która jest mu bliższa.

Co zdarzyło się na końcu?

Proces rozwoju stał się bardziej przejrzysty. Współczynnik BUS spadł. Członkowie zespołu, pracując nad błędami, stają się bardziej zmotywowani i poprawiają swoją karmę. Sukcesywnie podnosimy jakość naszych wydań.

odkrycia

Pracownicy generalistyczni mają swoje zalety i wady.

Zalety:

• możesz w dowolnym momencie zamknąć zalegające zadanie lub w krótkim czasie rozwiązać pilny błąd;
• zintegrowane podejście do rozwiązania problemu: wykonawca patrzy na niego z perspektywy wszystkich ról;
• generaliści mogą robić prawie wszystko równie dobrze.

Wady:

• wzrasta współczynnik BUS;
• podstawowe kompetencje związane z tą rolą ulegają erozji. Z tego powodu spada jakość pracy;
• wzrasta prawdopodobieństwo przesunięcia terminów, gdyż nie ma kontroli na każdym etapie. Istnieje również ryzyko wyrosnięcia na „gwiazdę”: pracownik ma pewność, że wie lepiej, że jest profesjonalistą;
• wzrasta ryzyko wypalenia zawodowego;
• wiele ważnych informacji o projekcie może pozostać jedynie „w głowie” pracownika.

Jak widać braków jest więcej. Dlatego korzystam z generalistów tylko wtedy, gdy nie ma wystarczających zasobów, a zadanie jest dość pilne. Albo dana osoba ma kompetencje, których brakuje innym, ale stawką jest jakość.

Jeśli we wspólnej pracy nad zadaniem przestrzegana jest zasada podziału ról, wówczas jakość pracy wzrasta. Patrzymy na problemy z różnych stron, nasz wzrok nie jest zamazany, zawsze pojawiają się świeże myśli. Jednocześnie każdy członek zespołu ma wszelkie możliwości rozwoju zawodowego i poszerzania swoich kompetencji.

Uważam, że najważniejsze jest poczucie zaangażowania w proces, wykonywanie swojej pracy, stopniowo zwiększając zakres swoich kompetencji. Jednak generaliści w zespole przynoszą korzyści: najważniejsze jest to, aby skutecznie łączyć różne role.

Życzę wszystkim samoorganizującego się zespołu „uniwersalnych mistrzów w swoim rzemiośle”!

Źródło: www.habr.com