Przepływ pracy i dokumentów – czego wymagać

Mój nie­daw­ny refe­rat na temat tren­dów w wybo­rze i wdra­ża­niu sys­te­mów work­flow i zapro­sze­nie na kolej­ną kon­fe­ren­cję z tego zakre­su, skło­ni­ły mnie do prze­rzu­ce­nia cię­ża­ru refe­ra­tu z isto­ty prze­pły­wu doku­men­tów, na prze­pływ doku­men­tów w kon­tek­ście wdro­że­nia narzę­dzia. któ­re w tym poma­ga. Poniżej pre­zen­ta­cja ilu­stru­ją­ca referat:

Na koniec tego krót­kie­go wpi­su dodam, że w swej głów­nej czę­ści, sys­tem obie­gu doku­men­tów to jeden przy­pa­dek uży­cia.

(refe­rat był wygło­szo­ny na kon­fe­ren­cji EOIF GigaCon, 9 Października 2014 we Wrocławiu).

Przepływ pracy w chmurze – czyli cudzy worlkflow

Wczorajsza kon­fe­ren­cja EOIF GigaCon była dla mnie kolej­ną oka­zją do podzie­le­nia się z jej gość­mi, moimi oraz cudzy­mi doświad­cze­nia­mi, cudzy­mi czy­li tymi, któ­rych bywam nie raz świad­kiem. Poproszono mnie o wygło­sze­nie refe­ra­tu na temat sys­te­mów zarzą­dza­nia prze­pły­wem pra­cy i kon­se­kwen­cja­mi korzy­sta­nia z nich w tak zwa­nej chmu­rze (clo­ud com­pu­ting). Przy oka­zji, dla porząd­ku i tytu­łem wpro­wa­dze­nia, powie­dzia­łem kil­ka słów o tym, czym w ogó­le tego typu sys­te­my są i jakie są ryzy­ka ich wdrażania.

BPM – czym jest

Krótkie pod­su­mo­wa­nie tego czym jest BPM (Business Process Management). BPM to przede wszyst­kim zarzą­dza­nie, a nie tyl­ko jed­no czy kil­ka zadań połą­czo­nych w logicz­ny ciąg”. BPM to cała dys­cy­pli­na zaj­mu­ją­ca się pod­no­sze­niem efek­tyw­no­ści orga­ni­za­cji poprzez opty­ma­li­za­cję pro­ce­sów w niej zacho­dzą­cych. Proces to coś co zacho­dzi w gra­ni­cach orga­ni­za­cji łącząc ludzi, zaso­by, prze­pływ infor­ma­cji, two­rzy okre­ślo­ną wartość.

Powyżej mamy defi­ni­cję zaczerp­nię­tą ze stron fir­my Gartner, któ­rą uwa­żam, że jed­ną z peł­niej­szych. Dalej mój dia­gram, któ­ry czę­sto pre­zen­tu­ję, obra­zu­ją­cy kom­plet wie­dzy jaką nale­ży posia­dać by móc mówić o tym, że pro­ces został udo­ku­men­to­wa­ny i zro­zu­mia­ny. Są to ogra­ni­cze­nia (pra­wo, wewnętrz­ne regu­ły biz­ne­so­we) oraz wyko­naw­ca pro­ce­su dys­po­nu­ją­cy okre­ślo­na wie­dzą, upraw­nie­nia­mi i narzę­dzia­mi pracy.

Trzeci dia­gram, waż­ny dla zro­zu­mie­nia tego czym jest wspo­ma­ga­nie prze­pły­wu pra­cy i doku­men­tów”, poka­zu­je ogól­na archi­tek­tu­rę opro­gra­mo­wa­nia work­flow”. Oprogramowanie takie skła­da się, naj­ogól­niej rzecz bio­rąc, z repo­zy­to­rium doku­men­tów oraz tak zwa­ne­go sil­ni­ka pro­ce­so­we­go (zarzą­dza pro­ce­sem). Repozytorium to nic inne­go jak archi­wum doku­men­tów elek­tro­nicz­nych. Silnik pro­ce­so­wy to kom­po­nent odpo­wie­dzial­ny za zarzą­dza­nie kolej­no­ścią wyko­ny­wa­nia zadań i ich przy­dzie­la­niem do wła­ści­wych osób. Należy tak­że pamię­tać, że prze­pływ pra­cy w orga­ni­za­cji jest nad­zo­ro­wa­ny postę­pem efek­tów tych prac, te zaś to nic inne­go jak powsta­ją­ce tre­ści (doku­men­ty, tak­że w posta­ci pól róż­nych formularzy).

