W obliczu rosnących wymagań rynkowych i ograniczonych zasobów wewnętrznych, organizacje IT często stają przed dylematem odpowiedniego doboru modelu współpracy z partnerem zewnętrznym. Zamiast powierzania pojedynczych zadań oderwanym od szerszego kontekstu deweloperom, coraz częściej wybiera się podejście oparte na pełnej odpowiedzialności za rezultat, co pozwala realnie odciążyć firmę i przyspieszyć realizację kluczowych inicjatyw.
Kiedy managed delivery jest lepsze niż dodatkowi developerzy?
Nie każdy problem z delivery da się rozwiązać przez dodanie kilku developerów do zespołu. Czasem organizacja nie potrzebuje tylko dodatkowych rąk do pracy. Potrzebuje zespołu, który przejmie odpowiedzialność za konkretny zakres i dowiezie go od początku do końca. To właśnie miejsce dla managed delivery.
Czym managed delivery różni się od team extension?
W tym modelu zewnętrzny zespół nie jest jedynie rozszerzeniem zespołu klienta. Nie czeka tylko na zadania z backlogu i nie działa wyłącznie jako dodatkowa capacity. Przejmuje uzgodniony obszar, organizuje pracę, planuje delivery i odpowiada za rezultat. Różnica jest prosta. W team extension klient zarządza pracą, a zewnętrzni specjaliści dołączają do jego procesu. W managed delivery dostawca bierze odpowiedzialność za ustalony zakres.
Ten model ma sens wtedy, gdy zakres jest wystarczająco wyraźny, żeby można było go przekazać jako osobny obszar pracy. Może to być nowy moduł, aplikacja, integracja, modernizacja wybranej części systemu, przejęcie maintenance albo rozwój konkretnego produktu.
Managed delivery dobrze sprawdza się szczególnie wtedy, gdy wewnętrzny zespół jest przeciążony i nie powinien samodzielnie prowadzić kolejnego obszaru. Nie chodzi tylko o brak czasu na development. Chodzi też o brak przestrzeni na analizę, planowanie, koordynację, decyzje techniczne, testy, release i support po wdrożeniu.
Jeżeli klient chce przekazać dostawcy konkretny problem, a nie tylko pojedyncze zadania, managed delivery może być lepszym wyborem niż staff augmentation.
Jakie zakresy warto przekazać w managed delivery?
Pierwszy scenariusz to nowy zakres poza główną roadmapą zespołu. Firma potrzebuje dostarczyć moduł, aplikację lub integrację, ale wewnętrzny zespół ma już własne priorytety. Przekazanie takiego zakresu zewnętrznemu zespołowi pozwala nie rozbijać capacity klienta, o ile zakres, ownership i punkty synchronizacji zostaną jasno ustalone.
Drugi scenariusz to legacy modernization. Modernizacja starszej aplikacji .NET często wymaga osobnego rytmu pracy. Trzeba zrozumieć zależności, ocenić ryzyko, zaplanować mniejsze zmiany, zabezpieczyć release i nie zatrzymać bieżącego developmentu. W takim przypadku managed delivery może pomóc przejąć konkretny obszar modernizacji, zamiast dokładać kolejne zadania do przeciążonego backlogu klienta.
Trzeci scenariusz to application ownership. Jeżeli aplikacja produkcyjna nie ma stabilnego ownera, utrzymanie zaczyna zabierać czas zespołowi wewnętrznemu. Błędy, incydenty, drobne zmiany i release’e rozbijają roadmapę. Wtedy zewnętrzny zespół może przejąć maintenance, incident support i continuous development w jasno określonym modelu odpowiedzialności.
Czwarty scenariusz to integracja AI z istniejącym procesem. AI nie powinno kończyć się na demo. Jeżeli funkcja ma działać w realnym workflow, potrzebne są dane, kryteria akceptacji, evaluation set, fallback, monitoring i integracja z systemem klienta. Taki zakres często wymaga zespołu, który nie tylko napisze kod, ale przeprowadzi wdrożenie od use case’u do kontrolowanego działania.
Kiedy managed delivery może nie zadziałać?
Managed delivery nie jest jednak dobrym wyborem zawsze. Jeżeli backlog jest niejasny, priorytety zmieniają się codziennie, decyzje techniczne są rozproszone, a klient nie wie jeszcze, co dokładnie chce przekazać, najpierw potrzebne jest doprecyzowanie zakresu. Bez tego dostawca będzie formalnie odpowiedzialny za wynik, ale praktycznie uzależniony od ciągłych decyzji po stronie klienta.
Co ustalić przed przekazaniem zakresu?
Dlatego przed rozpoczęciem managed delivery trzeba ustalić kilka rzeczy:
- co dokładnie jest zakresem,
- czego dostawca nie przejmuje,
- kto podejmuje decyzje techniczne,
- jak działa code review,
- kto zatwierdza release,
- jak mierzymy rezultat,
- jak wygląda komunikacja przy zmianie scope’u.
Im jaśniejsze granice odpowiedzialności, tym większa szansa, że zewnętrzny zespół rzeczywiście odciąży organizację.
Jak Prognetics rozumie managed delivery?
W Prognetics managed delivery oznacza przejęcie uzgodnionego zakresu, planu pracy i odpowiedzialności za rezultat. Może dotyczyć nowego developmentu, legacy modernisation, application ownership, maintenance albo integracji AI z istniejącym systemem. Nie chodzi o to, żeby klient „oddał projekt i zapomniał”. Chodzi o to, żeby wiedział, co przejmujemy, jak zaczynamy, czego potrzebujemy od jego zespołu i po czym poznać, że współpraca działa. Managed delivery ma największy sens wtedy, gdy problemem nie jest tylko brak developerów, ale brak przestrzeni na prowadzenie całego obszaru.
Od czego zacząć rozmowę o managed delivery?
Jeżeli zewnętrzny zespół ma przejąć cały zakres, rozmowa nie powinna zaczynać się od liczby developerów. Powinna zaczynać się od odpowiedzialności.
Na początku trzeba ustalić trzy rzeczy:
- jaki rezultat ma zostać dowieziony,
- jakie decyzje i zależności pozostają po stronie klienta,
- za co dostawca odpowiada do momentu release’u i po wdrożeniu.
Dopiero wtedy managed delivery różni się od zwykłego przekazania zadań. Zespół nie tylko pracuje nad backlogiem, ale bierze odpowiedzialność za uzgodniony obszar, plan delivery i efekt. Jeżeli zakres nie ma właściciela, managed delivery może go stworzyć. Jeżeli zakres nadal ma być prowadzony po stronie klienta, lepszym modelem może być team extension.
Podsumowanie
Wybór modelu managed delivery stanowi strategiczną decyzję, która wykracza daleko poza zwykłe uzupełnienie braków kadrowych w dziale IT. Przekazanie pełnej odpowiedzialności za dany obszar biznesowo-techniczny ma sens wyłącznie wtedy, gdy ramy współpracy, kryteria sukcesu oraz granice ownershipu zostaną precyzyjnie zdefiniowane przed startem prac. Odpowiednio wdrożone podejście oparte na mierzalnym rezultacie pozwala odciążyć wewnętrzny zespół, wyeliminować ukryte koszty koordynacji i zapewnić stabilny, przewidywalny rozwój oprogramowania.
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.