Wstęp

Całkiem nie­daw­no wpadł mi w oczy arty­kuł na temat zdal­ne­go pro­wa­dze­nia ana­li­zy, ostat­ni jego aka­pit brzmi:

Virtual com­mu­ni­ca­tion and faci­li­ta­tion skills will rema­in a key com­pe­ten­cy for BAs for years to come. Stop tor­tu­ring your sta­ke­hol­ders with boring, inef­fec­ti­ve con­fe­ren­ce calls. Find new and cre­ati­ve ways to alle­via­te the com­mon pain points. Please sha­re your vir­tu­al faci­li­ta­tion tips in the com­ments below! (Business Analyst | Virtual Requirements Meetings: Painful or Practical?).

(w uprosz­cze­niu: zdal­nie pro­wa­dzo­na ana­li­za to klu­czo­wa przy­szła kom­pe­ten­cja ana­li­ty­ków, war­to prze­stać tor­tu­ro­wać ludzi wie­lo­go­dzin­ny­mi nud­ny­mi spo­tka­nia­mi, znajdź inna kre­atyw­ną dro­gę…).

tak więc nie ja pierw­szy odkry­łem, że spo­tka­nia i warsz­ta­ty, to po pierw­sze ogrom­ny koszt (jeden dzień takich warsz­ta­tów to łącz­ny koszt dnió­wek wszyst­kich obec­nych na spo­tka­niu). Po dru­gie, takie zbio­ro­we dys­ku­sje naj­czę­ściej nie­ste­ty są nud­ne i męczą­ce, szyb­ko zmie­nia­ją się w nie­koń­czą­ce się nego­cja­cje, a zatwier­dza­nie nota­tek z takich spo­tkań to kolej­na dro­ga przez mękę (wysła­ne do wszyst­kich obec­nych wra­ca­ją z uwa­ga­mi, te trze­ba nanieść i roze­słać doku­ment jesz­cze raz…).

Artykuł ten napi­sa­łem w 2015 roku, teraz (2022) Podobnie jak wie­lu ana­li­ty­ków na świe­cie, daw­no już zre­zy­gno­wa­łem z wywia­dów i cyklicz­nych gru­po­wych warsz­ta­tów w loka­li­za­cji klien­ta, na rzecz zdal­nej pra­cy opar­tej na prze­ka­za­nych mi mate­ria­łach (doku­men­tach) a tak­że (patrz: niska efek­tyw­ność spo­tkań i ich ogrom­ne kosz­ty), zaś stan­dar­do­wo zdal­na pra­ca (w tym tele kon­fe­ren­cje) w moich pro­jek­tach to obec­nie 100%. 

Dzięki temu łącz­na pra­co­chłon­ność (szcze­gól­nie po stro­nie kadr zama­wia­ją­ce­go) i koszt pro­jek­tu ana­li­tycz­ne­go, są nawet o 70% niż­sze, w porów­na­niu z cyklicz­ny­mi spo­tka­nia­mi i uży­wa­niem opro­gra­mo­wa­nia biu­ro­we­go (ema­il, edy­tor tek­stu, arkusz kal­ku­la­cyj­ny) do komu­ni­ka­cji i wymia­ny tre­ści! (prze­czy­taj też: Dlaczego nie uży­wam pocz­ty elek­tro­nicz­nej do prze­ka­zy­wa­nia mate­ria­łów).

Warsztaty

Tak zwa­ne warsz­ta­ty wyma­gań (kie­dyś zwa­ne sesja­mi JAD, ang. Joint Application Development) to jed­na z naj­bar­dziej nie­efek­tyw­nych form zbie­ra­nia wyma­gań, bo ich uczest­ni­cy zgła­sza­ją subiek­tyw­ne ocze­ki­wa­nia opar­te na swo­im dotych­cza­so­wym doświad­cze­niu. Nie raz zgła­sza­ją swo­je tech­nicz­ne pomy­sły na imple­men­ta­cję funk­cjo­nal­no­ści, co rzad­ko bywa fak­tycz­nie opty­mal­nym roz­wią­za­niem. Rzecz w tym, że te zapi­sy są opar­te na subiek­tyw­nych odczu­ciach pra­cow­ni­ków, czę­sto nie popar­tych fak­ta­mi, są nie­spój­ne, nie­kom­plet­ne i nie­jed­no­znacz­ne co potwier­dza­ją bada­nia tak powsta­łych spe­cy­fi­ka­cji . Niestety czę­stym zja­wi­skiem jest zgła­sza­nie wyma­gań łamią­cych zasa­dy bez­pie­czeń­stwa, naj­czę­ściej spo­ty­ka­ne to eks­pert danych na zewnętrz­ne nośni­ki, prze­no­sze­nie tre­ści wprost z ekra­nu do popu­lar­nych pakie­tów biurowych). 

