O szkoleniu

Ameryka przy­je­cha­ła do nas, [[Darryl Booker]], któ­ry 20 lat (poza pra­cą na uczel­ni) pra­cu­je jako kon­sul­tant, ana­li­tyk biz­ne­so­wy był tre­ne­rem na szko­le­niu, któ­re mam wła­śnie za sobą.

Z jed­nej stro­ny trzy dni pozna­wa­łem coś do cze­go sam docho­dzi­łem, co w zasa­dzie znam i potra­fię, jed­nak z dru­giej stro­ny szko­le­nia pro­wa­dzo­ne przez ludzi z dużym doświad­cze­niem zawsze mają dwa aspek­ty: po pierw­sze począt­ku­ją­cy dowie­dzą się jak nale­ży pra­co­wać i co powin­no pod­czas tej pra­cy powsta­wać po dru­gie dla mnie (dla każ­de­go z dużym doświad­cze­niem) bar­dzo cen­ne są kon­tak­ty z inny­mi ludź­mi z bran­ży, bo porów­na­nie wie­dzy, wymia­na doświad­czeń oraz dys­ku­sje pozwa­la­ją porów­nać swo­je doko­na­nia z cudzy­mi. W wie­lu pro­jek­tach i na kon­fe­ren­cjach sły­szę, że wymy­ślam jakieś nie­stwo­rzo­ne rze­czy bo nikt tak nie robi (mode­lo­wa­nie, testo­wa­nie wyma­gań, pro­of-of-con­cept, itp.). Otóż nie praw­da, po pro­tu bar­dzo wie­lu ludzi (w bar­dzo wie­lu pro­jek­tach) nie zarzą­dza ryzy­kiem przyj­mu­jąc gene­ral­nie opty­mi­stycz­ne wer­sje wydarzeń.

Czego się nauczy­łem na tym szko­le­niu? Że war­to pla­no­wać, pro­jek­to­wać i ana­li­zo­wać bo wte­dy pro­jek­ty są prze­wi­dy­wal­ne zamiast być loterią.

Jak to się robi? Od kil­ku lat pro­mu­ję ideę nauko­wej ana­li­zy sys­te­mo­wej: opis celu, opis pro­ble­mu, sta­wia­nie hipo­tez, mode­le i sce­na­riu­sze, reko­men­da­cje i pro­jekt. Nie musi to być i nie jest żaden tak zwa­ny wodo­spad” pro­jek­to­wy ([[wat­ter fall model IT]]), zwin­ność tu pole­ga na reago­wa­niu na każ­dym eta­pie pro­jek­tu na pro­ble­my i wpro­wa­dza­nie zmian, pro­dukt pro­jek­tu jest zawsze mode­lo­wa­ny i testo­wa­ny na każ­dym eta­pie. W efek­cie spe­cy­fi­ka­cja tego co ma powstać jest kom­plet­na, nie wyma­ga pro­to­ty­po­wa­nia” na żywym cie­le (powsta­je kod dla klien­ta, któ­ry zgła­sza uwa­gi do tego co zoba­czy) a zama­wia­ją­cy wie co dosta­nie w dniu zamó­wie­nia i wie ile to będzie kosztowało.

Mity dostawców oprogramowania

Dostawcy goto­we­go opro­gra­mo­wa­nia szer­mu­ją tezą, że oszczę­dzą Wam kosz­tów ana­li­zy bo mają wie­dzę i doświad­cze­nie zawar­te” w swo­im pro­duk­cie. Ryzyko, że wyma­ga­nia biz­ne­so­we zosta­ną źle zde­fi­nio­wa­ne i ryzy­ko, że dostar­czo­ny pro­dukt nie speł­nia tych wyma­gań jest igno­ro­wa­ne (klient zamó­wił to klient dosta­nie, czy to będzie mu potem potrzeb­ne to nie nasz problem).

