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. 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. Masz pytania to treści artykułu, potrzebujesz pomocy? Kliknij tu!

Ten post ma jeden komentarz

Dodaj komentarz

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