Faza stabilizacji czyli jak nie dostarczać produktów

Podejście iteracyjne na dobre zadomowiło się w tworzeniu oprogramowania. Jednak rządowe inwestycje wciąż prowadzone są w klasycznym kaskadowym modelu. Jakie są tego efekty?

Blisko miesiąc temu został uruchomiony CEPiK 2.0, czyli program niezbędny między innymi do rejestracji samochodów w całej Polsce. Od tego czasu jest w “fazie stabilizacji”. Co to tak naprawdę oznacza? W fachowym słownictwie informatycznym “stabilizacja” to nic innego niż próba uruchomienia niedziałającego programu.

Czyli po prostu CEPiK nie działa.

Rejestracja nowych samochodów jest mocno utrudniona, a często nawet niemożliwa. To samo dotyczy przeglądów samochodowych. Dlaczego? Bo dostarczony produkt zawiera pełno błędów, które powodują te problemy. I te błędy są powoli usuwane. Tylko, że na żywym organizmie, co mocno utrudnia ludziom życie.

I to nie pierwszy problem CEPiKu

Prace nad CEPiK 2.0 rozpoczęły się w 2013 roku. Program miał zostać uruchomiony 4 stycznia 2016 czyli ponad półtora roku wcześniej. Jednak data została dwukrotnie przesunięta, między innymi bo:

Istniało realne ryzyko, że urzędnicy nie mogliby rejestrować samochodów, diagności prowadzić przeglądów pojazdów, a kandydaci na kierowców zdawać egzaminów na prawo jazdy. (źródło: Centralny Ośrodek Informatyki)

Powtórzę to jeszcze raz. Oddano do użytku niedziałający produkt, budowany przez cztery lata i dwukrotnie opóźniony, za każdym razem praktycznie o rok.

Ale to skomplikowany produkt

Oczywiście, tak jak większość produktów. Tylko, że w tym samym przedziale czasowym SpaceX był w stanie opracować rakietę kosmiczną wielokrotnego użytku, a Toyota potrzebowała mniej niż połowę tego czasu, żeby stworzyć Priusa – pierwszy hybrydowy samochód. Facebook, który na całym świecie ma dwa miliardy użytkowników jest w stanie aktualizować swoje oprogramowanie kilka razy dziennie, i nie potrzebuje ‘fazy stabilizacji’.

Więc jak to robić?

Iteracyjnie. Wytwarzając go w krótkich cyklach. Dostarczając działający produkt co iterację. Działający czyli taki, który jest przetestowany i można z niego korzystać. Ale to wymaga zmian: innej architektury rozwiązania, innych technik tworzenia i testowania oprogramowania, innego podejścia do zarządzania.

Niestety, takie podejście jest wciąż rzadkie, szczególnie jeżeli chodzi o wielkie, rządowe inicjatywy. Dlatego musimy pokazywać kolejne problemy “dużych inicjatyw”. Aż wreszcie, pewnego dnia, iteracyjne dostarczanie produktów stanie się tak oczywiste jak ma to miejsce w komercyjnych produktach.