Gdzie się realizują wymagania

Bardzo czę­sto spo­ty­kam, pew­nie nie ja jeden, spe­cy­fi­ka­cje wyma­gań zawie­ra­ją­ce zapi­sy ocze­ki­wań użyt­kow­ni­ków”. Bardzo czę­sto sły­szę tak­że, że to przy­szły użyt­kow­nik opro­gra­mo­wa­nia powi­nien być źró­dłem wyma­gań. nic bar­dziej błęd­ne­go.. […] Więc np. wyma­ga­nie sys­tem powi­nien pozwa­lać na budo­wa­nie dowol­nych raba­tów sprze­da­ży do sta­łych klien­tów” (tak­że cytat z pew­nej spe­cy­fi­ka­cji sys­te­mu CRM) jest pustym stwier­dze­niem. Po pierw­sze jak te raba­ty są nali­cza­ne, po dru­gie czy aby na pew­no mecha­nizm pozwa­la na dowol­ne raba­ty”… Jak to opi­sać? Tu powin­ny się poja­wić np. tabli­ce decy­zyj­ne a nie lako­nicz­ne dowol­ne rabaty”.

Na zakoń­cze­nie uwa­ga: jeże­li pla­nu­je­my kupić goto­we opro­gra­mo­wa­nie, to ono już (gdzieś tam) ist­nie­je, i spe­cy­fi­ko­wa­nie szcze­gó­łów opi­su­ją­cych dokład­nie ele­men­ty pra­cy z inter­fej­sem użyt­kow­ni­ka i enig­ma­tycz­ne opi­sy tego jak sys­tem liczy”, jest bez­war­to­ścio­we. Raczej wywo­ła listę tak zwa­nych kasto­mi­za­cji (zwa­nych gdzie­nie­gdzie zabój­ca­mi pro­jek­tów :)). Tak jed­nak wła­śnie wyglą­da­ją naj­czę­ściej spe­cy­fi­ka­cje pisa­ne ręka­mi przy­szłych użyt­kow­ni­ków: opi­szą oni to z czym się sty­ka­ją i co zna­ją ale w ogó­le nie opi­szą wnę­trza, któ­re­go naj­czę­ściej po pro­tu nie rozu­mie­ją (i nie muszą bo to nie ich rola), wte­dy spe­cy­fi­ka­cje sys­te­mów CRM pisa­ne ręka­mi przy­szłych użyt­kow­ni­ków – np. sprze­daw­ców – zawie­ra­ją wła­śnie bez­war­to­ścio­we zapi­sy w rodza­ju: sys­tem powi­nien pozwa­lać na budo­wa­nie dowol­nych raba­tów sprze­da­ży do sta­łych klien­tów” a nie zawie­ra­ją opi­su jak te raba­ty wyliczać.
Odpowiadając na tytu­ło­we pyta­nie: wyma­ga­nia (funk­cjo­nal­ne) reali­zu­ją się w mode­lu dzie­dzi­ny sys­te­mu, któ­re­go nie zawie­ra więk­szość zna­nych spe­cy­fi­ka­cji wyma­gań… a warun­kiem popraw­ne­go wybo­ru opro­gra­mo­wa­nia są ocze­ki­wa­nia co do efek­tów przetwarzania.

Czytaj dalej Gdzie się realizują wymagania

Wymagania biznesowe a wymagania wobec produktu – rola analityka

I tak mamy: 100% inter­fej­su użyt­kow­ni­ka zama­wia użyt­kow­nik (sam lub z pomo­cą spe­cja­li­stów), 100% wyma­gań funk­cjo­nal­nych reali­zu­je Model Dziedziny (pro­jekt ana­li­ty­ka-pro­jek­tan­ta), 100% wyma­gań poza-funk­cjo­nal­nych reali­zu­je deve­lo­per (pro­jekt i imple­men­ta­cja). Developer tak­że imple­men­tu­je model dzie­dzi­ny z pomo­cą tech­no­lo­gii jakiej używa.

A jeże­li klient powie: nie mamy tych wzo­rów doku­men­tów i ekra­nów! To pierw­szy sygnał, że nie ma pod­staw do zama­wia­nia jakie­go­kol­wiek opro­gra­mo­wa­nia, bo naj­pierw trze­ba wie­dzieć co się chce”.

