No to mamy cie­ka­wost­kę, … ale czy zaskoczenie :)?

W 2008 roku fir­ma Jama Software prze­pro­wa­dzi­ła ankie­tę wśród 203 pra­cow­ni­ków firm IT. Oto naj­cie­kaw­sze wnio­ski, któ­re moż­na wyczy­tać w rapor­cie stwo­rzo­nym na posta­wie ankiet:

„Zdobycie umie­jęt­no­ści lep­sze­go zro­zu­mie­nia potrzeb klien­ta” oraz ​„doku­men­to­wa­nie wszyst­kich wyma­gań” były wymie­nia­ne jako dwa naj­waż­niej­sze wyzwa­nia w bada­nych fir­mach. Przychodzi mi tu na myśl to o czym pisał ostat­nio Seth Godin.

34% pro­jek­tów zawie­ra od 100 do 500 wyma­gań, , 22% to mniej niż 100 wyma­gań, nato­miast 19% pro­jek­tów musi sobie radzić nawet z 1000 wymagań.

Zmiany w wyma­ga­niach są powszech­ne: 37% uczest­ni­ków bada­nia stwier­dzi­ło, że każ­de­go tygo­dnia muszą poświę­cać od 10 do 15% cza­su na radze­nie sobie ze zmia­na­mi w wyma­ga­niach, 24% poświę­ca mniej niż 10% swo­je­go cza­su, a 23% poświę­ca nawet 50% cza­su w tygo­dniu na pro­blem zmian w wymaganiach.

Jakie są naj­częst­sze pro­ble­my w nie­uda­nych pro­jek­tach? 70% to zmia­ny zakre­su pro­jek­tu, 66% to nie­okre­ślo­ne lub sła­bo udo­ku­men­to­wa­ne wyma­ga­nia, i podob­nie 66% to nie­re­ali­stycz­ne ocze­ki­wa­nia i har­mo­no­gra­my. Jak widzi­cie pierw­sze dwa pro­ble­my są ści­śle zwią­za­ne z wymaganiami.

83% pro­jek­tów korzy­sta z doku­men­tów tek­sto­wych oraz arku­szy kal­ku­la­cyj­nych do prze­cho­wy­wa­nia wyma­gań, 40% pro­jek­tów korzy­sta z ema­ili do zbie­ra­nia wyma­gań i komu­ni­ka­cji z klientem.

67% zespo­łów chcia­ło by zacząć korzy­stać z narzę­dzi do zbie­ra­nia i zarzą­dza­nia wyma­ga­nia­mi, 55% potrze­bu­je narzę­dzi do mode­lo­wa­nia i wizu­ali­za­cji wymagań.

Brzmi to dla Was zna­jo­mo? (źr. Raport Jama Sofware ? O wymaganiach).

Najciekawsze jest to, że im więk­sza fir­ma IT tym bar­dziej mam do czy­nie­nia z tym: ​„83% pro­jek­tów korzy­sta z doku­men­tów tek­sto­wych oraz arku­szy kal­ku­la­cyj­nych do prze­cho­wy­wa­nia wyma­gań, 40% pro­jek­tów korzy­sta z ema­ili do zbie­ra­nia wyma­gań i komu­ni­ka­cji z klientem.”

Teraz popa­trz­my co nam dostar­cza­ją naj­więk­si lide­rzy nasze­go ryn­ku IT w swo­ich projektach.…

Jednak na szczę­ście poza taki­mi jak powyż­sze bada­nia, mam przed sobą książ­ki pisa­ne przez ​„wiel­kich”. Coraz bar­dziej lubię książ­ki pisa­ne przez ludzi, któ­rzy po np. 30 latach pra­cy jako pro­gra­mi­ści, pro­jek­tan­ci, archi­tek­ci piszą: moż­na pro­jek­to­wać i trzeba.

Twierdzenia, że nie da się ina­czej, klien­ci nie wie­dzą cze­go chcą, doku­men­ty tek­sto­we to jedy­ne moż­li­we opi­sy wyma­gań itp. są pro­stu nie praw­dą, to uspra­wie­dli­wie­nia bra­ku kom­pe­ten­cji albo zawy­ża­nia kosz­tów pro­jek­tów (a raczej pokry­wa­nia bra­ku kom­pe­ten­cji pie­niędz­mi z kie­sze­ni klien­tów). Pewien zna­jo­my, współ­wła­ści­ciel pew­nej fir­my pro­gra­mi­stycz­nej, napi­sał mi nie­daw­no: ​„korzy­ści z takie­go doku­men­to­wa­nia wyma­gań są ogrom­ne. Wykonawca, któ­ry potra­fi pra­co­wać na mode­lach ma 2 – 3 krot­nie niż­sze kosz­ty i 1,5 – 4 krot­nie krót­szy czas wyko­na­nia. AMEN TO THIS:)” A co on miał na myśli?

O jakie doku­men­to­wa­nie cho­dzi? O takie: http://​mode​lo​wa​nie​biz​ne​so​we​.biz​.pl/. Ta cyto­wa­na fir­ma to mój part­ner (albo ja jestem ich part­ne­rem, sam już nie wiem ;))), efek­ty? Rok temu pro­jekt wyko­na­ny razem (ana­li­za, pro­jekt, imple­men­ta­cja) tą meto­dą, był łącz­nie tań­szy (po zakoń­cze­niu!) trzy­krot­nie niż inne ofer­ty, trwał dwu­krot­nie kró­cej niż pozo­sta­łe ofer­ty. Projekt został odda­ne w pier­wot­nym ter­mi­nie i budże­cie a nie był to try­wial­ny pro­jekt (powyż­sze przy­kła­dy to małe demo meto­dy a nie kom­plet­ne projekty).