Developerzy ofe­ru­ją­cy wyko­na­nie dedy­ko­wa­ne­go opro­gra­mo­wa­nia bez ana­li­zy wyma­gań a np. tyl­ko z pomo­cą tak zwa­nych sesji JAD (ang. [[Joint appli­ca­tion design]]) i kolej­nych pro­to­ty­pów, w ogó­le nie bio­rą pod uwa­gę ryzy­ka nie­kom­plet­no­ści tak okre­ślo­nych wyma­gań ani bra­ku ich spój­no­ści (zna­ny pro­blem odkry­wa­nia wyma­gań w trak­cie wdro­że­nia). Klient powie co chce i będzie OK a opro­gra­mo­wa­nie i tak ma być bo każ­dy ma.

A ryzy­ko, że ana­li­za potrzeb i pro­jekt tego co ma powstać, wyko­na­na przez przy­szłe­go wyko­naw­cę, będzie tak na praw­dę tyl­ko spe­cy­fi­ka­cję tyl­ko tego co dostaw­ca potra­fi wykonać?

Dlaczego tak często projekty łamią zasady rozsądku i zarządzania ryzykiem?

Wczoraj na sali i w kulu­arach padły mię­dzy inny­mi takie odpowiedzi:

  1. dostaw­cy opro­gra­mo­wa­nia bar­dzo czę­sto nie potra­fią takiej ana­li­zy wyko­nać bo nie mają wyma­ga­nych kom­pe­ten­cji, ale potra­fią pro­gra­mo­wać i tyl­ko na to się godzą.

  2. dostaw­cy opro­gra­mo­wa­nia dosko­na­le wie­dzą, że ist­nie­je ryzy­ko że ich pro­dukt nie speł­nia wyma­gań więc bar­dzo czę­sto nie dopusz­cza­ją do takich ana­liz for­su­jąc od razu wdro­że­nie (wręcz tępią w pro­jek­tach zewnętrz­nych analityków!).

  3. klien­ci mają sta­le do czy­nie­nia z dostaw­ca­mi a bar­dzo rzad­ko z nie­za­leż­ny­mi ana­li­ty­ka­mi i bar­dzo czę­sto przyj­mu­ją wia­rę w to co mówią dostawcy.

  4. nie ist­nie­ją nie­za­leż­ni analitycy.

Na ostat­nie odpo­wiem tak: jest ich (nas) mało… ale to łatwo spraw­dzić: popro­sić o refe­ren­cje i zapy­tać co reko­men­do­wa­li. Dobry ana­li­tyk nigdy nie reko­men­du­je imple­men­ta­cji a tyl­ko two­rzy spe­cy­fi­ka­cję biz­ne­so­wą. Po trze­cie, war­to anga­żo­wać ludzi zna­nych w bran­ży z tego, że nie są na pro­wi­zjach u producentów.

Agile…

Wielu z deve­lo­pe­rów idzie dalej: nie trze­ba ana­li­zy, trze­ba od razu zacząć two­rzyć roz­wią­za­nie, [[Agile Manifesto]] – hasło prze­wod­nie tej meto­dy jasno mówi, że cho­dzi o to by pro­gra­mo­wać a nie o to by coś doku­men­to­wać, szko­da cza­su na głu­po­ty (zawsze tak okre­ślo­ne meto­dy zwin­ne koja­rzy­ły mi się z home­opa­tią: dostaw­cy obie­cu­ją coś nie wie­dząc co na praw­dę boli i nie bio­rą żad­nej odpo­wie­dzial­no­ści za skut­ki, co cie­ka­we żad­ne dane nie potwier­dza­ją sku­tecz­no­ści tych metod).

Inna cie­ka­wost­ką metod Agile jest to, że pro­jekt koń­czy się nie wte­dy gdy powsta­nie to co zamó­wił (a raczej wyobra­żał sobie klient bo nic nie zamó­wił, w koń­cu nie powsta­ła żad­na spe­cy­fi­ka­cja) tyl­ko to co powsta­nie dopó­ki nie skoń­czy się budżet. Co powsta­nie? Zobaczymy jak skończymy.

IIBA czyli czym jest ta Analiza Biznesowa

Od pew­ne­go cza­su IIBA pro­mu­je idee Analizy Biznesowej, któ­ra jest poważ­nym zagro­że­niem dla opi­sa­nych wyżej dostaw­ców. Dlaczego? Bo pro­mu­je two­rze­nie doku­men­tów pozwa­la­ją­cych naj­pierw dokład­nie wyspe­cy­fi­ko­wać to co jest potrzeb­ne (czy­taj pomo­że w biz­ne­sie!), potem dopie­ro zosta­je to zamó­wio­ne i dostar­czo­ne lub wykonane.

