Szef pyta: „to na kiedy możemy puścić tę aplikację do ludzi”. W odpowiedzi od zespołu IT najpierw słyszy „Eeee, aaaa… hmm… 3 czerwca 2012″… Potem wszyscy spotykają się na sylwestra 2012 i prezes życzy zespołowi aby w ogóle skończył opóźnione już przedsięwzięcie. Dlaczego projekty IT prawie zawsze są w tyle z harmonogramem? Istnieje panaceum?
Kilka lat pracowałem jako project manager IT w korporacji (w PMO), firmie developerskiej i agencji interaktywnej. Prowadziłem projekty IT, które pomagały w sprzedaży, optymalizacji kosztów oraz minimalizacji ryzyk prawnych. Moim zadaniem było takie zarządzanie ludźmi, aby doprowadzić m.in. cele produktowe projektu do końca (implementacja systemu bądź zmian w istniejącym oprogramowaniu). Po wynegocjowaniu z Komitetem Sterującym założeń projektu, w ramach trójkąta ograniczeń, kompletowałem zespoły: wykonawcze, jakościowe, doradcze, itd. W połowie projektu okazywało się, że każdy w zespole ma zegarek, który działa z inną prędkością 🙂
Projekty IT – opóźnienie jest OK?
W projektach, które prowadziłem duże koszty (kasa, zasoby ludzkie) i rozbuchany do granic możliwości zakres rzadko były problemem dla beneficjentów projektu. Tak mi się trafiało. Jednak na kolejnych spotkaniach informujących o statusie projektu IT i planowanym terminie jego skończenia, „góra” dostawała białej gorączki, ja też. Każdy „status” był kolejną aktualizacją harmonogramu (opóźnienie).
Trochę się uspokoiłem kiedy zacząłem jeździć na konferencje PMI oraz IPMA i tam prelegenci ze stoickim spokojem prezentowali globalne statystyki, gdzie zaprezentowane są projekty IT w kontekście opóźnień. Okazuje się, że 90% z nich ma istotne zmiany w harmonogramie ze szkodą dla Właścicieli Biznesowych. Do tego ponad 40% projektów (nie tylko IT) jest przerywanych i rzadko dzieje się to ze względów koniunkturalnych, a częściej operacyjnych.
Jednak po paru latach raportowania opóźnień miałem dość. Zacząłem się zastanawiać o co chodzi w tym status quo? Gdzie radość z mojej pracy, w dostarczaniu ludziom potrzebnych im rozwiązań? Czy kiedyś uda mi się zaraportować aktualizację harmonogramu, w którym poinformujemy Komitet, że aplikacja zostanie wdrożona wcześniej niż zakładaliśmy?
Zespół ekspertów – czas to rzecz względna
Jako powody opóźnień, które odnotowują projekty IT, podaje się takie przyczyny:
- Zewnętrzne czynniki
- zmiany na rynku i brak dalszego uzasadnienia biznesowego dla kontynuowania projektu,
- zmiany prawne, restrukturyzacja firmy, czynniki kulturowe…
- Wewnętrzne czynniki
- brak metod szacowania czasu wykonania („no zajmie to nam 1 miesiąc… albo 1 rok”),
- brak motywacji zespołu („ten projekt jest bez sensu”),
- brak myślenia systemowego („mam w dupie co robi drugi zespół projektowy”),
- brak zarządzania priorytetami („zróbcie nam wszystko”),
- słabe umocowanie władzy PM-a w organizacji („gadaj z moim kierownikiem”),
- niewłaściwy sposób zgłaszania wymagań oraz ich dokumentowania przez klienta wewnętrznego (działy „biznesowe” organizacji) lub zewnętrznego (zlecenia). („eee… fajna ta aplikacja, ale nam chodziło o co innego”).
O każdym z punktów można napisać elaborat. Ja skupię się na ostatnim. Czy nigdy nie spotkałeś(aś) się z sytuacją, że razem z klientem lub wykonawcą IT ustalacie zakres, tworzycie jakąś mniej lub bardziej formalną specyfikację, a po implementacji jesteście negatywnie zaskoczeni? Wystarczą same opowieści znajomych. Kto się zetknął z zespołową realizacją jakiegokolwiek oprogramowania (w tym internetowego) wie o czym mówię.
Wy po chińsku, my w Suahili
Diabeł tkwi w komunikacji osób programujących i zlecających (tzw. Biznes). Technologia ma to do siebie, że nie każdy ją zna. Nieumiejętne przenoszenie na papier (przez Biznes) swoich oczekiwań powoduje ich błędną interpretację przez programistów. Powstaje coś co rozmija się z oczekiwania Biznesu. Wtedy zgłaszane są poprawki, również niezrozumiałe dla drugiej strony, a takie ciągłe zmiany kosztują czas. Wtedy opóźnienie mamy gotowe.
Czasami dział IT, poprzez bierne zachowanie w projekcie, jasno pokazuje, że czeka na specyfikację i że nie ma kompetencji („naprawdę?”) do aktywnego włączenia się w proces tworzenia dokumentu wymagań i projektu zmian. W wielu firmach to pewien fakt, jednak jest on patologią w najczystszej postaci, bo każdemu pracownikowi i jednostce powinno zależeć na osiąganiu celów biznesowych firmy.
Także po stronie Biznesu nie jest wesoło. Nawet jeśli PM stworzy wspólny słownik dla komunikacji (w dużych projektach) to nie każdy ekspert-indywidualista ma ochotę na zmianę swoich nawyków w imię dobra zespołu. Pojawiają się często osoby, które bardziej stawiają na lans i spotkania towarzystwa wzajemnej adoracji. Jeśli moje prośby nic nie dają, szybko usuwam takiego pacjenta z zespołu, choćby nie wiem jak wielką wiedzę posiadał.
Do tego permanentna zmiana opisu wymagań przez Biznes („hmm.. co ja tak naprawdę chcę?”) śni się po nocach Dyrektorom IT.
Jak temu zaradzić?
Po pierwsze na podstawie własnych doświadczeń i nabytej wiedzy, zauważyłem, że im większa firma i zespół projektowy, tym trudniejsza komunikacja. Prosta zależność, gdzie projekty IT odczuwają ją wyjątkowo boleśnie. Masa kanałów informacyjnych i większe prawdopodobieństwo tworzenia się szumów informacyjnych oraz „przekręcania treści”. Prosta zasada: im większy zespół tym bardziej musisz sformalizować projekty IT aby jako tako trzymać ludzi w ryzach. Inaczej nie zapanujesz i przesunięcie terminu zakończenia projektu będziesz liczył w setkach procent.
Jeśli natomiast zespół nie przekracza 20-30 osób (większe po części też), włącznie z klientami, a opóźnienia pojawiają się nadal, poniżej kilka moich rad (których nie znajdziesz w podręcznikach PRINCE2 czy PMI):
- Wyznacz analityka systemowego – albo jako PM sam nim bądź. Analityk systemowy ma za zadanie spisać wymaganiami Biznesu, tak aby były one w formie zrozumiałej dla programistów. Jest on kluczowy w projektach IT jeśli chodzi o komunikację. Jeśli zna podstawy UML, ma trochę zdrowego rozsądku to uda mu się zarzuć pomost pomiędzy światem IT i Biznesu. Wtedy wszyscy się dogadają i uśmiech wróci ludziom na twarz. Jednak ze względu na koszty firmy często przemilczają temat. W małym startupie się nie zastanawiaj, bierz sprawy w swoje ręce 🙂
- Pomagaj estymować czas – rzadko który programista lubi deklarować terminy wykonania. Jednak z moich doświadczeń wynika, że 80-90% komponentów jest używanych ponownie i są jedynie modyfikowane. Staraj się promować budowanie APIs, hermetycznych i re-używalnych komponentów. Do tego warto trzymać na jakiejś liście wykonywane „user stories” i wpisywać po zakończeniu implementacji rzeczywisty ich czas wykonania. Przegląd takiej historii naprawdę pomaga PM-owi i programiście w lepszym szacowaniu zadań. Nie polecam za to bardzo sformalizowanych metod estymacji takich jak SLOC czy metoda punktów funkcyjnych. Jedna firma konsultingowa karmiła nas tymi bajkami kiedyś w korpo i rezultaty były mało użyteczne.
- Marginesy błędów estymacji – to ostatnia deska ratunku, kiedy zakładasz, że każdy programista myli się i każdemu z nich przypisujesz jakąś wartość współczynnika takiej pomyłki. Nie lubię takiego podejścia bo zakłada ono, że niektóre osoby nie są na tyle dojrzałe aby brać odpowiedzialność za swoje deklaracje.
- Stosuj iteracje i dawaj feedback – to jedne z podstaw manifestów Agile i XP. Stosowane w ramach nich metody takie jak Scrum pozwalają poprzez iteracje zaplanować wiele punktów kontrolnych i minimalizować ilość niedopowiedzeń i pomyłek co do zakresu tworzonego projektu.
- Buduj relację pomiędzy IT i Biznesem – to już kwestia kultury organizacji, która unika mówienia o innych działach czy klientach „że to banda idiotów”. Takie podejście to pierwszy stopień do braku zrozumienia drugiej strony i budowania czegoś czego nie rozumiemy. Projekty IT są robione przez ludzi i dla ludzi.
Ja dzięki takim doświadczeniom i wnioskom przeniosłem się do mniejszej firmy gdzie „mam” zespół kilku osób. Tutaj projekty IT rzadko zaliczają opóźnienia, głównie dzięki szybkiej i jasnej komunikacji. Bliższe relacje pozwalają być świadomymi po co tu jesteśmy i dlaczego to robimy.
A jakie są wasze doświadczenia z harmonogramem jeśli chodzi o projekty IT? 🙂