Na koniec kil­ka innych przy­kła­dów z inne­go źródła:

Czy to ma sens? Widać, że ma a kry­zys zmu­sza do myślenia:

Według ana­li­ty­ków fir­my Panorama Consulting w 2010 roku fir­my z więk­szym niż wcze­śniej zaan­ga­żo­wa­niem pod­cho­dzi­ły do kwe­stii ana­li­zy przed­wdro­że­nio­wej, usta­le­nia celów biz­ne­so­wych, wybo­ru sys­te­mu i dostaw­cy, a tak­że do reali­za­cji same­go pro­jek­tu wdro­że­nio­we­go. Zdaniem eks­per­tów to bez­po­śred­ni sku­tek zała­ma­nia ryn­ku opro­gra­mo­wa­nia biz­ne­so­we­go sprzed dwóch lat – więk­sze zaan­ga­żo­wa­nie dostaw­ców wymu­si­ły przy­bie­ra­ją­ce na sile dzia­ła­nia kon­ku­ren­cyj­ne, nato­miast klien­ci zaczę­li uważ­niej ana­li­zo­wać wydat­ko­wa­ne środ­ki, na bie­żą­co śle­dzić postę­py prac i pre­cy­zyj­niej defi­nio­wać biz­ne­so­we cele pro­jek­tów wdro­że­nio­wych. (źr. Mniejsze budże­ty + krót­sze wdro­że­nia = więk­sze korzy­ści z sys­te­mów ERP? : ERPstandard​.pl – sys­te­my ERP, CRM, BI, wia­do­mo­ści, pora­dy, pre­zen­ta­cje.)

Na zakończenie

Kilka lat temu (ok. 2005 roku, nie­ste­ty nie pamię­tam dokład­nej daty…) fir­ma IBM opu­bli­ko­wa­ła wyni­ki swo­ich badań na ponad 500. zakoń­czo­nych pro­jek­tach u klien­tów swo­ich i u prze­ję­tych firm. Co się okazało.

Praktyka poka­zu­je, że czas i środ­ki poświę­co­ne na ana­li­zę wyma­gań (obej­mu­je ona tak­że pro­jekt logi­ki biz­ne­so­wej) istot­nie skra­ca­ją pro­ces imple­men­ta­cji (któ­ra zawie­ra pro­jek­to­wa­nie szcze­gó­łów archi­tek­tu­ry imple­men­ta­cji). Głównym źró­dłem oszczęd­no­ści jest wypra­co­wa­ny na począt­ku i prze­te­sto­wa­ny model logicz­ny sys­te­mu dzię­ki cze­mu prak­tycz­nie uni­ka­my pętli odkry­wa­nia nowych wyma­gań, nowych ?fak­tów? już na eta­pie imple­men­ta­cji. Nie ma miej­sca zja­wi­sko opi­sy­wa­ne przez pro­gra­mi­stów: ​„klient nie wie cze­go chce, a my dostar­cza­my to co mamy”. Nie wystę­pu­ją więc naj­bar­dziej kosz­tow­ne popraw­ki sys­te­mu, w tym popraw­ki mode­lu danych. W dobrze pro­wa­dzo­nym pro­jek­cie ana­li­za jest powta­rza­na tyl­ko w celu wytwo­rze­nia nowej wer­sji sys­te­mu. Korzyści odno­szą tu i klient i wykonawca:

1. System jest tań­szy i dostar­czo­ny w krót­szym cza­sie – korzy­sta klient,
2. Dotrzymane zakła­da­ne ter­min i pra­co­chłon­ność to zacho­wa­nie pier­wot­nej pla­no­wa­nej mar­ży ? korzy­sta wyko­naw­ca, w kon­trak­tach fixed-pri­ce każ­de opóź­nie­nie to utra­ta zysku,
3. Ryzyko poraż­ki pro­jek­tu spro­wa­dzo­ne do mini­mum ? korzy­sta­ją wszyscy.

Tak to wygląda:

Niestety powyż­sze obra­zu­je dla­cze­go tak wie­lu dostaw­ców opro­gra­mo­wa­nia prze­ko­nu­je swo­ich klien­tów do tezy, że ana­li­za to zbęd­ny koszt: ich pra­co­chłon­ność – war­tość kon­trak­tu – male­je! Klient pod­pi­su­jąc umo­wę, zna jej war­tość ale nie zna szcze­gó­łów kal­ku­la­cji… dla­te­go pod­pi­su­je nie wie­dząc, że wybrał wariant pierw­szy na powyż­szym diagramie.

To tak­że powód by nie pytać dostaw­ców o wyko­na­nie ana­li­zy bo jak widać będę one z regu­ły tań­sze, rze­tel­na ana­li­za i pro­jekt nie leży w inte­re­sie dostaw­cy. Dlatego – podob­nie jak w innych dzie­dzi­nach inży­nie­rii – nale­ży naj­pierw wyko­nać pro­jekt ana­li­tycz­ny a potem dopie­ro wybie­rać jego wykonawcę.