Kiedy projekt zaczyna tonąć?
Każdy projekt informatyczny rozpoczyna się podobnie. Są ambitne plany, harmonogram, prezentacja pierwszych makiet i przekonanie, że za kilka miesięcy firma będzie korzystać z nowoczesnego systemu. Początkowo wszystko wygląda obiecująco, ale z czasem pojawiają się pierwsze opóźnienia. Termin przesuwa się o tydzień, później o miesiąc. Liczba błędów rośnie, komunikacja z wykonawcą staje się coraz trudniejsza, a kolejne odpowiedzi brzmią: "Jeszcze chwila", "To tylko drobna poprawka" albo "Jesteśmy już na finiszu."
W pewnym momencie okazuje się, że zamiast gotowego produktu firma ma niedokończony projekt, którego nikt nie chce przejąć.
To scenariusz znacznie częstszy, niż mogłoby się wydawać.
Największym problemem nie jest kod
Większość przedsiębiorców zakłada, że jeśli projekt nie działa, winny jest źle napisany kod. Owszem - czasami tak właśnie jest. W praktyce jednak znacznie częściej problem leży głębiej.
Brakuje dokumentacji. Architektura powstawała "na bieżąco". Nie ma testów automatycznych. Integracje zostały wykonane prowizorycznie. Kolejne funkcje dopisywano bez analizy wpływu na cały system. W efekcie nawet niewielka zmiana powoduje kolejne błędy.
To trochę jak remont domu bez projektu. Każde kolejne pomieszczenie da się jeszcze wykończyć, ale z czasem okazuje się, że ściany nie są tam, gdzie powinny, instalacje prowadzone są przypadkowo, a przebudowa staje się coraz bardziej kosztowna.
Kiedy warto powiedzieć "stop"?
Jednym z najtrudniejszych momentów dla właściciela firmy jest decyzja o przerwaniu współpracy z dotychczasowym wykonawcą. Wielu przedsiębiorców zwleka z nią zbyt długo.
Dlaczego?
Bo projekt pochłonął już dużo pieniędzy.
Bo szkoda czasu.
Bo może "jeszcze się uda".
Psychologia nazywa to efektem utopionych kosztów. Im więcej już zainwestowaliśmy, tym trudniej przyznać, że obecny kierunek prowadzi donikąd.
Tymczasem czasami najlepszą decyzją nie jest dalsze dokładanie budżetu do tego samego problemu, ale zatrzymanie projektu i spokojna analiza sytuacji.
Czy każdy projekt da się uratować?
Nie. - I warto powiedzieć to uczciwie.
Są projekty, których naprawa kosztowałaby więcej niż stworzenie ich od nowa. Zdarza się również, że zastosowana technologia jest już przestarzała albo architektura została zaprojektowana w sposób uniemożliwiający dalszy rozwój.
Dlatego pierwszym krokiem nigdy nie powinno być składanie obietnic.
Pierwszym krokiem powinien być audyt.
Dopiero po dokładnym przeanalizowaniu kodu, dokumentacji, infrastruktury oraz procesów można odpowiedzieć na pytanie, czy bardziej opłaca się naprawiać istniejące rozwiązanie, czy rozpocząć nowy projekt.
Dobry partner technologiczny nie powie tego, co klient chce usłyszeć.
Powie to, co jest dla niego najlepsze biznesowo.
Jak wygląda ratowanie projektu w praktyce?
Wbrew pozorom nie zaczyna się od programowania.
Najpierw trzeba zrozumieć, z czym mamy do czynienia.
Analizujemy architekturę systemu, jakość kodu, sposób komunikacji pomiędzy modułami, bezpieczeństwo danych, wydajność oraz możliwości dalszego rozwoju. Sprawdzamy dokumentację, historię zmian i wykorzystane technologie. Często już po kilku dniach wiadomo, gdzie znajduje się rzeczywisty problem.
Dopiero wtedy powstaje plan działań.
Czasami wystarczy uporządkować kod i poprawić kilka kluczowych elementów. Innym razem konieczna jest przebudowa wybranych modułów. Zdarza się również, że najbardziej rozsądnym rozwiązaniem jest stworzenie nowego systemu z wykorzystaniem tego, co udało się już wypracować.
Nie ma dwóch identycznych projektów.
Tak samo jak nie ma jednej recepty na ich uratowanie.
Dlaczego przejęcie projektu jest trudniejsze niż stworzenie nowego?
To pytanie często słyszymy od klientów.
Odpowiedź jest prosta.
Tworząc system od początku, znamy każdą decyzję projektową. Wiemy, dlaczego wybrano konkretne rozwiązanie i jakie były założenia.
Przejmując cudzy projekt, najpierw musimy tę wiedzę odtworzyć.
To trochę jak przejęcie budowy domu po ekipie, która zostawiła plac budowy bez planów, bez dokumentacji i bez informacji o tym, co zostało wykonane.
Dlatego ratowanie projektów wymaga nie tylko umiejętności programistycznych, ale również doświadczenia architektonicznego, analitycznego i projektowego.
Partner technologiczny powinien być z Tobą także wtedy, gdy pojawiają się problemy
Dobry software house poznaje się nie po tym, jak rozpoczyna projekt.
Poznaje się po tym, jak reaguje, gdy pojawiają się trudności.
Nie wszystko da się przewidzieć. Zmieniają się wymagania biznesowe, technologie i potrzeby użytkowników. Kluczowe jest jednak to, czy zespół potrafi znaleźć rozwiązanie, jasno komunikować ryzyka i wspólnie z klientem podejmować najlepsze decyzje.
To właśnie wtedy buduje się zaufanie.
Jak pracujemy w Web24?
Do projektów wymagających przejęcia podchodzimy z dużą ostrożnością.
Nie składamy obietnic po pierwszej rozmowie.
Najpierw analizujemy sytuację. Sprawdzamy, co zostało wykonane, co można wykorzystać, a co będzie wymagało przebudowy. Dopiero później przygotowujemy rekomendację oraz plan dalszych działań.
Naszym celem nie jest napisanie kolejnych tysięcy linii kodu.
Naszym celem jest doprowadzenie projektu do momentu, w którym zacznie realnie wspierać rozwój biznesu.
Podsumowanie
Jeżeli Twój projekt utknął, wykonawca przestał odpowiadać, harmonogram istnieje już tylko w teorii, a kolejne poprawki generują następne błędy, nie oznacza to jeszcze, że wszystko jest stracone.
W wielu przypadkach problem można rozwiązać.
Trzeba jednak zacząć od jednego kroku - rzetelnej analizy sytuacji.
Bo zanim zacznie się ratować projekt, warto najpierw dowiedzieć się, dlaczego zaczął tonąć.
