Otrzymanie repozytorium nie oznacza jeszcze otrzymania systemu, który zespół potrafi utrzymywać. Aby przekazanie projektu PHP zespołowi wewnętrznemu było skuteczne, osoby przejmujące projekt muszą umieć uruchomić aplikację, wdrażać zmiany, analizować incydenty i podejmować decyzje ze świadomością ograniczeń systemu.
Przekazanie należy zaplanować jako część pracy, a nie jako spotkanie na sam koniec. Warto uzgodnić, jakie kompetencje zostaną przekazane, kto je zademonstruje i jak zostanie zweryfikowane, że zespół przejmujący potrafi z nich korzystać. Celem nie jest wyeliminowanie wszelkiej niepewności, lecz uwidocznienie ryzyk, nierozstrzygniętych decyzji i zależności, które nadal będą wymagały koordynacji.
Określ, co oznacza gotowość do obsługi systemu
Zanim zaczniecie gromadzić dokumentację, określcie, co zespół wewnętrzny musi umieć zrobić bez polegania na doraźnych instrukcjach zespołu przekazującego projekt. Zależnie od systemu może to obejmować uruchomienie środowiska lokalnego, wdrożenie wersji, przeglądanie logów, odtworzenie danych lub reakcję na awarię integracji.
Przełóżcie te oczekiwania na możliwe do zaobserwowania testy. Na przykład osoba z zespołu przejmującego powinna móc wdrożyć zmianę o niskim ryzyku zgodnie z dostępną procedurą albo wyjaśnić, jak zidentyfikować i wycofać problematyczną migrację. Test musi być dostosowany do uprawnień i rzeczywistego środowiska: nie należy wywoływać incydentu na produkcji, aby udowodnić, że istnieje plan odzyskiwania.
Należy też jasno określić, co nie wchodzi w zakres przekazania. Niektóre operacje mogą zależeć od innego zespołu, dostawcy lub zgody działu bezpieczeństwa. Zapiszcie tę zależność i sposób eskalacji; nie przedstawiajcie jej jako kompetencji, która została już przekazana.
Sporządź inwentaryzację systemu i jego zależności
Inwentaryzacja techniczna powinna umożliwiać zlokalizowanie komponentów potrzebnych do rozwijania i obsługi aplikacji oraz ustalenie, kto za nie odpowiada. Uwzględnijcie co najmniej:
- Kod i automatyzacja: repozytoria, istotne gałęzie, konfigurację continuous integration, zadania zaplanowane i skrypty operacyjne.
- Aplikacja: wymaganą wersję PHP, menedżer i pliki zależności, rozszerzenia, polecenia budowania oraz konfigurację dla poszczególnych środowisk.
- Infrastruktura i środowiska: miejsce uruchomienia każdego środowiska, sposób jego provisioningu oraz istotne różnice między testami a produkcją.
- Dane: używane silniki baz danych, migracje, kopie zapasowe, odtwarzanie, retencję oraz dane wrażliwe wymagające ochrony.
- Podłączone usługi: API, pocztę, płatności, przechowywanie danych, kolejki i usługi tożsamości wraz z osobami odpowiedzialnymi oraz znanymi trybami awarii.
Sama lista technologii nie wystarczy. Dla każdej krytycznej zależności wskażcie, kto nią zarządza, jakie poświadczenia lub uprawnienia są potrzebne, jak wykryć przerwę w działaniu i jak zachowuje się aplikacja, gdy usługa przestaje odpowiadać. Nie umieszczajcie sekretów w dokumentach ani repozytoriach; wskażcie, gdzie są przechowywane i jak uzyskać do nich dostęp.
Udokumentuj architekturę, decyzje i ograniczenia
Przydatna dokumentacja odpowiada na pytania pojawiające się podczas pracy: który komponent przetwarza żądanie? Gdzie walidowane są dane? Jaki proces aktualizuje te informacje? Których części nie można zmienić bez skoordynowania migracji? Krótki diagram komponentów i kluczowych przepływów jest zwykle praktyczniejszy niż próba opisania każdego pliku.
Zapiszcie istotne decyzje wraz z ich kontekstem, rozważanymi alternatywami i konsekwencjami. Jeśli integracja ma ograniczenia, zadanie okresowe nie jest idempotentne albo starsza część systemu nie ma testów, zaznaczcie to wyraźnie. Oddzielcie potwierdzone fakty od hipotez i wskażcie, kiedy informacje zostały zweryfikowane.
Uwzględnijcie również nierozstrzygnięte decyzje: dostępne opcje, skutki odłożenia decyzji, osobę odpowiedzialną za jej podjęcie oraz termin lub warunek ponownego przeglądu. Dzięki temu zespół przejmujący zachowuje możliwość podejmowania decyzji, zamiast traktować odziedziczone wybory jako rzekome obowiązki.
Przekaż procedury uruchamiania i obsługi systemu
Udokumentujcie procedury, które zespół będzie musiał regularnie powtarzać, i przetestujcie je z jego członkami. W podstawowym zakresie opiszcie przygotowanie środowiska lokalnego, uruchamianie testów, wprowadzanie zmian w schemacie, budowanie i wdrażanie, weryfikowanie wersji oraz postępowanie w przypadku wycofania wdrożenia lub odtworzenia danych.
Procedura powinna określać warunki wstępne, uprawnienia, polecenia lub kroki, oczekiwane wyniki oraz sygnały nakazujące przerwanie działania. Jeśli wdrożenie wymaga niekompatybilnej migracji lub ręcznego zadania, wskażcie kolejność i ryzyko. Opisanie opcji odzyskiwania nie dowodzi, że ona działa: jeśli jest to bezpieczne, przetestujcie ją w odpowiednim środowisku i zapiszcie wynik, ograniczenia oraz osobę uprawnioną do jej użycia.
Uzupełnijcie procedury o obserwowalność: wskażcie, gdzie sprawdzać logi i metryki, jakie alerty są skonfigurowane, kto je otrzymuje i jak powiązać sygnał z przepływem biznesowym. Jeśli dla istotnego ryzyka nie ma alertu, zapiszcie to jako lukę; nie zakładajcie, że nowy zespół odkryje problem na czas.
Zweryfikuj dostęp, własność i przechowywanie zasobów
Zespół przejmujący potrzebuje rzeczywistych uprawnień do kodu i niezbędnych narzędzi, a nie tylko obietnicy przyszłego dostępu. Sprawdźcie repozytoria, system zarządzania incydentami, pipeline’y wdrożeniowe, chmurę, domeny, certyfikaty, monitoring i konta u dostawców. Ustalcie, kto może zarządzać użytkownikami i odzyskać dostęp, jeśli ktoś opuści organizację.
Potwierdźcie również własność i pieczę nad odpowiednimi zasobami, w tym kodem, dokumentacją, domenami i konfiguracjami. Stosujcie zasadę najmniejszych uprawnień: autonomia nie oznacza udostępniania osobistych poświadczeń ani przyznawania nieograniczonych uprawnień. Korzystajcie z kont imiennych lub zatwierdzonych mechanizmów, a rotację lub odebranie dostępów zespołowi przekazującemu zaplanujcie zgodnie z wewnętrznymi zasadami.
Przekazuj wiedzę we wspólnej pracy i zweryfikuj zakończenie
Spotkanie wprowadzające jest pomocne, ale nie dowodzi, że wiedza została przekazana. Zorganizujcie przejścia przez rzeczywiste zadania i zmieniajcie osobę prowadzącą: najpierw zespół przekazujący wyjaśnia procedurę, a następnie osoba z zespołu przejmującego wykonuje te same kroki i opisuje, co oraz dlaczego weryfikuje. Zarezerwujcie czas na pytania i zapisujcie kwestie wymagające zbadania.
Weryfikacja powinna obejmować kilka rodzajów kompetencji: opracowanie i przetestowanie zmiany, zdiagnozowanie reprezentatywnej awarii, wdrożenie zgodnie z procedurą oraz ustalenie osób odpowiedzialnych za krytyczną zależność. Wybierajcie bezpieczne ćwiczenia, adekwatne do systemu. Jeśli zadanie się nie powiedzie, ustalcie, czy przyczyną jest luka w dokumentacji, brak uprawnień, ograniczenie techniczne czy potrzeba szkolenia; każda z tych przyczyn wymaga innego działania.
Zamknijcie przekazanie listą nierozstrzygniętych kwestii zawierającą opis, wpływ, właściciela, sposób ograniczenia ryzyka i termin przeglądu. Zespół przejmujący powinien świadomie zaakceptować ryzyka rezydualne. Akceptacja nie oznacza, że ograniczenie przestało stanowić ryzyko; dokumentuje, kto ma o nim wiedzę i jak będzie ono zarządzane.
Lista kontrolna kompletnego przekazania
- Zespół przejmujący potrafi znaleźć kod, uruchomić go i wykonać odpowiednie testy.
- Zinwentaryzowano środowiska, zależności, zaplanowane procesy i usługi zewnętrzne.
- Dostępna jest mapa architektury, krytycznych przepływów, decyzji i znanych ograniczeń, a informacje można aktualizować.
- Procedury wdrażania, weryfikacji, wycofywania wdrożenia i odzyskiwania wskazują osoby odpowiedzialne oraz warunki wstępne.
- Niezbędne dostępy zostały przetestowane, własność jest jasna, a sekrety są bezpiecznie przechowywane.
- Zespół przejmujący wykonał zadania praktyczne, a nie tylko uczestniczył w objaśnieniach.
- Ryzyka i nierozstrzygnięte decyzje mają przypisane osoby odpowiedzialne, sposoby ograniczania ryzyka i jawną akceptację.
- Uzgodniono kanał i okres przeznaczony na rozwiązywanie pytań związanych z przekazaniem, z jasno określonym zakresem.
Przekazanie jest gotowe, gdy zespół wewnętrzny potrafi zademonstrować uzgodnione kompetencje i wie, kiedy potrzebuje wsparcia. Jeśli brakuje testów, dostępów lub osób odpowiedzialnych, przekazanie pozostaje niekompletne, nawet jeśli udostępniono całą dokumentację. Takie kryterium pozwala zweryfikować zakończenie przekazania i zachować autonomię w utrzymywaniu oraz rozwijaniu projektu PHP.
