Pół roku temu arty­kuł o roli Product Ownera koń­czy­łem słowami:

Tak więc nasu­wa się wnio­sek, że rolę PO powi­nien peł­nić ten czło­wiek, któ­ry wła­śnie skoń­czył ana­li­zę biz­ne­so­wą i napi­sał raport z niej. Raport, któ­ry zawie­ra spe­cy­fi­ka­cją wyma­gań (naj­le­piej w for­mie jak opi­sa­na powy­żej). W zasa­dzie nad­zór autor­ski nad reali­za­cją tak­ty­ki wdro­że­nia sys­te­mu ERP (opro­gra­mo­wa­nia w ogó­le) to nic inne­go jak ?bycie pro­duct owne­rem? w pro­jek­cie na eta­pie jego reali­za­cji a SCRUM fak­tycz­nie, na dzi­siej­sze cza­sy, wyda­je się być naj­lep­szą meto­dą zarzą­dza­nia taki­mi pro­jek­ta­mi a utrzy­my­wa­nie aktu­al­no­ści doku­men­tu ana­li­zy biz­ne­so­wej i wyma­gań w toku pro­jek­tu pro­wa­dzi do tego, że po zakoń­cze­niu pro­jek­tu mamy ?nie­chcą­cy? kom­plet­ną i aktu­al­ną doku­men­ta­cje sta­nu uzy­ska­ne­go w toku wdro­że­nia. (Źródło: Kim jest pro­duct owner? | Jarosław Żeliński IT-Consulting)

Dzisiaj kil­ka słów na temat kwe­stii finan­so­wych, to jest porów­na­nia kosz­tów pro­jek­tu z ​„tra­dy­cyj­ną” ana­li­zą wyma­gań i ana­li­zą ​„zwin­ną”. Dotyczy przede wszyst­kim podej­ścia do wdro­żeń sys­te­mów ERP. Dwa lata temu pisałem:

Zarządzanie zmia­ną wyma­gań. To kolej­ne nie­chcia­ne dziec­ko w pro­jek­tach. Jeżeli zgo­dzi­my się, że zmia­na wyma­gań jest ?nor­mą? to brak wie­dzy (zapi­sów) o tych zmia­nach potra­fi zabić pro­jekt. Problem, któ­ry ja widzę w wie­lu pro­jek­tach to: im łatwiej zgło­sić i egze­kwo­wać zmia­nę w wyma­ga­niach tym wię­cej tych zmian jest. Nie cho­dzi o to by tych zmian zaka­zy­wać, cho­dzi o to by były one za każ­dym razem prze­my­śla­ne, a cho­dzi głów­nie o wpływ zmian na ter­min i budżet pro­jek­tu. (Źródło: Zarządzanie wyma­ga­nia­mi | Jarosław Żeliński IT-Consulting)

Mam za sobą dwa pro­jek­ty, któ­re poka­za­ły, że nale­ży szu­kać roz­wią­za­nia pro­ble­mu ​„nie­wie­dzy” o przy­szło­ści, jaką mamy w cza­sie gdy pro­jek­tu­je­my roz­wią­za­nie. W tych dwóch pro­jek­tach wdro­ży­łem nowe podej­ście, któ­re się dosko­na­le spraw­dza (ćwi­czę to w kolej­nych). Powodem było to, że obie fir­my (moi klien­ci) chcia­ły jak naj­szyb­ciej roz­po­cząć pra­ce nad pro­jek­tem wdro­że­nio­wym by nie opóź­niać momen­tu zastą­pie­nia sta­re­go sys­te­mu nowym. Obie fir­my mia­ły za sobą poraż­ki poprzed­nie­go wdro­że­nia, któ­re poka­za­ły, że roz­po­czy­na­nie pro­jek­tu od wybo­ru pro­duk­tu i jego dostaw­cy rodzi ogrom­ne ryzy­ko zarów­no prze­pła­ce­nia za ana­li­zę wyma­gań (przed-wdro­że­nio­wą u dostaw­cy) jak i utra­ty pano­wa­nia nad zakre­sem wła­sne­go pro­jek­tu, bo od pod­pi­sa­nia umo­wy z dostaw­cą zarzą­dzał on zakre­sem jako autor ana­li­zy wymagań.

