Przecież ana­li­zę zro­bi­my sami, a jak nie – to zro­bi to dostaw­ca. Tak czę­sto roz­po­czy­na się tak zwa­na Droga do klę­ski”. Jednym z typo­wych listów ini­cju­ją­cych współ­pra­ce z wie­lo­ma moimi klien­ta­mi był ten:

Planujemy wdro­że­nie nowe­go opro­gra­mo­wa­nia, chce­my tym razem unik­nąć pre­sji ze stro­ny dostaw­cy opro­gra­mo­wa­nia. Poprzednim razem dostaw­ca opro­gra­mo­wa­nia uprasz­czał sobie pra­cę, już na eta­pie ana­li­zy, któ­rą wyko­ny­wał sam. Analiza wyma­gań pole­ga­ła na wywia­dach i warsz­ta­tach gru­po­wych, skoń­czy­ła się zwy­kłym opi­sem, tabel­ka­mi i kil­ko­ma nie­czy­tel­ny­mi sche­ma­ta­mi. Podczas ana­li­zy i wdro­że­nia sta­le wma­wia­no nam, że tego nie moż­na”, to nale­ży upro­ścić” albo tak się nie robi” my zaś nie potra­fi­li­śmy tego oce­nić. Wiele naszych potrzeb odkry­wa­li­śmy dopie­ro pod­czas insta­la­cji kolej­nych pro­to­ty­pów, zaś dostaw­ca uni­kał wpro­wa­dza­nia zmian i obie­ca­nych dosto­so­wań. Dostaliśmy w efek­cie nie­przy­dat­ne i nie­zgod­ne z biz­ne­so­wy­mi potrze­ba­mi opro­gra­mo­wa­nie. Czy może nam Pan tym razem pomóc?

Czy to pro­pa­gan­da? Niestety nie. W czym pro­blem? A mia­no­wi­cie w meto­dzie pro­wa­dze­nia ana­li­zy i potem tre­ści spe­cy­fi­ka­cji wyma­gań. Łatwo powie­dzieć: zebrać wymagania.

Powszechnie uwa­ża się, że ana­li­za wyma­gań na opro­gra­mo­wa­nie to pro­sty, ale pra­co­chłon­ny pro­ces pro­wa­dze­nia wywia­dów i skrzęt­ne­go zapi­sy­wa­nia tego, cze­go ocze­ku­je przy­szły użyt­kow­nik. Nic bar­dziej błęd­ne­go – jest to naj­gor­szy sposób.

Wśród wie­lu tego typu metod są te naj­prost­sze i naj­bar­dziej ryzy­kow­ne a mia­no­wi­cie: wywia­dy, ankie­ty, [[sesje JAD]]. Sama ich isto­ta zakła­da, że klient wie co chce, nale­ży to tyl­ko z nie­go wycią­gnąć i upo­rząd­ko­wać. Być może cza­sa­mi tak jest, ale z regu­ły koń­czy się to kla­sycz­nym stwier­dze­niem klien­ta na koniec projektu:

Tak, dostar­czy­li nam Państwo dokład­nie to co chcie­li­śmy ale zupeł­nie nie to, cze­go potrzebujemy.

Dlaczego tak się dzie­je, choć wie­lu (ana­li­ty­ków) tak bar­dzo się sta­ra? Jak ana­li­za może wyglą­dać napi­sa­łem tu już nie raz. Ale po co tyle zacho­du? Dlaczego upie­ram się przy tych śmiesz­nych for­ma­li­zmach, sko­ro moż­na po ludz­ku zapi­sać co powie­dział user a potem zamie­nić to na wypunk­to­wa­ne listy lub wier­sze ład­nej tabe­li? Najlepiej jesz­cze gdy liczą sobie naj­mniej kil­ka­set pozy­cji. Jednak tak pra­cu­je ana­li­tyk dyk­ta­fon.

