Agile jest zawsze tańszy

Data: 2015-02-09
Autor: Sebastian Konkol
Agile jest zawsze tańszy

Seria projektów, w jakich brałem udział przez ostatnie dwa lata, stanowi dowód takiej tezy. A jeśli nie dowód, to jest przynajmniej bardzo zasadnym powodem dla głębokiej refleksji na temat pomiaru finansowych aspektów realizacji projektów informatycznych.

Postawię taką roboczą tezę, że celem projektu informatycznego jest wdrożenie rozwiązania, które zapewnia realizację wartości biznesowej. Napisałem „tezę”, gdyż – obserwując różne projekty – czasami trudno dopatrzeć się takiego celu w prowadzonych działaniach. Czasami jest to wytworzenie systemu informatycznego bez wdrożenia, czasami realizacja jakiegoś kontraktu, a czasami nawet… ale to już inna historia. Jeśli jednak teza ta jest zasadna, to celem jest realizacja jak największej wartości biznesowej przy jak najlepszym wskaźniku osiąganego wyniku do poniesionych nakładów.

Bardzo łatwo jest o tym dywagować a posteriori, po zakończeniu projektu. Kłopot polega jednak na tym, że na tryb realizacji projektu trzeba się zdecydować (i umówić, często z wieloma partnerami) a priori, na samym początku tegoż projektu. Jak to w każdym projekcie, przedsięwzięciu unikalnym, obarczonym mniejszą (rzadkość) lub większą (norma) dozą nieokreśloności, stan wiedzy o tym, co wpływa na osiągnięcie celów projektu jest zwykle następujący:

  • cel projektu nakreślony jest „marketingowo”, a cała definicja projektu niewiele mówi o tym, z jakimi przeciwnościami najprawdopodobniej trzeba się będzie zmierzyć na drodze do osiągnięcia celu;
  • zakres projektu jest określony jest „z grubsza”, zwykle niedoszacowując lub wręcz (o zgrozo!) pomijając trudne elementy projektu;
  • harmonogram projektu jest „napięty”, zanim jeszcze ktokolwiek napisał pierwszą literę kodu czy dokumentacji, jakie mają być wytworzone w projekcie;
  • istnieją, przynajmniej na prezentacji, dwa oddzielne (sic!) zespoły projektowe, jeden po stronie zamawiającego (członkowie tego zespołu właśnie z tej prezentacji się dowiedzieli o członkostwie), drugi po stronie dostawcy;
  • nikt po stronie zamawiającego nie ma bladego pojęcia, na ile można ufać dostawcy, a po stronie dostawcy wiadomo, że ufność w zamawiającego prowadzi do stanu zawałowego budżetu projektu.

To tyle na samym wstępie.

Tym niemniej, dla realizacji większości projektów informatycznych przyjmowane są metody / podejścia / procesy takie, jakby:

  • wiadomo było dokładnie, co jest do zrobienia, kto ma co zrobić i co osiągnie – niemalże w skali pojedynczych dni realizacji projektu;
  • wszystkie aspekty celu, zakresu, ograniczeń, uwarunkowań, ryzyka i „problemów komunikacyjnych” w projekcie były znane i zarządzone;
  • projekt miał dostarczyć dwie ciężarówki dokumentacji oraz kawałek oprogramowania, który – dzięki tym dwóm ciężarówkom dokumentacji – wdroży „się sam”;
  • panował powszechny ład i porządek, ludzie obdarzali się pełnym zaufaniem i nigdy nie popełniali błędów;
  • nikt po drodze nie miał zmienić zdania „nawet o milimetr”, a przyszłość była otwartą księgą, z której już wyczytano, że nic projektowi nie zagraża.

Fascynujące, prawda? Nierealność takiego obrazu nie przeszkadza jednak organizować projekty informatyczne czyniąc takie właśnie założenia. Co więcej (o zgrozo, po raz drugi!), założenia te nie są nigdy w trakcie projektu weryfikowane. Raz ustanowiony sposób realizacji, zabetonowany kontraktem, jest w zdecydowanej większości przypadków powodem porażki projektu.

