Czas jest ciągle największym wrogiem ludzi tworzących oprogramowanie. To zagrożenie jest często wzmagane przez nieodpowiedzialny marketing.

To, jak przebiega proces tworzenia aplikacji, w większości przypadków jest głęboko skrywaną tajemnicą firmową. Widoczny jest natomiast efekt w postaci działania (lub niedziałania) systemu. Wystarczy przeczytać doniesienia prasowe, poskładać w całość kilka faktów i możemy samodzielnie wyciągnąć wnioski odnośnie tego, jak źle zarządzać projektem IT. Nie ma tu znaczenia, czy tworzona jest aplikacja internetowa, czy system do obsługi banku.

Zdążyć przed terminem, to nie lada zadanie. Sam projekt informatyczny jest w wielu przypadkach firmą w firmie. Poziom skomplikowania jego struktury jest wprost proporcjonalny do poziomu złożoności tworzonej aplikacji. Składają się na niego ludzie, którzy tworzą oprogramowanie i ci, którzy je testują. Wszyscy oni wyposażeni są w komputery i niezbędne im oprogramowanie. Do normalnego funkcjonowania potrzebują wszystkiego: od spinaczy, poprzez powierzchnię biurową, po automat do kawy i profesjonalną obsługę HR.

Aby jednak potrafili skierować swoje wysiłki w określonym kierunku, potrzebny jest kierownik projektu, człowiek, który całe przedsięwzięcie poprowadzi. To on buduje zespół i bierze odpowiedzialność za każdą osobę z osobna. To na nim spoczywa odpowiedzialność za prawidłowe zaplanowanie, zaprojektowanie, zaimplementowanie, przetestowanie i w końcu wdrożenie oraz utrzymanie systemu IT. On również odpowiada za końcowe, domniemane, niepowodzenie projektu.

Planowanie i projektowanie

Opóźnienia projektów IT są tak powszechne, że nieomal stały się rutyną. Nikt zapewnień, że wszystko można zrobić na czas, nie traktuje poważnie. Standardem stało się precyzyjne zaplanowanie projektu i późniejsze pomnożenie tego przez mityczne "x2". Oczywiście, nijak ma się to do kalkulacji i wyliczeń. Prawdopodobieństwo bierze tu jednak górę. Ci, którzy mnożą razy dwa, mają większe szanse na sukces niż ci ślepo wierzący w nieomylne planowanie. To podwojenie budżetu czasowego i zasobowego uwzględnia wszystko, co nieprzewidywalne i nieprawdopodobne, ale co spełnia się jak amen w pacierzu. Ci menedżerowie, którzy opowiadają o nieudanych projektach zazwyczaj przyczyn dopatrują się w zbyt optymistycznych planach i w nieoczekiwanych problemach. Ktokolwiek założył, że w jeden rok uda mu się zbudować od podstaw złożony system informatyczny do obsługi internetowej, musiał zmierzyć się z realiami. Jedną z nich jest fakt, że bez względu na złożoność systemu, uda się jedynie częściowo zaimplementować jego funkcjonalność. Kwestią szczęścia jest, jak duża część to będzie...

Czy w roku 2009, rozpoczętym pod hasłem kryzysu, możemy pozwolić sobie na niedoszacowanie i nieprecyzyjne zaplanowanie kosztów wdrożenia struktury informatycznej? Jak pokazują znane przykłady - możemy. Musimy jednak, jako poważne ryzyko, uwzględnić współczynniki porażki. Ilu klientom z przyczyn technicznych nie udało się skorzystać z usług naszego systemu? Ilu z nich odwróci się od naszej marki tylko dlatego, że damy im oprogramowanie, z którym praca popsuje im dzień? Niestety, kalkulacja ryzyka, czy zarządzanie kryzysowe nie jest u nas standardem w prowadzeniu projektów.

Zazwyczaj polskie firmy na koniec przedsięwzięcia zakończonego klapą lub wdrożenia jedynie części funkcjonalności unikają przyznania się do błędów. Zamiast tego, zaklinają rzeczywistość. W takim przypadku pozyskanie rzetelnych informacji o przyczynach problemu, planach jego wyeliminowania, czy też poniesionych stratach graniczy z cudem. Wygląda na to, że kadra kierownicza wychodzi z założenia, że niemówienie o kryzysie spowoduje, że ludzie go nie zauważą. Firma zamiatająca porażkę pod dywan nie tylko nie daje innym niepowtarzalnej okazji uczenia się na błędach, ale sama de facto na błędach się nie uczy. Zamiast "zanalizujmy, zrozumiejmy, zapamiętajmy", częściej można usłyszeć "zapomnijmy". Daje to praktycznie gwarancję powtórzenia się sytuacji w przyszłości.

