Gdy delivery zwalnia, pierwsza diagnoza często brzmi: „Potrzebujemy więcej developerów.”. To naturalna reakcja. Backlog rośnie, roadmapa się przesuwa, zespół jest przeciążony, a biznes nadal oczekuje nowych funkcji. Dodatkowe osoby wydają się najprostszym sposobem na zwiększenie capacity. Ale nie zawsze rozwiązują problem. Czasem zespół nie potrzebuje więcej ludzi. Potrzebuje jaśniejszego ownershipu. Różnica jest duża.
Czym różni się brak capacity od braku ownershipu?
Brak developerów oznacza, że zadania są zrozumiałe, priorytety jasne, proces działa, ale zespół nie ma wystarczającej dostępności albo określonych kompetencji. Wtedy dodatkowi specjaliści mogą realnie pomóc. Niejasny ownership oznacza coś innego. Praca nie przesuwa się nie dlatego, że nie ma kto pisać kodu, ale dlatego, że nie wiadomo, kto podejmuje decyzje, kto odpowiada za zakres, kto zatwierdza zmiany i kto bierze odpowiedzialność za rezultat. W takiej sytuacji dodanie developerów może zwiększyć chaos.
Jakie są sygnały niejasnego ownershipu?
- Pierwszy sygnał problemu z ownershipiem to zadania, które długo czekają na decyzję. Developer może zacząć pracę, ale po drodze pojawia się pytanie o architekturę, integrację, priorytet, zakres albo wpływ na inny moduł. Jeżeli nikt nie jest właścicielem decyzji, zadanie zatrzymuje się mimo dostępnej capacity.
- Drugi sygnał to powtarzające się doprecyzowania. Jeżeli zespół ciągle wraca do tych samych tematów, problemem może nie być brak ludzi, ale brak osoby odpowiedzialnej za zamknięcie ustaleń. Wtedy kolejne spotkanie nie przyspiesza pracy. Tylko potwierdza, że decyzje nie mają właściciela.
- Trzeci sygnał to niejasna odpowiedzialność za release. Kod może być gotowy, pull request może być zaakceptowany, ale nadal nie wiadomo, kto decyduje o wdrożeniu, kto odpowiada za rollback, kto monitoruje produkcję i kto reaguje po release’ie. W takim modelu delivery blokuje się na końcu procesu.
- Czwarty sygnał to przerzucanie odpowiedzialności między zespołami. Zespół wewnętrzny zakłada, że zewnętrzny dostawca przejął temat. Dostawca zakłada, że klient nadal podejmuje kluczowe decyzje. Product owner zakłada, że technologia jest pod kontrolą. Tech lead zakłada, że scope został już uzgodniony.
Wszyscy mają częściową rację. I właśnie dlatego praca stoi.
- Piąty sygnał to backlog pełen zadań, które formalnie istnieją, ale nie mają realnego właściciela. Są opisane, przypisane, oszacowane, czasem nawet rozpoczęte. Ale nikt nie odpowiada za to, żeby przeprowadzić je od decyzji do release’u. Wtedy zespół może być zajęty, ale delivery nadal nie jest przewidywalne.
Jak odróżnić brak ludzi od braku decyzji?
Jak odróżnić brak capacity od braku ownershipu? Warto zadać kilka pytań:
- Czy wiadomo, kto podejmuje decyzje techniczne?
- Czy zakres jest wystarczająco jasno zdefiniowany?
- Czy ktoś odpowiada za rezultat, a nie tylko za wykonanie zadań?
- Czy wiadomo, kto zatwierdza release?
- Czy zespół wie, co może zrobić samodzielnie?
- Czy blokady wynikają z braku czasu, czy z braku decyzji?
Jeżeli odpowiedzi są niejasne, dodatkowi developerzy mogą nie pomóc. Mogą jedynie zwiększyć liczbę osób czekających na te same decyzje.
Jak dobrać model współpracy do problemu?
W Prognetics rozdzielamy te scenariusze już na początku rozmowy. Jeżeli klient ma jasny backlog, własny ownership i potrzebuje określonych kompetencji .NET lub Azure, dobrym rozwiązaniem może być team extension. Wtedy nasi specjaliści dołączają do istniejącego procesu, standardów i modelu zarządzania klienta.
Jeżeli problemem jest brak właściciela dla konkretnego zakresu, lepszy może być managed delivery. Wtedy przejmujemy odpowiedzialność za uzgodniony obszar, plan pracy i rezultat.
To nie jest tylko różnica w nazwie usługi. To różnica między dostarczeniem ludzi a przejęciem odpowiedzialności. Brak developerów spowalnia pracę. Brak ownershipu blokuje decyzje. Jeżeli organizacja pomyli te dwa problemy, może kupić capacity tam, gdzie potrzebuje odpowiedzialności.
Od czego zacząć rozmowę o ownershipie?
Przed zaangażowaniem zewnętrznego zespołu warto ustalić nie tylko zakres prac, ale też cel, który ten zakres ma realizować.
Na początku trzeba odpowiedzieć na trzy pytania:
- jaki rezultat ma zostać dowieziony,
- kto podejmuje decyzje techniczne po drodze,
- kto odpowiada za efekt po release’ie.
Dopiero wtedy można ocenić, czy problemem jest brak kompetencji, brak capacity czy niejasny ownership. Jeżeli cel nie ma właściciela, dodatkowi developerzy mogą tylko zwiększyć liczbę osób czekających na decyzje. Ownership zaczyna się tam, gdzie ktoś bierze odpowiedzialność nie za zadanie, ale za wynik.
Architektura sukcesu – dlaczego technologia bez strategii operacyjnej nie dowozi wartości?
Sam kod nie dowiezie wartości, jeśli w organizacji brakuje jasnych granic ownershipu i zdefiniowanego procesu wydawniczego. Optymalizacja architektury musi iść w parze z drożnym potokiem decyzyjnym. Bez tego zewnętrzny partner technologiczny generuje dodatkowe koszty koordynacji, zamiast skalować system.
Chris Gawliński
Programista i CEO warszawskiego software house'u Prognetics, kodujący od 11. roku życia i od ponad dekady tworzący oprogramowanie dla startupów, MŚP, globalnych korporacji i sektora publicznego. Pisze o technologii z perspektywy praktyka, który wie nie tylko jak zbudować software, ale jak sprawić, by dowoził realną wartość biznesową w bardzo różnych środowiskach.