Zarządzanie projektami to zarządzanie tymczasowymi (jednorazowymi) przedsięwzięciami, mającymi z góry znany rezultat („A project is a temporary endeavor undertaken to create a unique product, service, or result”, PMBOK wyd. 6, 2017). Podstawowe kryteria sukcesu w zarządzaniu projektem to dostarczenie tego, co zaplanowano, w takim koszcie jak zaplanowano oraz w takim czasie jak zaplanowano. Ostatnio dodaje się do tego kryteria jakościowe i inne kryteria, które oczywiście muszą być uzgodnione z góry. No właśnie – wszystko musi być zaplanowane i wiadome z góry! Oczywiście, zarządzanie projektami przewiduje istnienie zmian w czasie trwania projektu, ale traktuje je jako zło konieczne, które trzeba obsługiwać, ale raczej ograniczać.

Cały ten paradygmat świetnie pasuje do takiej dziedziny jak budownictwo. Budowle powstają według dokładnie tego schematu – najpierw należy zebrać wymagania inwestora, następnie przeanalizować warunki w planowanym miejscu budowy oraz ograniczenia formalne, następnie na tej podstawie przygotować wstępny projekt architektoniczny, przekazać do zatwierdzenia, na jego podstawie przygotować projekt inżynierski, na podstawie tegoż plan budowy – a następnie go zrealizować pilnując uważnie terminów i kosztów.

Podobnie rzecz ma się z wieloma innymi obiektami inżynierskimi, które powstają raz. Tak ma się rzecz również z tymi, które podlegają masowej produkcji (powtarzalne wytwarzanie wielu takich samych egzemplarzy), ale owa produkcja jest poprzedzona przygotowaniem produktu, co najczęściej w większości branż ma charakter projektu.

To se ne vrati

Problem z oprogramowaniem jest taki, że jeszcze 40 lat temu sprawy miały się z nim podobnie. To (pamiętane dziś przez nielicznych) czasy komputerów jako rozdzielnych maszyn (brak spinającej je w jeden supersystem sieci), których używano do „informatyzacji” relatywnie prostych procesów biznesowych, które pozostawały długi czas niezmienne. Tak więc można powiedzieć, że w roku 1975 system informatyczny nie różnił się co do cech zarządczych istotnie od kamienicy.

Jednak od dawna to już tak nie wygląda. Oprogramowanie przestało być „dziełem” w sensie takim, w jakim dziełem jest rzeźba czy budynek. Dzieła te posiadają ewidentny moment ukończenia, moment, od którego nic się już z nimi nie robi, poza tak zwanym utrzymaniem. Jak możemy się przekonać niemal na każdym kroku, większość tworzonego współcześnie oprogramowania zdecydowanie czymś takim nie jest. Przeciwnie, to byty, które podlegają ciągłej modyfikacji, ciągłemu rozwojowi.

Co więcej, częstotliwość wydań każdego niemal rodzaju oprogramowania znacząco w ostatniej dekadzie wzrosła. Z czego to wynika? Po pierwsze z tego, że jest to technologicznie możliwe – rozwój zarówno sieci (który doprowadził do tego, że nawet samochody mogą pobierać sobie aktualizacje), jak i narzędzi związanych ogólnie z zarządzaniem wydaniami doprowadził do tego, że częsta aktualizacja oprogramowania jest dużo łatwiejsza niż w XX wieku. Po drugie to kwestia potrzeb – częste aktualizacje są obecnie niezbędne, aby produkt mógł dobrze funkcjonować na rynku. Co więcej, użytkownicy są przyzwyczajani przez różne platformy online do tego, że dane i możliwości są zawsze aktualne.