Kim jest product owner?

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ę ;))

Po co komu analityk a jeśli tak to jaki czyli bałagan w administracji

Pytanie to wra­ca jak bume­rang. Z regu­ły, gdy sły­szę sło­wo ana­li­tyk” w kon­tek­ście pro­jek­tów zwią­za­nych z two­rze­niem opro­gra­mo­wa­nia poja­wia się ktoś, kto zbie­ra wyma­ga­nia”. Z regu­ły ana­li­ty­ka” wypusz­cza się do przy­szłych użyt­kow­ni­ków, któ­rzy prze­ści­ga­ją się w pomy­słach na temat tego jakie to opro­gra­mo­wa­nie ma być. Niestety to spon­sor pro­jek­tu, pierw­sze co robi naj­czę­ściej, to wska­zu­je kogoś z przy­szłych użyt­kow­ni­ków (a z regu­ły cały ich zespół) jako źró­dło infor­ma­cji o wyma­ga­niach”. Takie podej­ście zale­ca­ją tak­że, w swo­im inte­re­sie, dostaw­cy opro­gra­mo­wa­nia. Użytkownicy, nie mając (z regu­ły) poję­cia jaki cel ma pro­jekt (poza tym, że to dla nich to opro­gra­mo­wa­nie), nie tyl­ko pusz­cza­ją wodze wyobraź­ni zmie­sza­ne ze swo­imi dotych­cza­so­wy­mi doświad­cze­nia­mi, ale tak­że ucie­le­śnia­ją swo­je pomy­sły by jed­no­cze­śnie stro­nić od odpo­wie­dzial­no­ści. Nie będąc spe­cja­li­sta­mi ani w dzie­dzi­nie inży­nie­rii opro­gra­mo­wa­nia ani zarzą­dza­nia, nie są w sta­nie wery­fi­ko­wać pro­po­zy­cji dostaw­cy, przyj­mu­ją więc bezkrytycznie.

Formę eks­tre­mal­na przy­bie­ra to zja­wi­sko admi­ni­stra­cji publicz­nej, a co gor­sza idzie w jesz­cze gor­sza stro­nę. Spójrzmy na argu­men­ty za zmia­na­mi w usta­wie PZP:

Przeprowadzenie jed­ne­go postę­po­wa­nia [pro­jek­to­wa­nie i wyko­na­nie, przyp. mój] jest dużym uła­twie­niem dla zama­wia­ją­cych, ale jego skut­ki mogą się oka­zać niezadowalające.

Możliwość obję­cia jed­nym zamó­wie­niem prac pro­jek­to­wych i budow­la­nych, a tym samym unik­nię­cie koniecz­no­ści prze­pro­wa­dza­nia dwóch odręb­nych postę­po­wań o udzie­le­nie zamó­wie­nia, jest dużą zale­tą dla zama­wia­ją­cych. Tym zapew­ne nale­ży tłu­ma­czyć popu­lar­ność zamó­wień typu ?zapro­jek­tuj i buduj?.

Również opra­co­wa­nie pro­gra­mu funk­cjo­nal­no-użyt­ko­we­go nie­wąt­pli­wie wyma­ga mniej­sze­go nakła­du sił, środ­ków i cza­su niż stwo­rze­nie doku­men­ta­cji pro­jek­to­wej oraz spe­cy­fi­ka­cji tech­nicz­nej wyko­na­nia i odbio­ru robót budow­la­nych potrzeb­nych w przy­pad­ku udzie­la­nia zamó­wień typu ?wybu­duj?. Zamawiającym wygod­niej jest prze­rzu­cić na wyko­naw­ców obo­wią­zek opra­co­wa­nia pro­jek­tu i innych potrzeb­nych doku­men­tów. (Zamówienia typu ?zapro­jek­tuj i buduj? według nowych zasad -.…)

W zasa­dzie cała ta argu­men­ta­cja spro­wa­dza się do: zama­wia­ją­cy nie chce nicze­go robić ani brać jakiej­kol­wiek odpo­wie­dzial­no­ści”. Z uwa­gi na to, że taka for­ma jest tak­że bar­dzo korzyst­na dla wyko­naw­ców (sami sobie sta­wia­ją wyma­ga­nia) otrzy­mu­je­my kon­struk­cję: urząd wyda­je nie swo­je pie­nią­dze, całość prac mery­to­rycz­nych (poza opra­co­wa­niem SIWZ) prze­rzu­ca na dostaw­cę, któ­ry tym samym pro­jek­tu­je sam dla sie­bie i przyj­mu­je potem za to pie­nią­dze. W zasa­dzie nie było by pro­ble­mu gdy­by nie to, że my – oby­wa­te­le – za to wszyst­ko płacimy:

Rozmowa z Jarosławem Żelińskim: Sami wymy­ślą, sami zro­bią i sami oce­nią. Skąd tak duże róż­ni­ce mię­dzy efek­ta­mi infor­ma­ty­za­cji pry­wat­nych firm a infor­ma­ty­za­cją urzę­dów? (Informatyzacja admi­ni­stra­cji, czy­li naj­lep­szy spo­sób na total­ną klę­skę | Forsal​.pl – Giełda, Waluty, Finanse).

Jak widać pro­blem jest zna­ny nie od dziś, a mimo to powsta­ją usta­wo­we pomy­sły zmie­rza­ją­ce w tę gor­szą stronę.

W tym kon­tek­ście przy­to­czę pewien urzę­do­wy wątek. Ostatnio gło­śno się zro­bi­ło o nad­uży­wa­niu dostę­pu do infor­ma­cji publicz­nej”. Ciekawa dys­ku­sja na temat roz­go­rza­ła na stro­nach VaGla​.pl (frag­men­ty):

inco­gni­tus: Pozostaje zatem pyta­nie dla­cze­go wszel­kie urzę­dy wszyst­kie­go auto­ma­tycz­nie nie publi­ku­ją w BIP? Jak by to było robio­ne z auto­ma­tu to praw­do­po­dob­nie takie czyn­no­ści tech­nicz­ne były­by łatwiej­sze i szyb­sze dla urzę­du, niż publi­ko­wa­nie wybior­cze, a póź­niej odpo­wia­da­nie na set­ki wnio­sków o udostępnienie. […]

xpert17: Odpowiedź wyni­ka­ją­ca z teo­rii zarzą­dza­nia jest pro­sta – urząd nie ma żad­ne­go inte­re­su, żeby wyko­ny­wać coś łatwiej i szyb­ciej. Wręcz prze­ciw­nie, sta­ty­stycz­ny urzęd­nik (może nawet pod­świa­do­mie) będzie tak reali­zo­wał swo­je zada­nia, żeby wszyst­ko odby­wa­ło się jak naj­dłu­żej i anga­żo­wa­ło jak naj­wię­cej ludzi – dzię­ki temu uza­sad­nia sens ist­nie­nia swo­je­go miej­sca pra­cy. Gdyby wszyst­ko z auto­ma­tu” tra­fia­ło do BIP, mogło­by się oka­zać, że w dzia­le zaj­mu­ją­cym się wymy­śla­niem przy­czyn odmo­wy udzie­la­nia infor­ma­cji publicz­nej jest prze­rost zatrudnienia. […]