Niedawno napi­sa­łem o tym, że war­to mieć model archi­tek­tu­ry biz­ne­so­wej, która:

…sta­je się stan­dar­dem w dobrze zarzą­dza­nych fir­mach, kon­ty­nu­ują­cych aktu­ali­za­cję doku­men­ta­cji powsta­łej na eta­pie ana­li­zy biz­ne­so­wej jako nad­zo­ru autor­skie­go w toku pro­jek­tu wdro­że­nio­we­go. Powoli przy­by­wa tak­że firm, widzą­cych powyż­sze korzy­ści w bie­żą­cym zarzą­dza­niu, dostrze­ga­ją tak­że to, że posia­da­nie aktu­al­nej Architektury Biznesowej jest efek­tyw­niej­sze niż zle­ca­ne ?z dosko­ku? ana­li­zy biz­ne­so­we i ana­li­zy przed­wdro­że­nio­we. (Źródło: Architektura Biznesowa jako war­tość doda­na fir­my | Jarosław Żeliński IT-Consulting)

W czym problem?

W kosz­tach i cza­sie trwa­nia tego co nazy­wa­my ana­li­zą biz­ne­so­wą koń­czą­ca się spe­cy­fi­ka­cją wyma­gań oraz kosz­tach aktu­ali­za­cji spe­cy­fi­ka­cji wymagań.

W ogrom­nej czę­ści pro­jek­tów, to co było opi­sa­ne jako wyma­ga­nia nie ma nic wspól­ne­go z tym co w koń­cu fak­tycz­nie powsta­ło i zosta­ło odda­ne do użyt­ku. Oznacza to, że powsta­nie tych spe­cy­fi­ka­cji wyma­gań w ich ówcze­snej posta­ci, nie mia­ły żad­ne­go sensu…

Najczęściej spo­ty­ka­ne ​„typo­we” podej­ście do wyma­gań pole­ga na tym, że ana­li­za wyma­gań bazu­ją­ca na wie­lo­dnio­wych warsz­ta­tach obfi­tu­ją­cych w zapi­sy­wa­ne szcze­gó­ły, koń­czy się deta­licz­ną, obszer­ną Specyfikacją Wymagań na sys­tem ERP (sys­te­my dedy­ko­wa­ne tak­że cier­pią na tę cho­ro­bę), któ­ra sta­je się załącz­ni­kiem do umo­wy na wdro­że­nie, dostaw­ca zaś restryk­cyj­nie reali­zu­je tak spi­sa­ne wyma­ga­nia, w toku pro­jek­tu nie raz zama­wia­ją­cy żąda zmia­ny, jeże­li oka­że się, że zmie­ni­ły się realia. Bardzo czę­sto pro­po­nu­je wyko­naw­ca z powo­du trud­no­ści na jakie napo­ty­ka. Biorąc pod uwa­gę tak­że zmia­ny na ryn­ku, tych zmian jest w pro­jek­tach rela­tyw­nie dużo. Bardzo czę­sto zwo­len­ni­cy agi­le mówią: sko­ro te wyma­ga­nia się zmie­nia­ją a klient i tak nie wie cze­go chce to nie rób­my żad­nej doku­men­ta­cji, rób­my czę­sto spo­tka­nia i notat­ki z nich. To jest jed­nak jesz­cze gor­sze, bo roz­po­czy­na­jąc pro­jekt nikt nie wie co powsta­nie, zakres pro­jek­tu to cha­os, więc nikt nie wyce­ni tego, a biz­nes dąży jed­nak do umów o pla­no­wa­nych budże­tach, czy­li fixed-pri­ce. Kwadratura koła?

Nie. Można, zamiast szcze­gó­ło­wo spi­sy­wać (zbie­rać w ramach wywia­dów i warsz­ta­tów) wyma­ga­nia, sku­pić się na archi­tek­tu­rze i logi­ce biz­ne­so­wej oraz jej odwzo­ro­wa­niu w sys­te­mie ERP.