Tak więc opro­gra­mo­wa­nie nazy­wa­ne work­flow (nie raz docu­ment­flow) to nie to samo co opro­gra­mo­wa­nie wspo­ma­ga­ją­ce BPM. Mam nadzie­ję, że kon­fron­ta­cja defi­ni­cji BPM i archi­tek­tu­ry tych apli­ka­cji, jasno to poka­zu­je. Na co nale­ży uwa­żać? Kilka ele­men­tów, na któ­re war­to zwró­cić uwa­gę w ofer­tach przed wybo­rem rozwiązania:

  1. Aplikacja rekla­mo­wa­na jako obieg fak­tur kosz­to­wych” (wnio­sków urlo­po­wych i innych kon­kret­nych typów doku­men­tów) to naj­praw­do­po­dob­niej pro­ste repo­zy­to­rium z wbu­do­wa­nym sys­te­mem prze­ka­zy­wa­nia dostę­pu do doku­men­tu kolej­nym oso­bom z usta­lo­nej listy. Tego typu apli­ka­cje nada­ją się do zarzą­dza­nia (zatwier­dza­nie i archi­wi­za­cja) np. dowo­da­mi księ­go­wy­mi, bar­dzo praw­do­po­dob­ne, że jed­nak nie pora­dzą sobie, bez duże­go nakła­du pra­cy po stro­nie dostaw­cy, np. z pro­ce­sem obsłu­gi zapy­tań ofer­to­wych czy np. rekla­ma­cji, gdyż tu poza doku­men­tem otrzy­ma­nym z zewnątrz, powsta­ją nowe powią­za­ne doku­men­ty, ich prze­twa­rza­nie może zacho­dzić wie­lo­ma róż­ny­mi dro­ga­mi, a sam moduł repo­zy­to­rium (archi­wum doku­men­tów) naj­czę­ściej nie nada­je się do tego typu zasto­so­wań. Tego typu apli­ka­cje bar­dzo czę­sto, poza moni­to­wa­niem ter­mi­nów, nie pozwa­la­ją na budo­wa­nie roz­bu­do­wa­nych rapor­tów na potrze­by BPM.
  2. Narzędzia do mode­lo­wa­nia pro­ce­sów biz­ne­so­wych wbu­do­wa­ne w tego typu opro­gra­mo­wa­nie, pra­wie zawsze mają ogra­ni­cze­nia wyni­ka­ją­ce z archi­tek­tu­ry dane­go opro­gra­mo­wa­nia i zasto­so­wa­nych wewnętrz­nych wzor­ców, czę­sto są to tyl­ko tak zwa­ne maszy­ny sta­no­we”, któ­re pozwa­la­ją jedy­nie na budo­wa­nie pro­ce­sów pole­ga­ją­cych na prze­łą­cza­niu sta­tu­sów kon­kret­nych doku­men­tów (for­mu­la­rzy) w odpo­wie­dzi na defi­nio­wa­ne zda­rze­nia. Stosowanie takie­go narzę­dzia np. na eta­pie ana­li­zy przed-wdro­że­nio­wej, pro­wa­dzi czę­sto do znacz­ne­go ogra­ni­cze­nia zakre­su takiej ana­li­zy, do wie­lu zadań są to narzę­dzia po pro­tu nie­przy­dat­ne. Zastosowanie przed wdro­że­niem (a zale­ca się nawet przed wybo­rem dostaw­cy i roz­wią­za­nia) narzę­dzia do ana­li­zy i mode­lo­wa­nia pro­ce­sów, pozwa­la­ją­ce­go na sko­rzy­sta­nie z wszyst­kich zalet nota­cji np. BPMN (obec­nie prak­tycz­nie już stan­dard w takich pro­jek­tach) pozwa­la oce­nić na ile ogra­ni­cze­nia kon­kret­ne­go opro­gra­mo­wa­nia wpły­ną na utra­tę moż­li­wo­ści zaspo­ko­je­nia wszyst­kich potrzeb organizacji.
  3. Repozytorium doku­men­tów powin­no pozwa­lać na auto­ma­tycz­ne wer­sjo­no­wa­nie doku­men­tów, nie powin­no pozwa­lać na przy­pad­ko­we usu­nię­cie doku­men­tu, powin­no pozwa­lać na budo­wa­nie wie­lu, wła­snych, roz­bu­do­wa­nych sys­te­mów meta­da­nych (cechy doku­men­tów), gdyż jest to stan­dar­do­wy spo­sób na kla­sy­fi­ko­wa­nie doku­men­tów (bez tego np. trud­no je póź­niej wyszu­kać czy pogrupować).
  4. Narzędzie tego typu powin­no pozwa­lać użyt­kow­ni­kom na samo­dziel­ne budo­wa­nie kolej­nych nowych sche­ma­tów pro­ce­sów prze­pły­wu pra­cy bez koniecz­no­ści anga­żo­wa­nia pro­gra­mi­stów. Workflow, jako apli­ka­cja, powin­no być plat­for­mą budo­wy takich prze­pły­wów a nie opro­gra­mo­wa­niem zawie­ra­ją­cym wyłącz­nie zamó­wio­ne” pro­ce­sy. Brak tej cechy, samo­dziel­ne budo­wa­nie kolej­nych prze­pły­wów, to prak­tycz­nie dys­kwa­li­fi­ka­cja narzę­dzia w rozu­mie­niu BPM.