Nieco sar­ka­stycz­na powyż­sza odpo­wiedź nie­ste­ty nie­sie pew­ne wyja­śnie­nie tej sytu­acji. Tak więc patrząc na powyż­sze: czy ma sens by wyma­ga­nia na opro­gra­mo­wa­nie dla urzę­du pisa­li urzęd­ni­cy? Czy da się zro­bić opro­gra­mo­wa­nie lep­sze? Zapewniam, że da się:

Jarek Żeliński: wystar­czy dobrze opi­sać wyma­ga­nia” na sys­tem elek­tro­nicz­ne­go obie­gu doku­men­tów z wła­ści­wą” obsłu­ga meta­da­nych i publi­ka­cja w BIP będzie auto­ma­tycz­na”, pro­blem w tym, że (powo­łu­jąc się na przed­mów­cę) żaden urzęd­nik nie napi­sze takich wyma­gań – i to jest jeden z powo­dów moje­go zda­nia: nie ma żad­ne­go sen­su, żeby wyma­ga­nia na opro­gra­mo­wa­nie pisał/dyktował (i wszel­kie inne idio­tycz­ne meto­dy zbie­ra­nia wyma­gań bazu­ją­ce na tym co powie user) jego przy­szły użyt­kow­nik! A jest to stan­dard” nie tyl­ko w urzę­dach. (Umowa mię­dzy KPRM a brandADDICTED na wspar­cie komu­ni­ka­cyj­ne | pra­wo | VaGla​.pl Prawo i Internet).

Bo cóż może powstać w Urzędzie, jeże­li będzie­my sto­so­wa­li zasa­dę: użyt­kow­nik sta­wia wyma­ga­nia? A na przy­kład może­my zoba­czyć frag­ment prze­pi­su kuli­nar­ne­go w Centralnej Bazie Orzeczeń Sadów Administracyjnych (pole­cam lek­tu­rę całe­go arty­ku­ły na VaGla​.pl), tu tyl­ko moje zda­nie na ten temat:

Te powyż­sze ośmie­sza­ją­ce tre­ści to moim zda­niem efekt złe­go pro­jek­tu opro­gra­mo­wa­nia słu­żą­ce­go do ano­ni­mi­za­cji, gdzie nie tyl­ko ope­ra­cja copy-paste powin­na być zablo­ko­wa­na, ale sam pro­ces powi­nien być tak zapro­jek­to­wa­ny by, z natu­ry mylą­cy się czło­wiek, miał jak naj­mniej oka­zji by się mylić. Po trze­cie, sys­tem ano­ni­mi­za­cji dopusz­cza­ją­cy inge­ren­cję w treść orze­czeń po ich upra­wo­moc­nie­niu to masa­kra, to mega­bu­bel, auto­ra tego opro­gra­mo­wa­nia. (Centralna Baza Orzeczeń Sądów Administracyjnych +1 ząbek czosn­ku | pra­wo | VaGla​.pl Prawo i Internet).

Ale nie­ste­ty, to są skut­ki sto­so­wa­nia meto­dy pole­ga­ją­cej na pro­wa­dze­niu ana­liz wyma­gań meto­dą zbie­ra­nia wyma­gań od przy­szłych użyt­kow­ni­ków”, nie wyobra­żam sobie by tą meto­dą powstał inny sys­tem ano­ni­mi­za­cji niż ten, któ­ry powstał.

A jak to robić?

