Dwa lata temu cytowałem:

Jakie są naj­częst­sze pro­ble­my w nie­uda­nych pro­jek­tach? […] 83% pro­jek­tów korzy­sta z doku­men­tów tek­sto­wych oraz arku­szy kal­ku­la­cyj­nych do prze­cho­wy­wa­nia wyma­gań, 40% pro­jek­tów korzy­sta z ema­ili do zbie­ra­nia wyma­gań i komu­ni­ka­cji z klientem.

Brzmi to dla Was zna­jo­mo? (źr. Raport Jama Sofware ? O wyma­ga­niach).

Dzisiaj będzie kon­ty­nu­acja powyż­sze­go o tym, dla­cze­go część pro­jek­tów kosz­tu­je znacz­nie wię­cej niż mogła by kosz­to­wać, dla­cze­go pew­ne pro­jek­ty nigdy nie prze­kro­czą pew­ne­go pro­gu jako­ści. Dzisiejszy wpis adre­su­je dla wszyst­kich spon­so­rów pro­jek­tów, któ­rzy chcą wie­dzieć co zja­da ich pie­nią­dze jak sza­rań­cza plo­ny… To lista antywzorców.

public_domain chaos tłum

Swego cza­su napi­sa­łem doku­ment o wdzięcz­nej nazwie Metodyka pro­wa­dze­nia ana­li­zy biz­ne­so­wej i doku­men­to­wa­nia wyma­gań, któ­ry to doku­ment załą­czam do ofert a potem do umów. Dlaczego? By unik­nąć (na ile to moż­li­we) cofa­nia się o jakieś 15 a może nawet 20 lat wstecz w rozwoju.

Drugi powód to obro­na przed tym, by zama­wia­ją­cy nie nisz­czył ren­tow­no­ści swo­je­go i moje­go tak­że pro­jek­tu. Jak? Ano narzu­ca­jąc swój, pre­hi­sto­rycz­ny styl pra­cy, bo zama­wia­ją­cy naj­pierw z rado­ścią akcep­tu­je moje meto­dy pra­cy na eta­pie wyce­ny pro­jek­tu, a potem z nie mniej­szą rado­ścią twier­dzi: ale u nas w fir­mie takie są meto­dy pra­cy i ludzie chcą by się Pan dosto­so­wał” czy­li po pro­tu nisz­czył pro­jekt. Jakie to meto­dy? (Gdy Zamawiający podej­mu­je pró­by narzu­ce­nia swo­je­go kor­po­ra­cyj­ne­go” zwy­cza­ju pra­cy jak for­su­je umo­wę T&M).

Do tej pory o tym nie pisa­łem, nie licząc rzad­kie­go u mnie zachwa­la­nia” korzy­ści ze sto­so­wa­nia opro­gra­mo­wa­nia CASE. Wydawało mi się to tema­tem tak wsty­dli­wym jak i oczy­wi­stym zara­zem, ale arty­kuł na stro­nie Modern Analyst (link w dal­szej czę­ści) upew­nił, mnie że sza­rań­cza ma się dobrze: więk­szość ana­li­ty­ków, nadal opie­ra się na doku­men­tach tek­sto­wych i arku­szach kal­ku­la­cyj­nych by w zespo­le: oni i bada­na fir­ma, ręcz­nie dziar­gać” wymagania.

Most BAs, howe­ver, still rely on docu­ments and spre­ad­she­ets to manu­al­ly stitch toge­ther the­ir requ­ire­ments. (10 Ways Documents and Spreadsheets Sabotage the Business Analyst?s Career | Modern Analyst).

Ten wpis powstał na bazie powyż­sze­go arty­ku­łu, pole­cam cały, a tu tyl­ko klu­czo­we tezy. Co nisz­czy ana­li­ty­ka i ana­li­zy? Analityku:

1. Dokumenty i arku­sze kal­ku­la­cyj­ne spro­wa­dza­ją Cię do roli biu­ro­kra­ty. Praca z doku­men­ta­mi tek­sto­wy­mi i arku­sza­mi to per­ma­nent­ne pisa­nie, wyci­na­nie, kopio­wa­nie, spraw­dza­nie spój­no­ści, sta­no­wi to nawet 85% cza­su całej ana­li­zy, posta­ła war­to­ścio­wa pra­ca to 15%.

2. Nikt nie lubi prze­glą­da­nia tych doku­men­tów, ich kolej­nych wer­sji i ich setek stron. W szcze­gól­no­ści nie lubią tego twoi klienci.

3. Dokumentacja (taka) to wąskie gar­dło więk­szo­ści pro­jek­tów. Z dru­giej stro­ny klien­ci życzą sobie tych doku­men­tów i arku­szy, wie­lo­krot­nie zgła­sza­ją do nich uwa­gi, doda­ją do tre­ści notat­ki, pyta­nia i suge­stie. Mnożą się ema­ile, kolej­ne wer­sje dokumentów.