Cloud computing

Regularnie spo­ty­kam defi­ni­cje tego ter­mi­nu, więk­szość z nich bazu­je na róż­nych for­mach out­so­ur­cin­gu. Proponuje defi­ni­cję, któ­ra obec­nie chy­ba naj­traf­niej odda­je to czym jest clo­ud com­pu­ting (prze­twa­rza­nie w chmurze):

Slajd10

Ta uogól­nio­na defi­ni­cja pod­kre­śla, że clo­ud com­pu­ting to przede wszyst­kim pro­sto­ta, wrę­cza auto­ma­ty­za­cja, roz­po­czę­cia i rezy­gna­cji z korzy­sta­nia z zaso­bu. To głów­na, moim zda­niem, cecha odróż­nia­ją­ca chmu­rę” od zna­nych już usług w rodza­ju SaaS (Software as a Service) czy ASP (Application Service Provider). Warto tak­że zwró­cić uwa­gę na to, że z per­spek­ty­wy praw­nej czym innym jest dzier­ża­wa opro­gra­mo­wa­nia” a czym innym jest usłu­ga prze­twa­rza­nia”. Innymi sło­wy czym innym jest wypo­ży­cze­nie od kogoś (dzier­ża­wa) kal­ku­la­to­ra a czym inny­mi pła­ce­nie komuś za wyko­ny­wa­nie obli­czeń, to nie jest to samo. Cloud Computing to czę­sto wła­śnie opła­ta za przetwarzanie.

Ważna rzecz to bez­pie­czeń­stwo. Spotykam się z wie­lo­ma opi­nia­mi praw­ny­mi na temat tego kto prze­twa­rza dane i kie­dy. Samo posia­da­nie danych i mani­pu­lo­wa­nie nimi to ich prze­twa­rza­nie. Jednak prze­twa­rza­nie pli­ku nie musi ozna­czać prze­twa­rza­nia (dostę­pu do) jego tre­ści. Zarządca prze­strze­ni dys­ko­wej nie­wąt­pli­wie prze­twa­rza nasze pli­ki, ale czy aby na pew­no zawsze prze­twa­rza dane w nich zawar­te? Składowanie danych w posta­ci zako­do­wa­nej powo­du­je, że usłu­go­daw­ca prze­twa­rza nasze pli­ki (np. wyko­nu­je ich regu­lar­ne kopie zapa­so­we), ale czy prze­twa­rza zawar­te w tych pli­kach tre­ści? Nie, jeże­li są to więc np. zako­do­wa­ne dane oso­bo­we (typo­we tak zwa­ne wraż­li­we dane) to usłu­go­daw­ca nie prze­twa­rza tych danych (nie ope­ru­je dany­mi osób) a jedy­nie pli­kiem zawie­ra­ją­cym te dane w posta­ci zako­do­wa­nej, więc nie ma on dostę­pu do danych osobowych.