Wpadła mi nie­daw­no w oko rewe­la­cyj­na w swo­jej pro­sto­cie defi­ni­cja roli ana­li­ty­ka, poja­wi­ła się na jed­nej z wie­lu dys­ku­sji o wyma­ga­niach w ser­wi­sie LinkedIn (źr. http://www.its-all-design.com/a‑graphical-functional-specification-part‑1/):

defincija roli analityka

(ana­li­tyk, współ­pra­cu­jąc z oso­ba­mi zain­te­re­so­wa­ny­mi reali­za­cją celów pro­jek­tu – inte­re­sa­riu­sze – two­rzy spe­cy­fi­ka­cję wymagań/rozwiązania, któ­ra inte­re­sa­riusz wdro­ży do reali­za­cji swo­ich celów).

Warto zwró­cić uwa­gę na to, że tu tak­że nie ma mitycz­ne­go use­ra”. Cel biz­ne­so­wy pro­jek­tu ma ktoś uza­leż­nio­ny od wyni­ków pro­jek­tu. Skoro więc urząd nie ma żad­ne­go inte­re­su, żeby wyko­ny­wać coś łatwiej i szyb­ciej. Wręcz prze­ciw­nie…” nasu­wa się pyta­nie: jaki ma więc sens by urzęd­ni­cy, któ­rzy poten­cjal­nie nie mają żad­ne­go inte­re­su w tym, by uspraw­niać swo­ją pra­cę, two­rzy­li wyma­ga­nia na opro­gra­mo­wa­nie, któ­re powin­no im uspraw­nić pracę?

Analizy wyma­gań nie tyl­ko w admi­ni­stra­cji są pro­wa­dzo­ne, jako wywia­dy i spis życzeń przy­szłych użyt­kow­ni­ków. Czasami te pseu­do ana­li­zy wyma­gań” to beł­kot będą­cy spi­sem żądań pra­cow­ni­ków a ich inte­re­sie. Osobiście byłem kie­dyś świad­kiem, jak tak zwa­ny ana­li­tyk wyma­gań” (dla mnie czło­wiek dyk­ta­fon a nie ana­li­tyk) pew­ne­go lide­ra IT w tym kra­ju, zapi­sał w doku­men­ta­cji wyma­gań, pod dyk­tan­do sze­fo­wej sekre­ta­ria­tu: sys­tem powi­nien pozwa­lać na pod­pi­sy­wa­nie w sekre­ta­ria­cie doku­men­tów decy­zji admi­ni­stra­cyj­nych z pomo­cą prze­ter­mi­no­wa­ne­go pod­pi­su elek­tro­nicz­ne­go” (cho­dzi­ło o wygo­dę tej pani), masa­kra. Zrobiłem raban, obra­żo­na pani z sekre­ta­ria­tu stwier­dzi­ła, że ona jest w tym pro­jek­cie eks­per­tem dzie­dzi­no­wym i ona dyk­tu­je nie ja. Ten zapis jed­nak wyle­ciał (pola­złem do jej sze­fa), na mnie była skar­ga bo nie potra­fię pra­co­wać w zespole”.

Być może więc za spe­cy­fi­ko­wa­nie wyma­gań na opro­gra­mo­wa­nie powin­ny odpo­wia­dać urzę­dy cen­tral­ne od razu po tym, jak nało­żą jakiś usta­wo­wy obo­wią­zek na pod­le­głe im urzę­dy? Wtedy mamy oso­bę” ana­li­ty­ka, któ­ry wyko­na ana­li­zę nowej usta­wy i opra­cu­je wyma­ga­nia na opro­gra­mo­wa­nie. Firma, któ­ra wygra prze­targ, zapew­ne w ramach swo­jej ana­li­zy i opra­co­wa­nia kon­cep­cji roz­wią­za­nia, popy­ta urzęd­ni­ków o jakieś szcze­gó­ły w rodza­ju wewnętrz­na orga­ni­za­cja pra­cy urzę­du, struk­tu­ry obo­wiąz­ków i kom­pe­ten­cji itp. ale nie o to co urzęd­nik ma robić a cze­go nie!

I dokład­nie takie samo podej­ście pole­cam fir­mom: sza­now­ni człon­ko­wie zarzą­dów i rad nad­zor­czych, zanim wybie­rze­cie pro­dukt lub wyko­naw­ce opro­gra­mo­wa­nia, jako inte­re­sa­riu­sze wła­snych pro­jek­tów, zleć­cie ana­li­zę i opra­co­wa­nie spe­cy­fi­ka­cji i dopie­ro potem pozwa­laj­cie wła­snym Waszym pra­cow­ni­kom decy­do­wać o Waszych fir­mach, jeże­li już, to niech to będą przy­naj­mniej Wasze wyż­sze kadry kierownicze.

User Stories, czym jest?

O opi­so­wych meto­dach zbie­ra­nia wyma­gań napi­sa­no wie­le, eks­pe­ry­men­tu­ję cza­sa­mi z tek­sta­mi” i nabie­ram pew­ne­go prze­ko­na­nia: jako opis wyma­gań, czy­li jak chce to robić” (np. przy­pad­ków uży­cia) raczej nie, jako opis celu dzia­ła­nia, czy­li co chce osiągnąć/po co mi to” jak naj­bar­dziej. Tak więc opis z ręki zama­wia­ją­ce­go jako wsad do ana­li­zy” jak naj­bar­dziej, ale user sto­ry jako wyma­ga­nia”, raczej na pew­no nie (czy­taj User Story – kło­po­ty)…

User Story jaki jak” z regu­ły nie­ste­ty stwa­rza pro­ble­my i słusz­nie zauwa­żo­no, że:

User Story w posta­ci: Obsługa błę­dów i ich logo­wa­nie powin­no się odby­wać poprzez wspól­ny mecha­nizm” jest kiep­skim pomy­słem. Co praw­da widzi­my dość jasno, że to wyma­ga­nie jest war­to­ścio­we, ale czy użytkownik/klient będzie potra­fił oce­nić jego war­tość? Dodatkowo taki zapis zawie­ra w sobie suge­stię na temat imple­men­ta­cji spo­so­bu obsłu­gi błę­dów – czy z punk­tu widze­nia klien­ta ma to zna­cze­nie? Pamiętajmy też, że jako ana­li­ty­cy (lub jako pro­duct owner w Scrumie) nie chce­my suge­ro­wać roz­wią­za­nia pro­gra­mi­stom, któ­rzy czę­sto lepiej od nas zna­ją się na tech­no­lo­gii, któ­rej będą uży­wać. My powin­ni­śmy napi­sać, co chce osią­gnąć użyt­kow­nik i pozwo­lić pro­gra­mi­stom wybrać naj­lep­szy spo­sób imple­men­ta­cji roz­wią­za­nia. (Wartościowe User Stories ? O wymaganiach).

Moim zda­niem tak zwa­ne user sto­ry powin­no być napi­sa­ne: po pierw­sze języ­kiem zama­wia­ją­ce­go, po dru­gie wyłącz­nie o tym co zama­wia­ją­cy rozu­mie. Dlaczego? Bo tyl­ko wte­dy autor tego tek­stu – tego wyma­ga­nia”, zama­wia­ją­cy – jest w sta­nie sam oce­nić jego sens i praw­dzi­wość” a tak­że przy­dat­ność. Gdzie tu rola ana­li­ty­ka? Analiza to spro­wa­dze­nie tych opi­sów do okre­ślo­nej struk­tu­ry wraz z okre­ślo­ną logi­ką – for­ma­li­za­cja. Rolą ana­li­ty­ka jest na tym eta­pie usu­wa­nie nie­jed­no­znacz­no­ści. Kolejny etap to dopro­wa­dze­nie doku­men­tu wyma­gań do spój­no­ści. Jeżeli uzna­my, że wyma­ga­nia to testy, to rolą ana­li­ty­ka jest wyspe­cy­fi­ko­wa­nie wyma­gań w posta­ci testów (przy­po­mi­nam, że wyma­ga­nia to warun­ki jakie musi speł­nić coś, by było przy­dat­ne do okre­ślo­ne­go celu), wszę­dzie tam, że wyma­ga­na jest jakaś logi­ka biz­ne­so­wa”, nale­ży ją tak­że udokumentować.

Jak słusz­nie powy­żej zauwa­żył autor cyta­tu, nale­ży pozwo­lić pro­gra­mi­stom wybrać naj­lep­szy spo­sób imple­men­ta­cji roz­wią­za­nia”, ale tu waż­na uwa­ga: imple­men­ta­cja to nie roz­wią­zy­wa­nie pro­ble­mów biz­ne­so­wych. Innymi sło­wy, pro­gra­mi­sta nie może dostać wyma­ga­nia w posta­ci sprze­daż towa­ru to pobra­nie go z maga­zy­nu”, bo po pierw­sze nie wie co to jest towar” po dru­gie nie zawsze jest to pobra­nie z maga­zy­nu. Należy mieć świa­do­mość, że towar” z per­spek­ty­wy pro­gra­mi­sty to struk­tu­ral­ny opis” i nie on ten opis powi­nien robić. Kto? Analityk.

Tak wiec powyż­sze, cyto­wa­ne user sto­ry raczej powin­no mieć postać: celem admi­ni­stra­to­ra opro­gra­mo­wa­nia jest śle­dze­nie zacho­wa­nia sys­te­mu i wychwy­ty­wa­nie zaist­nia­łych błę­dów w jego zacho­wa­niu, infor­ma­cje o błę­dach powi­nien otrzy­my­wać natych­miast” oraz dodat­ko­wo (robo­ta ana­li­ty­ka) powi­nien ist­nieć słow­nik biz­ne­so­wy z defi­ni­cją poję­cia błąd opro­gra­mo­wa­nia” oraz natych­miast”. Rolą pro­gra­mi­sty jest prze­ło­że­nie tego na język uży­te­go narzę­dzia (języ­ka pro­gra­mo­wa­nia) oraz zapew­nie­nie by powsta­łe opro­gra­mo­wa­nie było zgod­ne z ocze­ki­wa­ny­mi wyma­ga­nia­mi jako­ścio­wy­mi (wyma­ga­nie poza-funk­cjo­nal­ne: natychmiast).

Tak więc pro­gra­mi­sta imple­men­tu­je logi­kę biz­ne­so­wą, tę musi jed­no­znacz­nie udo­ku­men­to­wać ana­li­tyk, oraz zapew­nia uzgod­nio­ną jakość (wyma­ga­nia poza­funk­cjo­nal­ne). Ma więc dużo pra­cy… ale nie powi­nien podej­mo­wać prób wpły­wu na imple­men­to­wa­ną logi­kę biznesową.

miecz dwa ostrza dwustronny

Czyli np. jako sprze­daw­ca, dosta­ję od klien­tów zamó­wie­nia, na pod­sta­wie któ­rych muszę wysta­wiać fak­tu­ry VAT”, do tego ana­li­tyk doda, np. po ana­li­zie otrzy­ma­nej par­tii doku­men­tów, struk­tu­rę zamó­wie­nia i fak­tu­ry VAT oraz algo­rytm” wyli­cze­nia podatków.

Jeżeli pro­gra­mi­sta zaczy­na lepiej wie­dzieć” od zama­wia­ją­ce­go, for­su­jąc np. prost­szą imple­men­ta­cję, to zna­czy, że prze­kro­czył swo­je kom­pe­ten­cje, sam sobie – jako deve­lo­pe­ro­wi – robi krzyw­dę psu­jąc to opro­gra­mo­wa­nie bo klient i tak prę­dzej czy póź­niej na tych uprosz­cze­niach pole­gnie”. Rolą ana­li­ty­ka są tak­że ewen­tu­al­ne nego­cja­cje z zama­wia­ją­cym, uprosz­czeń lub roz­wi­nięć tego opi­su. Czy ana­li­tyk może być pra­cow­ni­kiem” dostaw­cy? Jak sądzicie?

Teoria a praktyka – czyli kompetencyjna tragedia

Od cza­su do cza­su spo­ty­kam się w pro­jek­tach z taki­mi oto teza­mi, wypo­wia­da­ny­mi przez kie­row­ni­ków pro­jek­tów, głów­nych archi­tek­tów itp.:

Wiedza aka­de­mic­ka to jed­no a wie­dza prak­tycz­na to dru­gie 😉 Nie da się tego połączyć :(„

To objaw tra­ge­dii kom­pe­ten­cyj­nej… takie zda­nie może wypo­wie­dzieć tyl­ko kom­plet­ny igno­rant, któ­re­go jedy­ną kom­pe­ten­cją (bo zakła­dam, że jakąś musi mieć, sko­ro zaj­mu­je to sta­no­wi­sko) jest chy­ba peł­na lojal­ność wobec pra­co­daw­cy i sku­tecz­ne wycią­ga­nie pro­to­ko­łów odbio­ru z klien­tów (czy­taj wycią­ga­nie pie­nię­dzy), nie dam gło­wy jak z ety­ką pracy.

Co jakiś czas czy­ta­my o poraż­kach pro­jek­tów w sfe­rze publicz­nej, zapew­niam, że są one nie takim rzad­kim zja­wi­skiem w sfe­rze pry­wat­nej. Dlaczego nie czy­ta­my o tym? Bo, na szczę­ście dla firm pry­wat­nych, nie doty­czy ich usta­wa o dostę­pie do infor­ma­cji publicz­nej itp., pro­jekt naby­wa sta­tus tajem­ni­ca kor­po­ra­cji„ « i nikt nie wie poza tymi, co bra­li udział w projekcie.

Miewam kon­sul­ta­cje, kore­pe­ty­cje, coaching itp. Pytany jestem czę­sto: czy zda­rza się Panu w pro­jek­tach, że np. kie­row­nik pro­jek­tu mówi, że nie waż­na jest jakość tych pro­jek­tów tyl­ko ter­min i pro­to­kół odbio­ru, klient i tak nie potra­fi tego skon­tro­lo­wać”. Powiem tak, zda­rza mi się i wte­dy – o ile to ja nie nad­zo­ru­je pro­jekt po stro­nie kupu­ją­ce­go – odma­wiam albo rezy­gnu­je z udzia­łu w pro­jek­cie, jed­nak ja nie mam umo­wy o pra­ce i nie jestem nią szan­ta­żo­wa­ny (jej utra­tą). Prawdę mówiąc nie wiem co mam tym ludziom mówić, poza powyż­szym oczy­wi­ście, ale i tak zawsze mówię: bądź uczci­wy (co jest bar­dzo trudne).

Ale co z ta teo­rią i prak­ty­ką? To trosz­kę jak z samo­cho­dem, wie­lu ludzi nimi jeź­dzi ale nie każ­dy rozu­mie dzia­ła­nie skrzy­ni bie­gów. Wielu ludzi wyuczy­ło się przy jakiej pręd­ko­ści zmie­niać bieg na wyż­szy, kie­dy redu­ko­wać, ale już nie każ­dy wie jak się zacho­wać jadąc pod gór­kę, z gór­ki, co to jest hamo­wa­nie sil­ni­kiem i kie­dy się to robi, dla­cze­go chcąc przy­śpie­szyć wrzu­ca­my wyż­szy bieg póź­niej… aby to wie­dzieć, nale­ży rozu­mieć. Dlatego wie­lu ludzi bez pro­ble­mu jeź­dzi samo­cho­dem do pra­cy czy na wcza­sy, ale już nie tak wie­lu radzi sobie z sytu­acja­mi nietypowymi…

Owszem moż­na się wie­lu rze­czy nauczyć na pamięć i teo­ria tu nie jest potrzeb­na, ale pro­stych sytu­acji na dro­dze jest mało, owszem są to te naj­pow­szech­niej­sze ale tyl­ko te. Każdy nie­try­wial­ny przy­pa­dek wyma­ga… no cze­go? Na pamięć? Nie – zro­zu­mie­nia tego czym się zaj­mu­je­my. Człowiek ma ogra­ni­czo­ne moż­li­wo­ści zapa­mię­ty­wa­nia, para­dok­sal­nie to, cze­go uży­wa­my rzad­ko, szyb­ko ula­tu­je z naszej gło­wy, to natu­ral­ny mecha­nizm mózgu.

Dlatego, nie­ste­ty, wie­dza teo­re­tycz­na, rozu­mie­nie, to pod­sta­wa w każ­dym nie­try­wial­nym pro­jek­cie. Nauka na pamięć to bar­dzo ogra­ni­czo­ne moż­li­wo­ści, ruty­niar­stwo i zupeł­ny brak moż­li­wo­ści roz­wią­zy­wa­nia nowych pro­ble­mów. Zrozumienie powo­du­je, że nicze­go nie musi­my się uczyć na pamięć i radzi­my sobie w nowych sytu­acjach, tak samo jak ze skrzy­nią bie­gów: kto rozu­mie temu nie gaśnie sil­nik… kto nie rozu­mie – zawsze będzie zwy­kłym kierowcą”…

kamien przepowiada pogode

Ignorowanie wie­dzy aka­de­mic­kiej, jest przy­czy­ną więk­szo­ści pora­żek, bar­dzo wie­le pro­jek­tów IT to jak lecze­nie ludzi przez zna­cho­rów: nie ma poję­cia o ana­to­mii i wpły­wie sub­stan­cji che­micz­nych na ludzi ale z upo­rem mania­ka ser­wu­je ludziom pijaw­ki, suple­men­ty, pseu­do­le­ki, upusz­cza­nie krwi itp. wie­lu z takich zna­cho­rów do koń­ca życia uwa­ża, że aka­de­mia medycz­na szko­dzi i tych leka­rzy” nale­ży się bać…

Zacytuję: praw­dzi­wa wie­dza to zna­jo­mość przy­czyn” (Arystoteles), bez tego wie­lu PM,ów dosko­na­le ope­ru­je ryzy­ka­mi oce­nia­ny­mi z ich boga­te­go doświad­cze­nia ale nie ma bla­de­go poję­cia od cze­go one zale­żą… tak powsta­ła cała AGILE meto­dy­ka: reagu­je­my na to co zaob­ser­wu­je­my, dokład­nie tak jak góra­le pro­gno­zu­ją pogodę…

Swego cza­su pewien, jak sam o sobie mówi, bar­dzo doświad­czo­ny tester opro­gra­mo­wa­nia (czy­taj dłu­go pra­cu­je) napi­sał do mnie, że dobre testy to … i tu lita­nia metod. Doskonale rozu­miem spoj­rze­nie tego teste­ra, takie «kom­pe­ten­cje” widu­ję czę­sto. Z per­spek­ty­wy teste­ra w zasa­dzie ma on rację twier­dząc, że pod­no­sze­nie jako­ści opro­gra­mo­wa­nia to pod­no­sze­nie jako­ści testów”. Zapomniał jed­nak, że są dwa spo­so­by na pod­no­sze­nie jakości:

  1. coraz sku­tecz­niej­sze wykry­wa­nie błędów
  2. robie­nie coraz mniej­szej ilo­ści błędów

Niestety w gestii teste­ra leży wyłącz­nie to pierw­sze i tu go rozumiem.…ale dodam, że dru­gie jest znacz­nie tań­sze. Tylko do takiej decy­zji potrze­ba po pierw­sze zro­zu­mie­nia a po dru­gie spoj­rze­nia z szer­szej perspektywy.

I nie­ste­ty nie liczę na zro­zu­mie­nie u więk­szo­ści PM’ów (ich wie­dza jest czę­sto taka jak powyż­szy kamień pogo­do­wy), reali­zu­ją cele swo­je­go pra­co­daw­cy a nie cele kupu­ją­ce­go, a Ci ostat­ni albo mają kom­pe­ten­cje by nad­zo­ro­wać wła­sne pro­jek­ty albo nie…

teczki, akta, papiery

Mucha – czyli jak staję się biurokratą

mucha

Dykteryjka o meto­dzie badawczej:

Pewien nauko­wiec prze­pro­wa­dzał doświad­cze­nie na muchach. Dziennik: Do badań wyty­po­wa­no loso­wo muchę, mucha reagu­je na pole­ce­nia gło­so­we. Po ode­rwa­niu jed­nej nogi wyda­no pole­ce­nie – Mucha chodź! – mucha reagu­je. Po ode­rwa­niu dru­giej nogi – Mucha chodź! – mucha nadal cho­dzi. Po ode­rwa­niu trze­ciej nogi – Mucha chodź! – mucha cho­dzi lek­ko kuś­ty­ka­jąc. Po ode­rwa­niu czwar­tej nogi – Mucha chodź! – mucha cho­dzi, moc­no kule­je. Po ode­rwa­niu pią­tej nogi – Mucha chodź! – mucha z tru­dem ale jed­nak się prze­miesz­cza. Po ode­rwa­niu szó­stej nogi – Mucha chodź! – mucha nie reagu­je na to pole­ce­nie. Wnioski: Po ode­rwa­niu ostat­niej nogi mucha stra­ci­ła słuch.

To typo­wa heu­ry­sty­ka: czło­wiek postrze­ga jako przy­czy­nę zja­wisk te zda­rze­nia, któ­re je bez­po­śred­nio poprze­dza­ją. Bardzo czę­sto obser­wu­ję to zja­wi­sko przy oka­zji tłu­ma­cze­nia tego co dzie­je się w fir­mach: za przy­czy­nę suk­ce­sów i pora­żek (z regu­ły ostat­nie bywa tak oce­nia­ne) uzna­je się ostat­nio wpro­wa­dza­ne zmia­ny czy inno­wa­cje, nowych mene­dże­rów itp.. (zresz­tą podob­nie wyglą­da szu­ka­nie przy­czyn obec­ne­go kry­zy­su, o ile taki w ogó­le mamy…).

Inny przy­kład, tym razem na temat tego co oczywiste”:

W pew­nej wio­sce miesz­kał sza­man, któ­ry zawsze przed świ­tem odpra­wiał tanecz­ny rytu­ał wscho­du słoń­ca, dzię­ki któ­re­mu – jak utrzy­my­wał – wscho­dzi słoń­ce. Mieszkańcy wio­ski, sza­ma­na żywi­li i ubie­ra­li, jako jedy­ne­mu pozwo­li­li na posia­da­nie wie­lu żon, mimo, że sza­man nie pra­co­wał. Pewnego razu do wio­ski wró­cił po stu­diach syn jed­nej z miesz­ka­ją­cych w niej rodzin. Powiedział, że tam gdzie był nie było sza­ma­na i dzień nasta­wał jak tu, że sza­man to paso­żyt i wca­le nie musi rano tań­czyć by życie toczy­ło się nor­mal­nym try­bem. Zasugerował, że to co mówi łatwo spraw­dzić, wystar­czy zamknąć sza­ma­na na jeden dzień w sza­ła­sie i nie wypu­ścić. Mieszkańcy wio­ski zamor­do­wa­li mło­de­go chło­pa­ka, o czym sza­man nawet nie wiedział.

I teraz krót­kie rady:

  1. Jako ana­li­tyk sta­raj się zro­zu­mieć a nie tyl­ko zapi­sy­wać obser­wa­cje, heu­ry­sty­ka to coś przed czym ana­li­tyk powi­nien umieć się bro­nić a nie jej uży­wać …(praw­dzi­wa wie­dza to zna­jo­mość przy­czyn – Arystoteles).
  2. Jako ana­li­tyk, pisząc reko­men­da­cje, nie zapo­mi­naj, że wpro­wa­dze­nie zmia­ny może napo­tkać opór, któ­re­go źró­dłem wca­le nie jest nie­chęć a strach i brak wiedzy.

archiwum dokumentowTak więc gdy tra­fisz na klien­ta myślą­ce­go pro­sty­mi sche­ma­ta­mi, opo­wiedz mu co pro­po­nu­jesz i nie narzu­caj się. Klient, któ­ry wie lepiej” – nie mówiąc Ci o tym – i tak pogrze­bie Twoja pra­cę… A na począt­ku zawsze ostrze­gaj swo­ich klien­tów tak ja ja: zanim zapy­ta­cie, bądź­cie pew­ni, że chce­cie poznać odpowiedź”…

Niestety bywa tak, że klient na począt­ku poka­zu­je, że przyj­mu­je z poko­rą to co mówisz, a powie Ci o tym, że nie uzna­je odpo­wie­dzi dopie­ro jak ją pozna , wte­dy jedy­nym co moż­na zro­bić jest wyję­cie segre­ga­to­ra, któ­ry zawie­ra zapi­sa­ne wszyst­kie, zaak­cep­to­wa­ne po dro­dze, klu­czo­we eta­py tej współ­pra­cy… miej je zawsze. Drugim wyj­ście jest … wyj­ście z tego projektu.

Rada dla firm anga­żu­ją­cych ana­li­ty­ków: sprawdź czy przy­pad­kiem anga­żo­wa­ny ana­li­tyk nie jest bada­czem much…

Rada dla anga­żo­wa­nych ana­li­ty­ków: upew­nij się, czy przy­pad­kiem orga­ni­za­cja, któ­ra Cię anga­żu­je, nie jest wio­ską szamana…

To smut­ne, że głup­cy są tak pew­ni sie­bie, a ludzie mądrzy tak peł­ni wąt­pli­wo­ści” (Bertrand Russell). 

Inżynieria wymagań

W grud­niu 2011 roku napi­sa­łem na zakoń­cze­nie pew­ne­go arty­ku­łu o wymaganiach:

Większość pro­jek­tów takich jak np. wdra­ża­nie nowych metod kon­tro­lin­gu, zrów­no­wa­żo­nej kar­ty wyni­ków, nowych sys­te­mów IT itp. cier­pi głów­nie z powo­du posia­da­nia nad­mia­ru infor­ma­cji z jed­nej stro­ny i kom­plet­ne­go jej nie­zro­zu­mie­nia z dru­giej. Sławne już w bada­niach ?złe i nie­kom­plet­ne wyma­ga­nia? czy ?zmia­ny zakre­su pro­jek­tu w trak­cie jego trwa­nia? to kla­sycz­ne skut­ki złej (a czę­sto pomi­ja­nia!) ana­li­zy biz­ne­so­wej. Koszty tych pora­żek wie­lo­krot­nie prze­wyż­sza­ją koszt takich ana­liz. (Analiza biz­ne­so­wa ? sku­tecz­ne mode­lo­wa­nie a ryzy­ko pro­jek­tu).

Specyfikowanie wyma­gań, zarzą­dza­nie wyma­ga­nia­mi, inży­nie­ria wyma­gań, to jak widać bar­dzo trud­ny etap pro­jek­tu. Trudność bie­rze się stad, że dostęp­ne zale­ce­nia okre­śla­ją, że wyma­ga­nia maja być np. spój­ne i kom­plet­ne ale zupeł­nie nie opi­su­ją jak to osią­gnąć (a nawet jak to spraw­dzić).

Często moż­na się spo­tkać z poję­ciem inży­nie­ria wyma­gań”. Budzi ono mój opór z dwóch powo­dów: zna­cze­nie sło­wa inży­nie­ria w j.polskim i nie­ade­kwat­ność tego sło­wa do dzie­dzi­ny jaką jest spe­cy­fi­ko­wa­nie wyma­gań, któ­re są po pro­tu listą warunków.

Zajrzyjmy do słow­ni­ka języ­ka polskiego:

inży­nie­ria ?pro­jek­to­wa­nie i kon­stru­owa­nie obiek­tów oraz urzą­dzeń technicznych?

wyma­ga­nie ?waru­nek lub zespół warun­ków, któ­rym ktoś lub coś musi odpowiadać?

Więc jak rozu­mieć zło­że­nie inży­nie­ria wyma­gań”? Ja nie wiem, chy­ba, że ktoś uwa­ża, że wyma­ga­nia się kon­stru­uje”, i że są to zagad­nie­nia tech­nicz­ne. Za to ma sens inży­nie­rii sys­te­mów”. Mamy def. poję­cia system:

sys­tem ?układ ele­men­tów mają­cy okre­ślo­ną struk­tu­rę i sta­no­wią­cy logicz­nie upo­rząd­ko­wa­ną całość?

Gdyby defi­ni­cje sło­wa inży­nie­ria” okro­ić z tech­nicz­nych” albo uznać, że sys­te­my są tak­że nie tech­nicz­ne (bo są np. spo­łecz­ne) to mamy wdzięcz­na definicję:

inży­nie­ria sys­te­mów ?pro­jek­to­wa­nie i kon­stru­owa­nie ukła­dów ele­men­tów mają­cych okre­ślo­ną struk­tu­rę i sta­no­wią­cy logicz­nie upo­rząd­ko­wa­ną całość?

Jeden z moich ulu­bio­nych auto­rów aka­de­mic­kich, Ian Sommeville (lubię go tak­że za to, że książ­ki pisze w pubach popi­ja­jąc piwo ;)) defi­niu­je inży­nie­rię wyma­gań tak:

Requirements engi­ne­ering (RE) refers to the pro­cess of for­mu­la­ting, docu­men­ting and main­ta­ining softwa­re requ­ire­ments (źr. Kotonya G. and Sommerville, I. Requirements Engineering: Processes and Techniques. Chichester, UK: John Wiley & Sons)

(poję­cie inży­nie­rii wyma­gań odno­si do pro­ce­su for­mu­ło­wa­nia, doku­men­to­wa­nia i zarzą­dza­nia wymaganiami)

Tak więc uzna­jąc, że wyma­ga­nia na sys­te­my to ele­ment inży­nie­rii tych sys­te­mów, niniej­szym godzę się uży­wać poję­cia inży­nie­ria wyma­gań” w zna­cze­niu jakim opi­sał to Sommerville :).

