Jak uwalić projekt - Epilog

Ponieważ minęło trochę czasu, postanowiłem napisać obiecany epilog do poprzedniej historii.

Firma odkryła, że jest jakiś problem i zatrudniała Audytora. Audytor zajął się oglądaniem jak są prowadzone projekty, głównie na poziomie zarządzania. Audyt zajął około miesiąca i obejmował głównie rozmowy z project managerami i dyrektorem technicznym. Po miesiącu Audytor został nowym dyrektorem technicznym, natomiast dyrektor techniczny został architektem systemu (który przecież trwa już od ponad roku).
Projekt w tym czasie spokojnie sam posuwał się do przodu. Kierownictwo było zajęte głównie roszadami oraz przygotowywaniem papierków, negocjacjami z klientem oraz audytorem/nowym dyrektorem. Oznacza to, że tak na prawdę, nikt nie kontrolował jak idą prace. Co prawda programiści są kompetentni, więc tyle ile mogą robią, ale mimo wszystko kompletny brak kontroli jest nieco niepokojący.

W między czasie, zaczeło wychodzić (przynajmniej w gronie programistów), że nowi programiści (zdalni) w zasadzie niewiele wnoszą do projektu, a dodatkowo poświeca się im sporo czasu. Mimo to, zawsze można jeszcze pod-zlecić innej firmie część prac. O ile osobiście uważam, że jest to całkiem niezły pomysł, to w sytuacji w której dokumentacja jest na poziomie niskim (nie zgodnym z założeniami, nie dokładnym, nie aktualnym, itd.), nie da się ani dobrze oszacować czasu, ani nie da się po prostu pod-zlecić. Trzeba dodatkowo dać kogoś, w zasadzie na pełen etat kto będzie wyjaśniał wątpliwości. Mimo to, pod-zlecanie stało się nowym motto firmy. Żeby było lepiej, to zawsze można wziąć firmę po znajomości (a nie koniecznie po kwalifikacjach jej pracowników).

Miesiąc po objęciu stanowiska przez nowego dyrektora zaczęły się ruchy w poszukiwaniu czasu programistów. Pojawiły się duże znaki zapytania odnośnie urlopów oraz prośby zaplanowania go na później jeżeli tylko się da. Pojwaiły się również spotkania personalne z dyrektorem w zakresie: Co robisz, ile ci to jeszcze zajmie, kiedy planujesz urlop i jak ma on się do tego co masz zaplanowane do zrobienia. Mam jednak wrażenie, że mimo dobrych chęci, nie wnosiły one niczego w projekt. Oczywiście część programistów zajmowała się tylko komunikacją z zleceniobiorcami (w tym programistami zewnętrznymi) więc nie zajmowali się programowaniem. Co interesujące, dzięki temu ruchowi, prace spowolniły tempo.

Mniejwięcej w tamtym okresie sprawy przybrały jeszcze gorszy obrót, bo okazało się, że dwóch najbardziej doświadczonych programistów stwierdziło, że odchodzi. Ponieważ jeden miał na głowie bezpieczeństwo aplikacji a drugi silnik, to rozpoczęto działania w celu przekazania zadań związanych z silnikiem. Przekazanie bezpieczeństwa zostawiono na 2 ostatnie dni pracy. W końcu ten autorski rozbudowany system spełniający masę wymagań (często na wyrost) na pewno łatwo można przekazać...

Mniejwięcej w tamtym okresie okazało się również, że firma oficjalnie zawiesza projekt, ze względu na brak umówionej płatności ze strony klienta. W zasadzie, można by przyjąć, że to już był koniec projektu. Oczywiście firma planowała jeszcze wywiązać się ze zobowiązań kontynuując projekt wewnętrznie, ale oficjalnie projekt był zawieszony.
Klient oczywiście chciał, żeby projekt był kontynuowany, ale z punktu widzenia firmy, lepsza była ścieżka sądowa.

Na tym etapie rozpoczęto również zrywanie umów z podwykonawcami (czyli po około miesiącu).

Stan: Realizacja projektu w miarę obiektywnie 75% (ale pewne problemy nie zostały w ogóle podjęte), wg firmy 90 - 95%. Oficjalnie zawieszony.
Zespół: 3 programistów 2 osoby od kontaktów.
[EDIT] Zgodnie z komentarzem. Brak testów obciążeniowych, a funkcjonalność ta co jest, przetestowana pobieżnie, przez testerów którzy nie znają się na pisaniu testów i programowaniu (czytaj: Osoby które przeklikają aplikację).

Ta zupełnie teoretyczna historia mogła się wydarzyć na prawdę. Takich firm w Polsce jest wiele. Nie każdy, mimo tego, że potrafi wykonać mały produkt, powinien brać się za realizację dużych projektów. Dodatkowo, warto jednak zatrudnić specjalistów, w dziedzinach które dla dużych projektów są istotne, takich jak analitycy, architekci, specjaliści z danych dziedzin. Małe projekty nie wymagają tak silnego zaplecza. Można je realizować znacznie luźniej, uzupełniając pewne elementy w biegu. W przypadku dużych projektów, błędy w architekturze, dokumentacji, zarządzaniu kosztują firmy na prawdę duże pieniądze.

PS. Pozdrowienia dla tych, którzy jednak czytają tego bloga :)