Slajd14

Moim zda­niem, Ci praw­ni­cy, któ­rzy for­su­ją tezę, że dane zako­do­wa­ne tak­że nale­ży trak­to­wać jako dane prze­twa­rza­ne, pró­bu­ją wyka­zać, że fir­ma wywo­żą­ca maku­la­tu­rę powsta­łą w nisz­czar­kach doku­men­tów, prze­twa­rza dane, któ­re tam były zawar­te… Na szczę­ście dla mnie, są tak­że praw­ni­cy zga­dza­ją­cy się ze mną. Problem ten – moim zda­niem – jest efek­tem tego, że sło­wo dane” ozna­cza zarów­no dane cyfro­we jaki­mi są jakie­kol­wiek bity na nośni­kach, jak i treść zro­zu­mia­łą dla czło­wie­ka napi­sa­ną w jakimś języ­ku (źr. słow­nik j.p. PWN):

dane 1. ?fak­ty, licz­by, na któ­rych moż­na się oprzeć w wywo­dach? 2. ?infor­ma­cje prze­twa­rza­ne przez komputer?

gdzie infor­ma­cje prze­twa­rza­ne przez kom­pu­ter” to mię­dzy inny­mi ich cyfro­wa for­ma jaką jest każ­dy plik danych na dys­ku mają­cy nazwę. Tu więk­szość praw­ni­ków, nie mają­ca głę­bo­kiej wie­dzy tech­nicz­nej, myli się trak­tu­jąc uży­te w usta­wach sło­wo dane” lite­ral­nie, zapo­mi­na­jąc, że ma ono nie­ste­ty wię­cej niż jed­no znaczenie.

Na zakończenie

Tak wiec BPM to sfe­ra zarzą­dza­nia orga­ni­za­cją a nie tyl­ko jakieś opro­gra­mo­wa­nie, ono może jedy­nie wspie­rać to zarzą­dza­nie. Zły wybór opro­gra­mo­wa­nia z regu­ły pro­wa­dzi do pogor­sze­nia spraw­no­ści orga­ni­za­cji (przy­kła­dy poda­wał na tej kon­fe­ren­cji Pan Piotr Biernacki), nie raz pro­wa­dzi to do zarzu­ce­nia korzy­sta­nia z tego opro­gra­mo­wa­nia. Dlatego kolej­ność: naj­pierw wybór opro­gra­mo­wa­nia i jego dostaw­cy a potem wdro­że­nie, naj­czę­ściej koń­czy się poraż­ką lub co naj­mniej znacz­nie gor­szy­mi efek­ta­mi niż ocze­ki­wa­ne (obie­ca­ne).

Oprogramowanie work­flow, w tak zwa­nej chmu­rze, ma wie­le zalet, jed­nak ma tak­że poważ­ną wadę: kło­po­tli­wa inte­gra­cja z lokal­ny­mi sys­te­ma­mi (np. ERP) wyni­ka­ją­ca z tego, że doku­men­ty poko­nu­ją zawsze podwój­ną dro­gę od naszej loka­li­za­cji do usłu­go­daw­cy i z powro­tem. W przy­pad­ku małych firm (mała ilość danych) z regu­ły nie sta­no­wi to pro­ble­mu. Dla dużych firm może to być nawet barie­ra nie do poko­na­nia, dla­te­go tak zwa­na chmu­ra pry­wat­na” czy­li lokal­na insta­la­cja może być jedy­nym wyjściem.

Na koniec: zanim zawrze­cie Państwo umo­wę na taką usłu­gę war­to się skon­sul­to­wać z praw­ni­kiem wyspe­cja­li­zo­wa­nym w tego typu usługach.

złożoność złożony system skomplikowany http://hikingartist.files.wordpress.com/

Zarządzanie wymaganiami

