Jako zwie­rzę­ta, ludzie są w przy­tła­cza­ją­cej więk­szo­ści kon­for­mi­sta­mi szu­ka­ją­cy­mi pro­stych spo­so­bów na prze­ży­cie. Heurystyka, jako meto­da podej­mo­wa­nia decy­zji, góru­je nad ana­li­tycz­nym myśle­niem, nie dopusz­cza­my myśli, że coś, co komu­kol­wiek się uda­ło, może być trud­ne, daje­my wia­rę temu, że ukry­to przed nami ten ?pro­sty spo­sób?. Praktyka jest strasz­na : otóż nie ist­nie­ją pro­ste spo­so­by roz­wią­zy­wa­nia zło­żo­nych pro­ble­mów (nie licząc odkryć przypadkowych).

Daniel Kahneman w książ­ce ?Thinking, fast and slow? poka­zu­je, że nasze poglą­dy i postę­po­wa­nie kształ­tu­ją dwa sys­te­my myślo­we: szyb­ki (auto­ma­tycz­ny, bez­re­flek­syj­ny) i wol­ny (opar­ty na reflek­sji i namy­śle). Zastanawiające, jak czę­sto ludzie w więk­szo­ści nadal korzy­sta­ją tyl­ko z tego pierw­sze­go systemu.

Tym razem nie będzie to recen­zja książ­ki (któ­rą swo­ją dro­gą pole­cam), a kil­ka reflek­sji na temat tego z jaki­mi pyta­nia­mi o szko­le­nia przy­cho­dzą niektórzy.

Najpierw zna­ny fakt: sta­ty­sty­ki nie­uda­nych pro­jek­tów IT poka­zu­ją, że ok. 3/4 z nich to pro­jek­ty nie­uda­ne. Częstym kry­te­rium uzna­nia pro­jek­tu za nie­uda­ny jest prze­kro­cze­nie budże­tu lub ter­mi­nu o 20%. Co cie­ka­we sta­ty­sty­ki te są prak­tycz­nie nie­zmien­ne od lat. Tak więc teo­re­tycz­nie wie­my, że raczej nale­ża­ło by postę­po­wać tak, jak w przy­pad­ku tych 25% uda­nych pro­jek­tów (gdy­by kry­te­rium poraż­ki było każ­de prze­kro­cze­nie budże­tu lub ter­mi­nu, było by ich jesz­cze mniej). Jednak więk­szość firm (ich mene­dże­rów) postę­pu­je kon­for­mi­stycz­nie: ​„rób­my jak więk­szość, nie ryzy­kuj­my innej dro­gi”. Po dru­gie, dostaw­cy opro­gra­mo­wa­nia mówią: zama­wia­ją­cy za to pła­cą, wiec po co to zmie­niać? Po trze­cie zama­wia­ją­cy chcą tanio, wiec mają tanio, no przy­naj­mniej na eta­pie zawie­ra­nia umowy.

Niedawno na szko­le­niu usłyszałem:

musi­my skła­dać kon­ku­ren­cyj­ne tań­sze ofer­ty mimo żądań wyso­kiej jako­ści, jeże­li będzie­my uczci­wie kal­ku­lo­wa­li kosz­ty do wyma­gań jako­ścio­wych, prze­gra­my więk­szość przetargów.

Mamy więc cie­ka­we zamknię­te koło oszu­ku­ją­cych się na wła­sne życze­nie, na wza­jem, dostaw­ców i odbio­rów. Z dru­giej stro­nie zawsze moż­na powie­dzieć, i słusz­nie, że dro­gie nie gwa­ran­tu­je dobrego.

Więc co z tym zro­bić? Na pew­no war­to zarzą­dzać ryzy­kiem. Z jed­nej stro­ny mieć poko­rę patrząc na ww. sta­ty­sty­ki, z dru­giej wychwy­cić symp­to­my powięk­szo­ne­go ryzy­ka, a są nimi złe meto­dy pra­cy. Np. sto­so­wa­nie do komu­ni­ka­cji w pro­jek­cie, pocz­ty elek­tro­nicz­nej, zamiast wspól­ne­go repo­zy­to­rium, raczej pro­wa­dzi do bała­ga­nu i bra­ku zaufa­nia: nikt nie ma pew­no­ści, że dys­po­nu­je tymi samy­mi i taki­mi samy­mi co do tre­ści, doku­men­ta­mi jak ​„dru­ga stro­na” (jak każ­dy inny czło­nek zespo­łu projektowego).

