Why Organizations Need Business Analysts

We have always been fasci­na­ted by the excep­tio­nal busi­ness ana­ly­sts who can cre­ate order out of total cha­os. (za Ambiguity, Uncertainty or Both? > Business Analyst Community & Resources).

ModernAnalys​.com to jeden z moich ulu­bio­nych ser­wi­sów w sie­ci. W tego typu ser­wi­sach naj­bar­dziej fascy­nu­je mnie, że w zasa­dzie (w pew­nym sen­sie i ja tak­że w moim blo­gu) trak­tu­je o rze­czach oczywistych.

Powyżej kolej­ny cytat z tego ser­wi­su: Zawsze fascy­no­wa­ła nas nie­prze­cięt­na zdol­ność ana­li­ty­ków biz­ne­so­wych do porząd­ko­wa­nia total­ne­go cha­osu”. Tytuł arty­ku­łu brzmi Po co orga­ni­za­cjom Analityk Biznesowy”.

Autorzy słusz­nie zwra­ca­ją uwa­gę, że poję­cie nie­pew­no­ścinie­ja­sno­ści (dwu­znacz­ność) to odręb­ne poję­cia. Niepewność ma swo­je źró­dło w sta­ty­sty­ce i ozna­cza, ryzy­ko. Niejasność to poję­cie zwią­za­ne z komu­ni­ka­cją (pre­cy­zja języ­ka) i ozna­cza nie­jed­no­znacz­ność treści”.

Ale nie jest tu moim celem tłu­ma­cze­nie tego tek­stu na pol­ski. Postanowiłem dodać coś od sie­bie. Ryzyka zna­my (sta­ty­sty­ka nie­uda­nych pro­jek­tów IT) więc co z tymi dwo­ma poję­cia­mi? Zaryzykuje tezę:

Im więk­sza nie­jed­no­znacz­ność doku­men­tu wyma­gań tym więk­sze ryzy­ko, że pro­jekt będzie miał kłopoty”.

Powyższe nie sta­no­wi żad­ne­go odkry­cia co nie zmie­nia fak­tu, że jakość więk­szo­ści doku­men­tów wyma­gań (owe 70%) jest sła­ba, na co wska­zu­ją sami ankietowani.

Rola Kierownika Projektu to mię­dzy inny­mi zarzą­dza­nie ryzy­kiem. Statystyki są nie­ubła­ga­ne, więc brak dobre­go ana­li­ty­ka i dobrej ana­li­zy wyma­gań spy­cha pro­jekt w kie­run­ku kło­po­tów. No to mamy kolej­ne bada­nie: Znaczenie i zapo­trze­bo­wa­nie na spe­cja­li­stów wg. Forrestera: 70% bada­nych decy­den­tów uwa­ża, że Analityk Biznesowy to klu­czo­wa postać w pro­jek­cie. Jednak nie dla­te­go, że jest waż­niej­szy od np. kie­row­ni­ka pro­jek­tu, bo nie jest waż­niej­szy. Dlatego, że od jako­ści jego pro­duk­tu (ana­li­za i spe­cy­fi­ka­cja wyma­gań) zale­ży wła­śnie ryzy­ko całe­go projektu.

Co jest wadą większości analiz biznesowych?

To, że są one tak na praw­dę upo­rząd­ko­wa­nym zapi­sem wywia­dów z klien­tem a nie fak­tycz­ną ana­li­zą orga­ni­za­cji, jej potrzeb (bo raczej nie koniecz­nie jej pra­cow­ni­ków!) i celów biznesowych.

  • Jakie są tre­ści tek­sto­we­go lub tabe­la­rycz­ne­go zapi­su wywia­dów? NIEJEDNOZNACZNE! 
  • Jakie są nie­sfor­ma­li­zo­wa­ne, swo­bod­nie two­rzo­ne dia­gra­my pro­ce­sów? NIEJEDNOZNACZNE! 
  • Jakie są słow­ne opi­sy struk­tu­ry opro­gra­mo­wa­nia jakie ma powstać? NIEJEDNOZNACZNE!