Dobra spe­cy­fi­ka­cja wyma­gań na opro­gra­mo­wa­nie, to wynik ana­li­zy i mode­lo­wa­nia orga­ni­za­cji, kom­pro­mis pomię­dzy moż­li­wo­ścia­mi tech­no­lo­gii a cela­mi biz­ne­so­wy­mi wdro­że­nia. Nie ma tu zna­cze­nia czy będzie to goto­wy sys­tem ERP, czy dedy­ko­wa­ne roz­wią­za­nie. Ale po kolei.

Czym gro­zi ana­li­tyk dyktafon?

Tu pozwo­lę sobie sko­rzy­stać z zawar­to­ści krót­kie­go arty­ku­łu kole­gi pro­wa­dzą­ce­go blog O wyma­ga­niach. Poniżej kil­ka sta­ty­styk oraz mój komen­tarz co do ich przy­czyn. a że pro­blem jest poważ­ny wystar­czy wie­dzeć, że:

Błędy w wyma­ga­niach to jed­na trze­cia wszyst­kich defek­tów w pro­jek­tach. [Dean Leffingwell, Don Widrig – Managing Software Requirements” (1999)]

Produktem ana­li­zy wyma­gań są wyma­ga­nia, jak już wspo­mnia­łem, moż­na je zbie­rać meto­da­mi reje­stra­cyj­ny­mi” (odpy­ty­wa­nie klien­tów) oraz badaw­czy­mi”. Te dru­gie to kolej­no: ana­li­za i model orga­ni­za­cji klien­ta, iden­ty­fi­ka­cja celów biz­ne­so­wych i czyn­ni­ków wpły­wa­ją­cych na ich osią­gnię­cie, pro­jekt roz­wią­za­nia: co ma zostać dostar­czo­ne, opis pro­jek­tu czy­li spe­cy­fi­ka­cja pro­duk­tu. Wywiady są łatwe a peł­na ana­li­za trud­na. Nie trud­no się więc domy­ślić, któ­rych się robi naj­wię­cej. I mamy głów­ną przy­czy­nę, to właśnie:

Procesy zwią­za­ne ze zbie­ra­niem wyma­gań są źró­dłem więk­szo­ści poważ­nych pro­ble­mów z jako­ścią. [Gerald Weinberg – Quality Software Management” (1997)]

Jakość spe­cy­fi­ka­cji wyma­gań to mię­dzy inny­mi jej kom­plet­ność, spój­ność itp. Jak doku­ment wyma­gań jest niskiej jako­ści to typo­wym obja­wem jest tak zwa­ne odkry­wa­nie wyma­gań w trak­cie trwa­nia pro­jek­tu, czy­li zmia­ny zakre­su pro­jek­tu, a:

Zmiany zakre­su są jed­nym z naj­częst­szych źró­deł dodat­ko­wych kosz­tów w pro­jek­tach i czę­sto pro­wa­dzą do porzu­ce­nia pro­jek­tu. [Capers Jones – Assessment and Control of Software Risks” (1994)]

Co jesz­cze? Skąd te roz­dę­te budże­ty, prze­ter­mi­no­wa­ne pro­jek­ty typu czas i mate­riał”? Bo:

Naprawa błę­dów zwią­za­nych z wyma­ga­nia­mi pochła­nia 70 – 80% kosz­tów ponow­nej pra­cy w pro­jek­tach IT. A cał­ko­wi­te kosz­ty ponow­nej pra­cy zja­da­ją nawet do 50% kosz­tów pro­jek­tu. [Dean Leffingwell – Calculating and Return on Investment from More Effective Requirements Management” (1997)]

Kolejny etap, to kosz­ty utrzymania:

Szukanie i napra­wia­nie błę­dów wyma­gań po wdro­że­niu sys­te­mu jest 100 razy kosz­tow­niej­sze niż szu­ka­nie i napra­wia­nie tych samych błę­dów pod­czas zbie­ra­nia wyma­gań. [Barry Boehm, Victor R. Basili – Software Defect Reduction Top 10 List” (2001)]

I tyle o złych wymaganiach.

Analityk zamiast dyktafonu

Jeżeli wyma­ga­nia spe­cy­fi­ku­je się meto­dą pro­stej obser­wa­cji (odsłu­chu) otrzy­mu­je­my opis fak­tów a nie ich przy­czyn. Rzecz a tym, że fak­ty nic nie mówią o ich przy­czy­nach. Kolejny cytat:

