Wybierzcie drogę dla waszego projektu

Od czego zaczynacie?

Macie już wspólne zasady i przygotowane narzędzia. Teraz wybierzcie sytuację, od której zaczynacie. To różne drogi, nie kolejne lekcje do odhaczenia.

• Nowy produkt — greenfield. Ustalacie potrzebę, sposób działania i pierwsze ekrany. Potem budujecie pierwszy fragment. Korzystacie z istniejących standardów zespołu.
• Działający system. Najpierw poznajecie jego zachowanie, wiedzę i zależności. Dopiero wtedy wybieracie pracę z agentami albo modernizację.

AI-first oznacza tu zmianę codziennej pracy z pomocą agentów. Legacy to system, którego ograniczenia utrudniają rozwój. Starsza technologia sama w sobie nie jest powodem do przepisania produktu.

W każdej drodze potrzebujecie osoby prowadzącej zadanie, kogoś do sprawdzenia wyniku oraz czasu na próbę. Nowy projekt też powstaje obok innych obowiązków zespołu.

Moje pięć lekcji ze współpracy z software house’em

Te wnioski zebrałem, realizując projekt z zewnętrznym software house’em, czyli firmą tworzącą oprogramowanie, i przygotowując przejęcie pracy do własnego zespołu. Warto z nich skorzystać zarówno przy nowym projekcie, jak i przy zlecaniu modernizacji lub przepisania legacy. Ramy ustal na początku — nie dopiero wtedy, gdy chcesz zmienić wykonawcę.

1. Dokumentacja może istnieć, a mimo to być trudna do wykorzystania

U nas dokumentacja była, ale jej struktura powstawała doraźnie. Dziś ustaliłbym układ Confluence i wymagane materiały od pierwszego dnia: co opisujemy, kto to robi i jak sprawdzamy aktualność przy odbiorze. Tutaj pokazuję strukturę dokumentacji i plik do użycia.

2. Narzędzia i domeny mają być firmowe od pierwszego dnia

Dużo czasu straciłem później na przepinanie GitHuba, Jiry, Miro i innych narzędzi, z których korzystaliśmy w projekcie. Dziś ustaliłbym od początku, że pracujemy w firmowych kontach i organizacjach tych usług, z administratorem po naszej stronie i firmowymi rozliczeniami. Wykonawca dostaje potrzebny dostęp do pracy.

Dotyczy to repozytoriów, zadań i ich historii, dokumentacji, tablic oraz projektów w Google Cloud (GCP). Domeny też mają być zarejestrowane na firmę — również techniczne i testowe. Wskazana osoba po naszej stronie musi móc nimi zarządzać i zadbać o odnowienie. Samo zaproszenie mnie do narzędzia wykonawcy tego nie załatwia.

Przed startem spisz zasoby projektu i sprawdź dla każdego: na kogo jest założony, kto nim administruje, kto płaci i kto zapewnia ciągłość działania. Przy istniejącym systemie zaznacz zależności od wykonawcy i uzgodnij ich uporządkowanie przed dalszym rozwojem.

3. Exit plan ustal już w umowie

Exit plan to uzgodniony sposób zakończenia współpracy i przekazania projektu. Chcę mieć go w umowie od początku. Po decyzji o przejęciu pracy jest trudniej. Nie zakładam, że szybkie i dokładne przekazanie będzie wtedy takim samym priorytetem wykonawcy jak moim.

Ustal, co przekazuje zespół, kto robi to po każdej stronie, w jakim terminie i na jakich zasadach wspiera przejęcie. Obejmij konta, kod, historię zadań, dokumentację, domeny, środowiska, wiedzę oraz otwartą pracę. Zapisz też, kto utrzymuje działającą aplikację do czasu potwierdzonego przejęcia.

Do tego potrzebna jest aktualizowana lista: zadanie, odpowiedzialny, termin, dowód i warunek odbioru. „Daliśmy wam pliki” nie wystarcza. Mój zespół ma potrafić uruchomić aplikację, wdrożyć ją na testach i wykonać uzgodnione czynności utrzymania. Wtedy sprawdzamy przekazanie w działaniu, a nie tylko na spotkaniu.

4. Wiedza musi przechodzić do twojego zespołu w trakcie pracy

Dwie osoby techniczne po naszej stronie pomogły zachować ciągłość rozwoju. W momencie tego podsumowania nadal zależeliśmy jednak od wykonawcy w obszarze DevOps, czyli wdrożeń i utrzymania środowisk. To pokazało mi, że samodzielne rozwijanie kodu nie oznacza samodzielnego utrzymania produktu.

Od początku wskaż ludzi, którzy przejmują wiedzę. Niech wspólnie z wykonawcą przechodzą zmianę, wdrożenie i reakcję na problem. Potem niech wykonają te czynności sami, korzystając z dokumentacji. Sposób zapewnienia tych kompetencji ustal wcześniej: rozwój własnego zespołu, rekrutacja lub uzgodnione przejście osób.

5. Rozliczanie godzin nie oznacza dostępności kluczowych ludzi

T&M (time and materials) to rozliczanie czasu i kosztów pracy. Nie traktuję samego tego modelu jako gwarancji, że potrzebna osoba będzie dostępna. W ustaleniach z wykonawcą chcę mieć wskazane kluczowe role i osoby, ich dostępność oraz zasady zastępstwa. Gdy ktoś odchodzi z projektu, musi być jasne, kto przejmuje jego wiedzę i bieżące zadania.

Sprawdźcie to przed rozpoczęciem współpracy

Weźcie te pięć punktów na rozmowę z wykonawcą. Otwórzcie rzeczywiste konta, plan, dokumentację i ustalenia współpracy. Zapiszcie brak, osobę odpowiedzialną oraz sposób sprawdzenia. Nie ograniczajcie się do zapewnienia, że wszystko będzie przekazane na koniec.

W pliku znajdziecie część „Współpraca z zewnętrznym wykonawcą”. Uzupełnijcie ją razem z zespołem; nie twórzcie drugiej listy, jeśli macie już te ustalenia w swoim planie.