Jak to zro­bić? Tu kła­nia się ana­li­za biz­ne­so­wa: mode­lu­je­my pro­ce­sy biz­ne­so­we, dla każ­de­go z nich usta­la­my wej­ście oraz efekt (pro­dukt) czy­li wła­śnie owe wzo­ry doku­men­tów”. Po upo­rząd­ko­wa­niu tego i upew­nie­niu się, że nie ma w tym bała­ga­nu (powtór­ki, bra­ki, nie­kon­se­kwen­cje, sprzecz­no­ści itp.) może­my pytać o goto­we opro­gra­mo­wa­nie lub zama­wiać” jego wytwo­rze­nie. Produktem pra­cy ana­li­ty­ka powin­ny być, poza mode­la­mi pro­ce­sów bo one są narzę­dziem a nie celem, obiek­to­wy model dzie­dzi­ny czy­li model tego jaki­mi infor­ma­cja­mi i jak zor­ga­ni­zo­wa­ny­mi ope­ru­je orga­ni­za­cja, oraz to jak pra­cow­ni­cy tej orga­ni­za­cji chcą się komu­ni­ko­wać z opro­gra­mo­wa­niem (źro­dłem infor­ma­cji jest jed­nak klient).

Mamy czy­sty podział odpo­wie­dzial­no­ści i łatwość roz­li­cze­nia pro­jek­tu. Na czym pole­ga haczyk? Klient nie może uni­kać odpo­wie­dzial­no­ści za skut­ki swo­ich decy­zji i udzie­la­nych infor­ma­cji. Ale też, co jest klu­czo­we: Analityk musi zro­zu­mieć pro­blem i zapro­po­no­wać rozwiązanie.

Jednak nie jest rolą ana­li­ty­ka wyko­na­nie opro­gra­mo­wa­nia! To jak – tech­no­lo­gia – ma to zostać zre­ali­zo­wa­ne” jest decy­zją deve­lo­pe­ra. Ma dużo pra­cy. Nie zapo­mi­naj­my, że kod reali­zu­ją­cy tak zwa­ną logi­kę biz­ne­so­wą to led­wie kil­ka pro­cent cało­ści kodu apli­ka­cji, jed­nak nie zapo­mi­naj­my tak­że (pro­gra­mi­ści), że zła logi­ka biz­ne­so­wa dys­kwa­li­fi­ku­je całe to opro­gra­mo­wa­nie z pro­ste­go powo­du: sta­je się nieprzydatne.

Czytaj dalej Wymagania biznesowe a wymagania wobec produktu – rola analityka

Prawo a wymagania …

Podstawową korzy­ścią z wyod­ręb­nie­nia reguł biz­ne­so­wych i słow­ni­ka pojęć jest upo­rząd­ko­wa­nie słow­nic­twa w doku­men­ta­cji i uczy­nie­nie jej jed­no­znacz­ną oraz wery­fi­ka­cja ewen­tu­al­nych sprzecz­no­ści regu­la­cji wewnętrz­nych (Zarządzeń, Prawa). Powoływanie się na Reguły biz­ne­so­we na mode­lach pro­ce­sów biz­ne­so­wych, pozwa­la zacho­wać ich pro­sto­tę nie tra­cąc szcze­gó­ło­wo­ści wie­dzy o pro­ce­sach. Tak wyko­na­na doku­men­ta­cja pro­ce­sów nie wyma­ga czę­stej i kosz­tow­nej aktu­ali­za­cji, z regu­ły aktu­ali­zo­wa­ne są pro­ce­du­ry i regu­ły biz­ne­so­we, na któ­re mode­le pro­ce­sów się powołują.

Tak więc akty praw­ne to zaka­zy i naka­zy, regu­ły biz­ne­so­we. Oprogramowanie, zależ­nie od przy­ję­tej kon­wen­cji, nie powin­no ogra­ni­czać ani nawet utrud­niać postę­po­wa­nia zgod­ne­go z pra­wem, może poja­wić się ocze­ki­wa­nie by nie pozwa­la­ło łamać pra­wa. Szczegółowa ana­li­za aktów praw­nych, w moich oczach, ma sens gdy pro­jek­tu­je­my opro­gra­mo­wa­nie. Gdy sta­wia­my wyma­ga­nia przed już ist­nie­ją­cym opro­gra­mo­wa­niem, zakła­da­my że kupi­my goto­we, wystar­czy wyma­gać zgod­no­ści z pra­wem w obsza­rze sto­so­wa­nia opro­gra­mo­wa­nia. Jeżeli np. opro­gra­mo­wa­nie ma pozwa­lać na wysta­wia­nie fak­tur to zna­czy, że powin­no być moż­li­we wysta­wie­nie każ­dej fak­tu­ry prze­wi­dzia­nej pra­wem w spo­sób zgod­ny z nim. Możemy dodat­ko­wo zażą­dać by nie było moż­li­we wysta­wie­nie fak­tu­ry nie­zgod­nej z prawem. 

