Wycena analizy i projektowania

Temat wycen usług z zakre­su ana­li­zy, pro­jek­to­wa­nia i wyko­na­nia czę­sto budzi wie­le emo­cji, wyda­je się, że powo­dem jest brak wie­dzy o spe­cy­fi­ce tych prac. Nie ma zapew­ne zło­te­go środ­ka ale war­to mieć świa­do­mość tego, że płyn­ne prze­cho­dze­nie od prac ana­li­tycz­no-kon­cep­cyj­nych do ich reali­za­cji pod­le­ga pew­nej prawidłowości.

Popatrzmy po raz kolej­ny na poniż­szy diagram:

(źr. http://www.bptrendsassociates.com/)
(źr. http://​www​.bptrend​sas​so​cia​tes​.com/)

Spróbujmy się wyobrazić:

  • ile stron zaj­mu­je plan mar­ke­tin­go­wy i opis stra­te­gii (pew­na rela­tyw­nie mała cześć np. pro­spek­tu emi­syj­ne­go spół­ki gieł­do­wej), to wierz­cho­łek powyż­szej piramidy,
  • ile stron zaj­mu­je kom­plet­na, obej­mu­ją­ca całą spół­kę doku­men­ta­cja ISO, zakre­sy obo­wiąz­ków wszyst­kich pra­cow­ni­ków i opi­sy ich kom­pe­ten­cji, to pod­sta­wa powyż­szej piramidy,
  • Modele pro­ce­sów biz­ne­so­wych leżą (ceno­wo i ilo­ścio­wo) gdzieś pomię­dzy powyż­szy­mi, ale bli­żej stra­te­gii, to środ­ko­wa część piramidy.

Teraz idąc dalej: jakim nakła­dem pra­cy, czy­jej i jakim kosz­tem, powsta­ła jed­na stro­na pla­nu mar­ke­tin­go­we­go a jakim kosz­tem powsta­ła stro­na np. pro­ce­du­ry czy instruk­cji stanowiskowej.

Powyższy dia­gram, pira­mi­da, mniej wię­cej odwzo­ro­wu­je ilość doku­men­ta­cji na każ­dym z tych trzech pozio­mów (powie­rza­nia każ­dej war­stwy) jed­nak waga (ryzy­ko jakie stwa­rza powsta­nie złej doku­men­ta­cji) i trud­ność opra­co­wa­nia spra­wia­ją, że koszt ich wytwo­rze­nia jest porów­ny­wal­ny, pro­por­cje ilo­ści stron opi­su stra­te­gii vs. doku­men­ty HR i ISO to nawet 1:100.

To był etap ana­li­zy biz­ne­so­wej i pro­jek­to­wa­nia w obsza­rze zarzą­dza­nia i pro­ce­sów biz­ne­so­wych. A jak to wyglą­da w przy­pad­ku pro­jek­to­wa­nia opro­gra­mo­wa­nia? Bardzo podobnie:

CIM-PIM-PSM
źr. The Tao of Modeling Spaces http://​www​.jot​.fm/​i​s​s​u​e​s​/​i​s​s​u​e​_​2​0​0​6​_​1​1​/​a​r​t​i​c​l​e4/

Jak widać mamy zno­wu (pra­wie) pira­mid­kę. Od góry patrząc mamy kolej­ne eta­py ana­li­zy i pro­jek­to­wa­nia (meto­dą od ogó­łu do szcze­gó­łu). W tym przy­pad­ku mamy ana­lo­gicz­ną rela­cję ilo­ści tre­ści na eta­pie ana­li­zy i mode­lo­wa­nia vs. ilość linii powsta­łe­go na ich pod­sta­wie kodu. Tu rela­cja kosz­tów jed­nej stro­ny A4” tak­że docho­dzi do pozio­mu 1:100 a nie raz znacz­nie więcej.

Wyjaśnienie jest dość pro­ste: po pierw­sze opra­co­wa­nie jed­nej stro­ny mode­lu to wie­le ite­ra­cji i roz­wią­zy­wa­nie pro­ble­mów zwią­za­nych z logi­ką cało­ści, spój­no­ści, kom­plet­no­ści itp. Na eta­pie imple­men­ta­cji pro­ble­my te są już roz­wią­za­ne, wiec treść„ « powsta­je po pierw­sze szyb­ciej po dru­gie pod dyk­tan­do” więc taniej”.

To pra­wie jak na ryn­ku budow­la­nym: naj­więk­szym pro­blem i ryzy­kiem jest ana­li­za potrzeb i zapro­jek­to­wa­nie bry­ły budyn­ku i wewnętrz­ne­go roz­kła­du jego pomiesz­czeń z uwzględ­nie­niem przy­szłych zmian. Nikt chy­ba nie wąt­pli­wo­ści, ze pra­ca pro­jek­tan­ta archi­tek­ta jest znacz­nie bar­dziej kosz­tow­na” per oso­ba niż fir­my developerskiej.

Swego cza­su, na szko­le­niu orga­ni­zow­nym przez IIBA zapy­ta­łem pro­wa­dzą­ce­go o spraw­dzo­ne w prak­ty­ce dobrze prze­pro­wa­dzo­nych pro­jek­tów IT, pro­por­cje pomię­dzy cza­sem oraz kosz­tem eta­pu ana­li­zy i pla­no­wa­nia (pro­jek­to­wa­nia) a cza­su i kosz­tu reali­za­cji pro­jek­tu (na bazie powsta­łe doku­men­ta­cji). Są to odpo­wied­nio dla cza­su trwa­nia eta­pu 50%-50% dla kosz­tów 20%-80%. Co cie­ka­we pro­jek­ty mają­ce sil­nie ogra­ni­czo­ny pierw­szy etap, w zasa­dzie nie mie­ści­ły w kate­go­riach popraw­nych pro­jek­tów (prze­kro­czo­ne ter­mi­ny i budżety).

Koszt ana­li­zy i pro­jek­to­wa­nia powi­nien być dosto­so­wa­ny do ryzy­ka projektu:

KosztAnalizy

A tak wyglą­da to jako całość z per­spek­ty­wy ana­li­zy zre­ali­zo­wa­nych pro­jek­tów pro­gra­mi­stycz­nych (bada­nych było ponad 500 projektów):

Statystyka kosztów projektów IT

Tak więc war­to zawsze roz­wa­żać udział fazy ana­li­zy i pla­no­wa­nia w cało­ści pro­jek­tu, mieć świa­do­mość kon­se­kwen­cji tej decy­zji oraz w szcze­gól­no­ści, pla­nu­jąc budżet oraz czas na ana­li­zę i pro­jek­to­wa­nie, przy­jąć, że doku­men­ta­cja ana­li­tycz­no- pro­jek­to­wa jest obję­to­ścio­wo naj­szczu­plej­szym arte­fak­tem” w całym pro­jek­cie (naj­więk­szym arte­fak­tem jest kod) mimo, że nie najtańszym.

Na koniec przy­to­czę sło­wa jed­ne­go z moich klien­tów, dobrze doświad­czo­ne­go kie­row­ni­ka pro­jek­tów: każ­da oszczę­dzo­na godzi­na ana­li­ty­ka pro­jek­tan­ta, to dodat­ko­wy tydzień pra­cy zespo­łu programistów.

Dodaj komentarz

Twój adres email nie zostanie opublikowany

Komentuj i zadawaj pytania autorowi.

Identyfikator *
E-mail *
Witryna internetowa

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.