Po co tyle glę­dze­nia o sło­wach i ich zna­cze­niach? Poza szu­ka­niem” ali­bi dla ist­nie­nia poję­cia inży­nie­ra wyma­gań” chcę poka­zać, że sło­wa mają zna­cze­nie, zanie­dby­wa­nie tego pro­wa­dzi do wie­lu nie­po­ro­zu­mień (nie­jed­no­znacz­ność) a po dru­gie zwra­cam uwa­gę, że ana­li­za poję­cio­wa to jeden z klu­czo­wych ele­men­tów ana­li­zy w ogó­le (i czę­sto zaniedbywana).

Skoro wyma­ga­nia to warun­ki, to aż pro­si się by te warun­ki spraw­dzać. Patrzmy do słownika:

spraw­dzać ?skon­tro­lo­wać, zba­dać, czy coś jest zgod­ne z praw­dą, czy coś zosta­ło zro­bio­ne prawidłowo?

Tak więc wnio­sek jest pro­sty: wyma­ga­nie (każ­de!) powin­no być spraw­dzal­ne! Bez tego nie jeste­śmy w sta­nie okre­ślić czy coś” speł­nia te wyma­ga­nia, czy­li czy zda­nie: dostar­czo­ny pro­dukt jest zgod­ny z wyma­ga­nia­mi” jest praw­dzi­we czy nie (a nie chce­my oddać roz­strzy­ga­nia tego prawnikom ;)).

