Przyczyny nieplanowanych kosztów wdrożeń

Zarządzanie ryzy­kiem to pro­za życia kie­row­ni­ków pro­jek­tów. Z jed­nej stro­ny doświad­czo­ny kie­row­nik pro­jek­tu powi­nien dosko­na­le radzić sobie z ryzy­kiem, z dru­giej zaś stro­ny prak­ty­ka pro­jek­tów poka­zu­je, że efek­ty są nie­ste­ty sła­be bo ok. 90% IT na świe­cie ma prze­kro­co­zne budże­ty i ter­mi­ny .

Jednym z cie­kaw­szych narzę­dzi zarzą­dza­nia ryzy­kiem jest mało popu­lar­ny tak zwa­ny sto­żek nie­pew­no­ści. Ogólna zasa­da pla­no­wa­nia mówi, że im bar­dziej w przy­szłość wybie­ga­ją pro­gno­zy tym bar­dziej są one nie­pew­ne. Jest nie tyl­ko intu­icyj­ne ale i udo­wod­nio­ne mate­ma­tycz­nie. Stożek nie­pew­no­ści to wykres poka­zu­ją­cy zwią­zek pomię­dzy kosz­ta­mi pro­jek­tu a posia­da­ną wie­dzą na eta­pie ini­cja­cji pro­jek­tu np. imple­men­ta­cji (dostar­cze­nia) opro­gra­mo­wa­nia. Poniżej jeden z przy­kła­dów jego zobrazowania:

Stożek nie­pew­no­ści

Stożek ten (sto­żek nie­pew­no­ści) to narzę­dzie empi­rycz­ne (!), obra­zu­je spo­dzie­wa­ne kon­se­kwen­cje jaki­mi są kosz­ty, gene­ro­wa­ne przez nie­pew­ność (przed­wcze­sne, nie­uda­ne pro­to­ty­py, wpro­wa­dza­nie zmian po przed­wcze­snym roz­po­czę­ciu prac imple­men­ta­cyj­nych i wdro­że­nio­wych, itp.). 

Na powyż­szym wykre­sie, czer­wo­na linia obra­zu­je kosz­ty eta­pu prac bez ana­liz i pro­jek­to­wa­nia (agi­le) a zie­lo­na kosz­ty prac poprze­dzo­nych ana­li­za­mi i pro­jek­to­wa­niem. Linie te spo­ty­ka­ją w punk­cie, w któ­rym wie­dza o osta­tecz­nej wer­sji pro­duk­tu jest już taka sama. Punkty ozna­czo­ne dia­men­tem” to kamie­nie milo­we pro­jek­tu. Wartość kosz­tu odnie­sie­nia 1.0 to sytu­acja, w któ­rej w momen­cie roz­po­czę­cia pro­jek­tu nie było­by żad­nych nie­wia­do­mych (ryzy­ko zakre­su pro­jek­tu = zero). Całkowity koszt pro­jek­tu to pola pod krzy­wy­mi (pomię­dzy daną krzy­wą a pozio­mem zero lewej osi). Praktyka poka­zu­je więc, że brak pla­no­wa­nia i pro­jek­to­wa­nia pod­no­si kosz­ty pro­jek­tu śred­nio czterokrotnie.

W przy­pad­ku apli­ka­cji będą­cej mono­li­tem wykres repre­zen­tu­je cały pro­jekt („water fall”, meto­da wodo­spa­do­wa), czy­li pro­jekt trwa­ją­cy nie raz kil­ka lat. Prawdopodobieństwo, że reali­za­cja deta­licz­nie zapla­no­wa­ne­go np. na 5 lat pro­jek­tu będzie wyma­ga­ła korek­ty pla­nów lub wpro­wa­dza­nia zmian do pro­jek­tu, gra­ni­czy obec­nie z pewnością:

W przy­pad­ku zasto­so­wa­nia metod obiek­to­wych, zorien­to­wa­nych na komponenty/mikroserwisy, wykres Stożek nie­pew­no­ści repre­zen­tu­je dostar­cze­nie jed­nej usłu­gi apli­ka­cyj­nej (przy­pa­dek uży­cia, imple­men­to­wa­nej jako kom­po­nent, patrz tak­że ite­ra­cyj­no-przy­ro­sto­we dostar­cza­nie opro­gra­mo­wa­nia jako kolej­nych usług apli­ka­cyj­nych, MVP: Minimum Value Product). Implementacja jed­nej takiej usłu­gi z regu­ły mie­ści się w jed­nym kwar­ta­le. W efek­cie prak­tycz­nie eli­mi­nu­je­my skut­ki nie­pew­no­ści, pla­nu­jąc reali­za­cję pro­jek­tu tak, by żad­ne pla­ny nie wybie­ga­ły zbyt dale­ko w przy­szłość (z regu­ły gra­ni­ca jest rok budże­to­wy). Jest to moż­li­we dzię­ki odej­ściu od mono­li­tycz­nej archi­tek­tu­ry apli­ka­cji. Realizacja pro­jek­tu wytwa­rza­nia apli­ka­cji o kom­po­nen­to­wej (np. mikro­ser­wi­sy) archi­tek­tu­rze wyglą­da jak poniżej:

Warto tu zwró­cić uwa­gę, że apli­ka­cje zbu­do­wa­ne w opar­ciu o jed­ną i cen­tral­ną bazę danych w mode­lu rela­cyj­nym (RDBMS) są wła­śnie typo­wy­mi mono­li­ta­mi, np. więk­szość powszech­nie zna­nych dużych sys­te­mów ERP. Duże sys­te­my rela­cyj­nych baz danych są z tego powo­du od daw­na krytykowane:

(Designing Object Systems: Object-Oriented Modelling with Syntropy Textbook Binding ? November 18, 1994 by Steve Cook (Author), John Daniels (Author))

W tym przy­pad­ku ofer­ty (obiet­ni­ce) dostaw­ców tego typu sys­te­mów (mono­li­ty) to zie­lo­na linia na dia­gra­mie Stożek nie­pew­no­ści, a fak­tycz­ne kosz­ty tych wdro­żeń, pole­ga­ją­ce na bie­żą­cej, pro­wa­dzo­nej ad-hoc adap­ta­cji, to linia czer­wo­na, co potwier­dza­ją sta­ty­sty­ki .

Źródła

Little, T. (2006). Schedule esti­ma­tion and uncer­ta­in­ty sur­ro­un­ding the cone of uncer­ta­in­ty. Software, IEEE, 23, 48 – 54. https://​doi​.org/​1​0​.​1​1​0​9​/​M​S​.​2​0​0​6​.82
Cook, S., & Daniels, J. (1994). Designing object sys­tems: object-orien­ted model­ling with Syntropy. Prentice Hall.

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.

Effective software delivery. White paper. May 2009

Raport Jama Sofware ? O wymaganiach

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:

Effective software delivery. White paper. May 2009
Effective softwa­re deli­ve­ry. White paper. May 2009

Effective software delivery. White paper. May 2009
Effective softwa­re deli­ve­ry. White paper. May 2009

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