Doświadczenie pokazuje, że nawet w ciężkich czasach można zarabiać. Trzeba jednak wiedzieć, jak odpowiednio się do tego przygotować. Czynnikami sukcesu są tu na pewno innowacyjność rozwiązań, dbanie o wysoką jakość i świadomość kosztów. Najpierw trzeba przygotować produkt, a dopiero potem informować o tym dziennikarzy. W innym przypadku efekt projektu dostarczony klientom udowadnia, że zapowiedzi to w rzeczywistości kolejne hasła reklamowe z gwiazdką.

Dopiero perspektywa czasu pozwala nam realnie spojrzeć na nieudany projekt. Widać, że plan musiał być niemiłosiernie optymistyczny i absolutnie nie do zrealizowania. Brakowało w nim wielu elementów. No, i niestety, sprawdzają się Prawa Murphiego - zawodzi wszystko, co może zawieść.

Implementacja? Testowanie? Wdrożenie!

Kiedy na rynek wchodzą interesujące produkty IT, organizuje się zamknięte lub otwarte sesje testerskie. W przypadku testów alfa niewielka grupa ludzi ma okazję pracować ze wstępnymi wersjami oprogramowania. Kiedy kierownik projektu stwierdzi, że aplikacja nadaje się już do pokazania na forum publicznym, pojawia się wersja beta. Zazwyczaj jest to w miarę stabilna aplikacja dostępna dla ogółu użytkowników. Daje to niesłychaną okazję, by zanalizować końcowe fazy tworzenia oprogramowania. Z jednej strony, mamy praktycznie końcowy produkt, z drugiej - posiadamy oficjalną datę premiery. Możemy wtedy obserwować proces ścierania się dwóch sił. Czy błędy w wersji testowej zostaną zaakceptowane, czy może data premiery zostanie przesunięta?

Oczywiste jest, że produkty w wersjach alfa i beta mają swoje poważne wady. Użyteczność interfejsu może być różna od tego, czego się spodziewamy. Wydajność może kuleć, gdyż proces optymalizacji kodu pod kątem szybkości zazwyczaj następuje w końcowych fazach projektu. Ważne jest, aby problemy dostatecznie wcześnie zidentyfikować, wyeliminować i uchronić się przed ewentualną katastrofą w przyszłości. Proste analizy pokazują, iż błędy wykryte we wczesnych fazach implementacji kosztują dużo mniej, niż te, wykryte w czasie funkcjonowania systemu. Taka zapobiegliwość może uchronić projekt przed opóźnieniami we wdrożeniu.

Testowanie przy użyciu wolontariuszy jest złożonym podprojektem projektu głównego i musi być równie dobrze przygotowane. Wytrawni obserwatorzy zwrócą uwagę na to, czy poprawki programistyczne są wprowadzane na bieżąco i rozwiązują kłopoty funkcjonalne. Znajdując i zgłaszając defekt w aplikacji, możemy zobaczyć chociażby jak przebiega proces naprawy błędu.

Firmy, które na reklamę swoich produktów na bilbordach, portalach, w telewizji wydają miliony, powinny dużo wcześniej identyfikować i naprawiać pojawiające się problemy. W związku z dużymi budżetami reklamowymi, my jako klienci poddajemy je surowszym osądom. Wymagamy lepszej jakości, użyteczności i wydajności. Wielokrotnie mamy rację, ale czasami krytykujemy jedynie dla samej krytyki. W tym obszarze niekoronowanym królem jest środowisko Internautów, które jest chyba najbardziej surowym recenzentem. Czasami, patrząc na wpisy na forach można odnieść wrażenie, że od czasu powstania komputera nie powstała ani jedna dobra aplikacja. Może za wyjątkiem gry Tetris. Założę się jednak, że jakby dobrze poszperać, to również ta prosta aplikacja ma rzeszę swoich zagorzałych przeciwników.

Jeśli relacja między budżetem reklamowym a jakością aplikacji jest zbyt duża, następuje oczywisty bunt potencjalnych klientów. Każdy wie, że w uproszczeniu cena końcowa produktu, to koszt jego wytworzenia plus nakłady na reklamę. W przypadku kiedy produkt jest drogi, a jego jakość marna, mamy świadomość, że ulegamy potężnej dawce marketingowej presji, aby kupić bubel. Nie zakładamy jednak, że firmy chcą nas oszukać. One po prostu zbyt optymistycznie założyły wskaźniki, które wydają się oczywiste z perspektywy czasu. Winę za to, że zabrakło kilku miesięcy na zaimplementowanie pełnej funkcjonalności, firma może zrzucić na serię niefortunnych zdarzeń. Niestety, ktoś za to musi zapłacić. Gdy firma ma pecha, będzie musiała straty pokryć z własnej kieszeni. Jeśli ma szczęście, to na pewno zapłaci za to klient.

