Inny świat procesów

Każdy, kto choć trochę zna się na informatyce, dawno wyzbył się naiwnego oczekiwania, że system informatyczny może być zbudowany w terminie, przy założonym budżecie i zaplanowanej funkcjonalności.

Każdy, kto choć trochę zna się na informatyce, dawno wyzbył się naiwnego oczekiwania, że system informatyczny może być zbudowany w terminie, przy założonym budżecie i zaplanowanej funkcjonalności.

Profesjonaliści patrzą z przymrużeniem oka na tych, którzy uważają, że jest inaczej. Mądrze i "w dobrym tonie" jest znać na pamięć kilka nieudanych projektów lub takich, które wielokrotnie przekroczyły założony budżet.

Kryzys inżynierii oprogramowania jest zjawiskiem towarzyszącym biznesowi informatycznemu od lat 50., czyli od początku jego istnienia. Profesjonaliści potrafią to zjawisko dobrze wytłumaczyć. Inne dziedziny inżynierii, takie jak budownictwo, budowa okrętów czy urządzeń mechanicznych, mają zdecydowanie dłuższą historię. Człowiek od tysięcy lat uczy się budować domy i my - informatycy - możemy szczerze pozazdrościć skuteczności naszym kolegom inżynierom. Dzisiejsi inżynierowie i architekci korzystają z doświadczeń dziesiątek pokoleń. Technologie budowy domów są dobrze zdefiniowane. Wiadomo, jaki dom można zbudować za określone pieniądze i ile orientacyjnie będzie trwała budowa.

Gorzej jest z systemami informatycznymi. Obecne metody i języki programowania pozwalają na skonstruowanie wielokrotnie większego programu niż języki używane przed kilkudziesięcioma laty. Niestety, dzisiaj tak samo trudno jest opracować system zgodnie z planem, założonym budżetem i funkcjonalnością, jak przed czterdziestu laty.

Lata obserwacji i doświadczeń skonsolidowano w postaci wielu modeli i zbiorów zaleceń dotyczących skutecznej realizacji przedsięwzięć informatycznych. Powstały modele opisujące profil dojrzałych organizacji oraz metody doskonalenia sposobów działania firm i zespołów informatycznych. Do najbardziej znanych i uznanych modeli należą Capability Maturity Model (CMM), SPICE i Bootstrap.

Głównym wnioskiem płynącym z wieloletnich doświadczeń jest konieczność ciągłego doskonalenia praktyk wytwarzania systemów, które formalnie nazywamy procesem wytwórczym. Można więc stwierdzić, że jednym z kluczowych czynników sukcesu jest posiadanie procesu wytwórczego i umiejętne nim zarządzanie.

Zarządzanie procesem wytwórczym

Po kilkudziesięcioletnich doświadczeniach w budowie systemów informatycznych specjaliści od inżynierii oprogramowania zaczęli wyciągać wnioski z obserwacji innych, dojrzalszych dziedzin inżynierii. Podstawowym czynnikiem sukcesu jest umiejętność planowania i kontroli kosztów, harmonogramu oraz funkcjonalności systemu.

Większość projektów jest, niestety, szacowana intuicyjnie. Ludzie mają naturalną tendencję do nieuzasadnionego optymizmu, gdy muszą oszacować pracochłonność zadania, którego nie potrafią rzetelnie ocenić. Większość kierowników projektów i projektantów boi się, że zaplanowanie zbyt długiego terminu będzie oznaką ich niekompetencji. Handlowcy negocjujący kontrakty są "optymistami" z zupełnie innego powodu. Obiecują swoim klientom "złote góry" za małe pieniądze, bojąc się, że kontrakt wygra ktoś inny. Brak umiejętności rzetelnego szacowania zawsze prowadzi do niedoszacowania.

Pierwszym elementem dobrego procesu wytwórczego jest umiejętność wiarygodnego szacowania. Wdrożenie odpowiednich procedur oceny wielkości i pracochłonności projektu na bazie poprzednich doświadczeń pozwala na realistyczne planowanie budżetu i innych niezbędnych zasobów. Oczywiście, wiarygodne oszacowania są możliwe tylko wtedy, gdy monitorowaliśmy rzeczywiste koszty, pracochłonność i czas trwania poprzednich projektów.

Proces wytwórczy w informatyce to sformalizowany zapis dobrych praktyk wykorzystanych w poprzednich projektach. Należy zwrócić uwagę, że rzadko zespoły informatyczne opierają się w swoich pracach na standardach opracowanych we wcześniejszych projektach. Niestety, nagminne jest popełnianie ciągle tych samych błędów. Nie potrafimy, a nawet nie próbujemy zastanowić się, dlaczego jeden projekt się powiódł, a inny nie, dlaczego w projekcie A przekroczyliśmy harmonogram o 200%, a w projekcie B o 10%.