Wprowadzenie

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

Ludzie i ich pra­ca to infor­ma­cje i ich wymia­na. Komputer i opro­gra­mo­wa­nie to mecha­nizm prze­twa­rza­nia danych repre­zen­tu­ją­cych te infor­ma­cje. Projektowanie opro­gra­mo­wa­nia pole­ga na zro­zu­mie­niu i opi­sa­niu tego mecha­ni­zmu, tego jakie to dane i jak są (ana­li­za) lub powin­ny być (pro­jek­to­wa­nie) prze­twa­rza­ne. Aby to zro­bić ana­li­zu­je­my doku­men­ty, nie robi­my wywia­dów. Jeżeli ktoś tego nie potra­fi i nie rozu­mie, zaczy­na orga­ni­zo­wać wywia­dy i kodo­wać to, co ludzie postrze­ga­ją ze swo­jej per­spek­ty­wy. Tak powsta­je naj­gor­sze oprogramowanie. 

źr.: Produkt ana­li­zy jako twier­dze­nie nauko­we – Jarosław Żeliński IT-Consulting

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 – 90% wszyst­kich istot­nych infor­ma­cji (orga­ni­za­cje 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 dokumentó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”.

Oprogramowanie biz­ne­so­we to sys­tem prze­twa­rza­nia danych o tym co robi fir­ma (orga­ni­za­cja). Te dane to doku­men­ty, opis fak­tów czy­li tego co zacho­dzi w orga­ni­za­cji. Dlatego przed­mio­tem ana­li­zy jest ​„System infor­ma­cyj­ny” jako zestaw doku­men­tów i for­mu­la­rzy oraz ich treść oraz mecha­nizm ich prze­twa­rza­nia, a nie ​„maszy­ny, urzą­dze­nia i ludzie” (Środowisko lokal­ne organizacji). 

To rolą pra­cow­ni­ków orga­ni­za­cji jest umie­jęt­ność uży­cia lokal­ne­go wypo­sa­że­nia. Jednym z jego ele­men­tów jest kom­pu­ter i jego Oprogramowanie (sys­tem infor­ma­cyj­ny), któ­ry reali­zu­je funk­cje doty­czą­ce prze­twa­rza­nia danych wpro­wa­dza­nych do niego. 

Dlatego celem ana­li­zy i pro­jek­to­wa­nia jest udo­ku­men­to­wa­nie Systemu Informacyjnego i mecha­ni­zmu prze­twa­rza­nia danych, a nie audyt pomiesz­czeń biu­ro­wych i hal fabrycz­nych. Opis Mechanizmu prze­twa­rza­nia infor­ma­cji sta­no­wią potem Wymagania na opro­gra­mo­wa­nie (prze­twa­rza­nie danych). 

Pracując w ten spo­sób (pra­ca na doku­men­tach) 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