Wczoraj pod­czas dru­gie­go dnia dnia kon­fe­ren­cji EOIF jeden z refe­ra­tów (Zarządzanie wyma­ga­nia­mi biz­ne­so­wy­mi dla sys­te­mów IT wspie­ra­ją­cych elek­tro­nicz­ny obieg infor­ma­cji, Sylwia Raczko, Carrywater Group S.A.). Nie podej­mę pró­by powtó­rze­nia go, nie taki mam cel. Będzie tu kil­ka słów ode mnie. Ale po kolei.

Etap pierwszy to analiza otoczenia projektu

Najczęściej pomi­ja­ny etap w pro­jek­tach. Moim zda­niem z dwóch powo­dów. Mało któ­ry spon­sor pro­jek­tu ma świa­do­mość jakie ryzy­ka nie­sie brak wie­dzy o oto­cze­niu pro­jek­tu, bo jako spon­sor już uwie­rzył w jego suk­ces (cho­ro­ba zna­na jako emo­cjo­nal­ne podej­ście do wła­snych pomy­słów). Drugi powód to fakt, że wie­lu inte­re­sa­riu­szy pro­jek­tu ma inte­res w tym, by te ryzy­ka nie zosta­ły ujaw­nio­ne. ten etap to pierw­szy ele­ment, któ­re­go reali­za­cja napo­ty­ka opo­ry, a moim zda­niem powi­nien być wyko­na­ny nie raz przez zawar­ciem głów­nej umo­wy, gdyż może się oka­zać, że pro­jekt jest z góry ska­za­ny na porażkę.

Z per­spek­ty­wy każ­de­go sys­te­mu (sys­tem to nie tyl­ko opro­gra­mo­wa­nie, to tak­że sys­tem zarzą­dza­ni jako­ścią czy nowy sys­tem raba­to­wy) nale­ży opra­co­wać model uwzględ­nia­ją­cy tych, któ­rzy będę z nie­go bez­po­śred­nio korzy­sta­li (akto­rzy) oraz tych, któ­rzy odczu­ją skut­ki jego wdro­że­nia a mają wpływ na jego powsta­wa­nie. Taka ana­li­za wpły­wu pozwo­li oce­nić ryzy­ka gene­ro­wa­ne przez każ­de­go inte­re­sa­riu­sza i wła­ści­wie na nie zare­ago­wać. Jednym z pro­duk­tów takiej ana­li­zy jest plan komu­ni­ka­cji. Mamy więc na tym eta­pie produkty:

  1. model oto­cze­nia sys­te­mu (pro­jek­tu),
  2. ana­li­za ryzyka,
  3. plan komu­ni­ka­cji.

Więcej o tym eta­pie w arty­ku­le Udziałowcy pro­jek­tu czy­li któ­ry dia­gram UML (czy­taj).

Etap drugi analiza i specyfikowanie wymagań

Ten etap jest naj­więk­szą czę­ścią pro­jek­tu ana­li­tycz­ne­go. Jak zebrać wyma­ga­nia to tema rze­ka. Ogólnie meto­dy ana­li­zy i spe­cy­fi­ko­wa­nia wyma­gań moż­na podzie­lić na dwie grupy:

  1. meto­dy formalne,
  2. meto­dy nieformane.

Pierwsze opie­ra­ją się na zasto­so­wa­niu sfor­ma­li­zo­wa­nych sys­te­mów poję­cio­wych i wery­fi­ko­wal­nym pro­ce­sie ana­li­tycz­nym czy­li po pro­tu na sto­so­wa­niu okre­ślo­nych nota­cji (z regu­ły BMM i BPMN) oraz ana­li­zy systemowej.

Drugie bazu­ją na spo­tka­niach, warsz­ta­tach, mode­ro­wa­nych sesjach. Ich głów­ną cechą jest uzna­nie, że tak zebra­ne dane są wia­ry­god­ne: uzna­nie a prio­ri, że zama­wia­ją­cy się nie myli i ma rację. Jakkolwiek to brzmi, nie jest to takie oczy­wi­ste. Wykazanie nie­sprzecz­no­ści tak zebra­nych wyma­gań jest wyko­nal­ne ale już ich spój­ność i kom­plet­ność jest nie do wyka­za­nia bo nie ist­nie­je test kom­plet­no­ści opo­wia­da­nia”, sko­ro nie moż­na wyka­zać (prze­te­sto­wać) kom­plet­no­ści to tym bar­dziej nie da się wyka­zać spójności.

