To już nie projekty

Innymi słowy, współcześnie łamie się podstawowe założenie podejścia projektowego: nie jest jasny „koniec” ani pod względem czasu ani funkcjonalności – rozwój produktu to proces ciągły, który zapewne będzie miał koniec, ale zwykle ciężko przewidzieć, kiedy on będzie i co będzie w produkcie potrzebne po drodze. W takiej sytuacji ciężko mówić o „tymczasowości” projektu. Powoduje to również, że nie działają podstawowe narzędzia projektowe, takie jak ustalenie zakresu, zarządzanie zakresem i tak dalej, bo ciężko zarządzać czymś, co jest niewiadome i z góry wiadomo, że będzie zmienne.

Na tym nie koniec. Planowanie projektów polega na wcześniejszym zaplanowaniu pracy – im dokładniej, tym lepiej – i rozbiciu jej na „atomowe” prace, które są proste i przewidywalne – wiadomo mniej więcej, ile będą trwały. Tworzenie tak zwanej Work Breakdown Structure na tym właśnie polega. Układanie harmonogramów i szacowanie dat w projekcie jest wynikiem założenia, że znajdujące się na WBS czynności są przewidywalne, a więc że relatywnie rzadko zdarzają się odchylenia od założonej pracochłonności (wpływ na czas i koszt) oraz że są one niewielkie.

Inherentna nieprzewidywalność

I tu kolejny problem z oprogramowaniem: nie jest to działanie, które można rozbić na proste, przewidywalne czynności. W oprogramowaniu występuje inherentna nieprzewidywalność pracy w skali mikro. Innymi słowy ciężko jest programistom przewidzieć ile zajmie praca nad konkretnymi zmianami, ponieważ poziom złożoności oprogramowania jest na tyle wysoki, że relatywnie często zmiany, które wydawały się proste powodują nieprzewidziane skutki. Czyli żaden programista nie może być pewny, ile czasu zajmie mu dokonanie takiej czy innej modyfikacji oprogramowania, dopóki jej nie zakończy. Wynika to z tego, że przy ogromnym poziomie komplikacji współczesnego oprogramowania często zmiany kodu prowadzą do nieprzewidzianych konsekwencji.

Mówiąc obrazowo: programista pomyślał, zmienił – i coś nie działa tak, jak założył. Gdzieś jest błąd. Czy da się oszacować ile zajmie mu znalezienie go i usunięcie? Nie. Czy można mieć pewność, że nie pojawią się wtedy inne problemy? Nie.

Łamie się zatem fundamentalne założenie, na którym opierają się plany projektów, że sumując szacowaną pracochłonność poszczególnych czynności dostaniemy sensowne przewidywanie co do pracochłonności całości. A zatem WBS przestaje mieć sens, nawet jeśli nie brać pod uwagę zmian zakresu, które i tak powodowałyby jego ciągłą zmianę.

Podsumujmy: zakres się zmienia, nie jest pewne, kiedy będzie koniec, a prognozy co do czasu (effortu) na poszczególne zadania są bardzo niepewne. Z tym można sobie poradzić wyłącznie korzystając z podejścia iteracyjnego i inkrementalnego, połączonego z empiryzmem. Właśnie dlatego w oprogramowaniu kontynuacja stosowania podejść projektowych w latach dziewięćdziesiątych doprowadziła do szeregu spektakularnych klap, a w efekcie poszukiwania lepszych sposobów na poradzenie sobie z zarządzaniem tą dziedziną: powstania metod Agile, w tym oczywiście także Scruma.

Nie oznacza to, że zarządzanie projektami jako takie nie ma dziś sensu. Wszędzie tam, gdzie zakres jest w miarę stały, warunki stabilne, a praca przewidywalna, nadal to jest dobre podejście. Z tym, że po prostu w oprogramowaniu najczęściej tak już nie jest.

Artykuły Andy’ego Brandta można otrzymywać zapisując się do newslettera na stronie: https://andy.codesprinters.pl/.

Andy Brandt Andy Brandt  

Założyciel i senior consultant firmy doradczo-szkoleniowej Code Sprinters. Wcześniej był między innymi Country Managerem Swisscom CEE (w Polsce pod marką Air Bites), a także menedżerem i konsultantem w 4pi, Unisys i T-Mobile Polska, jak też pierwszym redaktorem naczelnym „Linux+”.