Premiera

Ostatnie dni do premiery to zawsze jeden z najboleśniejszych okresów w cyklu życia całego projektu. Programiści praktycznie śpią w firmie, asystenci dbają, żeby nie zabrakło kawy, a managerowie nerwowo kręcą długopisami w palcach. Data premiery została podana, nie ma już odwrotu. Produkt musi się ukazać. Sztandarowym przykładem nieprzekraczalnego terminu jest tzw. biznes świąteczny. Kierownictwo najwyższego szczebla nie przejmuje się rzeczywistym czasem potrzebnym do stworzenia produktu. Ma być on gotowy na czas Bożego Narodzenia, bo to okres, kiedy sprzedaje się wszystkiego najwięcej.

Oficjalna premiera to papierek lakmusowy powodzenia projektu. Jesteśmy świadomi, że produkt ma "pewne wady", ale został dobrze zareklamowany. Firma liczy więc na zyski. Co z tego, że tydzień temu, podczas ostatniej integracji okazało się, że nic nie działa i tylko cud może spowodować, że dotrzymamy terminu. Cud się musi zdarzyć. To, że obcięto funkcjonalność, zrezygnowano z testów, lub że kierownik projektu spał w ostatnim tygodniu 5h, nie ma już znaczenia. Raz uruchomiona maszyna reklamowa nie może zostać zatrzymana przez tak nieistotny szczegół jak niefunkcjonujący poprawnie system informatyczny. Pojawiają się pierwsze spoty, reklamy i plakaty. Kampania musi być perfekcyjna i ma podnieść świadomość marki. Teraz liczą się pozytywne opinie dziennikarzy i rekord sprzedaży w pierwszym tygodniu. Informatyka ma prawo zawieść, ale nie może zawieść reklama.

Silna reklama może być jednak gwoździem do trumny przedsięwzięcia. W przypadku projektów internetowych niedopracowana infrastruktura może nie wytrzymać obciążenia tysięcy skuszonych klientów. Może nawet chcą oni wydać pieniądze na nasz produkt, ale skutecznie ich do tego zniechęcamy niedostępnym systemem. Z perspektywy klienta, to może nawet i dobrze. Nie kupi słabego produktu, oszczędzi sobie nerwów.

Błędy się sypią. Następuje klasyczny rozdźwięk między rzeczywistością a pobożnymi życzeniami. Z perspektywy użytkownika systemu wszystko nie działa, z punktu widzenia dostawcy wszystko jest w porządku. Wmawia się klientom, że to właśnie oni są największymi pechowcami na świecie, bo przecież wszystko działa. Co z tego, że podłączając się do strony o podanym adresie otrzymujemy komunikat "Serwer zbyt długo nie odpowiada". Świetnie sprawdza się tu rzesza konsultantów od przyjmowania reklamacji - "To tylko chwilowy kłopot. Mała poprawka dokonywana przez IT. Proszę spróbować za 15 minut". Paradoksalnie - każda kolejna złotówka wydana na reklamę przekłada się na zainteresowanie produktem i dobija strukturę informatyczną. Firma staje się ofiarą swojej udanej akcji promocyjnej.

Dla większości klientów przygoda zakończy się zapewne rezygnacją albo oczekiwaniem na nową wersję oprogramowania. Oczywiście nie dotyczy to dużych klientów biznesowych, których stawia się pod murem i każe wziąć, co jest. Pół biedy, jeśli umowy są tak skonstruowane, że można dostawcę oprogramowania obarczyć konsekwencjami. Jak pokazują przykłady, można jednak zaimplementować i niedziałający system.

Niewiele organizacji jest w stanie przyznać się do błędu, czy też zgodzić się z opiniami innych, że wykonali falstart. Inwestorzy tracą pieniądze. Z przymrużeniem oka możemy powiedzieć, że na szczęście tylko pieniądze. Co mogłoby się wydarzyć, jeśli od tej zaimplementowanej aplikacji miałoby zależeć ludzkie życie?

Do powodzenia przedsięwzięcia informatycznego potrzeba czegoś więcej niż tylko dobrej reklamy, potrzebna jest symbioza marketingu i technologii. Te dwa obszary muszą się uzupełniać, a nie zwalczać. Nie może być tak, że przez reklamę nakłada się na projekt nierealne terminy.