Czytaj dalej Prawo a wymagania …

Wymagania na coś dużego – w czym problem?

Producenci róż­nych rze­czy zda­ją sobie spra­wę, że kosz­ty pod­ję­cia wła­ści­wej decy­zji przy skom­pli­ko­wa­nych pro­duk­tach są spo­re i ludzie będą podej­mo­wać decy­zje błęd­ne, to pozwa­la dzia­łać na ryn­ku fir­mom, któ­re w prze­ciw­nym wypad­ku by upadły.

I jak teraz wyglą­da­ją w Państwa oczach zaku­py i wdro­że­nia dużych goto­wych systemów?

Jak to robić lepiej? Po pierw­sze nie kupo­wać dużych i dro­gich zin­te­gro­wa­nych sys­te­mów” bo to duże ryzy­ko, kupo­wać mniej­sze, łatwiej­sze do opi­sa­nia, pro­jek­to­wać te, któ­re są zbyt dużym ryzy­kiem w przy­pad­ku złe­go wybo­ru. Jeżeli już z powo­du ryzy­ka mamy poświę­cić duży budżet na kosz­tow­ne spe­cy­fi­ko­wa­nie opro­gra­mo­wa­nia to sygnał, że nale­ży je za te pie­nią­dze po pro­stu zapro­jek­to­wać i wykonać.

Niestety nie ma pro­stej odpo­wie­dzi jak to robić dobrze”. Chyba, że będzie to pro­po­zy­cja nastę­pu­ją­ce­go procesu:

ana­li­za biznesowa
zde­fi­nio­wa­nie celu
zapro­jek­to­wa­nie archi­tek­tu­ry sys­te­mu (to jako sys­tem nale­ży rozu­mieć orga­ni­za­cję wraz z wspie­ra­ją­ca ją infor­ma­ty­ką), zmie­rza­my w kie­run­ku tak zwa­nej [[archi­tek­tu­ry korporacyjnej]]
ziden­ty­fi­ko­wać ocze­ki­wa­ne od opro­gra­mo­wa­nia usłu­gi (wyma­ga­nia), podzie­lić je na odręb­ne obsza­ry dziedzinowe,
dla każ­de­go obsza­ru dzie­dzi­no­we­go popro­wa­dzić odręb­ny pro­jekt wybo­ru rozwiązania.
wybrać rozwiązania.
Zwracam uwa­gę drob­ny szcze­gół: wybo­ry pro­duk­tu doko­nu­je­my na koń­cu, nigdy na początku!

Czytaj dalej Wymagania na coś dużego – w czym problem?

Raport: Zarządzanie wymaganiami 2011

Ponad 80% pro­jek­tów pro­gra­mi­stycz­nych ma prze­kro­czo­ne ter­min i budżet. Największą trud­no­ścią w tych pro­jek­tach oka­za­ło się jasne zro­zu­mie­nie tego, cze­go tak napraw­dę klient potrze­bu­je, oraz udo­ku­men­to­wa­nie jego wyma­gań. Do prze­cho­wy­wa­nia wyma­gań uży­ty był głów­nie word i excel oraz ema­il. Przyznajemy jed­nak, że dia­gra­my naj­le­piej wyja­śnia­ją­ce (uzu­peł­nia­ją­ce) wąt­pli­wo­ści zwią­za­ne z wyma­ga­nia­mi to mode­le pro­ce­sów i pro­to­ty­py, jed­nak nie sto­su­je­my ich. ( 2011 State of Requirements Management Report.)

Jak widać brzmi zna­jo­mo z dwóch powo­dów: pro­ble­my zna­ne każ­de­mu i powo­dy nie­ste­ty tak­że. Ciśnie mi się na usta a nie mówiłem”…

Czyli jed­nak wie­my że pro­ble­mem pro­jek­tów z zakre­su inży­nie­rii opro­gra­mo­wa­nia są zbyt pro­ste meto­dy i narzę­dzia zarzą­dza­nia wyma­ga­nia­mi (pakiet biu­ro­wy), któ­re w więk­szo­ści są sto­so­wa­ne. Wiemy, że mode­lo­wa­nie jest naj­sku­tecz­niej­sza meto­dą ana­li­zy i pro­jek­to­wa­nia a mimo to nie sto­su­je się tych metod szu­ka­jąc sta­le dro­gi na skróty”.