Co zro­bić? Używać już na eta­pie ana­li­zy biz­ne­so­wej i pro­jek­to­wa­nia sfor­ma­li­zo­wa­nych narzę­dzi takich jak stan­dar­do­we nota­cje i meto­dy­ki, wte­dy opi­sy będą JEDNOZNACZNE. Czy to trud­ne? Tak, w koń­cu te 70% pora­żek to nie przypadek…

A na popra­wę humo­ru i na dowód, że powyż­sze jed­nak war­te jest uwa­gi, przy­kład nie­jed­no­znacz­no­ści w tek­ście czy­li jak inten­cje roz­mi­ja­ją się z …

Na zakoń­cze­nie przy­to­czę sło­wa jakie na podob­ny temat wygło­sił [[Alfred Tarski]]:

Dysputy tego rodza­ju [co jest czym, przyp. mój] wca­le nie ogra­ni­cza­ją się do poję­cia praw­dy. Występują we wszyst­kich dzie­dzi­nach, gdzie – zamiast ści­słej nauko­wej ter­mi­no­lo­gii – uży­wa się języ­ka potocz­ne­go, z jego nie­ja­sno­ścią i wie­lo­znacz­no­ścią: są one zawsze pozba­wio­ne sen­su, i dla­te­go daremne.

Jarosław Żeliński

BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę 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.

