Wprowadzenie
Temat wycen usług z zakresu analizy, projektowania i wykonania często budzi wiele emocji, wydaje się, że powodem jest brak wiedzy o specyfice tych prac. Nie ma zapewne złotego środka ale warto mieć świadomość tego, że płynne przechodzenie od prac analityczno-koncepcyjnych do ich realizacji podlega pewnej prawidłowości.
Modele używane w toku wyceny
Popatrzmy po raz kolejny na poniższy diagram:
Spróbujmy się wyobrazić:
- ile stron zajmuje plan marketingowy i opis strategii (pewna relatywnie mała cześć np. prospektu emisyjnego spółki giełdowej), to wierzchołek powyższej piramidy,
- ile stron zajmuje kompletna, obejmująca całą spółkę dokumentacja ISO, zakresy obowiązków wszystkich pracowników i opisy ich kompetencji, to podstawa powyższej piramidy,
- Modele procesów biznesowych leżą (cenowo i ilościowo) gdzieś pomiędzy powyższymi, ale bliżej strategii, to środkowa część piramidy.
Teraz idąc dalej: jakim nakładem pracy, czyjej i jakim kosztem, powstała jedna strona planu marketingowego a jakim kosztem powstała strona np. procedury czy instrukcji stanowiskowej.
Powyższy diagram, piramida, mniej więcej odwzorowuje ilość dokumentacji na każdym z tych trzech poziomów (powierzania każdej warstwy) jednak waga (ryzyko jakie stwarza powstanie złej dokumentacji) i trudność opracowania sprawiają, że koszt ich wytworzenia jest porównywalny, proporcje ilości stron opisu strategii vs. dokumenty HR i ISO to nawet 1:100.
To był etap analizy biznesowej i projektowania w obszarze zarządzania i procesów biznesowych. A jak to wygląda w przypadku projektowania oprogramowania? Bardzo podobnie:
]
Jak widać mamy znowu (prawie) piramidkę. Od góry patrząc mamy kolejne etapy analizy i projektowania (metodą od ogółu do szczegółu). W tym przypadku mamy analogiczną relację ilości treści na etapie analizy i modelowania vs. ilość linii powstałego na ich podstawie kodu. Tu relacja kosztów „jednej strony A4” także dochodzi do poziomu 1:100 a nie raz znacznie więcej.
Wyjaśnienie jest dość proste: po pierwsze opracowanie jednej strony modelu to wiele iteracji i rozwiązywanie problemów związanych z logiką całości, spójności, kompletności itp. Na etapie implementacji problemy te są już rozwiązane, wiec „treść„ « powstaje po pierwsze szybciej po drugie „pod dyktando” więc „taniej”.
To prawie jak na rynku budowlanym: największym problem i ryzykiem jest analiza potrzeb i zaprojektowanie bryły budynku i wewnętrznego rozkładu jego pomieszczeń z uwzględnieniem przyszłych zmian. Nikt chyba nie wątpliwości, ze praca projektanta architekta jest znacznie bardziej „kosztowna” per osoba niż firmy developerskiej.
Swego czasu, na szkoleniu organizownym przez IIBA zapytałem prowadzącego o sprawdzone w praktyce dobrze przeprowadzonych projektów IT, proporcje pomiędzy czasem oraz kosztem etapu analizy i planowania (projektowania) a czasu i kosztu realizacji projektu (na bazie powstałe dokumentacji). Są to odpowiednio dla czasu trwania etapu 50%-50% dla kosztów 20%-80%. Co ciekawe projekty mające silnie ograniczony pierwszy etap, w zasadzie nie mieściły w kategoriach poprawnych projektów (przekroczone terminy i budżety).
Koszt analizy i projektowania powinien być dostosowany do ryzyka projektu:
A tak wygląda to jako całość z perspektywy analizy zrealizowanych projektów programistycznych (badanych było ponad 500 projektów):
Tak więc warto zawsze rozważać udział fazy analizy i planowania w całości projektu, mieć świadomość konsekwencji tej decyzji oraz w szczególności, planując budżet oraz czas na analizę i projektowanie, przyjąć, że dokumentacja analityczno- projektowa jest objętościowo najszczuplejszym „artefaktem” w całym projekcie (największym artefaktem jest kod) mimo, że nie najtańszym.
Zakończenie
Na koniec przytoczę słowa jednego z moich klientów, dobrze doświadczonego kierownika projektów: każda oszczędzona godzina analityka projektanta, to dodatkowy tydzień pracy zespołu programistów.