4. Tracisz więk­szość pra­cy tak pra­cu­jąc nad doku­men­tem wyma­gań. Cała histo­ria zmian, pomy­słów, powo­dów ich zgła­sza­nia i usu­wa­nia nie była śle­dzo­na, ginie.

5. Używanie arku­szy kal­ku­la­cyj­nych do zarzą­dza­nia zależ­no­ścia­mi pomię­dzy wyma­ga­nia­mi, prze­no­si całe ryzy­ko błę­dów na Ciebie, jest tak­że bar­dzo pracochłonne.

6. Twoje doku­men­ty podró­żu­ją jak towar, z regu­ły jako załącz­ni­ki ema­il. Tych maili są dzie­siąt­ki, zapy­cha­ją skrzyn­ki odbior­cze wszyst­kim i zmu­sza­ją do ich czytania.

7. Permanentne pisa­nie tych doku­men­tów powo­du­je, że pra­co­chłon­ność rośnie wydłu­ża­jąc każ­dy etap projektu.

8. Zarządzanie zmia­ną w takich warun­kach zabi­ja wszel­kie nadzie­je na spraw­ną współprace.

9. Opisywanie wszyst­kie­go tek­stem zmu­sza do bez­pro­duk­tyw­ne­go żmud­ne­go opi­sy­wa­nia każ­de­go pomy­słu, dopro­wa­dza­nia do zamie­nia­nia wszyst­kie­go na tekst (zamiast np. two­rze­nia diagramów) .

10. Stosując te meto­dy pra­cy nie posu­niesz się ani o krok do przo­du w rozwoju.

Cóż, dobrze że nie ja pierw­szy o tym piszę. Do spon­so­rów pro­jek­tów: Wasze pro­jek­ty zawsze będą albo niskiej jako­ści albo bar­dzo kosz­tow­ne, dopó­ki będzie­cie akcep­to­wa­li takie meto­dy pra­cy. Pomysł w rodza­ju: no to rezy­gnu­je­my z doku­men­ta­cji, jest jed­nak po sto­kroć gorszy…

Użycie narzę­dzi CASE tyl­ko do ryso­wa­nia dia­gra­mów i wkle­ja­nia ich do doku­men­tów tyl­ko pogar­sza spra­wę, bo powyż­sze pisa­nie tek­stów i two­rze­nie arku­szy kom­pli­ku­je­my dodat­ko­wym pro­gra­mem. Tworzenie tych dia­gra­mów jako zamien­nik tek­stu, łamiąc zasa­dy uży­wa­nych (i być może żąda­nych w pro­jek­cie) nota­cji, jest jesz­cze gor­sze od same­go tek­stu bez dia­gra­mów, bo wpro­wa­dza do pro­jek­tu ele­ment zbli­żo­ny do jaz­dy dro­ga­mi publicz­ny­mi z pomi­nię­cie prze­pi­sów ruchu drogowego…

Wiele się pisze o tym, że mode­lo­wa­nie słu­ży do doku­men­to­wa­nia pro­jek­tów. Otóż nie. Do doku­men­to­wa­nia pro­jek­tów słu­ży ryso­wa­nie, mode­lo­wa­nie słu­ży do pro­wa­dze­nia ana­liz poprzez testy mode­li, symu­la­cje i ana­li­zę sce­na­riu­szy. Wobec tego dobre narzę­dzie CASE to nie ?notat­nik? rysow­ni­ka ale ?symu­la­tor? i ?wali­da­tor? w rękach ana­li­ty­ka (Visual Paradigm Agilian).

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

  1. jacek2v

    Fajne, zga­dzam się z autorem.

  2. jokoz

    Cenne uwa­gi. Pewnie za dużo wokół antyw­zor­ców i nie ma za bar­dzo gdzie porów­nać praw­dzi­we­go mode­lu z ode­rwa­nym od rze­czy­wi­sto­ści rysun­kiem. Zwłaszcza, że jest to już jakiś poziom abs­trak­cji wyma­ga­ją­cy kon­kret­nych kom­pe­ten­cji, a nie­rzad­ko wręcz talentu 🙂

  3. Jarek Żeliński

    Ja jestem sta­rej szko­ły: matu­rę robi­łem w tech­ni­kum i nauczo­no mnie rysun­ku tech­nicz­ne­go. Jak sobie pomy­ślę, co by było gdy­by zamiast tych rysun­ków maszyn powsta­wa­ły ich opi­sy uzgad­nia­ne pocz­tą w zespo­le kil­ku­na­sto­oso­bo­wym to.. widzę dzi­siej­sze kor­po­ra­cyj­ne pro­jek­ty IT… to jest masakra…także dla­te­go, że nasz obec­ny sys­tem edu­ka­cji nie uczy nawet for­mu­ło­wa­nia myśli i pisa­nia… nie­ste­ty więk­szość ana­li­ty­ków” w tych pro­jek­tach to wła­śnie pisa­rze urzęd­ni­cy”, bez­kry­tycz­nie piszą to co im dyk­tu­ją biz­ne­sy”.

Dodaj komentarz

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