Analiza systemowa zdalnie

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ę…).

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…).

Tak zwa­ne warsz­ta­ty wyma­gań (tak zwa­ne [[sesje JAD]]) to jed­na z naj­bar­dziej wyna­tu­rzo­nych form tych spo­tkań, bo ich uczest­ni­cy wal­czą jak o ogień by zdo­być zapis sank­cjo­nu­ją­cych ich (nie­raz bar­dzo poboż­ne) życze­nia, każ­dy zgła­sza swo­je pomy­sły na imple­men­ta­cję, coraz to nowe fajer­wer­ki, pseu­do udo­god­nie­nia i oczy­wi­ście upraw­nie­nia dla sie­bie w nowej apli­ka­cji. Złośliwi mawia­ją, że obję­tość spe­cy­fi­ka­cji wyma­gań jest wprost pro­por­cjo­nal­na do cza­su trwa­nia (ilo­ści) takich warsz­ta­tów. Konsultanci zara­bia­ją też pro­por­cjo­nal­nie (koszt dnia pra­cy) a przy­szli użyt­kow­ni­cy zgła­sza­ją coraz to now­sze pomy­sły (z cza­sem coraz bar­dziej z poza zakre­su projektu).

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 ​„w czte­ry oczy” 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”.

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ń. W trak­cie typo­wych zbio­ro­wych warsz­ta­tów i burz mózgów, bar­dzo czę­sto nie­ste­ty mają miej­sce, ze stro­ny uczest­ni­ków tych spo­tkań, uda­ne pró­by prze­my­ca­nia dodat­ko­wych nie­uza­sad­nio­nych upraw­nień, obro­na sta­tus quo na swo­im sta­no­wi­sku itp. 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. Zgłaszanie 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, bo tak zwa­ni eks­per­ci dzie­dzi­no­wi klien­ta 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­muj im to znacz­ne mniej cza­su (nie musza z nikim się spie­rać). Dodatkową zale­tą jest pisem­ny ślad po każ­dej zmia­nie, po każ­dym nowym zgło­sze­niu (każ­dy sam spi­su­je swo­je uwa­gi i propozycje).

Owszem, w wie­lu orga­ni­za­cjach jest ogrom­na nie­chęć do takiej pra­cy ale zary­zy­ku­ję tezę, że jedy­nym powo­dem tej nie­chę­ci jest nie­lu­bia­na przez część ludzi odpo­wie­dzial­ność za każ­de swo­je sło­wo. 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 wymagań.

Tą meto­da pra­cu­je już kil­ka lat, korzy­sta­jąc z elek­tro­nicz­ne­go repo­zy­to­rium doku­men­tów i sys­te­mu obie­gu doku­men­tów i tre­ści (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!).

Od oko­ło dwóch lat dys­po­nu­ją bar­dzo dobrym narzę­dziem, któ­re pozwa­la na płyn­ną zdal­ną inte­rak­tyw­ną pra­cę, już nie na pozio­mie kolej­nych wer­sji wysy­ła­nej wyni­ko­wej ana­li­zy, a 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. 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: Analiza Biznesowa – narzę­dzia CASE, Visual-Paradigm | Jarosław Żeliński IT-Consulting)

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 nie raz spo­ty­kam się z fir­ma­mi, któ­rych pra­cow­ni­cy pre­fe­ru­ją spo­tka­nia nad pisanie.

Kluczowym powo­dem nie­chę­ci do pisa­nia jest utra­ta moż­li­wo­ści naci­sku na ana­li­ty­ka, w celu pozy­ska­nia korzyst­nych dla sie­bie, a nie koniecz­nie dla spon­so­ra pro­jek­tu, zapi­sów w doku­men­ta­cji. Po dru­gie gru­po­we spo­tka­nia i warsz­ta­ty dra­stycz­nie roz­my­wa­ją odpo­wie­dzial­ność za udzie­la­ne informacje.

Opór przed pisa­niem to naj­czę­ściej nie­chęć do pozo­sta­wia­nia śla­dów po swo­ich uwa­gach i pro­po­zy­cjach. W wie­lu fir­mach i insty­tu­cjach publicz­nych spo­ty­kam się z ogrom­ną nie­chę­cią do takiej pra­cy. Zbiorowe spo­tka­nia i warsz­ta­ty pozo­sta­wia­ją po sobie listę życzeń, pod nią listę obec­no­ści ale nie wia­do­mo kto co zgło­sił, a to pro­wa­dzi do zupeł­ne­go bra­ku odpo­wie­dzial­no­ści uczest­ni­ków takich warsz­ta­tów za treść nota­tek jakie na nich powstają.

Tak, meto­da­mi 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, zawie­ra­ją masę nie­spój­no­ści, są strasz­nie nad­mia­ro­we. Nie raz są to doku­men­ty mają­ce, po ok. roku albo i wię­cej pra­cy! nawet kil­ka tysię­cy 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% to dia­gra­my) zawie­ra­ją­ce opis (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. Szczegóły tech­nicz­ne (w tym model danych!) powi­nien opra­co­wać dopie­ro wyko­naw­ca, na eta­pie ana­li­zy wyma­gań (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 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 dzie­dzi­ny, 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 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.

Inne artykuły na podobny temat

• Plansza do gry w sza­chy czy­li ana­li­za i projektowanie
• Proces zbie­ra­nia i ana­li­zy wyma­gań u developera
• Rentowność pro­jek­tu czy­li jego wizja i wyko­ny­wal­ność – nale­ży planować
• Agile w PZP
• Inżynieria wyma­gań