Drugim typo­wym ​„kile­rem” pro­jek­tów jest sto­so­wa­nie wie­lu nie­zin­te­gro­wa­nych narzę­dzi w ana­li­zie, np. edy­tor tek­stu do pisa­nia rapor­tu, jakieś opro­gra­mo­wa­nie do two­rze­nia dia­gra­mów (któ­re jed­nak nie są for­mal­ny­mi mode­la­mi a ilu­stra­cją, gra­fi­ka­mi, doku­men­tu tek­sto­we­go), jakieś opro­gra­mo­wa­nie do zbie­ra­nia wyma­gań, jakieś opro­gra­mo­wa­nie do współ­dzie­le­nia pli­ków lub po pro­tu ema­il, itp. Praca bez pla­nu (har­mo­no­gram) – zakres pro­jek­tu to tak­że ele­ment tego pla­nu – sta­je się nie­prze­wi­dy­wal­na (nie myl­my pla­nu spo­tkań z pla­nem reali­za­cji). Narzędzia i meto­dy pra­cy: poza pocz­tą elek­tro­nicz­ną, w pro­jek­cie powsta­ją doku­men­ty, któ­rych treść powin­na być spój­na, a jak to uzy­skać w wie­lu wie­lo­stro­ni­co­wych doku­men­tach, jeże­li jedy­nym narzę­dziem wery­fi­ka­cji jest kole­żan­ka lub kole­ga? Brak zin­te­gro­wa­nych narzę­dzi do two­rze­nia doku­men­ta­cji (apli­ka­cje CASE) i zarzą­dza­nia doku­men­ta­cją ana­li­tycz­ną (repo­zy­to­rium) pro­wa­dzi to ogrom­nej licz­by dodat­ko­wych robo­czo­go­dzin na uzy­ska­nie wyma­ga­nej jako­ści. Składanie ofert o zani­żo­nych kosz­tach, naj­czę­ściej pro­wa­dzi do oszczęd­no­ści w obsza­rach zwią­za­nych z jakością…

Na koniec naj­więk­szy mit: ana­li­za jest pro­sta, wystar­czy wie­dzieć jak ją wyko­nać i mieć wła­ści­we wzor­ce doku­men­tów. Nic tej tezy nie potwier­dza, a tak wie­lu pró­bu­je… Znam masę przy­pad­ków, gdy ktoś uznał, że przy­uczo­na na szko­le­niu gru­pa pra­cow­ni­ków sama wyko­na ana­li­zę wyma­gań, w koń­cu to tyl­ko spi­sy­wa­nie potrzeb. Niestety nie znam żad­ne­go przy­pad­ku gdzie, na bazie tak spi­sa­nych wyma­gań, pro­jekt zakoń­czył się suk­ce­sem. Jest zresz­tą pro­sty spo­sób na oce­nę jako­ści doku­men­tu opi­su­ją­ce­go wyma­ga­nia: skon­fron­to­wa­nie go z tym co w koń­cu powstało.

Tak więc nie­ste­ty mamy jed­nak dwa sys­te­my myślo­we: szyb­ki (auto­ma­tycz­ny, bez­re­flek­syj­ny) i wol­ny (opar­ty na reflek­sji i namy­śle). Zastanawiające, jak czę­sto ludzie w więk­szo­ści nadal korzy­sta­ją tyl­ko z tego pierw­sze­go sys­te­mu. Tu zacy­tu­ję A.Einsteina: jeże­li na roz­wią­za­nie pro­ble­mu mam godzi­nę, 55 minut spę­dzam nad jego zro­zu­mie­niem a 5 minut nad opra­co­wa­niem rozwiązania.