Usługi wzmocnienia kadrowego polegają na dołączeniu inżynierów do zespołu, którym już kierujesz, pod Twoim własnym kierownictwem technicznym, z Twoim własnym backlogiem i zgodnie z Twoją własną definicją zakończenia zadania. Przyspieszają pracę, gdy wąskim gardłem jest brak rąk do realizacji planu działań, który już ustaliliście. Spowalniają pracę, gdy wąskim gardłem są w rzeczywistości niejasne priorytety, brak decyzji dotyczących architektury lub brak osoby, która miałaby czas na sprawdzenie pull requestu — bo w takim przypadku po prostu dodaliście więcej osób czekających na tę samą osobę.
Czym właściwie są usługi w zakresie uzupełniania kadry
Najprostszym sposobem zdefiniowania tego pojęcia jest określenie, kto podejmuje decyzje.
W przypadku usług wzmocnienia kadry decyzje pozostają w Twoich rękach. To Ty odpowiadasz za architekturę, planowanie sprintów, standardy przeglądu kodu oraz proces wydawania nowych wersji. Nowi inżynierowie dołączają do Twojego Slacka, codziennych spotkań standupowych i repozytorium. Stanowią oni dodatkowy potencjał w ramach systemu, który już zaprojektowałeś.
W przypadku projektu zleconego na zewnątrz decyzje przechodzą w ręce dostawcy. Przekazujesz mu zakres prac i termin, a w zamian otrzymujesz gotowy produkt. To dostawca decyduje, jak go zrealizować, kto się tym zajmie i w jakiej kolejności. Takie podejście sprawdza się, gdy zakres prac jest rzeczywiście zamknięty — chodzi o konkretną integrację, przeprojektowanie lub migrację z jasno określonym punktem końcowym.
Pomiędzy nimi działa wyspecjalizowany zespół programistów. Jest to stabilna grupa przypisana do Państwa produktu na dłuższą metę, zazwyczaj posiadająca własnego kierownika i własny wewnętrzny proces, ale działająca zgodnie z Państwa planem działania. To Państwo nadal wyznaczają kierunek; zespół zajmuje się przede wszystkim codzienną koordynacją działań w ramach własnej grupy. Jest to model, o którym większość osób myśli, mówiąc o “usługach rozszerzenia zespołu”, a różnica w stosunku do zwykłego wzmocnienia kadry IT polega głównie na tym, w jakim stopniu grupa ta wnosi ze sobą własne procesy.
Wersja, która kończy się niepowodzeniem, to taka, w której firma kupuje usługi wzmacniające, ale zachowuje się tak, jakby zamówiła projekt zlecony na zewnątrz: do zespołu dołączają wykonawcy, a potem nikt nie podejmuje za nich żadnych decyzji. Zgłoszenia pozostają nierozstrzygnięte. Żądania zmian pozostają niesprawdzone. Sześć tygodni później dochodzi się do wniosku, że “kontrahenci tu nie pracują”, podczas gdy w rzeczywistości zdolność do podejmowania decyzji nigdy się nie zwiększyła, a wzrosła jedynie wydajność pisania na klawiaturze.
| Wzmocnienie kadry | Specjalny zespół programistów | Projekt zlecony na zewnątrz | |
|---|---|---|---|
| Kto jest właścicielem zaległości | Ty | Ty | Dostawca, wbrew uzgodnionemu zakresowi |
| Kto sprawdza kod? | Państwa inżynierowie | Udostępniono – obowiązują Twoje standardy | Dostawca |
| Kto jest właścicielem architektury | Ty | Ty, z uwzględnieniem opinii dostawców | Dostawca |
| Najlepsze dopasowanie | Plan działania jest znany, brakuje rąk do pracy | Produkt o długiej historii, regularne aktualizacje | Zamknięty tor z linią mety |
| Kończy się słowami | Ludzie odchodzą, kod i kontekst pozostają | Stopniowe wycofywanie się | Przekazanie obowiązków |
Jak to działa w praktyce
Zastanów się, czego tak naprawdę ci brakuje. Zapisz trzy kolejne pozycje z planu działania i dla każdej z nich powód, dla którego nie została zrealizowana. Jeśli powodem jest to, że “nikt się tym nie zajął”, pomocne będzie wzmocnienie zespołu. Jeśli powodem jest to, że “nie zdecydowaliśmy jeszcze, jak to powinno działać”, zatrudnienie nowych osób nic tu nie zmieni, a nowi pracownicy spędzą pierwszy miesiąc na zadawaniu pytań, na które wciąż nie znamy odpowiedzi.
Czas na przegląd budżetu, a nie tylko na prace rozwojowe. Każdy nowy inżynier pochłania czas przeznaczony na weryfikację, który mógłby poświęcić ktoś z wyższego szczebla, mający już własne obowiązki. Dodanie dwóch programistów przy jednym recenzencie, który jednocześnie zajmuje się wdrażaniem nowych funkcji, powoduje powstanie kolejki, a nie przyspiesza pracę. Należy zaplanować, kto będzie przeprowadzał weryfikację, i odciążyć tę osobę od części obowiązków.
Należy liczyć się z rzeczywistymi kosztami wdrożenia. Wdrożenie programisty do pracy nad działającym produktem trwa zazwyczaj od dwóch do sześciu tygodni, zanim osiągnie on pełną wydajność — nie dlatego, że dobrzy inżynierowie pracują wolno, ale dlatego, że system produkcyjny charakteryzuje się nieudokumentowanym zachowaniem, specyficznymi cechami wdrażania oraz regułami dziedzinowymi, które istnieją wyłącznie w głowach ludzi. Czas ten można skrócić, jeśli dysponuje się działającym środowiskiem lokalnym, przejrzystym zestawem testów oraz aktualnym przeglądem architektury. Czas ten wydłuża się, jeśli pierwszy tydzień trzeba poświęcić na doprowadzenie projektu do stanu, w którym da się go skompilować.
Zajmijcie ich prawdziwą pracą już od samego początku. Najszybszym sposobem na skrócenie okresu wdrażania jest zgłoszenie w pierwszym tygodniu – niewielkie, ale autentyczne – dotyczące procesu kompilacji, testów i ścieżki wdrażania. Prawdziwa zmiana wprowadzona do środowiska produkcyjnego dostarcza więcej wiedzy o systemie niż dwa tygodnie czytania.
Należy na piśmie określić, kto jest właścicielem kodu. Kto jest właścicielem kodu, praw własności intelektualnej, dostępu do repozytorium oraz prawa do dalszej współpracy z tymi samymi osobami? Jeśli umowa nie określa, że kod należy do Ciebie, załóż, że to problem. Jeśli nie określa, co się stanie, gdy inżynier zakończy pracę w firmie, załóż, że stanie się to w najgorszym możliwym momencie.
Przed rozpoczęciem negocjacji zapoznaj się z przedziałem stawek. Jako punkty odniesienia dla branży stawki godzinowe wynoszą mniej więcej $40–100 w Europie Wschodniej, $75–200 w Europie Zachodniej oraz $100–250 w Stanach Zjednoczonych. Są to orientacyjne wartości rynkowe, a nie konkretna oferta od kogoś konkretnego — pozwalają jednak ocenić, czy dana propozycja jest nietypowa i w jakim kierunku. Aby uzyskać szerszy obraz czynników wpływających na budżet oprogramowania, napisaliśmy o tym osobno w Koszt tworzenia oprogramowania na zamówienie, gdzie region i częstotliwość okazują się mieć mniejsze znaczenie niż liczba systemów, z którymi oprogramowanie musi pozostawać zsynchronizowane.
Przykład z naszej praktyki
Firma VRpartments z siedzibą w Krakowie zwróciła się do nas jeszcze na etapie pomysłu — nie miała ani produktu, ani kodu, a jedynie koncepcję platformy nieruchomościowej, na której klienci mogliby zdalnie przeglądać nieruchomości za pomocą rzeczywistości wirtualnej i modeli 3D, w tym mieszkania znajdujące się jeszcze w budowie.
Ten punkt wyjścia jest nietypowy dla rozmów dotyczących rekrutacji i miał znaczenie dla dalszego przebiegu współpracy. Zanim cokolwiek zostało stworzone, praca skupiała się na zdefiniowaniu produktu: czym właściwie był ten produkt, co musiał udowodnić i w jakiej kolejności. Następnie wspieraliśmy fazę pozyskiwania inwestycji – dokumentację, spotkania z inwestorami, plan działania – oraz działania związane z wprowadzeniem produktu na rynek. Aplikacja została stworzona w React Native i jest dostępna zarówno w Google Play, jak i w App Store.
W kontekście tego artykułu istotne są wydarzenia, które miały miejsce po uruchomieniu. Jak opisał to klient: “Nadal współpracujemy jako przedłużenie zespołu IT klienta, a projekt wciąż znajduje się w fazie aktywnego rozszerzania zakresu”.”
W tej umowie nie ma określonego terminu realizacji. Nie jest to projekt, który został zakończony i przekazany; chodzi o zasoby inżynieryjne powiązane z produktem, który wciąż się rozwija. A powodem, dla którego to działa, jest kwestia, do której ciągle wracamy: to klient zachował prawo do podejmowania decyzji. Kierunek rozwoju produktu, priorytety oraz to, co oznacza dalsze skalowanie, leżą w ich gestii. My jesteśmy zespołem inżynierów, który realizuje te zadania.
To właśnie ta granica odróżnia udane rozszerzenie zespołu od rozczarowującego. Rozbudowa zespołu sprawdza się, gdy przekazujesz zadania, ale zachowujesz kontrolę nad decyzjami. Nie udaje się natomiast, gdy wraz z zadaniami przekazujesz również uprawnienia decyzyjne, a po kilku miesiącach okazuje się, że nikt w firmie nie potrafi wyjaśnić, dlaczego system został zbudowany właśnie w ten sposób.
Pełny opis: Studium przypadku VRpartments.
Na co zwrócić uwagę
Dodawanie osób do projektu na późnym etapie. Jeśli termin już się przesuwa, nowi inżynierowie sprawiają, że kolejne tygodnie będą jeszcze gorsze, a nie lepsze — wdrożenie nowych pracowników pochłania właśnie tę uwagę doświadczonych pracowników, która już wcześniej stanowiła ograniczenie. Zwiększcie możliwości, zanim będą wam potrzebne, albo zamiast tego zmieńcie zakres projektu.
Traktowanie inżynierów z rozszerzeniami jako odrębnej grupy. Dwie procedury weryfikacji, dwa poziomy kontekstu oraz oddzielny kanał na Slacku spowodują powstanie dwóch baz kodu w ramach jednego repozytorium. Jeśli ktoś pisze kod produkcyjny, powinien podlegać tym samym procedurom co wszyscy inni — tym samym weryfikacjom i mieć taki sam dostęp do osób, które wiedzą, dlaczego pewne rzeczy są takie, a nie inne.
Nie sprawujesz nadzoru nad osobami, których staż pracy wykupiłeś. Starszy inżynier, który nie ma po swojej stronie odpowiednika o profilu technicznym, z konieczności będzie podejmował decyzje dotyczące architektury, bo ktoś musi to robić. Jeśli taki był twój zamiar, to nie ma w tym nic złego. Jeśli jednak nie, to może to być dla ciebie zaskoczeniem.
Brak planu wycofania się z wiedzy. To właśnie w tym miejscu większość projektów po cichu przynosi straty. Jeśli wiedza tkwi wyłącznie w głowach osób, które w końcu odejdą, to tak naprawdę wynajmujesz zrozumienie własnego produktu. Niech dokumentacja stanie się częścią pracy, a nie czymś obiecanym na później: spisane decyzje dotyczące architektury, instrukcje postępowania dla wszystkich aspektów operacyjnych oraz co najmniej jeden z twoich inżynierów sprawdzający kod w każdym obszarze. Wtedy zakończenie współpracy będzie jedynie formalnością, a nie stratą.
Porównywanie niewłaściwych elementów pod kątem kosztów. Porównanie stawki godzinowej z wynagrodzeniem wewnętrznym nie ma sensu — pomija ono czas poświęcony na rekrutację, miesiące potrzebne na znalezienie pracownika i wdrożenie go do pracy, świadczenia oraz koszty związane z błędną decyzją dotyczącą zatrudnienia na stałe. Nasz wcześniejszy artykuł na temat tworzenie rozwiązań we własnym zakresie a współpraca z agencją omawia ten kompromis; artykuł skupia się na produktach z branży fintech, ale logika zatrudniania przebiega wszędzie według tego samego schematu. A jeśli rozważasz raczej strukturę biznesową niż kwestię zatrudnienia, nasze zestawienie wycena ryczałtowa, wycena na podstawie nakładu czasu i materiałów oraz wycena z wykorzystaniem dedykowanego zespołu dotyczy sytuacji, w których długoterminowy plan działania sprawia, że stały zespół staje się bardziej przewidywalnym rozwiązaniem.
Wniosek
Usługi wzmocnienia kadrowego rozwiązują problem wydajności, a nie problem związany z kierunkiem rozwoju. Jeśli wiesz, co chcesz stworzyć, ale brakuje Ci rąk do pracy, zatrudnienie inżynierów pod własnym kierownictwem jest najszybszym rozwiązaniem — pod warunkiem, że uwzględnisz w budżecie czas na weryfikację i zaakceptujesz okres wdrożenia trwający od dwóch do sześciu tygodni, zanim pracownicy osiągną pełną wydajność. Jeśli jeszcze nie wiesz, co chcesz stworzyć, najpierw to ustal; żadne zwiększenie zdolności operacyjnych nie zastąpi podjęcia decyzji. Zadbaj o to, by kod, architektura i priorytety pozostawały po twojej stronie, zapisuj na bieżąco zdobyte doświadczenia, a takie rozwiązanie może funkcjonować przez lata — lub zakończyć się w sposób uporządkowany — bez utraty wiedzy o twoim własnym produkcie. To właśnie model, na którym opiera się nasza rozbudowa zespołu i outsourcing informatyczny praca.