Dlaczego dostaw­cy opro­gra­mo­wa­nia nie sto­su­ją metod powszech­nie jed­nak uzna­wa­nych za skuteczne? 

Czytaj dalej Raport: Zarządzanie wymaganiami 2011

Wymagania na system ERP – co ma do tego M.E.Porter i rok 1985?

Podejście takie jest sto­so­wa­ne. Badania poka­zu­ją, że lide­rzy ryn­ku, bez wzglę­du na bran­żę, to fir­my dobrze zarzą­dza­ne a nie te, któ­re naj­wię­cej wyda­ły na IT. Podejście to wyma­ga dużej odwa­gi i samo­dziel­no­ści, igno­ro­wa­nia tak zwa­nych mode­li refe­ren­cyj­nych (bo te są dobry­mi prak­ty­ka­mi a nie czymś co nale­ży sko­pio­wać), owo­cu­je jed­nak suk­ce­sa­mi. Niestety czę­sto zda­rza się, że wdro­że­nie sys­te­mu ERP nisz­czy prze­wa­gę fir­my, gdyż nowa tech­no­lo­gia zamiast ją umoc­nić nisz­czy kom­pro­mi­sa­mi i kopio­wa­niem mode­li innych firm (nie raz kon­ku­ren­tów) wszyst­ko to co odróż­nia­ło ją od innych.

Za zakoń­cze­nie pole­cam gorą­co dru­gą ksiąz­kę Portera: [[Porter o kon­ku­ren­cji, Michael E. Porter, PWE, Warszawa 2001]]. W tej znaj­dzie­my zbiór dzie­wię­ciu arty­ku­łów na temat budo­wa­nia kon­ku­ren­cji i jej utrzy­ma­niu. W szcze­gól­no­ści war­to poznać arty­kuł „[[W jaki spo­sób infor­ma­cja wpły­wa na prze­wa­gę kon­ku­ren­cyj­ną]]”. Pięć zasad, któ­re mogą pomóc w budo­wa­niu prze­wa­gi na bazie infor­ma­cji, odsy­łam do książ­ki , war­to. To przy­czy­nek to napi­sa­nia kil­ku słów o sys­te­mach wspo­ma­ga­nia decy­zji ale to inny temat, nie ERP…

Czytaj dalej Wymagania na system ERP – co ma do tego M.E.Porter i rok 1985?

Czy wymagania opisują tylko to co” system ma robić?

Bardzo czę­sto tak wła­śnie defi­niu­je się pro­dukt ana­li­zy wyma­gań: wyma­ga­nia funk­cjo­nal­ne opi­su­ją to co ma sys­tem robić. W dys­ku­sjach (ile mam ich za sobą :)) z pro­gra­mi­sta­mi prze­bi­ja się teza, że ana­li­tyk spe­cy­fi­ku­je to co” sys­tem ma robić, a oni już zała­twia spra­wę tego jak” ma to robić. W czym pro­blem? W tym, że funk­cjo­nal­no­ści to test roz­wią­za­nia a nie wyma­ga­nia! […] Przypadki uży­cia sta­no­wią bar­dzo mier­ne przy­bli­że­nie rze­czy­wi­sto­ści. […] Tak więc doku­ment wyma­gań to nie tyl­ko przy­pad­ki uży­cia. Te są raczej testem popraw­no­ści roz­wią­za­nia, czy model jest popraw­ny (przy­po­mi­nam, że przy­pad­ki uży­cia, poza ich sce­na­riu­sza­mi, zawie­ra­ją stan począt­ko­wy i stan koń­co­wy akcji użyt­kow­ni­ka). […] Programiści, pro­szę, nie uda­waj­cie, że zna­cie się na zarzą­dza­niu, mar­ke­tin­gu, biz­ne­sie, sprze­da­ży, ryn­ku, pro­duk­cji itp. bo to (poza pew­nie ist­nie­ją­cy­mi wyjąt­ka­mi) nie praw­da, a pro­jek­to­wa­nie na zasa­dzie wyda­je mi się że rozu­miem” to dro­ga do poraż­ki. […] System ERP moż­na wybrać na bazie pro­jek­tu na wyż­szym pozio­mie abs­trak­cji. Analizy fir­my tak­że pole­ga tu na opra­co­wa­niu mode­li pro­ce­sów. Jednak w tym wypad­ku ich celem jest stwo­rze­nie raczej mode­lu filo­zo­fii dzia­ła­nia” fir­my a nie pro­jek­to­wa­nie sys­te­mu od zera. 

Czytaj dalej Czy wymagania opisują tylko to co” system ma robić?