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.