Ten post ma 7 komentarzy

  1. Warto po prze­czy­ta­niu tego arty­ku­łu na ModernAnalyst, wró­cić na chwi­lę do komen­ta­rzy do poprzed­nie­go arty­ku­łu zaty­tu­ło­wa­ne­go How Detailed Should Requirements Be? – Part 1”. Pojawia się tam sfor­mu­ło­wa­nie, że tak napraw­dę komu­ni­ka­cja wystar­czy i w sumie cha­osu nie trze­ba porząd­ko­wać, a jak widać z cyta­tu powy­żej war­to poświę­cić czas, aby potwier­dzić te usta­le­nia w posta­ci doku­men­tu, bo ina­czej rośnie ryzy­ko projektu.

  2. Szymon Drejewicz

    Fakt, stan­dar­do­we meto­dy­ki i nota­cje powo­du­ją, że wyma­ga­nia są doku­men­to­wa­ne. Dzięki temu wie­my na czym sto­imy. Podobnie jak budu­jąc dom ocze­ku­je­my stan­dar­do­we­go pro­jek­tu archi­tek­to­nicz­ne­go, a nie przy­pad­ko­wo opra­co­wa­ne­go tek­stu. Niestety wie­le osób ze świa­ta IT cią­gle uwa­ża, że rola IT pole­ga na pro­gra­mo­wa­niu. A cała resz­ta to jakieś bzdu­ry. Specyfikacja? Phi! Wymagania? Phi!? Traceablility? Phi! Zmiany? Yyyyy w czym?… 🙂

    1. Jarek Żeliński

      Czasami ciśnie mi się na usta pyta­nie do zespo­łów agi­le: czy zamiesz­kał byś w domu zbu­do­wa­nym tak jak opro­gra­mo­wa­nie, któ­re teraz piszesz?

    2. Szymon Drejewicz

      Jeśli obie stro­ny usta­lą, że cho­dzi o sza­łas, to na pew­no Agile jest OK 🙂

    3. Jarek Żeliński

      E.Yourdon pro­po­nu­je w swo­ich książ­kach budę dla psa w takich projektach…;)

  3. Bardzo podo­ba mi się ten arty­kuł. Rzeczywiście nie jest to pro­ste dla firm. Być może nie ma oso­by dedy­ko­wa­nej do ana­li­zy (robią to ludzie w innych rolach/na innych sta­no­wi­skach przy oka­zji”), a może te, któ­re są, nie wie­rzą” w sys­te­my poję­cio­we, nota­cje. Spotkałam się z opi­nia­mi, że I tak każ­dy UML rysu­je po swo­je­mu” albo lepiej – Gdyby pro­gra­mi­ści myśle­li, ana­li­ty­cy nie byli­by potrzebni”.
    Na stu­diach dzi­wi­ła mnie tak duża for­ma­li­za­cja opsiu wyma­gań, ale teraz, patrząc na kolej­ne pro­jek­ty, rze­czy­wi­ście przy­zna­ję rację – to waż­ne. A nawet chcia­ło­by się pójść jesz­cze dalej – pre­cy­zo­wać jesz­cze bardziej.
    Gdzieś wspo­mi­nał Pan o pra­cy dok­tor­skiej na ten tamat. Jak ma się ona do moż­li­wo­ści narzę­dzi takich jak Paradigm/Enterprise Architect? Jakie widzi Pan nie­wy­ko­rzy­sty­wa­ne do tej pory w prak­ty­ce możliwość/korzyści?

    1. Jarek Żeliński

      🙂 narzę­dzia są, wystar­czy uży­wać, w czym pro­blem? Hm.… to trosz­kę jak z pra­niem i dobrą pral­ką: po pierw­sze trze­ba czy­tać instruk­cję obsłu­gi, po dru­gie trze­ba się do niej sto­so­wać, po trze­cie trze­ba czy­tać wszy­te fisz­ki w ubra­niach i prać zgod­nie z zale­ce­nia­mi pro­du­cen­ta. W prze­ciw­nym wypad­ku dobre ubra­nie, znisz­czo­ne pod­czas pra­nia, leci do kosz­ta, prze­pła­ca­my kupu­jąc nowe… 

      Są narzę­dzia, są sys­te­my poję­cio­we, są nota­cje, są języ­ki pro­gra­mo­wa­nia,… trze­ba czy­tać. Mamy jed­nak coś co ja nazy­wam syn­dro­mem Lotto: w zasa­dzie wia­do­mo, że szan­sa jest nikła, gra­nie jest bez sen­su a mimo to rze­sze ludzi pró­bu­ją… tu podob­nie: w zasa­dzie wia­do­mo jak pro­wa­dzić pro­jek­ty, doku­men­ta­cję itp. a mimo to wie­lu pró­bu­je na skró­ty”… Drugi pro­blem doty­ka nie­co począt­ków nauki w szko­le i ocen: trze­ba się tego nauczyć i zrozumieć.

      W sumie moż­li­wo­ści mode­lo­wa­nia są takie:
      – wyma­ga­nia dzie­li­my na funk­cjo­nal­ne i jako­ścio­we (ogra­ni­cze­nia, nie­funk­cjo­nal­ne, inne nazwy),
      – funk­cjo­nal­ne moż­na mode­lo­wać i prze­te­sto­wać bez pisa­nia nawet linij­ki kodu co bar­dzo obni­ża kosz­ty projektu,
      – jako­ścio­we wyma­ga­ją testów i doświad­cze­nia (wydaj­ność, zna­jo­mość plat­for­my itp.)
      – dostaw­cy (więk­szość) opro­gra­mo­wa­nia nie są zain­te­re­so­wa­ni obni­ża­niem war­to­ści pro­jek­tów bo to obni­ża ich przychody.

      I na koniec: rola ana­li­ty­ka to:
      – ana­li­za i iden­ty­fi­ka­cja celu biznesowego
      – opra­co­wa­nie pro­jek­tu reali­za­cji wyma­gań funk­cjo­nal­nych (use case­’y to za mało, powin­na być mode­lo­wa­na obiek­to­wo cała logi­ka biz­ne­so­wa jaką trze­ba zaim­ple­men­to­wać, nikt inny tego nie zro­bi, na pew­nie nie jest to rola programisty),
      – spi­sa­nie listy wyma­gań jako­ścio­wych (ogra­ni­czeń)

      Rola deve­lo­pe­ra to wyce­na i imple­men­ta­cja powyższego.

Dodaj komentarz

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