Wyobraźmy sobie kogoś, kto chce napi­sać pro­gram symu­lu­ją­cy grę w sno­oke­ra. Problem ten może zostać opi­sa­ny przy­pad­ka­mi uży­cia opi­su­ją­cy­mi powierz­chow­nie cechę: Gracz ude­rza bia­ła kulę, któ­ra prze­miesz­cza się z pew­ną pręd­ko­ścią, ta po okre­ślo­nym cza­sie ude­rza czer­wo­ną kulę pod okre­ślo­nym kątem, ude­rzo­na czer­wo­na kula prze­miesz­cza się na pew­na odle­głość w pew­nym kie­run­ku.” Możesz sfil­mo­wać set­ki tysię­cy takich ude­rzeń, zare­je­stro­wać para­me­try każ­de­go ude­rze­nia i jego skut­ki. Jednak tą meto­dą i tak nie stwo­rzysz nawet dość dobrej symu­la­cji. Aby napi­sać na praw­dę dobrą grę, powi­nie­neś raczej zro­zu­mieć pra­wa rzą­dzą­ce ruchem kul, ich zależ­ność od siły i kie­run­ku ude­rze­nia, kie­run­ku itp. Zrozumienie tych praw pozwo­li Ci znacz­nie łatwiej napi­sać dobre opro­gra­mo­wa­nie. (źr. Analysis Patterns. Reusable Object Models, Martin Fowler, Addison-Wesley, 1997).

Inny przy­kład, z nie­co innej dzie­dzi­ny ale dosko­na­le odda­ją­cy efek­ty pole­ga­nia na obser­wa­cji. Przez wie­le lat uzna­wa­no, że Ziemia to cen­trum wszech­świa­ta. Ludzie obser­wo­wa­li Niebo z Ziemi. To co widzą, po pro­tu reje­stro­wa­li ufa­jąc, że sama obser­wa­cja da wła­ści­wy wynik. W efek­cie uzy­ski­wa­li takie oto tra­jek­to­rie pla­net i gwiazd:

geocentryczny

Nie dawa­ły się opi­sać żad­nym pro­stym rów­na­niem, a te rów­na­nia któ­re powsta­wa­ły były nie tyl­ko przy­bli­że­nia­mi ale tak­że bar­dzo zło­żo­ny­mi zależ­no­ścia­mi dla każ­de­go cia­ła nie­bie­skie­go z osob­na. Powyższy rysu­nek to namiast­ka tego przy­no­szą z sobą ana­li­ty­cy obserwatorzy.

Prawdę odkrył i udo­ku­men­to­wał Kopernik, czło­wiek któ­ry nie szu­kał pokla­sku ani u zwy­kłych ludzi patrzą­cych z wia­rą w nie­bo, ani u tych, w któ­rych inte­re­sie było, by Ci ludzie wie­rzy­li, że Ziemia to sta­no­wi cen­trum ich świa­ta. Odkryta praw­da w efek­cie wszyst­kim dobrze słu­ży ? mimo począt­ko­we­go opo­ru, a wyglą­da ona tak:

heliocentryczny

System helio­cen­trycz­ny jest pro­sty, zro­zu­mia­ły dla każ­de­go, łatwy do opi­sa­nia (mimo to wie­lu ludziom nadal trud­no się pogo­dzić z tym, że nie są pęp­kiem świa­ta a jedy­nie jego czę­ścią i to nie cen­tral­ną). Poszczególne komór­ki orga­ni­za­cyj­ne w fir­mach i orga­ni­za­cjach, owe fir­my na ryn­ku, są jak poszcze­gól­ne cia­ła nie­bie­skie we wszech­świe­cie, pra­cow­ni­cy tych orga­ni­za­cji jak róż­ni obser­wa­to­rzy tego same­go Nieba. Każdy ma swo­je oso­bi­ste spoj­rze­nie na swo­ją część ale nikt z nich nie widzi cało­ści «z góry”. Każdy ma swój, geo­cen­trycz­ny widok. Typowe wywia­dy to zle­pek takich opisów.

