Na usta cisną mi się tylko słowa Grega Zorby "Jaka piękna katastrofa" , ale wybiegam odrobinę w przyszłość.
Postanowiłem się podzielić z szerszą publiką moimi przemyśleniami na temat zarządzania projektami informatycznymi, a przede wszystkim, jak nie powinno się prowadzić projektu. Ponieważ obowiązuje mnie tajemnica, będę się starał unikać szczegółów, a pewne fakty mogą zostać przeze mnie zmienione.
Uczestniczę obecnie w projekcie który do małych nie należy a jego wartość wyceniona została na sumę, której w LOTTO z reguły wygrać się nie da. Projekt zawiera bardzo wiele powiązanych ze sobą systemów, zaczynając od CRM poprzez CMS, GIS, oraz zarządzanie bazą danych (w tym graficzną jej reprezentację) z poziomu GUI. Aplikacja pozwala na pracę w przeważającej części za pomocą przeglądarki. Z samego zakresu technologii, jak również jego wartości jasno wynika, że projekt do małych nie należy. Jak na projekt tej wielkości przystało, projekt jest zarządzany zgodnie z jedną z bardziej popularnych metodyk (jednak tylko na styku z klientem). Czas realizacji: około 1,5 roku + utrzymanie.
A teraz prosty przepis, jak taki projekt uwalić:
Na początek mamy podpisanie umowy, w ramach której obiecujemy klientowi gruszki na wierzbie. Przy czym, klient sam nie do końca wie co mu jest potrzebne, więc wymaga jak najwięcej się da. Nie ma przy tym sensu sprawdzenie, czy wymagania w ogóle mają sens, lub czy się wzajemnie nie wykluczają. Klient w końcu nigdy w życiu nie dał by sprzecznych ze sobą wytycznych, nawet jeżeli jest kilkanaście osób które ze strony klienta mogą decydować i wspólnie podejmować decyzje. Dodatkowo, ponieważ klient wymaga wstępnego projektu, można wziąć projekt innego systemu i trochę przystosować. Ponad dwustu tabel w dokumentacji bazy danych i tak nikt nie będzie czytał. W zasadzie, jak się głębiej nad tym zastanowić. To te tabele można żywcem wziąć, po co to przystosowywać, dopisać tylko do tego jakąś otoczkę.
Kolejnym krokiem jest zebranie wymagań. Ten krok można w zasadzie pominąć, bo przecież wymagania zostały już w zasadzie zebrane w ramach umowy, a tylko doprecyzować jak to w zasadzie ma być w ramach analizy.
A więc przystępujemy do analizy. Oczywiste jest, że w tej fazie, osoby zbierające wymagania nie muszą mieć ani doświadczenia, ani śladowego wykształcenia informatycznego. W końcu system który będzie wykonywany można zaplanować całkowicie w oderwaniu od sprzętu czy oprogramowania. Jeżeli przypadkiem okazuje się, że nie można do końca zebrać wymagań, to należy w dokumentacji wpisać jakieś ogólniki - uzupełni się w ramach projektu technicznego. Ponieważ zespól zbierający te informacje nie musi być duży, w zasadzie wystarczy 5 osób, to może się okazać, że będzie problem z dotrzymaniem terminów. Na szczęście, klient wymaga więcej, niż było podpisane w umowie, w związku z czym można podpisać aneks do analizy. Osób co prawda więcej nie będzie, ale zawsze można dłużej pisać. Klient niestety jest cwańszy, bo co prawda zgadza się na przesunięcie terminu oddania analizy (z aneksem), ale nie pozwala na przesunięcie terminu oddania projektu technicznego, którego realizacja ma być wykonana w terminie, a co najwyżej zostanie uzupełniony później o aneks. W ten oto sposób, aneks zostaje ze sporymi bólami oddany w terminie, co wypada w połowie czasu przewidzianego na oddanie projektu technicznego.
Stan:
Połowa czasu przewidzianego na projekt techniczny.
Analiza - po łepkach, nie kompletna a miejscami sprzeczna.
Aneks do analizy - tak samo
Projekt Techniczny -brak
A więc teraz można przystąpić do realizacji projektu technicznego. Najlepiej jak go zrobi jedna osoba techniczna. Osoba techniczna, to zresztą odrobinę nadużycie semantyczne. w/w osoba, to programista, z 3,5 letnim doświadczeniem, nawet dość szerokim, ale twierdzący, że jego najsłabszą stroną są bazy danych. A więc najlepiej będzie, jeżeli to właśnie ta osoba zaprojektuje bazę danych. Jednak, aby trochę życie ułatwić część bazy danych już jest gotowa i nie należy jej dotykać. Wynika to z faktu, że są gotowe narzędzie wypełniające tą bazę. Co prawda nikt tak na prawdę nie wie jakie to narzędzia, w jakim języku są napisane ani czy ta struktura która jest to właśnie z tych narzędzi, ale są. Oczywiście programista kompletnie nie jest wprowadzony w tematykę GIS, na której całość aplikacji się opiera. Wszystkie osoby które mają jakiekolwiek pojęcie są oczywiście zajęte pisaniem aneksu do analizy, a programista ma wytyczne "zrób projekt techniczny, tam jest analiza". W razie pytań dostaje odpowiedź "wszystko jest w analizie", co oczywiście załatwia sprawę. Po zakończeniu aneksu do analizy (przypominam w połowie trwania projektu technicznego), okazuje się, że w sumie nie wiadomo dlaczego, ale projekt techniczny jest w lesie, klient dodatkowo poza modelem danych wymaga jeszcze projektu interfejsów oraz przypadków użycia, a dodatkowo to co jest, nie jest zgodne z aneksem do analizy, który przecież już od 3 dni leży w repozytorium. Programista zostaje należycie opieprzony za jego niekompetencję a wiec sprawa jest załatwiona. Wprawiony team od analizy siada i wspólnymi siłami oraz posiłkując się dokumentacją z poprzedniego projektu generuje setki stron dokumentów technicznych. Co prawda są pewne zgrzyty, bo okazuje się, że chyba jednak nie wszystko jest w analizie, główny standard wymiany danych jest nie dopracowany (mimo, że zatwierdzony przez klienta). W związku z tym pewne elementy nie zostają doprecyzowane. Ponieważ termin realizacji projektu technicznego stoi pod wielkim znakiem zapytania atmosfera jest bardzo nieprzyjemna i napięta, ale praca wre.
Wreszcie następuje przełom. Okazuje się, że klient zgodził się na rozszerzenie. Oznacza to, że mamy 1,5 miesiąca więcej na wykonanie projektu technicznego. Co prawda klient wymaga teraz trochę więcej i w ramach rozszerzenia przemyca pewne funkcjonalności, ale mimo to są szanse się wyrobić, szczególnie, że projekt interfejsów i przypadki użycia są w powijakach. Jest jednak mały haczyk, polegający na tym, że równolegle należy rozpocząć już implementację, bo projekt techniczny do rozszerzenia idzie jakby torem obok.
To jest dobry moment na rozpoczęcie rekrutacji zespołu który ten projekt zrealizuje. A więc na dobry początek należy stwierdzić ile osób potrzeba. Ponieważ mamy kupę czasu (i nie są znane pełne wymagania), programista szacuje, że potrzeba około 6 osób od zaraz, do samej części CRM, CMS aby projekt zrealizować, około 5 do GIS. Oczywiście programista nie wie co mówi, ale rekrutacja się rozpoczyna. Po dwóch miesiącach rekrutacji są w zespole programistycznym już 3 osoby (w tym programista, który cały czas zajmuje się projektem technicznym). Od tego momentu, programista staje się team leaderem, ponieważ jest osobą techniczną która ma najbardziej całościowy pogląd na cały projekt (i jedyną która ma jakikolwiek pogląd od strony technicznej).
A więc po 2 miesiącach stan jest taki, że zostaje wykonany szkielet aplikacji oraz wypracowane zostają standardy kodowania w wybranych (nowych) technologiach. Warto nadmienić, że cały zespół części technologii uczy się od zera. W końcu jak by przynajmniej jedna osoba znała technologię....
Myślę, że to jest moment, w którym możemy określić, że tak na prawdę (z 2 miesięcznym opóźnieniem) rozpoczęła się faza implementacji.
Status:
2 miesiące do tyłu
3 osoby w zespole (zamiast 6).
0 osób w zespole GIS (zamiast 5).
Projekt techniczny bazujący na kulawej analizie wykonany przez zbyt małą grupę ludzi nie mających o tym zielonego pojęcia. - Sumarycznie 1,5 tyś stron.
Projekty Interfejsów taki, że każdy interfejs nie jest powiązany z żadnym innym (i nie przystaje do technologii).
Przypadki Użycia w dużej części nie są powiązane z interfejsami a dodatkowo część z nich jest pozostałością z innego systemu.
Ponownie zostaje zadane pytanie ile osób potrzeba - odpowiedź - na dzień dzisiejszy 7 w samym zespole do CRM, CMS. Na zapotrzebowanie do innych zespołów nie ma odpowiedzi, ponieważ prace nie są jeszcze na ten moment zaplanowane. Miesiąc później zespół liczy już 5 osób. Liczba ta utrzymuje się przez kolejne miesiące. Kierownictwo ma coraz większe zastrzeżenia do opóźnień i wielokrotnie stara się otrzymać od zespołu informację kiedy nadgonią opóźnienia. Warto nadmienić, że żadne nadgodziny, a przynajmniej płatne nie wchodzą w grę.
Mijają 3 miesiące i okazuje się, że jednak opóźnienia zamiast maleć rosną. Winny jest team leader który nie potrafi doprowadzić do zmniejszenia opóźnienia. Drań jeden dodatkowo próbuje się bronić, mówiąc, że od początku mówił, że potrzeba 7 osób a nie 5. W zespole od GIS również nie dzieje się dobrze. Zespół nie dość, że jest między dwoma projektami, to jeszcze wredny team leader zespołu GIS postanowił odejść z pracy. Coś mówił o burdelu w zarządzaniu, wymagał jakiś procedur i nie pozwalał na to, żeby jednej osobie zlecało pracę 5 osób w ciągu jednego dnia, ale szefostwo wie, że i tak tylko wprowadzał niepotrzebny zamęt w projekcie i w sumie lepiej że go nie będzie.
Mijają 2 tygodnie. Klient zaczyna się niepokoić stanem prac i twierdzi, że jak prace nie zostaną nadgonione, to będzie trzeba wprowadzić plan naprawczy. Zarząd, a za nim kierownictwo projektu nie zgadzają się jednak na to, żeby już wprowadzać plan naprawczy, w związku z czym zespół dostaje polecenie zrobić tak, żeby następna prezentacja aplikacji przeszła bez problemów. Team leader informuje kierownictwo, że jedyną możliwością aby to zrobić, to będzie zrobienie kompletnej wydmuszki (mockupu), już nie tak jak do tej pory, że jest masa błędów, ale generalnie jest, tylko całkowitej wydmuszki. Propozycja zostaje przyjęta.
Mijają 3 tygodnie. Udało się. Klient jest zadowolony ze zwiększonych postępów pracy. Co prawda w czasie prezentacji następuje spora awaria bazy danych więc nie wszystkie funkcjonalności można pokazać, ale ogólnie prezentacja kończy się sukcesem. Co prawda programiści zostają przedstawieni jako banda niekompetentnych... (oszczędzę sobie szczegółów), ale prezentacja przeszła dobrze.
Z bliżej nie określonych powodów w następnym tygodniu prace jakoś nie idą za szybko.
Są decyzje. Teraz już nie ukrywamy problemów. Można zacząć naprawiać błędy.
Minął kolejny miesiąc. Prace co prawda nie postępują, ale aplikacja zaczyna powoli działać. Zaczynają się co prawda problemy z określeniem postępów prac. Tym razem przy wyznaczaniu harmonogramu prac nikt już się nie konsultuje z team leaderem, bo w końcu tak spieprzył poprzedni harmonogram prac, że nie ma to sensu. Aby zapewnić pełną kontrolę nad źle zarządzanym projektem, tematem zajmuje się od tej pory project manager. Co prawda team leader niby nadal jest team leaderem, ale wszelkie podziały prac i decyzje są dokonywane poza nim.
2 tygodnie później, po ostrej awanturze za powolne wykonywanie obowiązków programisty, team leader (teraz już 7 osobowego zespołu) rezygnuje ze swojego stanowiska. Nikt inny nie zostaje wyznaczony do tej (nikomu nie potrzebnej) roli.
Stan na dzień:
-2 miesiące względem pierwotnego harmonogramu.
- +0 miesięcy względem harmonogramu z planu naprawczego (przy czym wg. starego team leadera już pierwszy miesiąc jest niewykonalny, ale jego nikt o zdanie nie pyta)
-7 osoób w zespole, z czego 2 osoby mają pracować zdalnie
- brak team leadera
- brak nałożonych kar ze strony klienta (ale są już odpowiednie zapisy odnośnie planu naprawczego)
C.D.N.