Inżynieria wymagań

Skoro więc ugią­łem się i uzna­łem poję­cie inży­nie­rii wyma­gań, popa­trz­my na to sys­te­mo­wo. Jak zawsze pro­ste jest pięk­ne więc co ana­li­zu­je­my w inży­nie­rii sys­te­mo­wej i inży­nie­rii wymagań:

Granice systemu

matrioszkaPojęcie sys­tem” to tak­że super­sys­tem (sys­tem nad­rzęd­ny) i pod­sys­tem (sys­tem pod­rzęd­ny, część sys­te­mu). To trosz­kę jak zna­ne wam, być może, matriosz­ki 🙂 (figur­ki jed­na w drugiej…).

Jest to, nazew­nic­two, bar­dzo waż­ne, bo w jed­nym pro­jek­cie (doku­men­ta­cji) nale­ży zacho­wać bez­względ­ną dys­cy­pli­nę poję­cio­wą, czy­li sło­wo System powin­no się odno­sić wyłącz­nie do kon­kret­ne­go pozio­mu opi­su, resz­ta to ele­men­ty sys­te­mu nad­rzęd­ne­go lub podrzędnego.

Mianem sys­tem okre­śla się zwy­cza­jo­wo spe­cy­fi­ko­wa­ne opro­gra­mo­wa­nie, jed­nak pro­blem poja­wi się natych­miast, gdy dotknie­my takich pojęć jak wyma­ga­nia funk­cjo­nal­ne na opro­gra­mo­wa­nie i wyma­ga­nia biz­ne­so­we. To ostat­nie nie­sie pew­ną nie­ja­sność. Bo nie wiem czy cho­dzi o wyma­ga­nia wobec (w sto­sun­ku do) biz­ne­su (np. popra­wa jako­ści obsłu­gi klien­ta o 5% w naj­bliż­szym bada­niu jako­ści ISO) czy wyma­ga­nia biz­ne­su wobec (w sto­sun­ku do) opro­gra­mo­wa­nia (np. mini­ma­li­za­cja do zera otrzy­ma­nych i zagu­bio­nych zapy­tań ofertowych).