Praktyka poka­zu­je, że sys­te­my (fir­my, orga­ni­za­cje) obser­wo­wa­ne z ich wnę­trza wyda­ją się bar­dzo skom­pli­ko­wa­ne i tak też są opi­sy­wa­ne przez więk­szość ludzi (patrz wyżej dia­gram sys­te­mu geo­cen­trycz­ne­go). W rze­czy­wi­sto­ści więk­szość sys­te­mów jest znacz­nie prost­sza, jed­nak odkry­cie tego wyma­ga głę­bo­kie­go spoj­rze­nia z zewnątrz.

Rzemieślnicy pro­du­ku­ją­cy ?przed Kopernikiem? skom­pli­ko­wa­ne i kosz­tow­ne przy­rzą­dy do okre­śla­nia poło­że­nia pla­net i gwiazd z wia­do­mych powo­dów nie byli zain­te­re­so­wa­ni uprasz­cza­niem tego mode­lu i swo­ich skom­pli­ko­wa­nych przy­rzą­dów. Dlatego zapew­ne nie raz jesz­cze usły­szę, że dobra ana­li­za to set­ki stron, tysią­ce wyma­gań, mie­sią­ce pracy.

Jednak dobra ana­li­za to tyl­ko: dzie­siąt­ki stron i wyma­gań, tygo­dnie pra­cy ale zaawan­so­wa­ne meto­dy takie jak for­mal­na ana­li­za sys­te­mo­wa opar­ta na mode­lach i ich testowaniu.

Warto jed­nak zazna­czyć, że tak jak pro­jek­ty dedy­ko­wa­ne mają sens od ok. 75 tys. zł. (wyli­cze­nie w jed­nym zw wcze­śniej­szych arty­ku­łów) tak zaprzę­ga­nie takich metod ana­li­zy ma sens nawet jeże­li war­tość pro­jek­tu (war­tość ryzy­ka) prze­kra­cza już 10 tys. czy­li nie tak wie­le.… (koszt tego typu ana­liz to ok. 20% budże­tu projektu).

Na zakon­cze­nie cytat:

Niestety naj­częst­szy­mi przy­czy­na­mi [pro­ble­mów i dużych kosz­tów w pro­jek­tach] są źle prze­pro­wa­dzo­na ana­li­za przed­wdro­że­nio­wa i nie­ste­ty zbyt małe doświad­cze­nie part­ne­ra wdro­że­nio­we­go. Zwłaszcza przy dużych pro­jek­tach, gdzie spe­cy­fi­ka przed­się­bior­stwa wyma­ga oddziel­nych roz­wią­zań uzu­peł­nia­ją­cych i dużej wie­dzy pro­gra­mi­stycz­nej, poja­wia­ją się pro­ble­my. (źr. Wdrożenie ERP ? koszt czy zysk? – ERP ‑view​.pl.)

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).

