Wczoraj pod­czas spo­tka­nia, mia­łem cie­ka­wą roz­mo­wę z przed­sta­wi­cie­la­mi jed­ne­go z pro­du­cen­tów sys­te­mów ERP. Okazało się, że mają bar­dzo podob­ne do moich doświad­cze­nia i wnio­ski: pod­czas wdro­że­nia sys­te­mu ERP potrzeb­ny im jest ktoś, jeden, kto zna i rozu­mie jak dzia­ła dana fir­ma, a nie set­ki stron doku­men­ta­cji czy ste­no­gra­my z dzie­siąt­ków godzin warsz­ta­tów z przy­szły­mi użyt­kow­ni­ka­mi. Do tego fir­ma ta – nabyw­ca sys­te­mu ERP – powin­na mieć, nie szcze­gó­ło­wo opi­sa­ne dzie­siąt­ki deta­licz­nie opi­sa­nych pro­ce­sów i ich warian­tów, pro­ce­dur czy set­ki i tysią­ce nie raz wyma­gań, a stra­te­gię i tak­ty­kę, z któ­rej wyni­ka (da się wyczy­tać) rola opro­gra­mo­wa­nia ERP w fir­mie: tak­ty­kę czy­li opis reali­za­cji stra­te­gii fir­my z pomo­cą pla­no­wa­ne­go do wdro­że­nia sys­te­mu ERP. Ta tak­ty­ka, to opis tego kie­dy i po co opro­gra­mo­wa­nie ma wspie­rać pra­cow­nikw orga­ni­za­cji. To, jak się to będzie odby­wa­ło w szcze­gó­łach, zosta­nie opra­co­wa­ne przez dostaw­cę (wyko­naw­cę) kon­kret­ne­go pro­duk­tu, to dostaw­ca goto­we­go opro­gra­mo­wa­nia opra­co­wu­je kon­cep­cję wdro­że­nia, na pod­sta­wie doku­men­tu opi­su­ją­ce­go tak­ty­kę uży­cia tego opro­gra­mo­wa­nia i wyma­ga­nia biz­ne­so­we (opro­gra­mo­wa­nie dedy­ko­wa­ne wyma­ga dodat­ko­wo zapro­jek­to­wa­nia i udo­ku­men­to­wa­nia logi­ki biz­ne­so­wej jaką ma ono realizować).

I co teraz? Teraz potrzeb­ne jest źró­dło spój­nej wie­dzy o orga­ni­za­cji, jej stra­te­gii i tak­ty­ce w któ­rą ma się wpa­so­wać opro­gra­mo­wa­nie ERP. Któż jest tym źró­dłem? [[Product owner]].

Pytane teraz brzmi: kim jest i człon­kiem czy­je­go zespo­łu jest (powi­nien być) pro­duct owner”? Tu zacy­tu­ję osta­ni aka­pit mojej cie­płej jesz­cze recen­zji książki:

…na ile wizja pro­duk­tu upraw­nia jej posia­da­cza do aktyw­ne­go kie­ro­wa­nia pro­jek­tem wraz z kie­row­ni­kiem pro­jek­tu (Scrum Master), ale to pozo­sta­wiam czy­tel­ni­kom i prak­ty­kom. Jedno moim zda­niem jest pew­ne: nie ma sen­su by zespół deve­lo­pe­ra kon­tak­to­wał się, z tabu­nem przy­szłych ?use­rów?, ma sens by dosta­wał spój­ną wie­dzę o tym co tak na praw­dę ma powstać.

Źródło: Agile Product Management with Scrum | Jarosław Żeliński IT-Consulting

Autor powyż­szej książ­ki nie daje wprost odpo­wie­dzi na to pyta­nie, jed­nak mil­czą­co zakła­da też, że to zespół dostaw­cy wal­czy” ze zja­wi­skiem i pro­duct owner jest człon­kiem tego zespo­łu, nie zmie­nia to fak­tu, że wyma­ga­na od nie­go wie­dza i zro­zu­mie­nie tego, do cze­go user będzie uży­wał opro­gra­mo­wa­nia, powin­na być taka jak opi­sa­łem wyżej.

