Projekt był dopiero na początku.
Nie było jeszcze presji ostatnich tygodni. Nie było sytuacji, w której trzeba było w panice przepisywać system przed deadlinem.
A mimo to było już wiadomo, że coś jest nie tak.
Dwuosobowy zespół. Projekt SaaS dla kliniki medycznej. Kilka technologii. Brak jednej osoby, która faktycznie dowodziłaby całością. Problemy ze współpracą z działem IT klienta. I zespół, który zamiast konsekwentnie dowozić kolejne elementy projektu, coraz bardziej skupiał się na jego dalszym rozwijaniu.
Na papierze projekt żył. W praktyce zaczynał dryfować.
W tym projekcie wszedłem właśnie w takiej roli. I z perspektywy czasu jedna decyzja okazała się kluczowa: zamiast ufać, że wszystko ostatecznie zostanie dowiezione, zbudowałem własną, bezpieczną wersję systemu równolegle do prac istniejącego zespołu. To właśnie ona pozwoliła później uratować projekt.
Projekt B+R może zacząć się psuć, zanim ktokolwiek zauważy problem
Kiedy myślimy o zagrożonym projekcie B+R, zazwyczaj wyobrażamy sobie coś spektakularnego. Deadline za miesiąc. Nieukończony produkt. Wykonawca, który nie dowozi. Telefon od zarządu: „Co my teraz z tym zrobimy?"
W rzeczywistości największe problemy często zaczynają się dużo wcześniej. Projekt wygląda wtedy całkiem normalnie. Ludzie pracują. Powstają nowe funkcje. Odbywają się spotkania. Na Jira są zadania. Na prezentacji można pokazać postęp.
Tylko że zaczyna brakować jednej rzeczy: jasnego kierunku prowadzącego do działającego rezultatu.
Dwuosobowy zespół i brak jednej osoby odpowiedzialnej za całość
Sam fakt, że zespół liczy dwie osoby, oczywiście nie oznacza problemu. Mały zespół może zbudować świetny produkt. Problem pojawia się wtedy, kiedy nikt nie bierze odpowiedzialności za całość projektu.
Można wtedy bardzo łatwo wejść w model: „Ja robię swoje. On robi swoje. Jakoś to połączymy."
Tylko że produkt nie jest sumą niezależnych zadań. Ktoś musi patrzeć na architekturę, technologię, zakres, harmonogram, integracje, infrastrukturę, ryzyko i końcowy rezultat jednocześnie. Bez tej perspektywy zespół może być zajęty praktycznie cały czas, a mimo to projekt będzie stał w miejscu.
Klient miał własny dział IT
Klinika medyczna będąca klientem projektu miała własny dział IT, który nie był szczególnie zainteresowany współpracą. To oczywiście dodatkowo komplikowało sytuację.
Bo w projektach technologicznych komunikacja pomiędzy zespołem budującym produkt a organizacją, w której produkt ma działać, jest niezwykle ważna. Ktoś musi ustalić jak wygląda środowisko, jakie są ograniczenia infrastruktury, jak będzie wyglądało wdrożenie i kto odpowiada za poszczególne elementy.
Jeżeli te rzeczy są niejasne, problemy pojawiają się później. A im później, tym droższe są w rozwiązaniu.
Największy problem nie wyglądał jak problem
Technologie były różne. Kod istniał. Zespół pracował. Projekt był rozwijany. I właśnie słowo „rozwijany" było tutaj kluczowe.
Bo można rozwijać produkt przez wiele miesięcy i nadal nie mieć produktu, który można bezpiecznie uznać za gotowy. Powstaje funkcja. Potem kolejna. Potem ktoś wpada na następny pomysł. Zespół cały czas coś robi. Tylko że projekt nie zbliża się proporcjonalnie do momentu, w którym można powiedzieć: „mamy działający rezultat".
Rozwój produktu nie jest tym samym co dowożenie projektu
W normalnym produkcie SaaS ciągły rozwój jest czymś naturalnym. Produkt żyje. Dodajemy funkcje. Eksperymentujemy. Testujemy.
Ale projekt B+R ma określony cel, zakres, rezultaty, terminy i zobowiązania. Dlatego w pewnym momencie trzeba przestać pytać: „Co jeszcze możemy dodać?" i zacząć pytać: „Co musi działać, żeby projekt faktycznie został dowieziony?"
Pierwsza rzecz, którą zrobiłem: zebrałem to, co naprawdę istnieje
Nie chciałem zaczynać od kolejnego planu. Najpierw chciałem wiedzieć, co mamy.
Uruchomiłem serwer. Sprawdziłem istniejące elementy systemu. Przejrzałem technologie. Zebrałem informacje dotyczące aktualnego stanu projektu. Porozumiałem się z kliniką.
I zacząłem oddzielać to, co rzeczywiście działa od tego, co miało działać. To bardzo ważne rozróżnienie. Bo dokumentacja, prezentacja czy lista zadań może mówić: „moduł jest gotowy". Ale dopiero uruchomiony system odpowiada na pytanie: „Czy rzeczywiście działa?"
Wtedy podjąłem dość nietypową decyzję
Zamiast zatrzymać cały projekt i powiedzieć: „Dobra, teraz wszyscy robimy od początku" — zrobiłem coś innego.
Zbudowałem drugą wersję.
Nie po to, żeby stworzyć konkurencyjny produkt. Nie po to, żeby udowodnić, że poprzedni zespół robił wszystko źle. Tylko po to, żeby stworzyć bezpieczny wariant projektu, który będzie można dowieźć.
Dwie wersje projektu
Od tego momentu funkcjonowały właściwie dwie ścieżki. Pierwsza: istniejący zespół kontynuował swoją pracę i rozwijał dotychczasową wersję. Druga: ja równolegle budowałem wersję opartą na tym, co według mnie było potrzebne do realnego dowiezienia projektu.
To może wyglądać na marnowanie zasobów. Przecież zamiast budować jedną wersję, budowaliśmy dwie. Tyle że w tym przypadku druga wersja nie była dodatkowym kosztem. Była ubezpieczeniem projektu.
Dlaczego nie zatrzymałem pierwszej wersji? Bo zatrzymanie całego zespołu również generuje ryzyko. I przede wszystkim: nie miałem jeszcze pewności, że cała istniejąca wersja jest do wyrzucenia. Dlatego zamiast podejmować decyzję „wyrzucamy wszystko", zrobiłem coś bezpieczniejszego: „Zbuduję wersję, która pozwoli nam mieć kontrolę nad sytuacją."
Najtrudniejsze było odbieranie kolejnych etapów
Przy odbieraniu kolejnych elementów projektu często dostawałem coś, co na pierwszy rzut oka wyglądało jak wykonana praca. Opis. Dokument. Lista zmian. Prezentacja.
Tylko że z punktu widzenia CTO najważniejsze pytanie jest dużo prostsze: „Pokaż mi działający rezultat."
Bo można napisać bardzo długi opis funkcji. Można przygotować świetną prezentację. Ale projekt technologiczny ostatecznie musi działać. Esej nie zastąpi działającego produktu.
Dlatego CTO musi patrzeć na system end-to-end
Nie interesuje mnie wyłącznie: „Czy backend działa?" albo „Czy frontend jest gotowy?"
Interesuje mnie: czy użytkownik może wykonać cały proces? Od początku: logowanie → działanie → dane → zapis → kolejny etap → rezultat.
Jeżeli każdy element osobno działa, ale cały proces nie działa, to z perspektywy użytkownika produkt nadal nie działa. To bardzo częsty problem w projektach rozwijanych przez kilka osób lub zespołów.
Druga wersja zaczęła mieć coraz większy sens
W miarę postępu prac moja wersja systemu dawała coś, czego wcześniej brakowało: pewność. Wiedziałem co zostało zbudowane, jak działa, jakie ma ograniczenia, co jeszcze trzeba zrobić i gdzie są ryzyka. Nie musiałem opierać się wyłącznie na deklaracjach. Miałem działający punkt odniesienia.
I to okazało się kluczowe. Bo kiedy projekt zaczął zbliżać się do końca, nagle pojawiło się dokładnie to, czego można było się spodziewać. Kolejne elementy istniejącej wersji nie były tak kompletne, jak wynikało z wcześniejszych deklaracji. Niektóre rzeczy wymagały dalszej pracy. Niektóre były bardziej koncepcją niż gotowym rozwiązaniem.
I wtedy okazało się, że decyzja o zbudowaniu drugiej wersji nie była przesadną ostrożnością. Była zabezpieczeniem projektu.
To jest właśnie różnica między programistą a CTO
Programista może patrzeć na: „Jak zrobić tę funkcję?" Tech Lead może patrzeć: „Jak zrobić ją dobrze technicznie?"
CTO musi natomiast zadać jeszcze inne pytanie: „Co się stanie z całym projektem, jeśli tego nie zrobimy?" I jeszcze jedno: „Jaki mamy plan B?"
To właśnie ta druga perspektywa była potrzebna w tym projekcie. Więcej o tym, kiedy decyzje technologiczne wykraczają poza kod, piszę w artykule o testach urządzenia medycznego w Ghanie →
Projekt B+R potrzebuje momentu „freeze"
W projektach technologicznych zmiany są normalne. Ale musi istnieć moment, w którym przestajemy traktować projekt jak nieskończony produkt. Pojawia się pytanie: Co dokładnie musi znaleźć się w finalnym rezultacie?
I od tego momentu każdą kolejną funkcję trzeba oceniać przez pryzmat celu. Nie: „Czy byłoby fajnie ją mieć?" Tylko: „Czy jest konieczna?"
O tej samej zasadzie — zatrzymania zmian przed deadline'em — piszę w artykule o zmianie technologii miesiąc przed oddaniem projektu →
Jak rozpoznać, że projekt B+R zaczyna się wykolejać?
- Zespół cały czas coś rozwija, ale nie kończy. Jeżeli lista nowych funkcji rośnie szybciej niż lista rzeczy ukończonych, jest problem.
- Nie ma jednej osoby odpowiedzialnej za technologię. Jeżeli każdy odpowiada za swój fragment, ale nikt za całość, ryzyko rośnie.
- Nie można pokazać działającego produktu end-to-end. To jeden z największych sygnałów ostrzegawczych.
- Status projektu opiera się bardziej na opisach niż demonstracjach. Dokumentacja jest ważna, ale nie zastępuje działającego systemu.
- Zakres ciągle się rozszerza. Problem zaczyna się wtedy, gdy podstawowy rezultat nadal nie jest stabilny.
- Nikt nie ma planu B. Jeżeli jedna wersja systemu jest jedyną możliwością ukończenia projektu, projekt jest bardziej podatny na awarię.
A co z projektem finansowanym z PARP lub Ścieżki SMART?
Tutaj dochodzi jeszcze jeden poziom. Jeżeli projekt jest finansowany ze środków publicznych, nie można patrzeć na niego wyłącznie jak na zwykły produkt SaaS. Trzeba rozumieć również zakres projektu, harmonogram, wskaźniki, zobowiązania, dokumentację i zasady programu.
CTO nie zastępuje doradcy dotacyjnego. Ale powinien potrafić odpowiedzieć na podstawowe pytanie: „Czy od strony technologicznej jesteśmy w stanie dowieźć to, co projekt ma osiągnąć?"
Nie każdy zagrożony projekt trzeba przepisywać
Ratowanie projektu nie oznacza automatycznie: „wyrzucamy wszystko". Czasami wystarczy zmienić architekturę jednego modułu, przejąć kontrolę nad infrastrukturą, uporządkować proces developmentu, ograniczyć zakres albo stworzyć plan awaryjny.
Właśnie dlatego pierwszym etapem powinien być audyt i diagnoza, a dopiero później decyzje. O tym, kiedy warto ratować istniejący kod, piszę w osobnym artykule: Kiedy NIE przepisywać systemu od zera? →
Najważniejsza lekcja: ratowanie projektu zaczyna się dużo wcześniej niż deadline
Kiedy projekt jest już miesiąc przed terminem, pole manewru jest niewielkie. Kiedy problem zostanie zauważony na początku, sytuacja jest zupełnie inna. Można zmienić kierunek, poprawić architekturę, ograniczyć zakres albo stworzyć alternatywną ścieżkę.
Projekt udało się dowieźć
Ostatecznie projekt został dowieziony. Ale z perspektywy czasu najważniejszym elementem nie była sama technologia. Była nim możliwość wyboru.
Gdybyśmy mieli tylko jedną ścieżkę, bylibyśmy całkowicie zależni od tego, czy istniejący proces faktycznie doprowadzi do rezultatu. Druga wersja sprawiła, że mieliśmy alternatywę. I właśnie dlatego projekt miał szansę zostać zakończony.
Czasami najlepszą rzeczą, jaką może zrobić CTO, jest przygotowanie się na to, że plan nie zadziała. Nie chodzi o brak zaufania do zespołu. Chodzi o zarządzanie ryzykiem. Jeżeli projekt jest ważny, powinien mieć nie tylko plan A — powinien mieć również plan B.