Wprowadzenie zewnętrznego partnera do prac nad istniejącym systemem ma na celu zwiększenie tempa dostarczania funkcji i odciążenie wewnętrznego zespołu. Jednak wraz z pojawieniem się dodatkowych rąk do pracy rośnie skomplikowanie procesów koordynacyjnych. Największym wyzwaniem staje się moment, w którym kod opuszcza repozytorium deweloperskie i ma trafić na środowisko produkcyjne. Brak jasnych reguł odpowiedzialności za wdrożenie prowadzi do nieporozumień i ryzyk operacyjnych.
Dlaczego ownership release’u trzeba ustalić przed startem?
Gdy do projektu dołącza zewnętrzny zespół, najczęściej rozmawia się o capacity, stacku i backlogu. To zrozumiałe. Brakuje ludzi, trzeba dowieźć zakres, zespół wewnętrzny jest przeciążony. Problem w tym, że jedno z najważniejszych pytań pojawia się często za późno: „Kto odpowiada za release?”.
Dopóki praca dzieje się na poziomie zadań, odpowiedzialność może wydawać się jasna. Jeden zespół robi swoją część, drugi swoją. Pull requesty trafiają do review. Funkcje przechodzą testy. Backlog się przesuwa. Ale release jest momentem, w którym podział odpowiedzialności przestaje być teoretyczny.
Co musi być jasne przed wdrożeniem zmian?
Jeżeli coś pójdzie nie tak, trzeba wiedzieć:
- kto zatwierdził zmianę,
- kto rozumie zależności,
- kto podejmuje decyzję o rollbacku,
- kto komunikuje incydent,
- kto poprawia błąd,
- kto odpowiada za stabilność produkcji.
Współpraca dwóch zespołów na jednym codebase bez jasnego ownershipu release’u może szybko stworzyć chaos. Najczęstszy problem polega na tym, że zespół zewnętrzny dowozi kod, ale nie ma pełnej odpowiedzialności za wdrożenie. Zespół wewnętrzny zatwierdza release, ale nie zna wszystkich szczegółów implementacji. Product owner widzi gotową funkcję, ale nie widzi ryzyka technicznego. DevOps lub osoba odpowiedzialna za środowisko produkcyjne dostaje zmianę na końcu procesu. Formalnie wszyscy uczestniczą. Praktycznie nikt nie ma pełnego obrazu. Dlatego model release’u trzeba ustalić przed rozpoczęciem pracy, a nie przed pierwszym wdrożeniem.
Jak model współpracy wpływa na odpowiedzialność za release?
Pierwsza decyzja dotyczy tego, kto jest właścicielem zakresu. Jeżeli zewnętrzny zespół działa w modelu team extension, zwykle pracuje w backlogu klienta i pod jego zarządzaniem. Wtedy ownership release’u najczęściej pozostaje po stronie klienta. Zewnętrzni developerzy dostarczają kod zgodnie ze standardami, ale decyzja o wdrożeniu, priorytetach i akceptacji pozostaje w istniejącym modelu klienta.
Jeżeli natomiast zewnętrzny zespół działa w modelu managed delivery, odpowiedzialność powinna być szersza. Wtedy trzeba jasno określić, czy dostawca odpowiada tylko za development, czy również za przygotowanie release’u, testy, dokumentację, monitoring, wsparcie po wdrożeniu i reakcję na błędy.
Jak ustawić code review i kryteria gotowości?
Druga decyzja dotyczy code review.
- Kto reviewuje zmiany?
- Czy każdy pull request wymaga akceptacji zespołu klienta?
- Czy zewnętrzny zespół ma własne review wewnętrzne?
- Czy istnieją obszary kodu, których nie można zmieniać bez dodatkowej akceptacji?
- Czy standardy są opisane, czy przekazywane ustnie?
Brak jasnych zasad code review może spowodować dwa problemy. Albo review stanie się bottleneckiem i każda zmiana będzie czekać zbyt długo, albo zmiany przejdą za łatwo i ryzyko pojawi się dopiero na produkcji.
Trzecia decyzja dotyczy testów i kryteriów gotowości. Release nie powinien oznaczać wyłącznie tego, że funkcja działa lokalnie i przeszła review. Trzeba ustalić, co oznacza „gotowe do wdrożenia”:
- testy automatyczne,
- testy regresji,
- aktualizacja dokumentacji,
- zgodność z wymaganiami bezpieczeństwa,
- monitoring,
- feature flag,
- plan rollbacku,
- akceptacja biznesowa,
- akceptacja techniczna.
Bez wspólnej definicji gotowości dwa zespoły mogą myśleć, że dowiozły ten sam standard, chociaż w praktyce oczekiwały czegoś innego.
Kto reaguje po wdrożeniu?
Czwarta decyzja dotyczy reakcji po wdrożeniu. To często pomijany element. Jeżeli release powoduje błąd, kto reaguje pierwszy? Zespół klienta? Zewnętrzny dostawca? Wspólny kanał incydentowy? Kto ma dostęp do logów, alertów i środowiska? Kto decyduje o rollbacku? Jak długo zespół zewnętrzny wspiera produkcję po wdrożeniu? Te zasady nie powinny być ustalane w trakcie incydentu.
Jak Prognetics traktuje release w pracy z klientem?
W Prognetics przy współpracy z zespołami klienta traktujemy release jako integralną część ownershipu, a nie osobny, techniczny detal na końcu projektu. Zamiast pozostawiać kwestię wdrożeń kwestii przypadkowych ustaleń, od samego początku klarownie definiujemy podział ról.
Wspólnie z klientem precyzyjnie ustalamy:
- jaki zakres funkcjonalny przejmuje nasz zespół, kto posiada ostateczne uprawnienia do zatwierdzania zmian,
- jak przebiegają procesy code review,
- jakie kryteria ukończenia zadań (Definition of Done) muszą zostać spełnione.
Jasno wskazujemy również osoby odpowiedzialne za samo przeprowadzenie wdrożenia oraz procedury wsparcia powdrożeniowego. Dzięki temu zewnętrzny zespół nie staje się źródłem dodatkowego chaosu organizacyjnego, lecz przewidywalnym elementem sprawnie działającego ekosystemu delivery, w którym każda zmiana produkcyjna ma swojego wyraźnego właściciela.
Od czego zacząć?
Wspólna praca nad jedną aplikacją prowadzona przez dwa niezależne zespoły wymaga precyzyjnego zarządzania momentem wdrożenia na produkcję. Samodzielnie pisany kod oraz zamknięte procesy code review to dopiero połowa sukcesu – bez jednoznacznie przypisanej odpowiedzialności za release, procedury rollbacku oraz natychmiastową reakcję na ewentualne incydenty, każda nowa wersja systemu staje się poważnym ryzykiem biznesowym.
Aby uniknąć paraliżu decyzyjnego, rozmowę o współpracy z zewnętrznym partnerem należy zacząć od trzech fundamentalnych pytań: kto zatwierdza zmiany przed ich publikacją, kto odpowiada za samo wdrożenie oraz ewentualne wycofanie zmian, a także kto monitoruje środowisko produkcyjne i natychmiast reaguje w przypadku awarii. Dopiero uregulowanie tych kwestii pozwala na bezpieczne i efektywne dzielenie pracy pomiędzy zespołami.
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.