Nie da się tak? A wła­śnie, że się da. Czy to kosz­tow­ne? Zapytam tak? Co lep­sze nie­przy­dat­ny pro­dukt za 100tys. zł czy przy­dat­ny za 120tys.? Co lep­sze, pro­jekt pla­no­wa­ny na pól roku za 100tys. i wyko­na­ny w ter­mi­nie czy obie­ca­ny za 50tys. w kwar­tał a dostar­czo­ny za 250 tys, po dwóch latach?

To się nazy­wa RYZYKO a ana­li­za i pro­jek­to­wa­nie to zarzą­dza­nie tym ryzykiem!

Co oferuję jako analityk a IIBA zaleca

Porządny pro­jekt analityczny:

[sin­gle­pic id=119 w=533 h=533 float=center]

Kończący się spe­cy­fi­ka­cją wyma­gań (IIBA nazy­wa to Dokument Wymagań Biznesowych):

[sin­gle­pic id=122 w=533 h=533 float=center]

A teraz to co mogę pole­cić: szko­le­nie Analiza Biznesowa w MT&DC. Dostawców nauczy pra­cy a klien­tów wia­ry, że moż­na lepiej. Dlaczego tak pole­cam to szko­le­nie? Bo jego koszt to nic w porów­na­niu do strat jakie gene­ru­je źle zapla­no­wa­ny pro­jekt a któ­rych moż­na unik­nąć lub znacz­nie zmi­ni­ma­li­zo­wać. Nawet jeśli ktoś po szko­le­niu nie będzie potra­fił sam od razu takiej ana­li­zy wyko­nać (bo raczej po trzech dnia nie) to na pew­no będzie w sta­nie oce­nić to co pro­po­nu­ją dostaw­cy a potem zarzą­dzać takim pro­jek­tem. Potem z cza­sem sam (lub na kolej­nych szko­le­niach) nauczy się dobrej ana­li­zy biznesowej.

Na koniec naj­waż­niej­sze, para­fra­zu­jąc stwier­dze­nie Daryll’a: ana­li­ty­kom, któ­rych jedy­nym narzę­dziem pra­cy jest pakiet MS Office, w szcze­gól­no­ści Excel i PowerPoint, z góry dzię­ku­je­my (on uży­wa pro­fe­sjo­nal­nych narzę­dzi CASE i pakie­tów do zarzą­dza­nia projektami).

