Bent Flyvbjerg, duński badacz megaprojektów napisał bardzo ciekawą książkę “How Big Things Get Done”. Książka opiera się na bazie danych ponad 16 000 projektów i analizuje, dlaczego wielkie przedsięwzięcia tak często przekraczają budżet i harmonogram. Przez “duże projekty” rozumiem tutaj organizacje olimpiad, elektrownie atomowe, ale też wielkie projekty informatyczne.
Część z podnoszonych przez niego przyczyn sukcesów to inkrementalność zmian.
Jeśli budujemy elektrownię konwencjonalną, a zwłaszcza atomową, zaczyna ona produkować prąd dopiero, kiedy cała jest gotowa. Ścieżka krytyczna obejmuje praktycznie wszystkie elementy i trudno ją zrównoleglić. Elektrownia gotowa nawet 90% nie działa. Prąd, a co za tym idzie zyski mamy dopiero po zakończeniu całego projektu.
Kontrprzykładem do elektrowni atomowej są elektrownie wiatrowe oraz elektrownie słoneczne. Jeśli mamy już zbudowaną stację transformatorową, to budowa jednego elementu elektrowni wiatrowej ogranicza się do wylania fundamentu, postawienia wieży, dodania gondoli z turbiną i łopatami, po czym można ją podłączyć do sieci. W tym momencie elektrownia zaczyna produkować prąd. Nawet jeżeli kolejne wieże opóźnią się, to część projektu już została zrealizowana.
Iteracyjny proces ma również tę zaletę, że oddając kolejne części takiego projektu, zdobywamy doświadczenie, które pomaga budować kolejne elementy szybciej i taniej. Cały proces na jednej farmie jest powtarzany kilkadziesiąt razy. W przypadku elektrowni atomowej, doświadczenie możemy wykorzystać dopiero przy budowaniu kolejnej elektrowni, po zakończeniu projektu, a nie w jego trakcie. Przy czym rzadko które państwo decyduje się na seryjne stawianie elektrowni, by to doświadczenie wykorzystać.
Dla branży IT nie jest to nowa wiedza. Agile od dekad mówi o dzieleniu projektów na mniejsze fragmenty. Łatwiej powiedzieć jednak niż zrobić.
Jeśli mam dwa projekty do wykonania, to staram się je prowadzić sekwencyjnie. Dzięki temu, gdy zaczynam drugi, to pierwszy jest już skończony i dostarcza wartość użytkownikom. Nie jest to łatwe. Ponieważ mamy mnóstwo pomysłów i rzeczy, które chcemy robić, wymaga to mówienia nie, pytania o priorytety i odkładania rzeczy na później, czego nikt nie lubi. Nauczyłem się, tego w twardy sposób.
Kilka lat temu prowadziliśmy integrację jednego z przewoźników. Integracja była co kilka miesięcy przerywana i wznawiana, ostatecznie zajęła nam dwa lata, a programista zwolnił się jak tylko ją skończył. Od tego czasu bardzo pilnuję, żeby albo coś robić na 100%, albo nie robić wcale.