Analiza oparta na faktach

Alternatywą dla tych zja­da­ją­cych czas i pie­nią­dze warsz­ta­tów jest ana­li­za doku­men­tów ope­ra­cyj­nych . Zawierają one z regu­ły ok. 80% wszyst­kich istot­nych infor­ma­cji (orga­ni­za­cji z zasa­dy doku­men­tu­ją istot­ne dla nich rze­czy), w toku pra­cy nad tymi doku­men­ta­mi moż­na wychwy­cić ewen­tu­al­ne bra­ki (to co jest reali­zo­wa­ne nie­for­mal­nie a war­to jed­nak zacząć doku­men­to­wać) oraz nie­po­trzeb­ne już doku­men­ty (zmie­nio­no pro­ce­du­ry a nie wyco­fa­no wzo­rów doku­men­tów). Wszelkie wąt­pli­wo­ści moż­na wyja­śniać tele­fo­nicz­nie lub na krót­kich spo­tka­niach z kon­kret­ną oso­bą, eks­per­tem z danej dzie­dzi­ny, kie­row­ni­kiem dzia­łu itp. Co cie­ka­we, tą meto­dą moż­na ana­li­zę z góry wyce­nić (licz­ba doku­men­tów do ana­li­zy jest skoń­czo­na więc zakres pra­cy tak­że) i pod­pi­sać z ana­li­ty­kiem umo­wę fixed price”.

Organizacja jako sys­tem zło­żo­ny z wypo­sa­że­nia, ludzi i sys­te­mów IT. Po pra­wej obszar ana­li­zy i pro­jek­to­wa­nia. Po lewej obszar wdro­że­nia, nie­pod­le­ga­ją­cy ana­li­zie biz­ne­so­wej i wyma­gań na sys­te­my IT. Środowisko lokal­ne orga­ni­za­cji to śro­do­wi­sko imple­men­ta­cji. Dlatego obec­ność ana­li­ty­ka w orga­ni­za­cji ana­li­zo­wa­nej nie jest wymagana.

Pracując w ten spo­sób uni­ka­my tak­że wszel­kich naci­sków ze stro­ny uczest­ni­ków spo­tkań. Badanie doku­men­tów ope­ra­cyj­nych jest wol­ne od tego ryzy­ka. Wyjaśnianiu pod­le­ga­ją wyłącz­nie nie­ści­sło­ści w doku­men­tach. Na ich pod­sta­wie powsta­ją mode­le pro­ce­sów biz­ne­so­wych, wzo­ry doku­men­tów w tych pro­ce­sach itp. Pisemne zgła­sza­nie uwag do powsta­ją­cej doku­men­ta­cji ana­li­tycz­nej jest znacz­nie efek­tyw­niej­sze niż wal­ka o każ­de jej zda­nie w trak­cie warsz­ta­tów, jest tak­że znacz­nie tań­sze, kadry kie­row­ni­cze Zamawiającego oraz przy­szli użyt­kow­ni­cy, pra­cu­ją nad swo­imi uwa­ga­mi w chwi­lach wol­nych (nie są to narzu­co­ne ter­mi­ny spo­tkań) i zaj­mu­je im to znacz­ne mniej cza­su (nie musza z nikim się spie­rać). Dodatkową zale­tą jest pisem­na histo­ria zmian (każ­dy sam spi­su­je swo­je uwa­gi i pro­po­zy­cje). Badania pro­jek­tów poka­zu­ją, że tak pro­wa­dzo­ne ana­li­zy przed­wdro­że­nio­we sys­te­mów ERP, reali­zo­wa­ne meto­da­mi zorien­to­wa­ny­mi na fak­ty, dają znacz­nie lep­sze efek­ty .

Zdalnie czyli jak?

Od wie­lu lat pra­cu­ję korzy­sta­jąc z elek­tro­nicz­ne­go sys­te­mu zarzą­dza­nia pro­ce­sem ana­li­zy i recen­zo­wa­nia. Jest to repo­zy­to­rium powsta­ją­cych mode­li i tre­ści, zebra­nych doku­men­tów oraz narzę­dzie komu­ni­ka­cji (nie korzy­stam z pocz­ty elek­tro­nicz­nej do pro­wa­dze­nia pro­jek­tów z uwa­gi na bała­gan jaki wprowadza!).