Oczywiście, że można inaczej, a to inaczej nazywa się właśnie Agile. Równie oczywiście, można inaczej, o ile robocza teza postawiona na wstępie jest poprawna. O tym, czym jest agile i czym się różni od waterfall nie ma co się więcej rozpisywać. W zamian kilka myśli „wspomagających” dotyczących „taniości”:

  • Fixed Price na samym początku projektu. Fascynuje mnie wiara w ustalenie kwoty kontraktu na samym początku projektu w sytuacji, w której nikt – tak naprawdę – nie wie, co trzeba zrobić i z czym sobie poradzić, aby „dowieźć” cel projektu. W takiej sytuacji fixed price oznacza tożsamościowo wliczając w kwotę czynniki ryzyka, które mogłyby być efektywniej „obsłużone” w inny sposób, a więc z góry przepłacone.
  • Analiza ryzyka. Zatrważa mnie, jak ograniczona jest analiza ryzyka w projekcie bazującym na kontrakcie fixed price. Z niezrozumiałego dla mnie powodu zamawiający zakłada, że przeniesienie na dostawcę ryzyka kontraktowego oznacza przeniesienie na niego odpowiedzialności za osiągnięcie wartości biznesowej. To jednak nie ma nigdy miejsca, a zamawiający jest „nagle” zaskoczony, że pozostaje sam z systemem do wdrożenia.
  • Wyciskanie „jak cytrynę”. Poraża mnie stopień przyzwolenia (a wręcz poparcia) dla działań służb kontraktowych zamawiających polegających na zmniejszeniu kwoty kontraktu do poziomu, przy którym – gdyby docisnąć jeszcze raz – dostawca rzuciłby ten projekt w ogóle. W konsekwencji jedyną motywacją dostawcy jest minimalizacja kosztów własnych, czego efektem może być jedynie: projekt realizowany w permanentnym konflikcie oraz – w najlepszym wypadku – słabe rozwiązanie.
  • Nieuczciwość i niekompetencja. Jeśli dostawca nie cechuje się uczciwością lub poziom jego kompetencji nie jest taki, jaki być powinien, to o tym wszystkim zamawiający dowie się raczej bliżej końca projektu, niż na początku.

Wierząc więc w siłę fixed price i nierozerwalnie z nim związanego waterfall, zamawiający przyjmuje na siebie największe ryzyko, jakie jest w projekcie – niedostarczenia wartości biznesowej. Dostawca jest kontraktowo wyłączany ze współodpowiedzialności za to ryzyko.

Kontrakt to forma prawna powołana do życia w celu usankcjonowania celu i zasad współpracy. Jeśli dwie strony podejmują świadomą decyzję o współpracy w trybie agile, to kontrakt trzeba napisać „pod to” przedsięwzięcie. Inaczej, zanim jeszcze zaplanowane zostaną pierwsze działania, projekt będzie podporządkowany formie kontraktowej. Projekt napotka w pewnym momencie na rafę i tylko kwestią czasu jest, kiedy pojawi się znaczące „A jak mamy to zapisane w kontrakcie?”. Później jest już tylko „z górki” – w kierunku jednego wielkiego dołka…

Chcecie efektywnie kosztowo realizować projekty informatyczne? Róbcie to w trybie agile. Chcecie tak działać? Dostosujcie formy kontraktowe. Chcecie przekonać do tego zarząd? Pokażcie pełną analizę ryzyka, bez „zarządzania poprzez przymykanie oczu”. Jeśli to nie podziała, pozostaje – po japońsku – realizować cudzy plan, mimo że nie zgadzacie się z jego realnością. W zanadrzu zawsze jest możliwość odejścia z projektu – możliwość, z której ja nigdy dotąd nie skorzystałem. Ale to także, zapewne, tylko kwestia czasu.

Pozostaw komentarz