Podczas jednej z wielu moich dyskusji na forach na tematy “wysokich nakładów na analizę i projektowanie” :), padło stwierdzenie:

Mam jednak wrażenie, że znaczenie może tu mieć skala projektu o którym ja pisze. Nie jest to jakiś wielki system. Jest to prosta aplikacja webowa w php. Myślę, że to w jakiś sposób usprawiedliwia pewne uproszczenia i skróty. Czy się mylę?

Obawiam się, że niestety tak. Znaczenie ma, nie wielkość projektu, a cykl jego życia. Jeżeli planowane  jest stworzenie efemerydy, czyli powstanie aplikacja, którą wywalimy do kosza po kwartale używania np. aplikacja obsługująca jedną kampanię promocyjną, po której potrzebne są potem tylko dane, program który je zbierał leci do kosza, jest już niepotrzebny.

Jeżeli jednak planowana jest aplikacja, która ma przed sobą kilka lat życia, to jedno jest pewne: pojawią się nowe wymagania, o których dziś nie mamy bladego pojęcia… taka aplikacja musi być majstersztykiem projektowym, bo poprawianie czegoś “niepoprawialnego” jest bardzo kosztowne… Należy pamiętać, że nawet
wielka efemeryda wymaga mniej pracy analityczno-projektowej niż malutka aplikacja na kilka lat…

Podstawową rzeczą, jaka należy określić podczas analizy biznesowej, powinno być jedno z kluczowych wymagań jakościowych(!)  jest nim właśnie zaplanowanie cyklu życia aplikacji (produktu). Poniżej prosty diagram:

Na osi pionowej mamy koszty, oś pozioma to czas życia aplikacji (opr. własne autora).

Czerwona linia ciągła to projekt ” na żywioł”. Ograniczono do minimum analizę i projektowanie aplikacji, wytworzenie jej nie było więc zbyt kosztowne a samo administrowanie jest zawsze kosztem niskim. Jednak każda ingerencja w zmianę (w tym rozbudowę) funkcjonalności to niemalże kolejny projekt o skali często porównywalnej z pierwotnym wytworzeniem. Linia przerywana obrazuje narastające w czasie koszty ponoszone na utrzymanie “przy życiu” takiego produktu.

Brak pierwotnego projektu powoduje, że wymagania są identyfikowane poprzez kolejne prototypy (są nimi kolejne wersje). Projekty na “żywioł” także wiec powstaje “długo”. Wymaga dodatkowego czasu na te iteracje i raczej nigdy nie są oddawane do użytku aplikacje w pierwszej wersji.

Linia zielona, to analiza i projektowanie nastawione na optymalizację architektury, przyszłe zmiany i rozwój. Tu koszt wytworzenia, poprzedzonego analizą i projektowaniem, jest wyższy, bywa, że nawet dwukrotnie. Co ciekawe jednak, z reguły nie trwa to dłużej,bo często oprogramowanie jest oddawane do użytku w pierwszej, góra drugiej iteracji. Linia przerywana obrazuje, analogicznie, narastające koszty utrzymania i rozwoju w czasie, tak powstałej aplikacji.

Każdy projekt (efemeryda vs. “long life”), porównując dwa powyższe scenariusze, ma próg rentowności. Najczęściej jest to moment pierwszej poważnej zmiany lub rozszerzenia (szary obszar na diagramie to czas przepłacania dla wersji czerwonej “na żywioł”). Niestety, gdy to odkryje księgowość (kontroling) jest za późno, bo rezygnacja na tym etapie jest jako decyzja bardzo trudna a także kosztowna. Nie zmienia to faktu, że rezygnacja na tym etapie jest najczęściej najrozsądniejszym wyjściem, tu jednak działa

stara zasada manipulacji, tak zwana niska piłka: łatwo (małym kosztem) rozpoczęty projekt o szybko rosnących kosztach w czasie jest mentalnie trudny do zarzucenia a rosnące koszty są usprawiedliwiane i racjonalne myślenie jest odkładane. Dostawcy oprogramowania stosują nie raz tę metodę manipulacji z pełną premedytacją,

nie raz jednak to nabywca sam się “manipuluje” wierząc na początku, że można bardzo tanio i bardzo dobrze. Potem ma już miejsce tylko obrona własnego “honoru”, co z racjonalnym zarządzaniem kosztami nie ma nic wspólnego. Tu winny jestem uwagę:

projekty na żywioł znacznie częściej mają przekraczane terminy i budżety (badania mówią, że 75% projektów ma przekroczony budżet średnio o 60% z winy źle określonych wymagań) niż projekty prowadzone “metodycznie”.

Jak więc zaradzić dużym kosztom utrzymania oprogramowania?

Jest tylko jeden sposób: planować rentowność i czas życia każdego projektu i jego produktu. Warto zwrócić uwagę, że pojawia się tu [[różnica pomiędzy projektem a programem]]).

Aplikacje zaplanowane jako efemerydy, to produkty projektów, należy bez litości i sentymentów wyrzucać je jak “zrobią swoje”. Zmiana planów z ich wyrzucenia na dalszy rozwój to najczęściej krach finansowy projektu. W takich wypadkach, na bazie doświadczeń z eksploatacji efemerydy, najlepiej zaprojektować nowy system z planem na kilka lat eksploatacji.

Aplikacje planowane jako narzędzia pracy na lata,  bezwzględnie dobrze projektować i poprzedzać analizą biznesową przed ich wytwarzaniem, bo wtedy mamy już do czynienia nie z projektem a właśnie z programem.

Podstawowym błędem, moim zdaniem, jest traktowanie zakupu lub wytworzenia oprogramowania planowanego na “długie używanie” jako projektu programistycznego. To nie projekt, to program!  Projektem jest wytworzenie pierwotnej wersji, potem projektami są kolejno wprowadzane nowe funkcjonalności lub zmiany. Całość to program.

A teraz proszę sobie wyobrazić, że większość oprogramowania ERP czy CRM na naszym rynku, to produkty, które pierwotnie powstały na potrzeby jednego konkretnego zamawiającego a potem, jak się udało wdrożyć w jednej firmie, ktoś dochodził do wniosku: “to może sprzedawajmy to kolejnym klientom”… resztę sami Państwo sobie dopowiedzcie.

Powyższe nasuwa od razu kolejny wniosek: zamawiający najczęściej formułują zapytania w sposób pozwalający dostawcom składać oferty  na pierwszy etap, polegający tylko na dostarczeniu i wdrożeniu. Jak widać z zasady wygrywają tu projekty “na żywioł”.  Żądanie od dostawców ujęcia kosztów utrzymania (tak zwany “maintenance”) niczego nie zmienia bo to tylko stała oplata administracyjna. Jedynym sposobem na rzetelne porównanie ofert jest operowanie kosztem cyklu życia dostarczonego produktu.