Metody for­mal­ne bazu­ją na ana­li­zie od ogó­łu do szcze­gó­łu” orga­ni­za­cji i opra­co­wa­niu jej kom­plet­ne­go mode­lu (na wyma­ga­nym dla danej ana­li­zy pozio­mie szcze­gó­ło­wo­ści). Model taki sta­je się narzę­dziem testo­wa­nia wyma­gań, np. mając mode­le wszyst­kich pro­ce­sów biz­ne­so­wych może­my spraw­dzić, czy nie pomi­nę­li­śmy jakichś istot­nych dzia­łań, któ­re wyma­ga­ły by uję­cia w wymaganiach.

Bardzo waż­na rze­czą jest jest podzie­le­nie wyma­gań na biz­ne­so­we i funk­cjo­nal­ne bo to nie to samo (czy­taj Produkty w pro­ce­sie ana­li­zy wyma­gań). Pani Raczko przy­wo­ła­ła defi­ni­cję Rona Ross’a, jed­nak chy­ba zbyt upro­ści­ła ory­gi­nał spro­wa­dza­jąc sło­wo sys­tem” do opro­gra­mo­wa­nie”. Znany mi ory­gi­nał brzmi:

We defi­ne a busi­ness requ­ire­ment as ?some­thing cal­led for or deman­ded by a busi­ness model that a sys­tem model must support?

We defi­ne a sys­tem model as fol­lows a model that pro­vi­des a design for an auto­ma­ta­ble sys­tem that is com­pu­ta­tio­nal­ly competent.

(źr. What?s the Difference Between Business Requirements and Functional Requirements?)

Rzecz w tym, że sło­wo com­pu­ta­tio­nal” ozna­cza wyli­czal­ność” w rozu­mie­niu da się wyli­czać auto­ma­tycz­nie (raczej w sen­sie algo­ryt­micz­nym). To nie koniecz­nie musi być kom­pu­ter, mogą to być okre­ślo­ne do wdro­że­nia pro­ce­du­ry (przy­po­mnę, że przed­mio­tem pro­jek­to­wa­nia może być sys­tem zarzą­dza­nia jako­ścią lub sys­tem raba­to­wy sprze­da­ży). Warto zwró­cić uwa­gę, że Ross nie użył sło­wa requ­ire­ment” (wyma­ga­nia) w odnie­sie­niu do sys­te­mu a model”. Ross tak­że słusz­nie zauwa­ża, że wiki­pe­dia zrów­nu­je poję­cie wyma­gać z wyma­ga­nia­mi funk­cjo­nal­ny­mi co jest i moim zda­niem błę­dem. Prawdopodobnie to uprosz­cze­nie w pre­zen­ta­cji zosta­ło doko­na­ne z uwa­gi na tema­ty­kę kon­fe­ren­cji, uwa­żam jed­nak, że jest groź­ne. Mam wszyst­kie książ­ki Ross’a i wyda­je mi się, że nie zrów­nu­je on poję­cia sys­tem z oprogramowaniem.

Wymagania biz­ne­so­we w sto­sun­ku do wyma­gań sys­te­mo­wych” cechu­je inna bar­dzo waż­na róż­ni­ca: treść wyma­gań biz­ne­so­wych MUSI być w 100% zro­zu­mia­ła dla zama­wia­ją­ce­go, napi­sa­na jego języ­kiem. Model sys­te­mu, jako wyma­ga­nia na sys­tem, może być (i z regu­ły jest) już wie­dzą tajem­ną” zro­zu­mia­łą tyl­ko dla dostaw­cy systemu.

Zarządzanie zmianą wymagań