Popatrzmy na powyż­szy dia­gram. Mamy tu dwa Systemy:

  1. Organizacja jest pod­sys­te­mem, jest ele­men­tem sys­te­mu, któ­rym tu jest rynek na jakim ta orga­ni­za­cja funkcjonuje.
  2. Organizacja jest ana­li­zo­wa­nym sys­te­mem, opro­gra­mo­wa­nie jest jed­nym z zaso­bów tej orga­ni­za­cji (opro­gra­mo­wa­nie jest tu podsystemem).

Wymagania może­my tu odno­sić w sto­sun­ku do Organizacji i w sto­sun­ku do Oprogramowania. To dla­te­go jasno wyod­ręb­nia­my ana­li­zę biz­ne­so­wą (pro­duk­tem są mode­le biz­ne­so­we i wyma­ga­nia biz­ne­so­we) od ana­li­zy wyma­gań na opro­gra­mo­wa­nie (mode­le i wyma­ga­nia na opro­gra­mo­wa­nie). Jak widać wyma­ga­nia na opro­gra­mo­wa­nie to wyma­ga­nia, któ­rych źró­dłem jest biz­nes, któ­ry ma kon­kret­ne cele do osią­gnię­cia. Nie powin­ny być one poboż­ny­mi życze­nia­mi użyt­kow­ni­ków, aż do momen­tu gdy spon­sor pro­jek­tu nie powie np.: moim celem jest wygo­da pra­cy moich pra­cow­ni­ków. Oczywiście, ta wygo­da jest zawsze wyma­ga­na ale nie musi ona być celem samym w sobie i nie musi mieć naj­wyż­sze­go priorytetu.