Dysponują bar­dzo dobrym narzę­dziem (patrz Postmania), któ­re pozwa­la na płyn­ną zdal­ną inte­rak­tyw­ną pra­cę, już nie tyl­ko na pozio­mie dra­ftu całe­go doku­men­tu ana­li­zy, ale na pozio­mie poje­dyn­czych dia­gra­mów i ich opi­sów. Jest to bez­piecz­ne opro­gra­mo­wa­nie pozwa­la­ją­ce mi – ana­li­ty­ko­wi – zdal­nie pre­zen­to­wać bie­żą­ce efek­ty pra­cy i przyj­mo­wać na bie­żą­co uwa­gi (2,5 min, moż­na oglą­dać bez dźwięku): 

Narzędzia te opi­sa­łem tu:

Dla utrzy­ma­nia wyso­kiej jako­ści efek­tów pra­cy sto­su­ję spraw­dzo­ne na ryn­ku opro­gra­mo­wa­nie fir­my Visual-Paradigm. W moich pro­jek­tach nie są wyko­rzy­sty­wa­ne do pra­cy żad­ne bez­płat­ne czy spo­łecz­no­ścio­we zaso­by Internetu, gdyż dostaw­cy tych usług nie bio­rą za nie odpo­wie­dzial­no­ści, ogra­ni­cza­ją, a nie raz przej­mu­ją, pra­wa do prze­trzy­my­wa­nych tam doku­men­tów i tre­ści. Z opro­gra­mo­wa­nia fir­my Visual-Paradigm korzy­sta­ją naj­więk­sze kon­cer­ny na świe­cie (lista wybra­nych użyt­kow­ni­ków pakie­tu Visual-Paradigm. Nagrody dla Visual Paradigm). (Źródło: Komunikacja w pro­jek­cie)

Okazuje się, że moż­na pro­wa­dzić zwin­nie nawet takie ana­li­zy, oszczę­dzić czas człon­ków zespo­łu i innych uczest­ni­ków pro­jek­tu (tak­że inte­re­sa­riu­szy, któ­rzy mogą brać udział w takiej pra­cy). Zalety opi­sa­ne w cyto­wa­nym na począt­ku arty­ku­le mogę tyl­ko potwier­dzić. Owszem bywa, że bio­rę udział w spo­tka­niach, gdy pra­cow­ni­cy pre­fe­ru­ją spo­tka­nia nad pisa­nie, jed­nak to bar­dzo wydłu­ża cały pro­ces i znacz­nie pod­no­si koszty.

Więc skąd ten opór?

W wie­lu orga­ni­za­cjach jest ogrom­na nie­chęć do pra­cy pole­ga­ją­cej na pisa­niu, jed­nak ta meto­da pra­cy wyklu­cza zbio­ro­wą odpo­wie­dzial­ność za wyni­ki zbio­ro­wo pro­wa­dzo­nej ana­li­zy wyma­gań . Analityk jest czę­sto trak­to­wa­ny jak sekre­tarz, na co wie­lu auto­rów na świe­cie zwra­ca uwa­gę. Jest to efekt bra­ku doświad­cze­nia z pra­cą inną niż spo­tka­nia oraz prze­ko­na­nie, że ina­czej nie moż­na bo wszy­scy tak robią”, a fak­ty są takie, że ana­li­zy i pro­jek­to­wa­nie są na świe­cie coraz czę­ściej pro­wa­dzo­ne, podob­nie jak pra­ce pro­gra­mi­stycz­ne i audy­tor­skie: zdal­nie i w opar­ciu o dokumenty.

Podsumowanie

Metodami zbio­ro­wych warsz­ta­tów, powsta­ją z regu­ły doku­men­ty bar­dzo niskiej jako­ści, bar­dzo pra­co­chłon­ne, będą­ce mało mery­to­rycz­nym zgni­łym kom­pro­mi­sem” (Design by com­mit­tee is a pejo­ra­ti­ve term for a pro­ject that has many desi­gners invo­lved but no uni­fy­ing plan or vision.), zawie­ra­ją masę nie­spój­no­ści, są strasz­nie nad­mia­ro­we. Nie raz są to doku­men­ty powsta­ją­ce po ok. roku albo i wię­cej pra­cy! Mają nie raz set­ki stron!… któ­rych z regu­ły już nikt nigdy nie czyta!

