Jeśli trafiłeś na ten artykuł prawdopodobnie doświadczyłeś lub doświadczasz sytuacji, w której wszelkie deadline’y i terminy uruchomienia Twojego projektu są przekroczone. Masz biznes plan, terminy, harmonogram a Twój zespół IT lub zewnętrzna firma ciągle przekłada termin oddania, lub też w oprogramowaniu, które już jest gotowe istnieje tyle dziur co w szwajcarskim serze. W tym artykule napiszę o kilku najpopularniejszych przyczynach dlaczego taki stan rzeczy się pojawił, jak doprowadzić produkcje do szczęśliwego końca, oraz jak w przyszłości unikać opóźnień. Zaznaczam, że nie są to wszystkie przyczyny, a jedynie najpopularniejsze, z którymi ja, jak i współpracujące firmy z branży miały okazje się spotkać. Na początek przyjmijmy założenie, że realizowana jest aplikacja internetowa (portal, web aplikacja, narzedzie intranetowe etc.) a współpraca odbywa się z zewnętrzną firmą informatyczną lub wewnętrznym działem IT. Inwestor w omawianym przypadku ma bezpośredni wpływ na produkt końcowy. Popularne problemy, które chciałbym poruszyć w dalszej części artykułu:

1. Modyfikacje oprogramowania podczas jego realizacji.
2. Brak precyzyjnej dokumentacji.
3. Źle zorganizowany zespół IT.
4. Przeładowanie obowiązkami.
5. Niedoszacowanie projektu.
6. Błędy, błędy, błędy.

#1 Modyfikacje oprogramowania w czasie jego powstawania, czyli czy projekt musi być idealny i bezkonkurencyjny od momentu uruchomienia?

Nie musi. Przysłowiowe „polerowanie kuli” to bardzo popularny problem wśród inwestorów, którzy nie mają odwagi uruchomienia czegoś co jest niedoskonałe. W praktyce wygląda to tak – zespół IT na początku poznał założenia projektu, rozplanował sobie prace, wprowadził harmonogram, etapy oddawał na początku w terminie. Inwestor po pewnym czasie zaczął otrzymywać wgląd do fragmentów aplikacji no i zaczęły się schody. Inwestor jako osoba decyzyjna i mająca największy wpływ na wygląd finalny projektu zaczęła podczas jego realizacji wprowadzać „ulepszenia”. Wiadomo, apetyt rośnie w miarę jedzenia, fantazja wielu jest bardzo szeroka więc czemu by nie dodać jeszcze kilku niesamowitych i rozkładających na łopatki konkurencję funkcjonalności? Do zespołu IT zaczęły spływać coraz to nowe pomysły, nowe rozwiązania a czasem (o zgrozo) modyfikacje kluczowych założeń. Zespół programistyczny co raz to dokleja nowe funkcjonalności do kodu, przebudowuje bazę danych, czasem wprowadza zmiany w samej architekturze projektu. Nagle się okazuje, że terminy są już znacznie  przekroczone, a stan aplikacji nie nadaje się do pokazywania komukolwiek.

Prowadź „backlog”

Żaden poważny projekt internetowy nie kończy się na pierwszej wersji. Błędy projektowe, ulepszenia i nowe funkcjonalności to chleb powszedni. Zacznij prowadzić „backlog” czyli dokument, w którym spiszesz wszystkie swoje pomysły i nowe (lepsze) rozwiązania w jednym miejscu. Dzięki temu po uruchomieniu projektu Ty oraz Twój zespół będziecie mogli się zastanowić nad listą zmian z backlog. Dzięki temu pozwolisz zespołowi spokojnie zrealizować to co pierwotnie założyłeś i wszelkie dodawane zmiany nie będą opóźniały terminu uruchomienia.

Rozmawiaj z zespołem

Często zdarza się, że brak kilku funkcjonalności ma bardzo poważny wpływ na konkurencyjność i atrakcyjność projektu. Nie jesteś w stanie z nich zrezygnować przed premierą swojego produktu. Postaraj się więc porozmawiać z zespołem jak Twoje udoskonalenia wpłyną na projekt, kiedy mogły by być zrealizowane i jak przesuną oddanie projektu. Zawsze jednak pamiętaj – terminy i sposób wdrożenia powinien wypływać nie od Ciebie ale od Project Managera projektu, który w kontakcie z programistami może Ci przedstawić realne warunki realizacji. Nie narzucaj swoich terminów, mało asertywni Project Managerowie posłusznie je zaakceptują, ale terminu siłą rzeczy i tak nie dotrzymają.

#2 Brak dobrej dokumentacji to początek końca

