Czas – kluczowe wymaganie w projektach IT
Czy warto rozpatrywać „czas” jako wymaganie w projektach IT? Uważam, że tak. Uważam, że jest to kluczowe wymaganie projektowe…
Kilka lat temu prowadziłem audyt w niewielkiej firmie informatycznej budującej rozwiązania wspierające spedycję. Podczas rozmów z pracownikami co chwilę ktoś wskazywał na problem niewielkich opóźnień w realizacji zadań. Raz zespół spóźnił się o jeden dzień z oddaniem nowej funkcji, raz o dwa tygodnie, raz o pół dnia, etc. Te wszystkie opóźnienia przyjmowane były w firmie z milcząca akceptacją zarządu. Nikt oczywiście nie był z nich dumny, jednak czy drobne, jednodniowe opóźnienia projektu, który realizowany był od kilku lat, stanowiły problem? A może wręcz przeciwnie, w firmie pracującej na umowach typu time and materials okazywały się źródłem dodatkowego przychodu? Spóźnialscy mieli zawsze dobre wymówki: „Projekt IT są trudne i nieprzewidywalne!”, „Z klientem ciężko się dogadać.”, albo „Mamy do czynienia ze złożoną domeną i warunkami wysokiej niepewności, więc nie jesteśmy w stanie precyzyjnie estymować zdań.”.
Poprosiłem zespół, by spróbowali policzyć ile kosztuje 1 dzień ich spóźnienia. Ktoś szybko policzył, że przy ich ośmioosobowym zespole 1 dzień opóźnienia, to koszt ośmiu osobodni.
Poprosiłem zatem, by przypomnieli sobie ostatni przypadek, w którym projekt opóźnił się o 1 dzień. Opisali mi historię sprzed 3 tygodni. Zespół został poproszony o przygotowanie pilnej poprawki związanej z generowaniem listów przewozowych. Coś niestety poszło nie tak i poprawka nie została wdrożona do końca sprintu, ale dopiero w kolejnym tygodniu we wtorek. Jak się później okazało, opóźnienia udałoby się uniknąć, gdyby została przeprowadzona kontrola jakości specyfikacji przed rozpoczęciem implementacji poprawki, a nie po jej implementacji.
Ze względu na to 1 dniowe opóźnienie w dostarczeniu poprawnie działającego oprogramowania, klienci firmy informatycznej musieli wstrzymać sporą część swojej floty przewozowej, która miała wyruszyć w poniedziałek z samego rana. Flota czekała aż do wtorkowego popołudnia na poprawnie wygenerowane listy przewozowe. Tym samym zamówiony towar nie został dostarczony na czas do klientów docelowych, co przełożyło się na duże straty. Zespół oszacował je na prawie dwieście tysięcy złotych (to nieco więcej niż osiem osobodni).
Już nawet nie wspominałem im o koszcie alternatywnym (opportunity cost) i stratach wizerunkowych, które ponieśli wszyscy.
Czas dostarczenia rozwiązania jest wymaganiem projektowym, tak jak wszystkie pozostałe wymagania i nie należy o nim myśleć w innych kategoriach.
Uświadomienie sobie jak ważne jest spełnienie tego wymagania i ile kosztuje spóźnienie powinno zmotywować nas do poszukania lepszych i dojrzalszych metod planowania. Metod, które pozwalają na precyzyjniejsze definiowanie wymagań projektowych, dekompozycję złożonych zadań na mniejsze, łatwiejsze w estymacji, urealnienie naszego optymizmu w planowaniu oraz dobór rozwiązań, które pozwalają na realizację zadania w ustalonym czasie, budżecie i poziomie jakości.
Na potrzeby tego artykułu chciałbym wspomnieć o dwóch metodach planowania i realizacji projektów, które nie są niestety w mainstreamie, mimo, że od dekad managerowie dowodzą ich skuteczności.
Pierwszą z nich jest metoda Cleanroom (Cleanroom software engineering process) stworzona przez Harlana Millsa z IBM. Harlan tą metodą realizował niezwykle trudne projekty rządowe. Bliźniaczą metodą dla Cleanroom jest EVO (Evolutionary Project Management) stworzone przez Toma Gilba, którą m.in. wdrożył Intel i Boeing.
Obie metody łączy m.in. iteracyjne dostarczanie wartości biznesowej, wysokiej jakości specyfikacja wymagań oparta na kwantyfikacji i statystyce, czy też SQC (Specification Quality Control), której założeniem jest unikanie błędów, a nie ich usuwanie z kodu programu.
To co sprawia, że obie metody są tak skuteczne, to fakt, że stawiają one na pierwszym miejscu dowożenie projektu na czas, poniżej założonego budżetu, na najwyższym ustalonym poziomie jakości. Metody te zostały opisane i przetestowane w praktyce na tysiącach projektów na długo przed pojawieniem się SCRUMa i późniejszej rewolucji agile. Dzisiaj są tak samo skuteczne jak 40 lat temu.
Jak napisał kiedyś filozof George Santayana:
“Those who cannot remember the past are condemned to repeat it.”
Tymczasem wszystkich zainteresowanych, którzy chcieliby w praktyce poznać EVO i Cleanroom zachęcam do udziału w Masterclassie Toma Gilba, który odbędzie się w dniach 25 – 29 maja 2019 w Warszawie. Zapisy na stronie: www.nowy.me/gilb