Dobra doku­men­ta­cja ana­li­ty­ka biz­ne­so­we­go, w tym wyma­ga­nia, to ok. 50 – 100 stron (naj­więk­sze moje pro­jek­ty to ok. 200 str. w tym ponad 50% ich tre­ści to dia­gra­my) zawie­ra­ją­ce opis i mode­le logi­ki dzia­ła­nia orga­ni­za­cji i logi­ki jaką ma reali­zo­wać przy­szłe opro­gra­mo­wa­nie (mecha­nizm dzia­ła­nia). Szczegóły tech­nicz­ne imple­men­ta­cji powi­nien opra­co­wać wyko­naw­ca na eta­pie przy­go­to­wa­nia imple­men­ta­cji (kon­cep­cja imple­men­ta­cji i wdro­że­nia), nie ma sen­su zbyt wcze­sne żąda­nie” kon­kret­nych tech­no­lo­gii, tech­no­lo­gia jest kon­se­kwen­cją wyma­gań poza-funk­cjo­nal­nych. Przypomnę, że wyma­ga­nia to warun­ki (logi­ka, archi­tek­tu­ra biz­ne­so­wa) jakie ma speł­nić opro­gra­mo­wa­nie a nie deta­licz­ny pro­jekt. Owszem logi­ka dzia­ła­nia biz­ne­su, w posta­ci mode­lu pro­ce­sów i mode­li dzie­dzi­ny sys­te­mu, jak naj­bar­dziej powin­na powstać, bo to jest wyma­ga­nie: taki ma być mecha­nizm dzia­ła­nia” zama­wia­nej aplikacji.

Mam świa­do­mość, że nie wszę­dzie zasto­so­wa­nie zdal­nej pra­cy jest moż­li­we ale takich przy­pad­ków jest bar­dzo mało. Podstawą i wystar­cza­ją­cym ele­men­tem jest wola po stro­nie zama­wia­ją­ce­go taką usłu­gę, mam tu na myśli spon­so­ra pro­jek­tu czy­li zarząd fir­my. Zapraszam do kon­tak­tu.

Źródła

Christian Ruf. (2015). Towards an Artifact-Oriented Requirements Engineering Model for Developing Successful Products, Services, and Systems: Identification of Model Requirements. Bled EConference, 14.
Dyba, T., Kitchenham, B. A., & Jorgensen, M. (2005). Evidence-based softwa­re engi­ne­ering for prac­ti­tio­ners. IEEE Software, 22(1), 58 – 65. https://​doi​.org/​1​0​.​1​1​0​9​/​M​S​.​2​0​0​5.6
Fillottrani, P. R., & Keet, C. M. (2021). Evidence-based Lean Conceptual Data Modelling Languages. Journal of Computer Science, 21(2), 19.
Gerede, C. E., Bhattacharya, K., & Su, J. (2007). Static ana­ly­sis of busi­ness arti­fact-cen­tric ope­ra­tio­nal models. IEEE International Conference on Service-Oriented Computing and Applications (SOCA’07), 133 – 140.
Hosseini, J. (1995). Business pro­cess mode­ling and orga­ni­za­tio­nal memo­ry sys­tems: A case stu­dy. Proceedings of the Twenty-Eighth Annual Hawaii International Conference on System Sciences, 4, 363 – 371.
Kitchenham, B. A., Budgen, D., & Brereton, P. (2016). Evidence-based softwa­re engi­ne­ering and sys­te­ma­tic reviews. CRC Press.
Kitchenham, B. A., Dybå, T., & Jørgensen, M. (2004). Evidence-based Software Engineering. Th International Conference on Software Engineering, 9.
Nigam, A., & Caswell, N. S. (2003). Business arti­facts: An appro­ach to ope­ra­tio­nal spe­ci­fi­ca­tion. IBM Systems Journal, 42(3), 428 – 445. https://​doi​.org/​1​0​.​1​1​4​7​/​s​j​.​4​2​3​.​0​428
Pajic Simovic, A., & Becejski-Vujaklija, D. (2016). Metamodel of the Artifact-Centric Approach to Event Log Extraction from ERP Systems. International Journal of Decision Support System Technology, 8(2), 18 – 28. https://​doi​.org/​1​0​.​4​0​1​8​/​I​J​D​S​S​T​.​2​0​1​6​0​4​0​102
Šenkýř, D., & Kroha, P. (2019). Problem of Incompleteness in Textual Requirements Specification: Proceedings of the 14th International Conference on Software Technologies, 323 – 330. https://​doi​.org/​1​0​.​5​2​2​0​/​0​0​0​7​9​7​8​0​0​3​2​3​0​330

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 jeden komentarz

Dodaj komentarz

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