Brak capacity w zespole developerskim można rozwiązać na kilka sposobów. Najczęściej rozmowa zaczyna się od prostego wniosku: potrzebujemy dodatkowych developerów .NET. To może być prawda. Ale nie zawsze. Czasem problemem rzeczywiście jest brak rąk do pracy. Wtedy staff augmentation, czyli dołączenie konkretnych specjalistów do istniejącego zespołu klienta, może być najlepszym wyborem.
Innym razem problem nie leży w samej liczbie osób, ale w tym, że określony zakres nie ma właściciela. Roadmapa rośnie, backlog się nie skraca, a wewnętrzny zespół nie ma przestrzeni, żeby przejąć kolejny moduł, aplikację lub obszar utrzymania. Wtedy lepszym rozwiązaniem może być managed team. Różnica jest ważna, bo oba modele kupuje się z innego powodu.
Kiedy staff augmentation wystarczy?
Staff augmentation sprawdza się wtedy, gdy klient ma własny proces, backlog, tech leadów i ownership po swojej stronie. Zewnętrzny developer lub kilku developerów dołącza do istniejącego modelu pracy. Korzysta z repozytoriów klienta, uczestniczy w jego code review, realizuje zadania z jego backlogu i działa według jego priorytetów.
W tym modelu klient kupuje kompetencje i dostępność.
Kiedy managed team jest lepszym wyborem?
Managed team działa inaczej. Zespół zewnętrzny nie tylko uzupełnia capacity, ale przejmuje odpowiedzialność za uzgodniony zakres. Może to być nowy moduł, aplikacja, fragment platformy, modernizacja legacy albo utrzymanie systemu produkcyjnego. Kluczowe jest to, że odpowiedzialność nie kończy się na dostarczeniu ludzi. Obejmuje również organizację pracy, plan delivery i rezultat. W tym modelu klient kupuje ownership.
Jak wybrać model współpracy w projekcie .NET?
Wybór odpowiedniego sposobu współpracy przy projekcie .NET ma fundamentalne znaczenie dla sukcesu całego przedsięwzięcia. Dobrze dobrany model pozwala uniknąć frustracji, przestojów w pracy oraz niepotrzebnych kosztów koordynacyjnych. W projekcie .NET wybór między dostępnymi modelami powinien zależeć od kilku kluczowych pytań.
Po pierwsze: czy zakres jest wystarczająco jasno zdefiniowany?
Jeżeli tak, można rozważyć managed team, czyli zespół zarządzany. Jeżeli nie, a klient sam zarządza backlogiem i priorytetami, lepiej sprawdzi się staff augmentation, czyli uzupełnienie personelu.
Po drugie: kto ma podejmować decyzje techniczne?
Jeżeli architektura, standardy, release i code review są w pełni po stronie klienta, dodatkowi specjaliści mogą dołączyć do obecnego zespołu. Jeżeli jednak zakres wymaga osobnego ownershipu, warto jasno ustalić, czy zewnętrzny zespół ma przejąć część decyzji technicznych.
Po trzecie: czy problemem jest capacity, czy odpowiedzialność?
To najważniejsze pytanie. Jeżeli zespół wie, co ma robić, ma proces i potrzebuje senior .NET lub Azure kompetencji, staff augmentation może wystarczyć. Jeżeli jednak praca nie przesuwa się, bo nikt nie ma przestrzeni, żeby przejąć cały obszar, sam dodatkowy developer nie rozwiąże problemu.
Po czwarte: jak duży koszt koordynacji może przyjąć organizacja?
Każda współpraca z zewnętrznym zespołem wymaga onboardingu, dostępu do repozytoriów, poznania architektury, ustalenia zasad komunikacji, code review i release’u. Jeżeli te elementy nie są jasno ustawione, dodatkowa capacity może zwiększyć liczbę spotkań, zamiast skrócić backlog.
Dlatego dobry zewnętrzny zespół powinien na początku ustalić nie tylko stack i zakres, ale też model odpowiedzialności.
Jak Prognetics rozróżnia team extension i managed delivery?
W Prognetics rozróżniamy te dwa scenariusze. W modelu team extension senior .NET i Azure specjaliści dołączają do procesu klienta. Pracują w jego backlogu, standardach i modelu zarządzania. W modelu managed delivery przejmujemy uzgodniony zakres, plan delivery i odpowiedzialność za rezultat. Żaden z tych modeli nie jest uniwersalnie lepszy. Lepszy jest ten, który odpowiada realnemu problemowi.
- Jeżeli brakuje kompetencji, warto rozszerzyć zespół.
- Jeżeli brakuje ownershipu, warto przekazać zakres.
Od czego zacząć rozmowę techniczną?
Przed wyborem modelu warto przygotować trzy informacje:
- stack,
- zakres,
- główne ograniczenie.
To wystarczy, żeby rozpocząć techniczną rozmowę i sprawdzić, czy potrzebny jest dodatkowy specjalista, czy zespół, który przejmie odpowiedzialność za konkretną część delivery.