Co usły­sza­łem po raz kolej­ny (podob­ne roz­mo­wy z dostaw­ca­mi opro­gra­mo­wa­nia nie raz już pro­wa­dzi­łem) od przed­sta­wi­cie­li dostaw­cy sys­te­mu ERP? Potrzebują bar­dzo zwię­złej i spój­nej doku­men­ta­cji (ale raczej 50-ciu stron niż setek, że nie wspo­mnę o kil­ku tysią­cach (tak – widy­wa­łem takie) i po stro­nie klien­ta (jed­nej) oso­by, któ­ra ten doku­ment zna, rozu­mie, ma dostęp do klu­czo­wych osób w orga­ni­za­cji. Najchętniej do auto­ra tego doku­men­tu… Dostawcy opro­gra­mo­wa­nia jak dosta­ją listę setek pozy­cji wyma­gań podzie­lo­nych w mało zro­zu­mia­ły spo­sób na funk­cjo­nal­ne i poza funk­cjo­nal­ne (i inne) raczej sobie z tych spe­cy­fi­ka­cji dwo­ru­ją niż cie­szą się z ich otrzy­ma­nia (pomi­jam, ze nie czy­ta­ją w cało­ści). Po co są więc robio­ne? Bo zama­wia­ją­cy postrze­ga swo­ją pra­cę przez pry­zmat jej zło­żo­no­ści, warian­to­wo­ści, nie patrzy z per­spek­ty­wy narzę­dzia a tym wła­śnie jest opro­gra­mo­wa­nie. To tak jak by cie­śla lub sto­larz opi­sał wyma­ga­nia na mło­tek cie­siel­ski w posta­ci setek stron user sto­ry” o tym jak, do cze­go i kie­dy używa(łby) młot­ka.. dla ana­li­ty­ka pro­jek­tan­ta taki opis (a kon­kret­nie jego ską­pa część) ma sens, dla kon­struk­to­ra – żad­ne­go, ten raczej ocze­ku­je rysun­ku tech­nicz­ne­go wykonawczego.

The role of Product Owner (Scott Ambler, Agile Modeling)
The role of Product Owner (Scott Ambler, Agile Modeling)

Powyższy dia­gram to poglą­do­wy model roli pro­duct owne­ra (PO) autor­stwa jed­ne­go z moich ulu­bio­nych zwin­nych ana­li­ty­ków”: Scott’a Amblera (Scott Ambler). Niewątpliwie moż­na dywa­go­wać czy PO to pra­cow­nik” dosa­tw­cy czy kupu­ją­ce­go ale tu chy­ba część wąt­pli­wo­ści roz­wie­ją sło­wa jed­ne­go z moich klien­tów, postrze­gam go jako jed­ne­go z lepiej zarzą­dza­ją­cych ryzy­kiem biz­ne­so­wym, zna­nych mi, pre­ze­sów firm: Panie Jarku nie wiem czy jest Pan lep­szym czy gor­szym spe­cja­li­stą od ludzi dostaw­cy, zatrud­ni­łem Pana bo prze­ło­żo­nym tam­tych jest Prezes tam­tej firmy”.

Where Do Product Owners Come From? The goods news is that the­re are seve­ral via­ble options for whe­re Product Owners may come from: Business ana­lyst. Although a tra­di­tio­nal busi­ness ana­lyst could fill the role of pro­duct owner, the­re is a risk that they will fall into the­ir old habits of com­mu­ni­ca­ting via docu­men­ta­tion. Keep in mind that what agi­le teams real­ly need are people with agi­le ana­ly­sis skills who are empo­we­red to make deci­sions. So, a bet­ter option is an empo­we­red agi­le busi­ness ana­lyst. (za The Product Owner Role: A Stakeholder Proxy for Agile Teams).

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żenia.

(książ­ki Scotta Amblera cze­ka­ją na recenzję ;))

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).

Dodaj komentarz

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