Niestety cały czas dużym problemem jest nieprzywiązywanie wystarczająco dużej wagi do dobrej dokumentacji. Jeśli jesteś osobą biznesową, zazwyczaj opisujesz co chcesz i jaką drogą to osiągnąć. Przesyłasz „dokumentacje” kilkustronicową do firmy IT lub przekazujesz swojemu Project Managerowi. Spotykacie się, omawiacie projekt, otrzymujesz wycenę i start! Wydaje Ci się, że zespół IT już wszystko wie. Masz racje! Wydaje Ci się. Tworzenie oprogramowania internetowego to nie gotowanie („szczypta soli”, „jedna średnia marchewka”, „odrobina pieprzu”). Tu pracuje się na bardzo konkretnych danych i wskaźnikach. Wszystko musi być bardzo precyzyjnie opisane i zdefiniowane. Nie wiesz jak to zrobić? To normalne, w końcu jesteś od biznesu a nie programowania! O tym jak przygotować przyzwoitą dokumentację będzie poświęcony osobny wpis. Załóżmy jednak, że zespół IT przyjął projekt i zaczął go realizować. Co w dobrej dokumentacji projektu powinno się znaleźć?

• Specyfikacja techniczna czyli wymagania jakie ma spełnić oprogramowanie (technologia, środowisko w którym ma działać, wymagania jakościowe);
• Specyfikacja funkcjonalna czyli możliwie najdokładniejsze opisanie funkcjonalne wszystkich elementów aplikacji;
• Algorytmy i zależności pomiędzy różnymi elementami aplikacji;
• Dobrze opracowane prototypy, czyli prezentacja wszystkich możliwych stanów oraz interakcji interfejsu użytkownika.

To jest w mojej ocenie tak zwane „must have”, w zależności od rodzaju projektu konieczne mogą się jeszcze okazać dodatkowe dokumenty (np. diagramy UML, specyfikacja interfejsu, bezpieczeństwo, wydajność etc.), natomiast przy mniejszej i średniej skali oprogramowania często jest to wystarczające na początek i uzupełniane później.

#3 Problemy w zespole IT

Niestety, ale bardzo często słyszy się o problemach nie wynikających bezpośrednio z niewiedzy Inwestora, a z błędów popełnianych przez zespół wdrożeniowy. Ponieważ bardzo trudna jest ocena jakości zespołu IT, dlatego przed rozpoczęciem projektu:

• Upewnij się, że każdy z członków zespołu tak samo rozumie projekt, jego działanie i cele biznesowe jak Ty. Częste problemy wynikają z błędnego zrozumienia problematyki – bądź co bądź realizowanie zaawansowanego oprogramowania wiąże się często z koniecznością zdobycia dodatkowej wiedzy specjalistycznej z przedmiotu realizowanego projektu.
• Zadbaj o bardzo dobrego Project Managera, który ma na swoim koncie niejeden oddany (w terminie!) duży projekt internetowy. Dzięki niemu prace będą lepiej skoordynowane, możliwe problemy zostaną rozpoznane dużo wcześniej zanim się jeszcze pojawią, a najsłabsze ogniwa w zespole mogą być najszybciej wymienione.
• Pamiętaj, że programista nie zrobi wszystkiego. Niech Twój Project Manager zbuduje kompetentny zespół składający się ze wszystkich koniecznych specjalizacji w projekcie (np. testerów, front-end developera, software architect’a, projektanta architektury informacji etc.).
• Jeśli zespół IT nie dotrzymuje terminów i etapy lub sprinty nie są zrealizowane na czas – porozmawiaj z Project Managerem. Najprawdopodobniej zespół IT nie jest sam w stanie oszacować czasochłonności prac i powinna zapalić Ci się czerwona lampka związana z doświadczeniem zespołu. Często pierwsze terminy łatwiej dotrzymać niż kolejne, ponieważ nie istnieje jeszcze pojęcie „długu technologicznego”, czyli drobnych niedoróbek niewidocznych gołym okiem.
• Sprawdź czy Project Manager korzysta np. z CPM czyli z planowania metodą ścieżki krytycznej (to jako przykład, są również inne metody)

#4 Przeładowanie obowiązkami

Niejednokrotnie zdarza się, że osoby zaangażowane w jeden projekt realizują jeszcze równolegle drugi lub trzeci mniejszy. Poza ograniczeniami czasowymi, które zaczynają się pojawiać zespół przestaje myśleć tylko o Twoim projekcie, co w konsekwencji często kończy się wieloma błędami i nieprzewidzianymi zachowaniami aplikacji. Warto zadbać o zespół, aby zaangażowany był tylko w jeden projekt, i cały czas myślał tylko o nim. Pamiętaj – zespół pracujący w nadgodzinach, weekendami lub nocą to poważny spadek jakości. Nie dopuść do tego. Programowanie to bardzo specjalistyczna praca wymagająca świeżości umysłu, skupienia  i pomysłowości.