Ten post ma 8 komentarzy

  1. Jakub Jurkiewicz

    Wydaje mi się, że uprasz­czasz Jarku wywia­dy, spo­tka­nia i warsz­ta­ty. Na takich warsz­ta­tach moż­na bar­dzo dobrze zro­zu­mieć klien­ta i jego pro­blem oraz pomóc zro­zu­mieć klien­to­wi, cze­go tak napraw­dę potrze­bu­je. Na warsz­ta­tach moż­na rów­nież two­rzyć mode­le i na bie­żą­co je walidować. 

    Nie chcę tutaj jed­no­znacz­nie orze­kać, któ­re podej­ście jest lep­sze, ale wyda­je mi się, że takie stra­sze­nie” sesja­mi JAD i warsz­ta­ta­mi jest dla nich krzywdzące.

    1. Jarek Żeliński

      Owszem uprasz­czam ale tyl­ko do pew­ne­go stop­nia, pole­cam dwa arty­ku­ły na ten temat, a szcze­gól­nie komen­ta­rze prak­ty­ków pod nimi:

      1. http://​it​-con​sul​ting​.pl/​a​u​t​o​i​n​s​t​a​l​a​t​o​r​/​w​o​r​d​p​r​e​s​s​/​i​n​d​e​x​.​p​h​p​/​2​0​1​1​/​0​1​/​1​3​/​w​y​m​a​g​a​n​i​a​-​k​l​i​e​n​t​-​t​o​-​n​a​s​z​-​p​a​n​-​c​z​y​-​p​a​c​j​e​nt/

      oraz

      2. http://it-consulting.pl/autoinstalator/wordpress/index.php/2010/11/08/mozliwe-wyjasnienie-metod-typu-user-story-use-case-driven-%E2%80%A6-prototyping-i-klopotow-inzynierow/

      Ja tak­że pro­szę o wyro­zu­mia­łość: w 100% przy­pad­ków gdy audy­to­wa­łem doku­men­ta­cję wyma­gań zawa­lo­nych” pro­jek­tów były to zapi­sy spo­tkań, ankiet, sesji JAD itp. Te meto­dy spraw­dza­ją się przy two­rze­niu inte­rak­tyw­nych por­ta­li dla klien­tów fir­my, ale moim zda­niem nie są dobre do sys­te­mów biz­ne­so­wych. W biz­ne­sie wyma­ga­nia sta­wia szef a nie jego pra­cow­nik. Po dru­gie wewnątrz fir­my ankie­ty i sesje JAD to pra­wie zawsze wal­ka pra­cow­ni­ków o wpły­wy a nie mode­lo­wa­nie firmy.

    2. Jakub Jurkiewicz

      Z kil­ko­ma Twoimi teza­mi posta­wio­ny­mi w poda­nych arty­ku­łach nie mogę się zgo­dzić. Wydaje mi się, że wyni­ka to z tego, że pró­bu­jesz trak­to­wać JADy zbyt płyt­ko. Są ana­li­ty­cy, któ­rzy potra­fią bar­dzo efek­tyw­nie prze­pro­wa­dzać warsz­ta­ty i są z nich bar­dzo zado­wo­le­ni. Co wię­cej, klient wów­czas też jest bar­dziej zadowolony.
      Pod tymi tek­sta­mi wypo­wie­dzia­ło się tak napraw­dę dwóch prak­ty­ków, co wyda­je mi się zbyt małą gru­pą, aby jasno potwier­dza­ły Twoje tezy.

      Najbardziej chy­ba nie zga­dzam się z tym, że nie powin­ni­śmy przej­mo­wać się użyt­kow­ni­ka­mi, bo to pre­zes fir­my jest naszym klien­tem i to jego powin­ni­śmy słu­chać (tak na mar­gi­ne­sie, to wła­śnie mam w przy­go­to­wa­niu wpis o tej tema­ty­ce na swo­im blo­gu). Użytkownicy potra­fią być skarb­ni­cą wie­dzy. Rzekłbym nawet, że czę­sto pre­zes nie wie, co i jak sys­tem ma robić. Oczywiście prze­słan­ki biz­ne­so­we naj­bar­dziej rozu­mie zarząd, co do tego nie ma wąt­pli­wo­ści, ale to użyt­kow­ni­cy korzy­sta­li z poprzed­niej wer­sji sys­te­mu i będą korzy­stać z nowej wer­sji. Ja bym nie ośmie­lił się odsta­wić ich na bok i nie sko­rzy­stać z ich wiedzy.

      Tak przy oka­zji dzię­ki Jarku za Twoje tek­sty, któ­re nie­jed­no­krot­nie zmu­sza­ją mnie do prze­my­śle­nia nie­któ­rych kwe­stii. Co praw­da na nie­któ­re spra­wy mamy inne spoj­rze­nie, ale wła­śnie dzię­ki temu Twoje tek­sty są dla mnie jesz­cze bar­dziej wartościowe 🙂

    3. Jarek Żeliński

      Ścierają się róż­ne tezy i to ma naj­więk­szą war­tość. Bronię swo­jej bo przyj­mu­je pew­ne zało­że­nia na począt­ku pro­jek­tu. Z zasa­dy są w pro­jek­tach dwie głów­ne role: rola spon­so­ra pro­jek­tu i rola użyt­kow­ni­ka. Od koń­ca: użyt­kow­nik ma decy­du­ją­ca role jeśli on decy­du­je o tym czy w ogó­le będzie sys­te­mu uży­wał. Ma to miej­sce prak­tycz­nie w każ­dym pro­jek­cie, w któ­rym powsta­je stro­na ano­ni­mo­we­go” akto­ra jakim jest jakiś użyt­kow­nik sie­ci”. Wtedy robi się sesje warsz­ta­to­we, bada­nia focu­so­we, ankie­ty itp. Jednak i tu nie wykro­czy­my poza czar­ną skrzyn­kę” przy­pad­ków użycia. 

      Uważam, za bar­dzo nie­bez­piecz­ne dla pro­jek­tu powo­ły­wa­nie się na poprzed­nio uży­wa­ny sys­tem” gdyż czę­sto jest wymie­nia­ny wła­śnie z tego powo­du, że jest kulą u nogi, ale jest to waż­ne, jeśli mowa o korzy­sta­niu z por­ta­li kon­ku­ren­cji. Tak więc w więk­szo­ści pro­jek­tów, jak je nazy­wam, por­ta­lo­wych, user wyzna­cza potrze­by a spon­sor je reali­zu­je. W pro­jek­tach biz­ne­so­wych, umow­nie wnę­trze fir­my, spon­sor zabez­pie­cza swo­je potrzeby. 

      Mój opór do sesji JAD (i podob­nych metod) bie­rze się z tego, że ich wyni­ki są nie­we­ry­fi­ko­wal­ne. Są to dekla­ra­tyw­ne, demo­kra­tycz­nie usta­la­ne zapi­sy ocze­ki­wań, któ­re mnie się koja­rzą raczej z usta­la­niem wyna­gro­dzeń na zebra­niu związ­ków zawo­do­wych (mówię teraz o pro­jek­tach biznesowych). 

      Moim zda­niem meto­dy nie raz dosko­na­le dzia­ła­ją­ce w pro­jek­tach inter­ne­to­wych nie spraw­dza­ją się w pro­jek­tach biz­ne­so­wych. Niestety widzę nie raz jak wykła­da­ją się na biz­ne­so­wych pro­jek­tach zna­ne i dobre agen­cje inte­rak­tyw­ne. Po dru­gie w biz­ne­sie jest dru­gi istot­nie inny ele­ment: w pro­ces biz­ne­so­wy jest zaan­ga­żo­wa­nych wie­le osób ale każ­da zna go tyl­ko na swo­im odcin­ku”. Jeżeli więc np. ja jako klient skle­pu inter­ne­to­we­go sam jestem akto­rem całe­go pro­ce­su zaku­pu książ­ki i mam pra­wo o nim mówić, tak jako pra­cow­nik maga­zy­nu nawet śred­niej fir­my nie mam, żad­nych pod­staw by dys­ku­to­wać o pro­ce­sie logi­stycz­nym. To jest zresz­tą klu­czo­wy powód by takie ana­li­zy robił ktoś z zewnątrz ale nie dostaw­ca (ten ma już swo­je roz­wią­za­nie i będzie for­so­wał, nawet jeśli jest to deve­lo­per i tyl­ko jakiś jego fra­me­work i zestaw wypra­co­wa­nych wła­snych bibliotek).

    4. Jakub Jurkiewicz

      I tak, i nie 🙂
      Wcale nie twier­dzę, że na warsz­ta­tach, JADach i innych takich powi­nien zakoń­czyć sie etap zbie­ra­nia wyma­gań. Mam raczej zda­nie, że warsz­ta­ty wła­śnie (ale odpo­wied­nio prze­pro­wa­dzo­ne, z dobrze zary­so­wa­nym celem, odpo­wied­nim przy­go­to­wa­niem i prze­pro­wa­dze­niem) mogą nam pomóc lepiej zro­zu­mieć pro­blem biz­ne­so­wy spon­so­ra oraz użyt­kow­ni­ków. A póź­niej moż­na to prze­ło­żyć na wery­fi­ko­wal­ne modele.

      Powoływanie się na poprzed­ni sys­tem ma tę zale­tę, że pozwa­la zna­leźć pro­ble­my, któ­re moż­na spró­bo­wać roz­wią­zać w kolej­nej wer­sji sys­te­mu. Chociaż cza­sa­mi może być to nie­bez­piecz­ne, szcze­gól­nie w przy­pad­kach, gdy użyt­kow­ni­cy boją się zmia­ny. W takiej sytu­acji mogą pró­bo­wać utrud­niać pra­cę niestety.

    5. Jarek Żeliński

      No to zbli­ża­my się do celu: jeże­li JAD ma pomóc lepiej zro­zu­mieć pro­blem biz­ne­so­wy spon­so­ra oraz użyt­kow­ni­ków, to ja w to miej­sce żądam od klien­ta zesta­wu przy­kła­dów doku­men­tów (np. trzy egzem­pla­rze każ­de­go, z infor­ma­cją kto jest wystaw­cą każ­de­go z nich i komu go prze­ka­zu­je) i na tej pod­sta­wie odtwa­rzam” pro­ce­sy w fir­mie oraz wstęp­ny model dzie­dzi­ny. Jak nie trud­no się domy­śleć, mode­le te są dziu­ra­we jak ser i wyma­ga­ją uzu­peł­nień, i tu spo­ty­kam się z ludź­mi (lub nawet tyl­ko dzwo­nię) by wyja­śnić bra­ki. Po pierw­sze doku­men­ty są obiek­tyw­ne, wywia­dy już nie koniecz­nie. Po dru­gie cały taki pro­ces jest szyb­szy i mniej kosz­tow­ny (nie zbie­ram na całe dnie dużych zespo­łów ludzi klien­ta, sam nie tra­cę cza­su na nie raz gorą­ce dys­ku­sje, robię to sam, czy­li kolej­ne niż­sze kosz­ty) więc klient odno­si korzyść. Zaś pro­blem i cel klien­ta musi być usta­lo­ny na samym począt­ku pro­jek­tu poprzez sakra­men­tal­ne: na grzy­ba Panu/Pani ten sys­tem 🙂 bo to daje świa­teł­ko w tune­lu na cały czas trwa­nia projektu …

    6. Tomasz

      Witaj Jarku, dzię­ku­ję Tobie za wie­le war­to­ścio­wych arty­ku­łów, któ­re, oprócz prze­ka­zy­wa­nia wie­dzy, zmu­sza­ją rów­nież do prze­war­to­ścio­wa­nia pew­nych rzeczy.
      Jednak jeśli ana­li­tyk biz­ne­so­wy ograniczy/umniejszy za moc­no ilość i war­tość wie­dzy od użyt­kow­ni­ków sys­te­mu, to moim zda­niem ist­nie­je zagro­że­nie, że będzie for­so­wać swój model refe­ren­cyj­ny (czy­li bazo­wać tyl­ko na roz­wią­za­niach z poprzed­nich ana­liz i swo­je­go doświad­cze­nia). W efek­cie powsta­nie ana­li­za ode­rwa­na od rze­czy­wi­sto­ści – przed­sta­wia­ją­ca ide­ał przed­się­bior­stwa, a nie stan fak­tycz­ny. Często bywa tak, że pro­ce­sy fak­tycz­ne róż­nią się od tego, jak się wyda­je kadrze zarzą­dza­ją­cej naj­wyż­sze­go szcze­bla (spon­so­ro­wi). Bez roz­mów z użytkownikami/pracownikami fir­my nie moż­na takich odchy­leń wychwycić.
      Inną kwe­stią jest to, że np. nie dowie­my się, że poprzed­ni sys­tem pró­bo­wał wpro­wa­dzić pro­ce­sy zbyt modelowo/teoretycznie (za duża inge­ren­cja w pro­ce­sy fir­my), któ­re ze wzglę­du na opór przed zmia­ną były sabo­to­wa­ne przez użyt­kow­ni­ków lub po pro­stu nie­prak­tycz­ne w danym przed­się­bior­stwie (np. wydzie­le­nie funk­cji do róż­nych modu­łów, któ­re są obsłu­gi­wa­ne przez tych samych użytkowników).
      Oczywiście zbyt obszer­ne bazo­wa­nie na wywia­dach i warsz­ta­tach z użyt­kow­ni­ka­mi może pro­wa­dzić do ście­ra­nia się róż­nych sił w przed­się­bior­stwie. Jednak, gdy użyt­kow­ni­cy zoba­czą nowy dedy­ko­wa­ny sys­tem zbyt póź­no, może się oka­zać, że nowy sys­tem jest gor­szy od sta­re­go (tak ogrom­ny jest opór przed zmia­ną, któ­ra nie wyni­ka oddol­nie). No i jesz­cze trze­ba uwa­żać, by nie zabe­to­no­wać” nie­opty­mal­nych pro­ce­sów biz­ne­so­wych. A jed­no­cze­śnie przez przy­pa­dek nie dosto­so­wać dobrych pro­ce­sów do pro­ce­sów refe­ren­cyj­nych, co może z bar­dzo dobre­go przed­się­bior­stwa uczy­nić przeciętne.

    7. Jarek Żeliński

      Problem nie jest pro­sty. Osobiście uwa­żam, że zna­ne z orga­ni­za­cji i zarzą­dza­nia podej­ście trój­war­stwo­we (podział orga­ni­za­cji na war­stwę budo­wa­nia stra­te­gii, pro­ce­sów biz­ne­so­wych i reali­za­cji) daje pod­sta­wę do pro­wa­dze­nia pro­jek­tów ana­li­zy przed-wdro­że­nio­wej i pro­jek­to­wa­nia opro­gra­mo­wa­nia. Cel biz­ne­so­wy musi wyjść od Zarządu, któ­ry wie co chce osią­gnąć. Procesy biz­ne­so­we opi­su­ją to co i po co się dzie­je w orga­ni­za­cji. Procesy reali­zu­ją cel biz­ne­so­wy fir­my (sta­no­wią wewnętrz­ny łań­cuch war­to­ści). To jak pra­cu­ją ludzie to spo­sób wyko­ny­wa­nia tej pra­cy w kon­kret­nych warun­kach. Po latach funk­cjo­no­wa­nia te trzy war­stwy są zin­te­gro­wa­ne”, ludzie pra­cu­ją, fir­ma funk­cjo­nu­je. Ale: to Zarząd podej­mu­je decy­du­je, że coś będzie sprze­da­wał, pro­ces wysta­wia­nia fak­tu­ry VAT musi ist­nieć, to jak fak­tu­ra zosta­nie wysta­wio­na zale­ży już od wie­lu lokal­nych warun­ków – to spe­cy­fi­ka wyko­na­nia. Zarząd jed­nak narzu­ca regu­łę (biz­ne­so­wą): wszyst­kie doku­men­ty ope­ru­ją­ce war­to­ścią 10.000zł lub wię­cej muszą być zatwier­dza­ne przez zarząd. Rola ana­li­ty­ka biz­ne­so­we­go jest pra­ca bli­ska desty­la­cji zmie­sza­ne­go pły­nu: musi to wszyst­ko roz­dzie­lić na owe trzy war­stwy. Oprogramowanie z jed­nej stro­ny wspie­ra pro­ce­sy biz­ne­so­we więc wspie­ra powsta­wa­nie pro­duk­tów pro­ce­sów. Tu mamy przy­pad­ki uży­cia (usłu­gi sys­te­mu). Z dru­giej stro­ny opro­gra­mo­wa­nie to narzę­dzie pra­cy, wiec poja­wia się pyta­nie jak ma to robić i tu mamy sce­na­riu­sze tych przy­pad­ków uży­cia (to war­stwa reali­za­cji). Na koniec: cała orga­ni­za­cja pra­cu­je z jaki­miś infor­ma­cja­mi (dany­mi) więc potrzeb­ny jest model infor­ma­cyj­ny. Teraz nale­ży się zasta­no­wić: w czym, w któ­rym eta­pie tej pra­cy może na pomóc pra­cow­nik pra­cu­ją­cy w jed­nym miej­scu (na jed­nym stanowisku)?

Dodaj komentarz

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