Na powyż­szym dia­gra­mie poka­za­no (linia obra­zu­je kosz­ty nara­sta­ją­co, kosz­ty uwzględ­nia­ją tak­że zaan­ga­żo­wa­nie pra­cow­ni­ków zamawiającego):

1. linia czer­wo­na: naj­pierw opra­co­wa­nie szcze­gó­ło­wej spe­cy­fi­ka­cji wyma­gań, po roz­po­czę­ciu reali­za­cji, w toku pro­jek­tu, każ­da wyma­ga­na zmia­na w sto­sun­ku do sta­nu z cza­su powsta­nia spe­cy­fi­ka­cji (lub od ostat­niej aktu­ali­za­cji), wyma­ga refak­to­ry­za­cji doku­men­tu spe­cy­fi­ka­cji (aktu­ali­za­cji wyma­gań, kolej­na linia wzrostowa),
2. linia zie­lo­na, na począt­ku zamiast szcze­gó­ło­wej spe­cy­fi­ka­cji, powsta­je model biz­ne­so­wy i tyl­ko archi­tek­tu­ra przy­szłe­go roz­wią­za­nia (trwa to kró­cej i jest tań­sze), szcze­gó­ły wyma­gań usta­la­ne są na bie­żą­co (linia kosz­tów sta­le rośnie jed­nak znacz­nie wol­niej), robi to Product Owner repre­zen­tu­ją­cy zama­wia­ją­ce­go (zakres pro­jek­tu powi­nien być zarzą­dza­ny przez kupu­ją­ce­go); jed­nak archi­tek­tu­ra i logi­ka biz­ne­so­wa pozo­sta­ją prak­tycz­nie nie­zmien­ne bo sta­no­wią fun­da­ment całe­go systemu.

Co cie­ka­we wyma­ga­nia jako archi­tek­tu­ra i lista reguł i usług biz­ne­so­wych, pozwa­la­ją dostaw­cy na wyce­nę, opra­cu­je on ​„kon­cep­cje wdro­że­nia”. Całkowity nakład pra­cy i kosz­ty po stro­nie kupu­ją­ce­go poświę­co­ne na pra­ce ana­li­tycz­no-pro­jek­to­we są łącz­nie znacz­nie niż­sze. W wer­sji ​„czer­wo­nej” dostaw­ca przej­mu­je zarzą­dza­nie wyma­ga­nia­mi od ana­li­ty­ka po zakoń­cze­niu pier­wot­nej ana­li­zy (w dniu pod­pi­sa­nia umo­wy). W wer­sji zie­lo­nej zakres pro­jek­tu cały czas ma w ręku zama­wia­ją­cy, repre­zen­tu­je go mery­to­rycz­nie ana­li­tyk, któ­ry naj­pierw opra­co­wu­je ana­li­zę a potem spra­wu­je nad­zór autor­ski (jako [[pro­duct owner]]). Komunikacja pole­ga na uzu­peł­nia­niu spe­cy­fi­ka­cji o kolej­ne szcze­gó­ły, w mia­rę jak są one potrzeb­ne fir­mie wdra­ża­ją­cej (reali­za­tor żąda tych szcze­gó­łów por­cja­mi w toku pro­jek­tu). Żadne pra­ce nad spe­cy­fi­ka­cją nie idą na mar­ne (niż­sze koszty).

Porównanie tra­dy­cyj­nej zwin­nej meto­dy two­rze­nia wyma­gań i zarzą­dza­nia nimi:

A tu pro­ce­du­ra zarzą­dza­nia zmianą:

Zmiany może zgła­szać zarów­no Wykonawca jak i Zamawiający, a zgła­sza je wła­śnie do Product Ownera, któ­ry oce­nia ich wpływ na całość i refe­ru­je skut­ki Zamawiającemu, ten – po ana­li­zie – akcep­tu­je lub odrzu­ca propozycję.

P.S.

Polecam świet­ny arty­kuł Pana Mecenasa Łukasza Węgrzyna na temat tego jak to zawrzeć w umo­wie.