Temat nie­uda­nych wdro­żeń wra­ca jak bume­rang, regu­lar­nie poja­wia­ją się arty­ku­ły w pra­sie, wnio­ski, a kolej­ne pro­jek­ty powie­la­ją te same błę­dy. Czy może cho­dzi o to, by te pro­jek­ty były takie złe?

W jed­nym z poprzed­nich wpi­sów na podob­ny temat (Policja znów ma …) napi­sa­łem:

Hegel napi­sał kie­dyś, że ​„histo­ria uczy ludzi, że histo­ria nicze­go ludzi nie nauczy­ła”. Lubię tę sen­ten­cję bo jest praw­dzi­wa, codzien­nie obser­wu­ję coś co ją potwier­dza. Jak nazwać fir­my i urzę­dy, któ­re wie­dzę, że nie mają żad­nych kom­pe­ten­cji do ana­li­zy wyma­gań i sta­le to jed­nak robią? Jak nazwać fir­my, któ­re z upo­rem mania­ka skła­da­ją wią­żą­ce ofer­ty na pod­sta­wie tak źle opi­sa­nych wyma­gań? Jak nazwać kie­row­ni­ków pro­jek­tów IT tych firm i urzę­dów, któ­rzy jedy­ne co robią to wli­cza­ją każ­dy zły pro­jekt w sta­ty­sty­kę ryzy­ka, zamiast po pro­stu w koń­cu zmie­nić meto­dę pra­cy na lep­szą, sko­ro dotych­cza­so­we są złe – co widać?

Wczoraj mia­łem refe­rat na kon­fe­ren­cji o wdro­że­niach sys­te­mów ERP, po mnie miał refe­rat Pan Kowalczyk z fir­my Mandarine. Wygłosił bar­dzo cie­ka­wy refe­rat na temat zarzą­dza­nia pro­jek­ta­mi ([[zarzą­dza­nie pro­jek­ta­mi meto­dą ścież­ki kry­tycz­nej]]). Nie licząc pre­zen­to­wa­ne­go opi­su metod zarzą­dza­nia pro­jek­ta­mi (pole­cam ;)), wska­zał na coś bar­dzo waż­ne­go: wyma­gań (eta­pów pro­jek­tu) powin­na być roz­sąd­na – rela­tyw­nie mała – ilość (nie da się zarzą­dzać tysią­ca­mi wyma­gań) oraz, każ­da pra­ca powin­na być poprze­dza­na jej pla­no­wa­niem. Nic dodać nic ująć. Ja w swo­im refe­ra­cie mówi­łem, że pla­no­wa­nie to tak­że pro­jek­to­wa­nie poprze­dza­ją­ce pra­cę (zanim zaczniesz pro­gra­mo­wać, zapla­nuj co zapro­gra­mu­jesz – pro­jek­tuj). W prze­ciw­nym wypad­ku, poja­wia się w pro­jek­cie coś dziw­ne­go jako zada­nie: reali­za­cja cze­goś, o czym nie wie­my czym ma być (bo prze­cież nie ma pro­jek­tu).

Kolejny pro­ble­ma­tycz­ny etap, kon­se­kwen­cja bra­ku pro­jek­tu, a wcze­śniej dobrze okre­ślo­nych wyma­gań, to odbiór pro­duk­tu. Jeżeli wyma­ga­nia nie sta­no­wią zara­zem testu ich speł­nie­nia (zno­wu przy­po­mnę, że sło­wo wyma­ga­nie ozna­cza waru­nek lub warun­ki jakie musi coś speł­niać, by było przy­dat­ne do okre­ślo­ne­go celu), to odbiór pro­duk­tu pro­jek­tu sta­je czymś dziw­nym. W toku dys­ku­sji o tym na pew­nym forum napisałem:

Wydaje mi się, sed­no tkwi w tym stwier­dze­niu: ​„rzecz, na któ­rą sta­ram się zwró­cić uwa­gę to fakt, iż akcep­ta­cja odbio­ru nie­ko­niecz­nie jest toż­sa­ma z uda­nym wdro­że­niem w ska­li całe­go przed­się­bior­stwa.” [sło­wa przed­mów­cy, przyp. mój]. Bo tu poja­wia się ​„co jest wyma­ga­niem”, czy­im wyma­ga­niem i wyma­ga­niem wobec cze­go. Wymaganie ​„kosz­ty obsłu­gi sprze­da­ży mają spać do pozio­mu 10%” rodzi dopie­ro potrze­bę zapro­jek­to­wa­nia roz­wią­za­nia. Tym roz­wią­za­niem może być uprosz­cze­nie orga­ni­za­cji pro­ce­su fak­tu­ro­wa­nia albo zakup narzę­dzia do fak­tu­ro­wa­nia (zamiast drucz­ków i kal­ku­la­to­ra, kom­pu­ter i pro­gram). Na tym eta­pie nale­ży spraw­dzić, któ­re roz­wią­za­nie daje naj­więk­sze szan­se powo­dze­nia reali­za­cji celu. Poważnym błę­dem wie­lu zarzą­dza­ją­cych i spon­so­rów pro­jek­tów, jest zakła­da­nie a prio­ri, że opro­gra­mo­wa­nie pomaga.

Jeżeli jed­nak oka­że (ana­li­za) się, że zakup pro­gra­mu ma pomóc, to nale­ży opi­sać wyma­ga­nia jakie taki pro­gram musi speł­nić (wyma­ga­nia wobec pro­duk­tu). Te wyma­ga­nia są pod­sta­wą do wybo­ru goto­we­go, dostęp­ne­go na ryn­ku opro­gra­mo­wa­nia, lub decy­zji o napi­sa­niu dedy­ko­wa­ne­go, jeże­li poszu­ki­wa­nia nie dadzą pozy­tyw­ne­go rezul­ta­tu (ale etap szu­ka­nia goto­we­go powi­nien dla zasa­dy mieć miej­sce). Dedykowane roz­wią­za­nie wyma­ga jego zapro­jek­to­wa­nia, to moż­na (zale­ca­ne) zro­bić przed wybo­rem wyko­naw­cy lub zle­cić wybra­ne­mu wcze­śniej wyko­naw­cy. Wariant dru­gi nara­ża nas jed­nak na utra­tę pano­wa­nia nad pro­jek­tem bo wyko­naw­ca będzie for­so­wał meto­dy budu­ją­ce mu mar­że a potem sam sobie świad­czy nad­zór autor­ski. Wbrew pozo­rom, anga­żo­wa­nie audy­to­ra pro­jek­tu, któ­ry nie jest auto­rem doku­men­ta­cji wyma­gań nie wno­si nic, a kom­pli­ku­je cały pro­ces: taki audy­tor może jedy­nie oce­nić zgod­ność dzia­łań pro­jek­to­wych z doku­men­ta­cją wytwo­rzo­ną przez (audy­to­wa­ne­go) wyko­naw­cę, a w przy­pad­ku spo­ru i tak tu ​„wła­dzę” ma autor pro­jek­tu a nie audytor.

I teraz: ogło­sze­nie prze­tar­gu na całość na począt­ku tej dro­gi jest jak widać idio­ty­zmem bo nie mamy żad­nej wie­dzy by oce­nić wynik pra­cy a dostaw­ca żad­nej by cokol­wiek sen­sow­nie wyce­niać. Pominięcie jakie­go­kol­wiek z tych w/w opi­sa­nych eta­pów to pod­no­sze­nie ryzy­ka pro­jek­tu, co mam na dzie­ję widać. Każde wyma­ga­nie może być zero jedyn­ko­we na każ­dym z tych eta­pów, wystar­czy chcieć i umieć. Owszem, moż­na je dzie­lić na biz­ne­so­we itp… ale to tyl­ko sztucz­ne podzia­ły, po pro­stu pod­czas reali­za­cji mamy już tyl­ko etap i jego wyma­ga­nia. (Nieudane wdro­że­nie sys­te­mu biz­ne­so­we­go – czy­li uczmy się na błę­dach innych | LinkedIn).

I tyl­ko tu poja­wia się pyta­nie jak w fil­mie MIŚ: a może to fak­tycz­nie ma być dro­gie i nie­przy­dat­ne a ja zupeł­nie bez sen­su jestem tym zdziwiony?