To kolej­ne nie­chcia­ne dziec­ko w pro­jek­tach. Jeżeli zgo­dzi­my się, że zmia­na wyma­gań jest nor­mą” to brak wie­dzy (zapi­sów) o tych zmia­nach potra­fi zabić pro­jekt. Problem, któ­ry ja widzę w wie­lu pro­jek­tach to: im łatwiej zgło­sić i egze­kwo­wać zmia­nę w wyma­ga­niach tym wię­cej tych zmian jest. Nie cho­dzi o to by tych zmian zaka­zy­wać, cho­dzi o to by były one za każ­dym razem prze­my­śla­ne, a cho­dzi głow­nie o wpływ zmian na ter­min i budżet projektu.

Ja tak­że widzę tu dużą róż­ni­cę. Z moich obser­wa­cji wyni­ka, że pro­jek­ty, w któ­rych zasto­so­wa­no zwin­ne meto­dy zarzą­dza­nia nimi, bar­dzo czę­sto tra­cą kon­tro­lę nad zakre­sem pro­jek­tu. Po pierw­sze dla­te­go, że wpro­wa­dza­nie zmian bez ich doku­men­to­wa­nia i świa­do­me­go prze­pro­jek­to­wy­wa­nia sys­te­mu, pro­wa­dzi do nie­kon­tro­lo­wa­ne­go przy­ro­stu pra­cy. Po dru­gie pro­jek­ty zwin­ne cechu­je to, że nie mają opi­sa­ne­go zakre­su pro­jek­tu a jedy­nie wizje pro­duk­tu jaki ma powstać, w efek­cie jedy­nym ele­men­tem pro­jek­tu jakim zarzą­dza kie­row­nik pro­jek­tu jest prak­tycz­nie tyl­ko budżet gdyż zakres jako taki nie ist­nie­je a har­mo­no­gram to tyl­ko na bie­żą­co defi­nio­wa­ne etapy.

Zarządzanie wymaganiamiUogólniając nie­co: w meto­dach kla­sycz­nych ist­nie­je sztyw­na gra­ni­ca pomię­dzy fazą ana­li­zy i spe­cy­fi­ko­wa­nia wyma­gań a fazą ich imple­men­ta­cji. W meto­dach zwin­nych mamy pętlę zgła­sza­nia zmian (i nowych wyma­gań), któ­ra z regu­ły nie jest dokumentowana.

Czy to powo­du­je, że w meto­dach kla­sycz­nych odci­na­my sobie moż­li­wość zasto­so­wa­nia nowych pomy­słów? Absolutnie nie, nowe pomy­sły są mate­ria­łem na nowy pro­jekt. Zgłaszane zmia­ny są ana­li­zo­wa­ne i albo są akcep­to­wa­ne bo mają mały lub żaden wpływ na budżet i har­mo­no­gram, albo są odkła­da­ne na etap eks­plo­ata­cji i roz­wo­ju” w cyklu życia pro­duk­tu (nowy cel pro­jek­tu i nowy pro­jekt). Pani Raczko stwier­dzi­ła, że jej doświad­cze­nie wska­zu­je, że pro­jek­ty pro­wa­dzo­ne meto­dą kla­sycz­ną są z regu­ły szyb­ciej koń­czo­ne, ale doty­czy to raczej więk­szych pro­jek­tów. Moje doświad­cze­nia są ana­lo­gicz­ne. Granicą któ­rą kie­dyś obli­cza­łem, po prze­kro­cze­niu któ­rej war­to zre­zy­gno­wać z metod zwin­nych, jest budżet prze­kra­cza­ją­cy 100 tys. zł. Jak widać nie są to aż tak wiel­kie pro­jek­ty. Jednak dla każ­dej fir­my utra­ta 100 tys. zł (nie­uda­ny pro­jekt) sta­no­wi bar­dzo odczu­wal­ny wydatek.

Jak wyglą­da taka zmiana?

Zarządzanie zmianą

