Pesymizm wczesnoprojektowy

Zaczynając nowy projekt nadzieje i oczekiwania są wielkie - dzieło będzie wspaniałe, cudowne, wielkie, idealne i inne superlatywy. Jaka jest rzeczywistość - wie każdy, kto ukończył (lub chociaż próbował) przynajmniej jeden w miarę kompletny projekt. Zwykle po czymś takim powstaje post mortem projektu, opisujące co wyszło, co nie wyszło i starające się dociec dlaczego nie wyszło. Przy kolejnym projekcie postanowiłem odwrócić PERL-kota ogonem - zacząć od wstępnego szkicu prawdopodobonego post mortem (ułożonego na bazie moich doświadczeń przy poprzednich projektach).

Założenie jest wyjątkowo proste: przed napisaniem pierwszej linijki kodu, na etapie zbierania wymagań, założeń ogólnych itd. zastanowić się, co może być problemem. Biorąc pod uwagę założenia, osobę(-y) zaangażowane w projekt, częste problemy wypisać wszystko, co może powodować opóźnienia, błędy, znaczne trudności. Jako, że trudno mówić o szczegółach implementacyjnych, gdy projekt projektu (project design) jest na etapie zygoty, powyższe problemy oczywiście są bardzo ogólne. Jednak zakładając te dość prawdopodobne, wspomniana lista może być nawet bardzo długa.

Przykładowo, z często spotykanych przy amatorskich, jednoosobowych projektach problemów można wymienić:

• utratę zainteresowania projektem w pewnej fazie jego tworzenia - po prostu w pewnym momencie nie chce się tego pisać
• zagubienie projektowe - nie bardzo wiadomo, co należy pisać dalej, możliwości jest zbyt dużo, żeby wybrać coś konkretnego lub odwrotnie - dodanie czegokolwiek dodaje kilka miesięcy pracy bez efektów i testów
• skomplikowanie, przeprojektowanie, przesadzone wymagania
• brak jakiegokolwiek planu finalnego dzieła
• brak odpowiednich zasobów do użycia w projekcie
• różne, zależne od konkretnego obszaru projektu cechy jak np. brak serwera (WWW), problemy z wydajnością (gra, silnik), deadlock i synchronizacja (aplikacje wielowątkowe)

Wypisywanie pesymistycznych założeń jak najbardziej ma swój cel - przede wszystkim daje wczesną informację co może się nie udać. Oczywiście gdyby ta lista (szczerze przygotowana) miała się nie udać, nie byłoby sensu zaczynać projektu - byłby martwy od samego początku ;-) Wypisane potencjalne problemy i trudności oczywiście trzeba ominąć, a sam początek projektu jest świetnym momentem na zastanowienie się, jak ich uniknąć od samego początku. Oszczędza to pracy, nerwów i problemów na dalszym etapie.

Wiadomo, że nie wszystko uda się przewidzieć; wiadomo, że niektóre rzeczy zmieniają się w tracie powstawania projektu. Wspomniana lista problemów i ich rozwiązań na bieżąco powinna być aktualizowana - w ten sposób, docierając do końca projektu, mamy wypisane w punktach dość dokładne post mortem. Pozostaje tylko przejrzeć, nadać notatkom bardziej strawną formę i można publikować, mając niemal pewność, że nic nie zostało zapomniane, pominięte, przekręcone.