Jak uratować projekt IT, który się sypie (i kiedy lepiej zacząć od nowa)

Projekty rzadko upadają w jeden dzień. Powoli dryfują w złą stronę, a każdy sygnał z osobna łatwo wytłumaczyć. Razem trudno je przeoczyć:

• Terminy wciąż się przesuwają, za każdym razem z innego powodu.
• Każda poprawka psuje coś innego, a te same błędy wracają.
• Nikt nie potrafi jasno powiedzieć, kiedy produkt wystartuje.
• Programista albo agencja odpisuje coraz wolniej albo wcale.
• Nie masz dostępu do kodu, serwerów ani kont.
• Nowi programiści mówią, że nie da się pracować z tym kodem „bez przepisania go od nowa”.

Jeden z tych sygnałów to ostrzeżenie. Trzy lub więcej zwykle oznaczają, że projekt potrzebuje ratunku, a nie kolejnego terminu.

Przykład: startup, którego freelancer przestał odpowiadać i jako jedyny zna hasło do serwera, potrzebuje ratunku, nawet jeśli sam kod jest w porządku.

Pierwszy tydzień jest podstawą wszystkiego, co przyjdzie potem, i decyduje o tym, ile czasu i pieniędzy kosztuje cały ratunek. Przed jakąkolwiek pracą techniczną są cztery kroki:

• Wstrzymaj nowe funkcje. Budowanie dalej na niestabilnej podstawie podnosi koszt każdej późniejszej poprawki.
• Zabezpiecz dostępy. Upewnij się, że kontrolujesz kod, serwery, domenę i każdą usługę, od której zależy produkt.
• Spisz, co obiecano, a co istnieje. Zbierz ofertę, umowę, projekty graficzne i listę tego, co dziś naprawdę działa.
• Wstrzymaj płatności niezwiązane z dostarczoną pracą. Jeśli płacisz za kamienie milowe, odłóż następną płatność do czasu, aż powstanie jasny plan.

Nie zaczynaj od szukania winnych. To, kto doprowadził projekt do tego stanu i dlaczego, znaczy dużo mniej niż odpowiedź na pytania: co można zrobić teraz, ile to będzie kosztować i kiedy produkt zacznie działać.

Dostępów założycielom brakuje najczęściej właśnie wtedy, gdy są najbardziej potrzebne. Przejdź przez każdy punkt tej listy i zapisz, kto go dziś kontroluje:

• Repozytorium kodu z pełną historią, a nie archiwum zip z ostatnią wersją.
• Konta hostingowe i serwerowe, razem z bazami danych i kopiami zapasowymi.
• Rejestratora domeny i ustawienia DNS.
• Konta deweloperskie w sklepach z aplikacjami, jeśli jest aplikacja mobilna.
• Usługi zewnętrzne: płatności, e-mail, analitykę, mapy, API sztucznej inteligencji.
• Pliki projektów graficznych i każdą istniejącą dokumentację.

Jeśli repozytorium jest na koncie innej osoby, poproś o jego przeniesienie. Dokumentacja GitHuba wyjaśnia, jak przy przeniesieniu zachowuje się historia, zgłoszenia i pull requesty.

Jeśli ktoś nie współpracuje, odzyskaj to, co możesz po swojej stronie: domena i hosting często są opłacane twoją kartą albo zarejestrowane na twój e-mail, i to jest droga powrotna.

Audyt to uporządkowane spojrzenie na produkt takim, jaki jest naprawdę, a nie takim, jak opisał go poprzedni wykonawca. Przydatny audyt obejmuje te obszary:

• Architektura. Jak części łączą się ze sobą i czy struktura udźwignie funkcje, których potrzebujesz.
• Jakość kodu. Czytelność, powtórzenia i to, jak ryzykowne są zmiany.
• Bezpieczeństwo. Typowe zagrożenia, takie jak te z listy OWASP Top 10, oraz sposób przechowywania sekretów i danych osobowych.
• Infrastruktura. Hosting, wdrażanie, kopie zapasowe i monitoring.
• Testy i dokumentacja. Co istnieje, czego brakuje i ile kosztowałoby uzupełnienie.

Wynikiem powinien być jasny werdykt dla każdej części produktu: zostawić, naprawić albo przepisać, każdy z uzasadnieniem. Dopiero wtedy ktoś może podać cenę, która odpowiada kodowi takiemu, jaki jest.

W Sakura pracujemy dokładnie w tej kolejności: najpierw audyt, potem wycena. Tylko tak nie wycenia się ratunku na podstawie obietnic, których kod nie spełnia.

Twój projekt właśnie utknął? Opowiedz nam, co się stało. Zaczniemy od dostępów i audytu i uczciwie powiemy, co da się uratować.

