W zespołach pracujących w modelu Time & Materials (T&M) urlopy, zwolnienia lekarskie i dni wolne są czymś zupełnie normalnym. Jednak każda nieobecność oznacza zmniejszone capacity zespołu oraz utratę możliwości zafakturowania klienta. W małych zespołach nie stanowi to wielkiego problemu. Jednak wraz ze wzrostem skali projektu wpływ absencji kadry znacząco rośnie – zarówno na budowany produkt, jak i wynik finansowy. Shadow developer to jedna z możliwości optymalizacji.
Kim jest shadow developer?
Według mojego doświadczenia i własnych implementacji, w przeciwieństwie do definicji zaproponowanej przez digitalmesh.com, shadow developer to pełnoprawny członek zespołu, uczestniczący w codziennych aktywnościach: sprintach, spotkaniach refinementowych, przeglądach kodu i rozwoju produktu.
Różnica polega na sposobie rozliczania – shadow developer jest fakturowany klientowi tylko wtedy, gdy w zespole pojawia się nieskonsumowany budżet wynikający z nieobecności innych osób. Gdy budżetu nie ma, nie jest uwzględniany na fakturze. shadow developer nie musi (i wg mnie nie powinien) być oficjalną rolą przypisaną do konkretnej osoby. To raczej jedynie umowne, dodatkowe miejsce w zespole o szczególnym sposobie rozliczenia ze sponsorem projektu. Przykład: w projekcie o budżecie obliczonym dla 10 FTE udział bierze nie 10, a 11 członków zespołu (jedno, dodatkowe miejsce to nasz shadow developer).
Skąd wziąć budżet na Shadow Developera?
Załóżmy, że każdy członek zespołu bierze średnio 20 dni wolnego rocznie. Przy większym zespole (wg moich obliczeń 11-osobowym) daje to równowartość jednego pełnego etatu „straconego” na nieobecności. Budżet ten można śmiało wykorzystać na zaangażowanie shadow developera.
Korzyści dla zespołu i klienta
Wprowadzenie shadow developera przynosi wiele korzyści:
- Zespół staje się bardziej odporny na urlopy i nieprzewidziane nieobecności,
- Zabezpieczenie przed rotacjami w składzie (na wypadek nieprzewidzianego odejścia, mamy w zespole jednego dodatkowego developera).
- Obniżenie presji projektowej na developerów – jest więcej przestrzeni na realizację zadań.
- Łatwiej utrzymać stałe tempo pracy i uniknąć opóźnień.
- Pojawia się dodatkowa przestrzeń na zadania często odkładane, takie jak refactoring, poprawki jakościowe czy dokumentacja.
- Maksymalizacja revenue (przychodu projektu).
- Możliwość przeszkolenia i „przetarcia w boju” dodatkowych pracowników.
Dla klienta to rozwiązanie nie generuje dodatkowych kosztów – ponosi jedynie te koszty, które i tak były zaplanowane w budżecie. W zamian otrzymuje dodatkowego developera, stabilniejszy zespół i mniejsze ryzyko opóźnień. Nigdy nie spotkałem się jeszcze z odrzuceniem przez klienta takiej propozycji – wszak z jego punktu widzenia, w przypadku przekroczenia dedykowanego budżetu shadow developer pracuje zupełnie za darmo.
Kto najlepiej sprawdzi się jako shadow developer?
Tak jak wspomniałem, rola shadow developera jest umowna i nie powinna być sztywno powiązana z konkretnym pracownikiem. Jednak chcąc obsadzić dodatkowe miejsce w zespole, warto wziąć pod uwagę:
- developerów z mniejszym doświadczeniem zawodowym bądź w danej technologii (np. juniorzy czy inżynierowie zmieniający specjalizację),
- osoby pracujące na część etatu,
- developerów wracających po dłuższej przerwie (np. po urlopie macierzyńskim),
- osoby narażone na częstsze absencje (L4, urlopy etc.).
Minusy i ryzyka związane z modelem Shadow Developera
Choć model shadow developera przynosi wiele korzyści, warto również rozważyć potencjalne wyzwania:
Przyzwyczajenie stakeholderów do większego zespołu
W dłuższej perspektywie klient lub sponsor projektu mogą przyzwyczaić się do obecności dodatkowej osoby w zespole. Rezygnacja z shadow developera może wówczas wiązać się z niezadowoleniem lub koniecznością ponownego tłumaczenia modelu rozliczeń. Dlatego ważne jest, aby od początku jasno komunikować tymczasowy charakter tej roli.
W praktyce często np. junior shadow developer – gdy nadarza się odpowiednia okazja (bo np. ktoś bardziej doświadczony odchodzi z zespołu) – po jakimś czasie zostaje „wchłonięty” przez team.
Ograniczona przestrzeń budżetowa przy kontraktorach B2B
Jeśli zespół składa się głównie z developerów rozliczanych za godzinę pracy (np. kontraktorów B2B), którzy nie mają puli płatnych dni wolnych, generowanie budżetu na shadow developera staje się trudniejsze. Tacy pracownicy rzadziej biorą urlopy, co ogranicza przestrzeń na zatrudnienie dodatkowej osoby. W takim przypadku o zaangażowaniu shadow developera powinny zdecydować nie tylko czynniki czysto finansowe.
Shadow developer to cenne narzędzie optymalizacji
Mimo tych wyzwań, odpowiednio wdrożony model shadow developera pozostaje wartościowym narzędziem optymalizacji projektu w modelu T&M. Zdecydowanie nie jest panaceum na wszystkie problemy zespołu i nie zastąpi dobrego planowania. Ale w odpowiedniej skali zespołu to świetny sposób na optymalne wykorzystanie budżetu projektowego budżetu. W modelu T&M shadow developer jest inwestycją w stabilność zespołu i spokój obu stron kontraktu – zarówno zespołu, jak i klienta.