Inny bar­dzo cie­ka­wy arty­kuł o wyma­ga­niach: Jak zawa­lić pro­jekt infor­ma­tycz­ny. Analiza wymagań.

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 6 komentarzy

  1. Monika Brocka

    Niestety w wie­lu fir­mach kule­je jesz­cze ana­li­za, bo albo nie ma cza­su, albo więk­szość wycho­dzi z zało­że­nia: Dokładnie wiem cze­go chcę, a doku­ment? no doku­ment uzu­peł­ni­my póź­niej”, czy­li wizja jest naj­waż­niej­sza. Owszem jest waż­na, ale nadal nie rozu­miem tej oba­wy, że jeśli poświę­ci­my odpo­wied­nio dużo cza­su do prze­ana­li­zo­wa­nia wszyst­kich moż­li­wych sce­na­riu­szy dla danej funk­cjo­nal­no­ści to nagle stra­ci­my moż­li­wość reali­za­cji naszej wizji. Totalna bzdu­ra!!! Przecież takie prze­wi­dy­wa­nie to unik­nię­cie poraż­ki, czy zasko­cze­nia, że nagle coś nie dzia­ła tak jak powin­no, czy też słyn­ne sło­wa Klientów:„Myślałem, że to będzie wyglą­da­ło” inaczej”.….

    1. Jarek Żeliński

      Dodatkowo poja­wia się tak­że ten powód: a co będzie jak pro­dukt któ­ry odda­my będzie inny niż spe­cy­fi­ka­cja? lepiej więc nie robić tej spe­cy­fi­ka­cji…”. Niestety nie raz tak zwa­ny biz­nes” nie pali się do ana­li­zy bo to wyma­ga podej­mo­wa­nia decy­zji… a tych nie­któ­rzy nie lubią…

  2. A na dia­gra­mie porząd­ne­go pro­jek­tu ana­li­tycz­ne­go nie powin­no być jesz­cze kro­ku Akceptacja wyma­gań”? Czy wali­da­cja wyma­gań obej­mu­je rów­nież ich wery­fi­ka­cję oraz zde­fi­nio­wa­nie zało­żeń i ogra­ni­czeń? Trochę to przy­po­mi­na połą­cze­nie tech­nik zwin­nych oraz BABOK.

    1. Jarek Żeliński

      To co opi­sa­łem powy­żej to 100% BABoK. Zwinność tu pole­ga na reago­wa­niu na każ­dym eta­pie wali­da­cji (wykry­cie nie­zgod­no­ści to adap­ta­cja pro­jek­tu). Nie ma tu jed­nak nic a nic z Agile Manifesto. Wymagania to kon­se­kwen­cja celu biz­ne­so­we­go, ten jest zatwier­dza­ny. Na koń­cu jest prze­cież tak­że zatwier­dze­nie rezul­ta­tów. Tym rezul­ta­tem jest wła­śnie BRD czy­li Business Requirement Document czy­li spe­cy­fi­ka­cja wyma­gań. Po jej zatwier­dze­niu star­tu­je wyko­na­nie i dostar­cze­nie pro­duk­tu. Jednak spe­cy­fi­ka­cja jest zawsze wcze­śniej prze­cho­dzi testy.

      Dodam, że w pro­ce­sie powyż­szej ana­li­zy biz­ne­so­wej nie powsta­je nawet linij­ka kodu…podobnie jak w nastę­pu­ją­cym zaraz po niej wery­fi­ka­cji wyma­gań i testo­wa­niu bia­łej skrzyn­ki” (use case­’y to czar­na skrzynka”)

  3. Może mieć miej­sce tak­że pro­blem z wydłu­ża­niem cza­su reali­za­cji pro­jek­tu z powo­du ocze­ki­wa­nia na zatwier­dze­nie tych spi­sa­nych wyma­gań przez klien­ta. Każdy w róż­nym stop­niu anga­żu­je się w pro­jekt, nie­kie­dy zama­wia­ją­cy nie zda­ją sobie spra­wy ile zaan­ga­żo­wa­nia wyma­ga od nie­go takie zatwier­dza­nie wyma­gań. Może być zaan­ga­żo­wa­ny w pro­wa­dze­nie swo­je­go biz­ne­su i przez to mało dostęp­ny. Niekiedy brak jed­nej decy­zji (posia­da­ją­cej wie­le impli­ka­cji) może powo­do­wać prze­stój w dal­szych pra­cach ana­li­tycz­nych czy unie­moż­li­wiać ich zakoń­cze­nie. Jak radzi Pan sobie w takich przypadkach?

    1. Jarek Żeliński

      To zale­ży od kon­struk­cji umo­wy. W zasa­dzie mamy dwie: czas i mate­riał oraz fixed pri­ce” (czy­li umo­wa o dzie­ło). Przestój z winy Zamawiającego, zawsze bije w Zamawiającego, któ­ry albo pła­ci za czas zaan­ga­żo­wa­nia ana­li­ty­ka albo prze­su­wa mu się ter­min odda­nia dzie­ła (o ile mu to prze­szka­dza). Minus dla ana­li­ty­ka pole­ga na tym, że prze­cią­ga­nie z winy zama­wia­ją­ce­go wpły­wa na inne pro­jek­ty. Kodeks Cywilny chro­ni tu wyko­naw­ce Dzieła: ma pra­wo wysta­wić fak­tu­rę i żądać zapła­ty jeże­li pozo­sta­wał w goto­wo­ści do wyko­na­nia dzie­ła a zama­wia­ją­cy, mimo zawar­tej umo­wy, nie udzie­lał wyma­ga­ne­go wsparcia”.

Dodaj komentarz

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