Wymagania inte­re­sa­riu­szy. Moja defi­ni­cja inte­re­sa­riu­sza (jed­na z wie­lu): oso­ba (pod­miot) zain­te­re­so­wa­na zaist­nie­niem pro­duk­tu, na któ­rą poja­wie­nie się pro­duk­tu ma wpływ. Nie raz jestem pyta­ny czy inte­re­sa­riusz ma pra­wo zgła­sza­nia wyma­gań. Jeżeli ma coś do powie­dze­nia pod­czas odbio­ru pro­duk­tu to zna­czy, że ma wyma­ga­nia. One mogą być jed­nak nie­jaw­ne czy­li taki inte­re­sa­riusz nie zgła­sza wyma­gań ale ma wpływ na odbiór pro­duk­tu, nale­ży go koniecz­nie ziden­ty­fi­ko­wać. Jeżeli zaś ktoś nie ma nic do gada­nia przy odbio­rze pro­duk­tu nie jest inte­re­sa­riu­szem (ang. sta­ke­hol­der, klu­czem jest tu «hol­der» czy­li dys­po­nent mają­cy coś do powie­dze­nia, mają­cy wpływ). Tak wiec inte­re­sa­riusz to ktoś kto, na swo­im pozio­mie ogól­no­ści, tak­że musi umieć okre­ślić, kie­dy uzna, że pro­dukt speł­nia jego wyma­ga­nia. Jak nie potra­fi, ktoś musi mu pomóc…analityk :)).