#5 Niedoszacowanie projektu

Jedna z najgorszych rzeczy jaka może Cie spotkać, kiedy w połowie realizacji oprogramowania okazuje się, że budżet się już wyczerpał i całość realizacji będzie znacznie droższa. Z czego wynika niedoszacowanie?

• Brak kompetencji członków zespołu;
• Brak lub słaba dokumentacja projektu;
• Nieprzewidziane niespodzianki na etapie realizacji.

Pierwszy i drugi punkt to klasyczne błędy, na które znaczący wpływ ma Inwestor (przecież kto buduje dom bez planów i zatrudnia murarzy tylko dlatego, że są tani?) natomiast ostatni jest często problemem, który pojawia się niezależnie od sytuacji i nie mają na niego wpływu ani Inwestor ani zespół. O jakich niespodziankach mowa? Na przykład brak możliwości z powodów technicznych zrealizowania danej funkcjonalności tak jak to było założone w projekcie. Niestety czasami studium wykonalności realizowane na początku może takich sytuacji nie uwzględnić. Jak zminimalizować ryzyko niedoszacowania projektu?

• Zadbaj o dobrą dokumentację (punkt 2-gi artykułu);
• Oczekuj od zespołu IT precyzyjnego kosztorysu z uzasadnieniem kosztów części składowych. Kiedy zespół będzie taki kosztorys przygotowywał może również sam zauważyć swoje błędy i niedopatrzenia. Oczekuj dokumentu zawierającego listę wszystkich koniecznych do wykonania prac i usług (w wierszach), a w kolumnach czasochłonności każdego specjalisty zaangażowanego w dany element projektu. Dzięki temu sam zrozumiesz lepiej koszt łączny inwestycji;
• Przeprowadź studium wykonalności;
• Nie wierz w ekstremalnie krótkie czasy realizacji – np. jeśli przeprowadzasz przetarg, a 3 firmy oferują czas realizacji na poziomie 6 miesięcy, a czwarta firma chce zrealizować go w 2 miesiące – niech zapali Ci się czerwona lampka. Szybciej i taniej nie znaczy dobrze;
• Uważaj na tanich wykonawców – każdy dziś liczy skrupulatnie swoje pieniądze, ale czy lepiej wyrzucić w błoto 1000zł czy zainwestować 2000zł? Jeśli jesteś osobą nietechniczną nie ufaj tylko cenie, koszt tworzenia oprogramowania to w przytłaczającej większości praca, której nigdy nie zobaczysz, a która wpływa diametralnie na jakość końcową. Postaraj się, aby ekspert weryfikował spływające do Ciebie wyceny czasowe i kosztorysy uwzględniając wszystkie wskaźniki jakościowe.

#6 Niekończące się błędy

Otrzymujesz do wglądu projekt, okazuje się, że gdzie nie klikniesz to błąd. Zgłaszasz to zespołowi, zespół kolejkuje, naprawia, potem znowu testujesz i dostrzegasz gdzieś indziej błąd. I tak w kółko. Bardzo znany i powszechny problem. Niestety, jeśli tych błędów jest naprawdę dużo, mija kolejny miesiąc, a po załataniu jednego problemu pojawia się drugi, trzeci, czwarty – masz jedno wyjście. Powiedz stop. Zespół w takiej sytuacji najwyraźniej nie radzi sobie ze swoim własnym kodem. Zleć przeprowadzenie audytu oprogramowania aby poznać realny stan projektu od kuchni. Jeśli wynik audytu będzie negatywny – powinieneś wprowadzić bardzo daleko idące zmiany w projekcie i nie wahać się podejmować odważnych decyzji jak również tych związanych z całkowitą zmianą zespołu wdrożeniowego. Jak uniknąć takiej sytuacji? Ciężko odpowiedzieć jednoznacznie. Z doświadczenia mogę powiedzieć jedno – nie wierz, że da się coś zrobić bardzo tanio, bardzo szybko, bardzo dobrze i ogólnie „będzie Pan zadowolony”.

Podsumowanie

Problemy związane z opóźnieniami projektów są bardzo powszechne, jeśli przytrafiły się Tobie – nie załamuj się, wielu innych też przez to przechodzi. W większości przypadków, każdy projekt można uporządkować, wprowadzić na dobry tor i pomyślnie go ukończyć. Chciałbym również zaznaczyć, że omawiane problemy dotyczą tych popularnych spotykanych przy wszelkiego rodzaju start’upach. Realizacje o budżetach > 1mln zł (lub porównywalnie dużych), rządzą się już swoimi prawami i ich problemy są często odrobinę innej natury.