Najczęściej naprawiać. Stary kod, który działa na produkcji, zawiera lata drobnych poprawek do prawdziwych problemów, a przepisanie wyrzuca je razem ze złymi częściami.

Joel Spolsky opisał to w znanym eseju Things You Should Never Do. Nazwał przepisywanie kodu od zera „najgorszym strategicznym błędem, jaki może popełnić firma programistyczna”, na przykładzie Netscape: przepisanie trwało prawie trzy lata, a konkurencja w tym czasie uciekła do przodu.

Są przypadki, w których przepisanie to uczciwa odpowiedź. Ta tabela pokazuje, jak to ważymy:

Nawet gdy wygrywa przepisanie, rzadko trzeba robić je za jednym zamachem. Wzorzec Strangler Fig Martina Fowlera opisuje, jak wymieniać system kawałek po kawałku: nowe części rosną obok starych, aż stary kod można wyłączyć.

Jeśli poprzedni programista albo agencja jest wciąż osiągalna, krótkie i spokojne przekazanie oszczędza czas i pieniądze. Poproś o trzy rzeczy: dostęp do wszystkiego, listę znanych problemów i godzinne omówienie tego, jak produkt jest wdrażany.

Trzymaj rozmowę przy faktach. Ludzie mówią więcej, gdy nie czują się oskarżani, a szczegóły, które pamiętają o kodzie, są warte więcej niż każdy spór o winę.

Jeśli poprzedni zespół nie współpracuje, nie czekaj na niego. Odzyskaj konta, które kontrolujesz, zacznij audyt od tego, co jest, i zapisuj daty oraz treść każdej prośby.

Kiedy werdykt jest gotowy, pracuj w ścisłej kolejności. Najpierw premiera, potem ulepszenia:

• Ustabilizuj. Napraw krytyczne błędy, które wywracają produkt, gubią dane albo blokują płatności.
• Dokończ ścieżki potrzebne do premiery. Zrób tylko to, czego produkt potrzebuje do startu; reszta poczeka.
• Skonfiguruj wdrażanie i monitoring. Żeby wydania stały się rutyną, a problemy były widoczne, zanim zgłoszą je użytkownicy.
• Wystartuj. Prawdziwi użytkownicy pokażą, które z pozostałych problemów naprawdę mają znaczenie.
• Ulepszaj. Przechodź przez resztę listy według wpływu na biznes.

Cotygodniowe wersje, które możesz przeklikać, utrzymują ratunek w uczciwych ramach. Gdy projekt raz już się wykoleił, postęp trzeba widzieć co tydzień, a nie tylko o nim słyszeć.

Przykład: startup, którego agencja przekroczyła kilka terminów, może odkryć, że większość produktu działa, a premierę blokują trzy zepsute ścieżki. Jeśli najpierw naprawi się te trzy, produkt wystartuje, a resztę backlogu można zaplanować na podstawie prawdziwych danych o użyciu.

To zależy od tego, co znajdzie audyt, dlatego uczciwa wycena przychodzi po audycie, a nie przed nim. Kto wycenia ratunek bez zajrzenia do kodu, ten zgaduje.

Po audycie pracę do premiery zwykle da się wycenić jako stały zakres. Dostajesz wtedy jasną kwotę za dojście do produkcji, oddzieloną od ulepszeń, które przyjdą później.

Jeśli porównujesz oferty na sam ratunek, obowiązują te same zasady co przy każdym projekcie. Nasz poradnik o tym, czy wybrać stałą cenę czy rozliczenie godzinowe, wyjaśnia, kiedy pasuje który model.

Uratowany projekt to okazja, żeby wprowadzić zabezpieczenia, których zabrakło za pierwszym razem:

• Własność. Repozytorium, hosting, domena i konta w sklepach pozostają zarejestrowane na twoją firmę.
• Dokumentacja. Powstaje w trakcie pracy, żeby produkt nigdy więcej nie zależał od jednej osoby.
• Kamienie milowe. Płatności idą za wynikami, które da się sprawdzić, na przykład za działającą wersją pod linkiem testowym.
• Proces zmian. Nowe wymagania są wyceniane i zatwierdzane, zanim ktokolwiek zacznie nad nimi pracować.
• Wsparcie po premierze. Jasny plan poprawek i aktualizacji, na przykład miesięczny plan wsparcia.

Jeśli na kolejny etap wybierasz nowy zespół, nasz poradnik o tym, jak wybrać software house, zbiera pytania, które przed podpisaniem umowy ujawniają słabych partnerów.

Jeśli chcesz, żeby twój produkt znowu ruszył, wyślij nam krótki brief. Zaczniemy od dostępów i audytu, żeby przed jakimkolwiek dużym zobowiązaniem było jasne, na czym stoisz.