I tu rola ana­li­ty­ka. Interesariusz spi­su­je co mu przyj­dzie do gło­wy swo­im języ­kiem, ana­li­tyk upew­nia się, że zro­zu­miał, dopro­wa­dza je do posta­ci testo­wal­nej i kla­sy­fi­ku­je wyma­ga­nia” jako źró­dło: kon­kret­ny inte­re­sa­riusz” (bo każ­de wyma­ga­nie musi mieć wła­ści­cie­la). Proszę zwró­cić uwa­gę, że inte­re­sa­riu­szem jest tak­że użyt­kow­nik jeże­li tyl­ko ma coś go powie­dze­nia w projekcie :).

Popatrzmy na wymaganie:

Wymagania

Wymaganie jest jed­no (waru­nek jaki coś musi speł­nić) ale może ono mieć wie­le atry­bu­tów i tu widzę zło­żo­ność” wyma­gań (ich [[tak­so­no­mia]]). Zarówno wysta­wia­nie fak­tur VAT” jak i dostęp­ność 99,99% cza­su” to rów­no­praw­ne wyma­ga­nia bo opro­gra­mo­wa­nie np. wspo­ma­ga­ją­ce sprze­daż jest bez­war­to­ścio­we zarów­no gdy nie pozwa­la wysta­wiać fak­tur jak wte­dy, gdy czę­sto się psu­je. Owszem, jed­no jest funk­cjo­nal­ne dru­gie jest poza-funk­cjo­nal­ne ale jed­no i dru­gie to rów­no­praw­ny waru­nek przy­dat­no­ści” czy­li Wymaganie wobec oprogramowania.

Jak wspo­mnia­łem, wyma­ga­nia są (war­to tak robić) kla­sy­fi­ko­wa­ne za pomo­cą atry­bu­tów. Najczęściej spo­ty­ka­ne to: rodzaj (Kind), źró­dło wyma­ga­nia (Source), pole­cam tak­że prio­ry­tet, meto­dę wery­fi­ka­cji (np. test, audyt zgod­no­ści z opi­sem w doku­men­ta­cji), sta­tus (pla­no­wa­ne, zaakc­pe­to­wa­ne, odrzu­co­ne, …) i inne, zależ­nie od wyma­gań i typu projektu.

Ważna uwa­ga i zale­ce­nie IIBA: zarzą­dza­nie wyma­ga­nia­mi zabra­nia” ich usu­wa­nia (albo renu­me­ra­cji po usu­nię­ciu). usu­wa­nie powo­du­je to nie­spój­ność wer­sjo­no­wa­nej doku­men­ta­cji, któ­ra tak­że ma swój cykl życia. Ja od dłuż­sze­go cza­su sto­su­ję dodat­ko­wy sta­tus odrzu­co­ne”, co daje mi cią­głość doku­men­ta­cji a tak­że pozwa­la na odwie­sze­nie” wcze­śniej zde­fi­nio­wa­ne­go wyma­ga­nia, gdy ktoś jed­nak uzna, że coś co było zbęd­ne nagle zno­wu sta­je się konieczne :).

Liczba pytań i suge­stii (tak­że na kil­ku forach dys­ku­syj­na) skło­ni­ła mnie do pod­ję­cia pró­by zbu­do­wa­nia tak­so­no­mii wyma­gań. Jak już wspo­mnia­łem wyżej, zale­ce­nia takie jak FURPS to nie­ste­ty tyl­ko pła­ska lista cech” (i nie wszyst­kich). Wydaje mi się, że struk­tu­ra wyma­gań, ich tak­so­no­mia wza­jem­ne zależ­no­ści oraz rela­cje do udzia­łow­ców pro­jek­tu (inte­re­sa­riu­sze) i przy­szłych użyt­kow­ni­ków roz­wią­za­nia, wyma­ga­ją bar­dziej for­mal­ne­go podej­ścia. Celem jest uzy­ska­nie moż­li­wo­ści spraw­dza­nia czy wyma­ga­nia – jako przed­miot inży­nie­rii wyma­gań – speł­nia­ją jakieś, trze­ba je stwo­rzyć, wymagania.

Taksonomia wymaganPowyżej pró­ba usys­te­ma­ty­zo­wa­nia wyma­gań” na bazie wyżej cyto­wa­nych defi­ni­cji tego pojęcia.

Na koniec jesz­cze kolej­na waż­na rzecz. Warto wska­zy­wać, któ­re ele­men­ty logi­ki biz­ne­so­wej (Model) odpo­wia­da­ją (są powią­za­ne) z danym wyma­ga­niem bo np. szcze­gó­ło­wo opi­su­ją wyma­ga­ny spo­sób reali­za­cji dane­go wyma­ga­nia (np. sys­tem upu­stów albo kon­kret­ny przy­pa­dek uży­cia, tak­że Model). Warto tak­że, jeże­li opis wyma­ga­nia nie jest testem, zapro­jek­to­wać test (przy­pa­dek testo­wy), któ­ry potwier­dzi speł­nie­nie wyma­ga­nia np. opro­gra­mo­wa­nie ma pozwa­lać na wyli­cza­nie pier­wiast­ków dru­gie­go i trze­cie­go stop­nia”. Tu war­to podać kil­ka kon­kret­nych danych wej­ścio­wych wraz z pra­wi­dło­wy­mi wyni­ka­mi (może to doty­czyć nap. tabe­li upu­stów, sys­te­mu sko­rin­gu klien­tów itp.).

Tego typu meto­dy maja nazwę deklaratywnych:

Programowanie dekla­ra­tyw­ne ? rodzi­na para­dyg­ma­tów pro­gra­mo­wa­nia, któ­re nie są z natu­ry impe­ra­tyw­ne. W prze­ci­wień­stwie do pro­gra­mów napi­sa­nych impe­ra­tyw­nie, pro­gra­mi­sta opi­su­je warun­ki, jakie musi speł­niać koń­co­we roz­wią­za­nie (co chce­my osią­gnąć), a nie szcze­gó­ło­wą sekwen­cję kro­ków, któ­re do nie­go pro­wa­dzą (jak to zro­bić). Programowanie dekla­ra­tyw­ne czę­sto trak­tu­je pro­gra­my jako pew­ne hipo­te­zy wyra­żo­ne w logi­ce for­mal­nej, a wyko­ny­wa­nie obli­czeń jako ich dowo­dze­nie. Programowanie dekla­ra­tyw­ne jest szcze­gól­nym przed­mio­tem zain­te­re­so­wa­nia naukow­ców, gdyż dzię­ki mini­ma­li­za­cji lub eli­mi­na­cji skut­ków ubocz­nych może zna­czą­co upro­ścić two­rze­nie pro­gra­mów współ­bież­nych. Paradygmat pro­gra­mo­wa­nia dekla­ra­tyw­ne­go obej­mu­je sze­ro­ką gamę języ­ków pro­gra­mo­wa­nia i bar­dziej szcze­gó­ło­wych para­dyg­ma­tów pod­rzęd­nych. (Programowanie dekla­ra­tyw­ne ? Wikipedia, wol­na ency­klo­pe­dia).