Kluczowe korzy­ści to kom­plet­na doku­men­ta­cja pro­jek­tu, jest ona nie tyl­ko pomoc­na po jego zakoń­cze­niu, ale tak­że w trak­cie jego trwa­nia, gdyż sta­no­wi narzę­dzie kon­tro­li budże­tu. Bardzo złym mier­ni­kiem postę­pu pro­jek­tu jest dekla­ro­wa­nie zuży­wa­nych zaso­bów (robo­czo­go­dzi­ny lub dni), w zwin­nych meto­dach to w zasa­dzie jest to jedy­ny mier­nik. Jeżeli zaś dys­po­nu­je­my doku­men­ta­cją każ­dej zmia­ny, jest ona znacz­nie bar­dziej wia­ry­god­nym mier­ni­kiem postę­pu pro­jek­tu, gdyż zarzą­dza­my pro­jek­tem zada­nio­wo a nie zaso­bo­wo. W meto­dach zwin­nych nie da się wyko­nać ana­li­zy wpły­wu zmia­ny na cały pro­jekt, bo nie ist­nie­je doku­men­ta­cja całe­go sys­te­mu (jego model), on dopie­ro powsta­je w trak­cie trwa­nia pro­jek­tu. Tak więc w zasa­dzie nie ist­nie­je poję­cie ana­li­zy ryzy­ka zgła­sza­nej zmia­ny w meto­dach zwin­nych. W meto­dzie kla­sycz­nej, mamy udo­ku­men­to­wa­ny, każ­dy etap pro­jek­tu co, poza ewen­tu­al­ny­mi spo­ra­mi o zakres, pozwa­la pano­wać nad spój­no­ścią i nie­sprzecz­no­ścia zgła­sza­nych zmian wyma­gań, gdyż spe­cy­fi­ka­cja – jako całość – przez cały czas trwa­nia pro­jek­tu (a nie tyl­ko na począt­ku) ma być kom­plet­na, spój­na i niesprzeczna.

Na koniec narzędzia

W tej kwe­stii jed­no jest pew­ne: jeże­li już uzna­my, że wyma­ga­nia­mi zarzą­dza­my, to robie­nie tego narzę­dzia­mi biu­ro­wy­mi (edy­tor tek­stu, arkusz kal­ku­la­cyj­ny, pro­ste opro­gra­mo­wa­nie do dia­gra­mów typu Visio) strasz­nie pod­nie­sie pra­co­chłon­ność pro­jek­tu (czy­taj o sabo­ta­żu doku­men­ta­cyj­nym). Klienci, któ­rzy uwa­ża­ją, że wol­no użyć tyl­ko narzę­dzi, któ­rych sami na co dzień uży­wa­ją, sami sobie robią krzyw­dę, bo zgła­sza­nie zmian nie pole­ga na mody­fi­ka­cji cudzych doku­men­tów pro­jek­to­wych, a na two­rze­niu wła­snych (czy­taj o zgła­sza­niu zmian).

Biorąc pod uwa­gę fakt, że wyma­gań w śred­nim nawet pro­jek­cie jest co naj­mniej kil­ka­dzie­siąt, utrzy­ma­nie ich spój­no­ści i ana­li­za wpły­wu każ­dej zmia­ny na cały pro­jekt sta­je się bene­dyk­tyń­ską pra­cą, naj­czę­ściej szyb­ko zarzu­ca­ną wła­śnie z powo­du pra­co­chłon­no­ści (a nie bra­ku jej sen­su). Dlatego w zasa­dzie brak narzę­dzia CASE do zarzą­dza­nia wyma­ga­nia­mi (są z regu­ły czę­ścią narzę­dzi do ana­li­zy i mode­lo­wa­nia) w zasa­dzie w moich oczach dys­kwa­li­fi­ku­je usługodawcę.

Z powyż­sze­go pły­nie tak­że kolej­ny wnio­sek: autor spe­cy­fi­ka­cji wyma­gań, powi­nien kon­ty­nu­ować pro­jekt jako oso­ba zarzą­dza­ją­ca wyma­ga­nia­mi, i bar­dzo dobrze jest jeże­li pra­cu­je po stro­nie Zamawiającego, gdyż sta­no­wi natu­ral­ny mecha­nizm kon­tro­li pra­cy dostaw­cy np. opro­gra­mo­wa­nia. Zamawiający nie ma innej moż­li­wo­ści real­ne­go, mery­to­rycz­ne­go nad­zo­ru nad dostaw­cą, to Zamawiający powi­nien zarzą­dzać wyma­ga­nia­mi bo to w koń­cu jego wymagania!