Dom bez planów

Proces zbierania i analizy wymagań u developera

Dziś nie­co kon­tro­wer­syj­ny arty­kuł, kry­ty­ka naj­czę­ściej sto­so­wa­nych metod ana­li­zy wyma­gań. Pojawią się tu cyta­ty ze stron dużych firm dostar­cza­ją­cych opro­gra­mo­wa­nie. Są to kry­ty­ko­wa­ne prze­ze mnie opi­sy metod pra­cy. Jednak z mojej stro­ny będzie tu: nie moje widzi­mi­się” jako wła­ści­wa meto­da”, a meto­dy powszech­nie uzna­ne za sku­tecz­ne i opi­sa­ne w sie­ci i w lite­ra­tu­rze. Osobiście zresz­tą uwa­żam, że wie­le tak zwa­nych autor­skich meto­dyk” to albo udziw­nio­ne i nad­mier­nie kom­pli­ko­wa­ne stan­dar­dy (czy­taj pod­nie­sio­ne kosz­ty ana­li­zy), albo ubra­ne w pro­ce­du­ry” meto­dy tu kry­ty­ko­wa­ne (czy­li tak­że pod­nie­sio­ne kosz­ty ale już dal­szych etapów).

Bardzo czę­sto z ust dostaw­ców opro­gra­mo­wa­nia, moż­na usły­szeć o takim podzia­le wyma­gań, któ­ry co cie­ka­we, trud­no zna­leźć w opi­sach stan­dar­dów metod ana­li­tycz­nych (np. OMG​.org):

Wymaganie jest potrze­bą klien­ta, któ­ra wpły­wa na powsta­nie nowe­go roz­wią­za­nia lub zmie­nia roz­wią­za­nie już ist­nie­ją­ce. Ze wzglę­du na poziom szcze­gó­ło­wo­ści wyma­ga­nia mogą być biz­ne­so­we lub sys­te­mo­we.

Wymaganie biz­ne­so­we reali­zo­wa­ne jest poprzez jed­no lub zbiór wyma­gań sys­te­mo­wych. Przykładem może być Import pli­ków z umo­wa­mi. Wymaganie to moż­na zre­ali­zo­wać poprzez dwa wyma­ga­nia sys­te­mo­we: import pli­ków i obsłu­ga zaim­por­to­wa­nych plików.

Wymagania sys­te­mo­we doty­czą bez­po­śred­nich funk­cjo­nal­no­ści sys­te­mu. Złożone wyma­ga­nia sys­te­mo­we moż­na przed­sta­wić za pomo­cą bar­dziej szcze­gó­ło­wych, np. Import pli­ków obej­mu­je wyko­na­nie spraw­dzeń i wali­da­cji na zaim­por­to­wa­nych danych oraz pro­ces zapi­su umów z pli­ku impor­tu w sys­te­mie.

Pojawia się poję­cie Import pli­ku z umo­wa­mi”. Jaki to ma zwią­zek z biz­ne­sem? Domyślać się moż­na jedy­nie, że te umo­wy gdzieś są i w jakimś celu powin­ny być gdzieś dostęp­ne, ale nie jestem prze­ko­na­ny by użyt­kow­nik od razu wyar­ty­ku­ło­wał, że chce mieć ich import”. To poję­cie techniczne.

Osobiście pole­mi­zu­ję z takim podej­ściem nie tyl­ko dla­te­go, że trud­no o wska­za­nie pod­staw takie­go a nie inne­go podzia­łu wyma­gań. Także dla­te­go, że jest to pro­ces z grun­tu ryzy­kow­ny. Po trze­cie, powyż­sze defi­ni­cje nie speł­nia­ją pod­sta­wo­we­go kry­te­rium słow­ni­ka pojęć: poję­cia danej prze­strze­ni nazw nie mogą być defi­nio­wa­ne z pomo­cą innych pojęć tej samej prze­strze­ni. Takie błę­dy pro­wa­dzą do tak zwa­ne­go masła maśla­ne­go, co wyszło dość szyb­ko, bo tekst w dal­szej czę­ści tre­ści cyto­wa­nej stro­ny zaprze­cza czę­ści wcze­śniej­szej defi­ni­cji wymagań:

Zgodnie z teo­rią spe­cy­fi­ka­cja powin­na zawie­rać przede wszyst­kim wyma­ga­nia zapre­zen­to­wa­ne z punk­tu widze­nia klien­ta i w ter­mi­nach dla nie­go zro­zu­mia­łych. Powinna stwier­dzać, co ma zostać zre­ali­zo­wa­ne, a nie jak nale­ży to zro­bić. Specyfikacja wyma­gań nie może być więc pró­bą pro­jek­to­wa­nia systemu.

i z tym nale­ży się zgo­dzić w 100%, wiec co robi tu import pli­ku w raz całym opi­sem ich obsłu­gi, wali­da­cji itp. (w peł­nym tek­ście cyto­wa­nym jako wyma­ga­nie opi­sa­no pro­ces impor­tu pliku).

Po pierw­sze kim tu jest Klient? Gdzie jest użyt­kow­nik? Dlaczego wyma­ga­nie okre­śla spo­sób reali­za­cji wyma­ga­nia (Import pli­ków obej­mu­je…)? Co to są bez­po­śred­nie funk­cjo­nal­no­ści sys­te­mu”? Skoro są bez­po­śred­nie to czym są nie­bez­po­śred­nie funk­cjo­nal­no­ści” i gdzie je opisano?

Ogólnie poję­cie wyma­ga­nia sys­te­mo­we”, będą­ce pró­bą opi­su jak to ma być zro­bio­ne” nie mają żad­nej racji bytu jako Wymaganie Klienta. W ogó­le lite­ra­tu­ra (nie licząc masy mier­nej jako­ści porad­ni­ków) nie zawie­ra poję­cia wyma­ga­nie sys­te­mo­we” w zna­cze­niu innym niż wyma­ga­nia na plat­for­mę sprzę­to­wo-sys­te­mo­wą. Jednak te wyma­ga­nia powi­nien okre­ślić wyko­naw­ca na eta­pie pro­jek­tu imple­men­ta­cji a nie biznes.

W moich oczach doku­men­ta­cja wyma­gań powsta­ła na bazie powyż­szych defi­ni­cji, jest po pro­stu nie­we­ry­fi­ko­wal­na (pole­cam wpis o szko­dli­wo­ści dwu­znacz­no­ści tre­ści doku­men­ta­cji). Po dru­gie war­to wie­dzieć, że zama­wia­ją­cy nie jest w sta­nie (i nie powi­nien) pre­cy­zo­wać wyma­gań innych niż biz­ne­so­we zaś wyko­naw­ca (pro­gra­mi­sta, deve­lo­per) ocze­ku­je pro­jek­tu a nie wyma­gań. Wymagania ma – okre­śla – zama­wia­ją­cy, swo­im języ­kiem (więc raczej nie import umów”), ktoś powi­nien umieć je zwe­ry­fi­ko­wać (audyt) i zamie­nić na pro­jekt tego co ma wyko­nać (dostar­czyć) dostaw­ca opro­gra­mo­wa­nia. Dokładnie tak jest w innych dzie­dzi­nach inży­nie­rii, np. budowlanej.

Cytowany opis to mniej wię­cej taki pro­sty model ról w projekcie:

Mamy użyt­kow­ni­ka, któ­ry ma wyma­ga­nia co do opro­gra­mo­wa­nia, ana­li­tyk wyma­gań je zbie­ra (sesje warsz­ta­to­we, ankie­ty, spo­tka­nia, wywia­dy, inne) i wery­fi­ku­je. Powstaje spe­cy­fi­ka­cja. Tak powsta­łe spe­cy­fi­ka­cje wyma­gań nie pod­da­ją się żad­nej wery­fi­ka­cji na kom­plet­ność i spój­ność, są dekla­ra­cją użyt­kow­ni­ków bez gwa­ran­cji, że nie odkry­je­my nowych wyma­gań lub nie uzna­my wie­lu z nich za nadmiarowe.

Jak wyglą­da zale­ca­ny proces

Bazuje na pro­stej” kolej­no­ści dzia­łań opi­sa­nej na stro­nach OMG​.org pod nazwą pro­ces MDA”, nie raz w moim blo­gu przy­wo­ły­wa­ny. Proces ten ma na trzy klu­czo­we kroki:

  1. opra­co­wa­nie mode­lu fir­my: model biz­ne­so­wy (pro­ce­sy biz­ne­so­we, struk­tu­ra org., regu­ły biz­ne­so­we), jest to tak zwa­ny model CIM (Computing Independent Model), celem jego powsta­nia jest zbu­do­wa­nie narzę­dzia opi­su­ją­ce­go fir­mę Klienta, któ­re posłu­ży dopie­ro do zde­fi­nio­wa­nia i wery­fi­ka­cji wymagań.
  2. opra­co­wa­nie mode­lu PIM (Platform Independent Model), jest to opis usług sys­te­mu i ich logi­ki bez żad­nych infor­ma­cji o imple­men­ta­cji, to pro­jekt oprogramowania.
  3. opra­co­wa­nie mode­li PSM (Platform Specyfic Model), jest to opis tego jak model PIM ma być imple­men­to­wa­ny (zre­ali­zo­wa­ny) i to dopie­ro robi developer.

Całość bazu­je na kla­sycz­nej ana­li­zie sys­te­mo­wej (zwa­ną tez meto­da nauko­wą). Bazując na tym opi­sie powin­no więc być tak:

Wygląda na dość skom­pli­ko­wa­ny pro­ces ale to pozo­ry. Sponsor pro­jek­tu, klu­czo­wa postać w ana­li­zie wyma­gań, okre­śla cele biz­ne­so­we. One wyzna­cza­ją wszel­kie prio­ry­te­ty w dal­szej ana­li­zie np. prio­ry­te­ty wyma­gań. Sponsor sta­wia cele biz­ne­so­we np. pod­nie­sie­nie jako­ści obsłu­gi rekla­ma­cji poprzez eli­mi­na­cję przy­pad­ków zagu­bień doku­men­tów. Powstaje model CIM, z jego pomo­cą wyszu­ku­je­my miej­sca, w pro­ce­sach biz­ne­so­wych, w któ­rych te doku­men­ty giną lub jest ryzy­ko zagi­nię­cia. I tak prze­cho­dzi­my wszyst­kie wyma­ga­nia biz­ne­so­we. Tu wyma­ga­niem biz­ne­so­wym jest cel spon­so­ra, lista jego potrzeb i w kon­se­kwen­cji dopie­ro użyt­kow­ni­ków. Jednak to nie użyt­kow­nik dekla­ru­je, że coś chce”, takie ocze­ki­wa­nie musi wyni­kać z celu spon­so­ra. Wszystkie zało­że­nia, a są nimi np. ocze­ki­wa­ne funk­cjo­nal­no­ści opro­gra­mo­wa­nia i teza, że zaspo­ka­ja­ją one wyma­ga­nia spon­so­ra pro­jek­tu, są wery­fi­ko­wa­ne z pomo­cą mode­li. Modele sa tu narzę­dziem na eta­pie ana­li­zy CIM i pro­jek­tem na eta­pie PIM.

Lista wyma­gań jako ankie­ta życzeń przy­szłych użyt­kow­ni­ków to naj­częst­sze źró­dło pro­ble­mów w projektach. 

Dalej cele biz­ne­so­we wyzna­cza­ją na mode­lu CIM jakie usłu­gi przy­szły sys­tem ma ofe­ro­wać jego użyt­kow­ni­kom, by cele biz­ne­so­we speł­nić. Np. aby doku­men­ty nie ginę­ły, należ je ska­no­wać i archi­wi­zo­wać w spo­sób bez­piecz­ny i łatwy do wyszu­ka­nia zaraz po otrzy­ma­niu. To zna­czy, że System powi­nien udo­stęp­nić usłu­gi: ska­no­wa­nie i indek­so­wa­nie, wyszu­ki­wa­nie i prze­glą­da­nie. Logika tych usług to spo­sób wza­jem­ne­go koja­rze­nia tych doku­men­tów i póź­niej­sze­go wyszu­ki­wa­nia. Dokument, któ­ry to opi­su­je to model PIM. I to wszyst­ko robi Analityk Biznesowy.

Koszty takiej analizy

Tu war­to powie­dzieć, że nie zawsze ana­li­za w posta­ci kolek­cjo­no­wa­nia np. ankiet czy wyni­ków [[sesji JAD]] jest tań­sza od pro­jek­tu reali­zo­wa­ne­go opi­sa­ną metodą.

Jeżeli ana­li­zę wyma­gań robi jed­na oso­ba, i jej kom­pe­ten­cje to tyl­ko duże doświad­cze­nie w takich wywia­dach i two­rze­nie doku­men­tów (tek­sty, tabe­le itp.), to jej koszt może być rela­tyw­nie niski, jed­nak nie­ste­ty tak opra­co­wa­na lista wyma­gań to naj­czę­ściej listy cech zawie­ra­ją­ce tak­że owe pró­by imple­men­ta­cji” (np. import pli­ków umów”), bez żad­nej gwa­ran­cji, że dla odmia­ny cze­goś oczy­wi­ste­go” a waż­ne­go nie pomi­nię­to. Brak celu biz­ne­so­we­go spon­so­ra nie daje zaś żad­ne­go narzę­dzia do odsie­wu życzeń nad­mia­ro­wych”, zwa­nych potocz­nie w pro­jek­tach poboż­ny­mi życze­nia­mi użytkowników”.

Jeżeli ana­li­za robio­na jest siłą kil­ku kon­sul­tan­tów orga­ni­zu­ją­cych sesje warsz­ta­to­we z gru­pa­mi pra­cow­ni­ków, doku­men­ta­cja ma kil­ku recen­zen­tów i trwa to np. kwar­tał, to jest to pro­ces nie mniej ryzy­kow­ny, bo pro­duk­tem tak­że jest spe­cy­fi­ka­cja życze­nio­wa, za to bar­dzo kosz­tow­na, znacz­nie kosz­tow­niej­sza niż pra­ca jego doświad­czo­ne­go ana­li­ty­ka Biznesowego.

Tego typu życze­nio­we doku­men­ty, gene­ru­ją bar­dzo duże kosz­ty na eta­pie wdra­ża­nia i zarzą­dza­nia zmia­ną (odkry­wa­nie wyma­gań i ich zmiany).

Analiza Biznesowa i spe­cy­fi­ka­cja wyma­gań opra­co­wa­na meto­dą opi­sy­wa­ną tu i na stro­nach OMG, jest od tej ostat­niej (gru­pa kon­sul­tan­tów i sesje warsz­ta­to­we) znacz­nie tań­sza. W cza­sie trwa podob­nie, jed­nak robi to z regu­ły jed­na oso­ba (tak! ale przy zało­że­niu ma sto­su­je zaawan­so­wa­ne narzę­dzia CASE nie tyl­ko do two­rze­nia dia­gra­mów ale tak­że do ich wery­fi­ka­cji śla­do­wa­nia zarzą­dza­nia spój­no­ścią mode­li itp.), a efek­tem jest pro­jekt logicz­ny a nie dopie­ro lista wyma­ga­nych cech. Korzyść jest więc podwój­na. Jeżeli zro­bi to Analityk wyna­ję­ty przez Klienta a nie Dostawcy, to wszel­kie pra­wa (know-how) do pro­jek­tu pozo­sta­ją po stro­nie nabywcy.

Można powie­dzieć, że to trud­ne i kosz­tow­ne. Trudne owszem, wyma­ga doświad­cze­nia i wie­dzy zarów­no z zakre­su zarzą­dza­nia jak i inży­nie­rii opro­gra­mo­wa­nia. Per sal­do, wli­cza­jąc w to kosz­ty mody­fi­ka­cji na eta­pie wdra­ża­nia i odkry­wa­nia wyma­gań (wady spe­cy­fi­ka­cji nie pod­da­ją­cej się wery­fi­ka­cji) jest to pro­ces zawsze tań­szy (bada­nia kie­row­ni­ków pro­jek­tów wska­zu­ją, że zła jakość wyma­gań gene­ru­je dodat­ko­we kosz­ty rzę­du 60% war­to­ści pro­jek­tu, koszt takiej ana­li­zy nie prze­kra­cza zaś 20%). Do tego poja­wia­ją się poten­cjal­ne kosz­ty nie­ujaw­nio­ne klien­to­wi: pra­wa autor­skie do pro­jek­tu i apli­ka­cji. Jeżeli fir­ma będą­ca wyko­naw­ca opro­gra­mo­wa­nia robi ana­li­zę swo­je­go klien­ta i potem mu sprze­da­je pra­wa do jej wyni­ków wraz z dostar­cza­nym opro­gra­mo­wa­niem, to jest to kla­sycz­ny przy­pa­dek aneg­do­ty o kon­sul­tan­tach, któ­rzy zapy­ta­ni o to któ­ra jest godzi­na, pro­szą Cie o Twój zega­rek, odpo­wia­da­ją na pyta­nie któ­ra godzi­na i wysta­wia­ją fak­tu­rę za usłu­gę i tak­że za zwra­ca­ny Ci Twój zegarek.

Tak więc naj­pro­ściej: mamy spon­so­ra pro­jek­tu i ewen­tu­al­nych innych zain­te­re­so­wa­nych. Oni mają wyma­ga­nia biz­ne­so­we – chcą coś w swo­ich orga­ni­za­cjach osią­gnąć lub zmie­nić. Kolejny etap to ana­li­za, któ­rej celem jest oce­na czy to moż­li­we i jak. Jako narzę­dzia pra­cy” powsta­ją model tej orga­ni­za­cji: mapy pro­ce­sów, struk­tu­ra orga­ni­za­cyj­na, sys­tem reguł i pojęć biz­ne­so­wych. Produktem tej pra­cy są reko­men­da­cje gdzie i jak moż­na osią­gnąć efek­ty wyma­gań biz­ne­so­wych. Jeżeli zapad­nie decy­zja o tym, że wyma­ga­nia biz­ne­so­we pomo­że osią­gnąć nowe opro­gra­mo­wa­nie wspie­ra­ją­ce orga­ni­za­cję, na bazie posia­da­nych mode­li opra­co­wu­je się listę wyma­gań funk­cjo­nal­nych i poza-funk­cjo­nal­nych. Są to usłu­gi sys­te­mu jakich od nie­go ocze­ku­je­my oraz ogra­ni­cze­nia jakościowe.

Ale to za mało, taki opis jest dopie­ro wsa­dem” do pro­jek­to­wa­nia. Nie wystar­czy powie­dzieć jakiej usłu­gi ocze­ku­je­my, koniecz­ne jest opi­sa­nie tego, jaką logi­kę ma każ­da usłu­ga reali­zo­wać i jaki­mi dany­mi zarzą­dzać. Należy okre­ślić jaką wie­dzą nadal będzie dys­po­no­wał użyt­kow­nik (aktor sys­te­mu) a jaką wie­dzę” ma posia­dać opro­gra­mo­wa­nie świad­czą­ce wyma­ga­ną usłu­gę (np. kto ma umieć poli­czyć poda­tek VAT na fak­tu­rze: użyt­kow­nik czy opro­gra­mo­wa­nie do fak­tu­ro­wa­nia). Dopiero taki opis sta­no­wi jasne zada­nie” dla dostaw­cy opro­gra­mo­wa­nia, któ­ry powi­nien zostać wybra­ny dopie­ro po tym, jak będzie­my dys­po­no­wa­li opi­sem tej logi­ki i jej ogra­ni­cze­nia­mi. Dlaczego? Dostawcy się zawsze w czymś spe­cja­li­zu­ją, ta spe­cja­li­za­cja jest czyn­ni­kiem wpły­wa­ją­cym na to, któ­ry zre­ali­zu­je nasz pro­jekt naj­le­piej. Jeżeli to przy­szły wyko­naw­ca wyko­na ana­li­zę i pro­jekt, jest pra­wie pew­ne, że będzie on opty­mal­ny z per­spek­ty­wy spe­cja­li­za­cji wyko­naw­cy a nie z per­spek­ty­wy wyma­gań Zamawiającego.

Inne artykuły na podobny temat

image_print(wydruk PL)

Komentarze

  1. Hania Wesołowska 2 października 2012 at 11:39

    Wszystko to dobre i daje szan­sę na dostar­cze­nie opro­gra­mo­wa­nia, któ­re rze­czy­wi­ście speł­nia potrze­by klienta.

    Tylko… Jak prze­ko­nać nie­wie­rzą­cych w ana­li­zę, że to rze­czy­wi­ście jest taniej? Wielu widzi tyl­ko to, że w fazie począt­ko­wej jest dro­żej. Musimy spę­dzić czas na pozna­wa­niu celów i pro­ce­sów klien­ta. Tu się też moż­na spo­tkać z nie­zro­zu­mie­niem po co się na to tra­ci czas, sko­ro mamy od klien­ta listę poboż­nych życzeń”.

    Później tra­ci­my czas” na pro­jek­to­wa­nie. Przecież jest już jakiś doku­ment”, niech go sobie pro­gra­mi­ści wezmą i pro­gra­mu­ją (są spe­cja­li­sta­mi i sobie pora­dzą bez pro­jek­tu, może nawet lepiej, jak im nikt nie będzie nic narzucał). 

    Łatwo jest zoba­czyć w tych pierw­szych fazach, że czas trwa­nia się zwięk­sza, zwięk­sza­ją się kosz­ty. Trudno jest zoba­czyć, a raczej powią­zać póź­niej­sze pro­ble­my jako bez­po­śred­nia kon­se­kwen­cja zanie­cha­nia tych pole­ca­nych czyn­no­ści. Skąd wia­do­mo, że dokład­nie temu pro­ble­mo­wi byśmy zapobiegli? 

    Jeszcze docho­dzi pro­blem taki, że każ­dy pro­jekt jest inny. Trudno porów­nać pro­jekt, w któ­rym dzia­ła­li­śmy odpo­wied­nio z pro­jek­tem, w któ­rym zanie­cha­li­śmy dobrych prak­tyk. One mają inny zakres, inne­go klien­ta, inne czyn­ni­ki ryzy­ka, panu­ją­ce warun­ki, itd. 

    Decydenci chcą dowo­du, ale jak to udowodnić?

    • Jarek Żeliński 2 października 2012 at 15:35

      Jak prze­ko­nać…”, nie znam spo­so­bu inne­go niż … popa­rze­nie się. 100% moich klien­tów to fir­my po przej­ściach w rodza­ju Agile i umo­wa czas i mate­riał albo ana­li­za wyma­gań meto­dą ankiet i warsz­ta­tów JAD a potem maso­we zarzą­dza­nie zmia­ną w pro­jek­cie itp. Moim zda­niem zawsze byli i będę ludzie, któ­rzy cięż­ko cho­ru­ją a nawet scho­dzą, tyl­ko dla­te­go, że zamiast leczyć się u dobrych leka­rzy cho­dzi­li do zna­cho­rów lub sto­so­wa­li leki” ofe­ro­wa­ne w rekla­mach TV. 

      Zawsze mówię klien­tom i na kon­fe­ren­cjach: nie porów­nu­ją treść ana­liz i spe­cy­fi­ka­cji wyma­gań z tym co maja po zakoń­cze­niu pro­jek­tu (o ile się zakoń­czy) im bar­dziej te dwa byty” od sie­bie odbie­ga­ją tym gor­szej jako­ści była ana­li­za i wymagania.

      Niestety to, że fak­tycz­nie nie da się wprost ze sobą porów­ny­wać róż­nych pro­jek­tów powo­du­je tyl­ko, że fir­my nie­sto­su­ją­ce dobrych prak­tyk mają argu­men­ty za tym, by ich nie sto­so­wać, ale jest mier­nik na któ­ry war­to zwra­cać uwa­gę: naj­lep­sze są fir­my zawie­ra­ją­ce umo­wy o dzie­ło czy­li dekla­ru­ją­ce jakieś ter­mi­ny i budże­ty i wywią­zu­ją­ce się z tych umów.… inny­mi sło­wy: fir­my for­su­ją­ce w pro­jek­tach biz­ne­so­wych umo­wy czas i mate­riał” nale­ży omijać.

  2. Hania Wesołowska 2 października 2012 at 13:44

    Spotkałam się z jesz­cze dokład­niej­szym podzia­łem wymagań 😉
    Wymagania podstawowe
    Wymagania biznesowe
    Wymagania funkcjonalne
    Wymagania techniczne

    • Jarek Żeliński 2 października 2012 at 15:27

      Ja też, i pytam wte­dy co każ­de z nich ozna­cza i spraw­dzam czy ich defi­ni­cje się wza­jem­nie wyklu­cza­ją, bo powin­ny… i nigdy nie zosta­ły obro­nio­ne”.…

  3. Hania Wesołowska 2 października 2012 at 15:47

    Zawsze mówię klien­tom i na kon­fe­ren­cjach: nie porów­nu­ją treść ana­liz i spe­cy­fi­ka­cji wyma­gań z tym co maja po zakoń­cze­niu pro­jek­tu (o ile się zakoń­czy) im bar­dziej te dwa ?byty? od sie­bie odbie­ga­ją tym gor­szej jako­ści była ana­li­za i wymagania.”

    Tak, to kon­kret­nie może­my spraw­dzić. I może­my się zdzi­wić jak pro­jekt muto­wał do zupeł­nie inne­go kształtu:)

    Ale to nadal nie udo­wad­nia, że ta gor­sza dro­ga” nie jest mimo wszyst­ko tańsza.

    Drążę temat, bo zacho­dzę w gło­wę jak to moż­na udo­wod­nić, jak prze­ko­nać do takie­go spo­so­bu pra­cy, jeśli głów­nym argu­men­tem jest kasa, a nie obcho­dzi innych zgod­ność ze sztu­ką i zapo­bie­ga­nie ryzy­ku, któ­re się nie opłaca.

    • Jarek Żeliński 2 października 2012 at 16:44

      Udowodnić moż­na tyl­ko w sfe­rze ryzy­ka pro­jek­to­we­go. Nie da się np. wyka­zać, że opro­gra­mo­wa­nie wyko­na­ne na bazie krót­kie­go słow­ne­go opi­su będzie złe lub bar­dzo kosz­tow­ne. Można jed­nak wska­zać bada­nie ankie­to­we, któ­re mówią, że (zależ­nie od kon­kret­ne­go bada­nia) 75 – 85% pro­jek­tów ma prze­kro­czo­ny budżet śred­nio o 60% a ter­mi­ny o 200% a jed­nym z powo­dów, któ­ry wska­za­ło 100% ankie­to­wa­nych była spe­cy­fi­ka­cja wyma­gań: bra­ki i nie­spój­no­ści. Z tego wyni­ka, że zanie­dbu­jąc ana­li­zę wyma­gań, robiąc ją meto­da­mi nie dają­cy­mi żad­nej pew­no­ści spój­no­ści i kom­plet­no­ści, z praw­do­po­do­bień­stwem 80% prze­kro­czy­my budżet o 60% a ter­min o 200%. Problem w tym, że na począt­ku wszy­scy wie­rzą, że są w tych pozo­sta­łych 20%. :))), wie­dzą to tyl­ko Ci co mają doświadczenie …

  4. Hania Wesołowska 2 października 2012 at 16:57

    Czyli pozo­sta­je cze­kać na poraż­ki i mieć nadzie­ję, że odpo­wied­nie oso­by wycią­gną odpo­wied­nie wnioski 🙂

    • Jarek Żeliński 2 października 2012 at 20:49

      chy­ba tak.… ale wycią­ga­ją bo mam, nie tyl­ko ja, klientów 😉

  5. Jacek Rybicki 3 października 2012 at 22:15

    Obawiam się, że nie da się udo­wod­nić przy­dat­no­ści dokład­nej ana­li­zy wyma­gań i roz­dzie­le­nia pra­cy ana­li­ty­ka i dewelopera.
    Wiele pro­jek­tów na tym korzy­sta, ale jeże­li korzy­sta­ją, to zna­czy że to są i tak spo­koj­ne” pro­jek­ty, któ­rych szan­se powo­dze­nia są bar­dzo wyso­kie, jeże­li tyl­ko prze­pro­wa­dza­ne są przez profesjonalistów.

    Jednak żyje­my w cią­głym postę­pie wyzwań. Od kil­ku­na­stu lat sta­ty­sty­ki nie­po­wo­dzeń pro­jek­tów poda­ją bar­dzo podob­ne rezul­ta­ty. Waha się tole­ran­cja ryzy­ka, sta­re pro­ble­my są roz­wią­zy­wa­ne tak szyb­ko jak poja­wia­ją się nowe.

    Projekty będą nie­uda­wać się zarów­no przez nie­do­sta­tecz­ną ana­li­zę jak i przez zbyt dłu­gą ana­li­zę przedwykonawczą.

    Agile jest tu przed­sta­wia­ny tak, jak­by powi­nien mieć swój kod ICD-10.
    Ja cią­gle sły­szę, że kon­trak­ty agi­le są bar­dzo rzad­kie, sto­so­wa­ne są tyl­ko w warun­kach wyso­kie­go zaufa­nia do pod­wy­ko­naw­cy, zwy­kle fir­my powią­za­nej biz­ne­so­wo. Skąd zatem bio­rą się kon­trak­ty T&M w sytu­acji spo­re­go ryzy­ka nie­po­wo­dze­nia i bra­ku prze­ło­że­nia na podwykonawcę?

    Jasne, że Agile to wygod­ny para­sol dla bra­ku pomy­słu na orga­ni­za­cję pra­cy i z tym trze­ba wal­czyć. Duży kon­trakt opar­ty o agi­le-by-the-book to też uto­pia. Z dru­giej stro­ny odrzu­ce­nie prak­tycz­nej wie­dzy jaką agi­le przy­no­si jest nierozsądne.

    • Jarek Żeliński 3 października 2012 at 22:53

      Patrząc na kon­trak­ty T&M to jest to w zasa­dzie naj­mo­wa­nie zaso­bów, pro­blem poja­wia się gdy naję­te zaso­by” same się ste­ru­ją (sam sobie daje robo­tę i sam sobie ją kontroluje). 

      Co do kło­po­tów z powo­du zbyt dłu­gich ana­liz przed­wy­ko­naw­czych to zga­dzam się w 100%: wie­le firm gene­ru­je mega­pra­co­chon­ne ana­li­zy przed­wy­ko­naw­cze i ana­li­zy wyma­gań jako uza­sad­nie­nie wyso­kich budże­tów. To czę­sto pato­lo­gicz­na kon­se­kwen­cja kon­trak­tów T&M na te ana­li­zy. Znam kil­ka firm z tak roz­bu­cha­ną, nie­zro­zu­mia­łą i nad­mia­ro­wą meto­dy­ką, że… 

      Nie odrzu­cam prak­ty­ki Agile, praw­do­po­dob­nie sam ją sto­su­ję, roz­po­czy­na­jąc pro­jekt od usta­le­nia jakie nie­zbęd­ne doku­men­ty powin­ny postać by osią­gnąć cele pro­jek­tu mini­mal­nych ryzy­kiem i mini­mal­nym kosz­tem zara­zem (kom­pro­mis). To co mi się nie podo­ba” w pro­jek­tach (z per­spek­ty­wy kupu­ją­cych) to roz­po­czy­na­nie ich na bazie jedy­nie wizji, czy­li luź­ne­go pomysłu…

  6. Jacek Rybicki 3 października 2012 at 23:40

    Nie negu­ję pre­zen­to­wa­ne­go na tym blo­gu podej­ścia. Zwracam tyl­ko uwa­gę na isnie­nie obsza­rów wyma­ga­ją­cych bar­dziej ela­stycz­nych rozwiązań.

    Paradygmaty pra­cy ana­li­ty­ka jed­nak zwy­kle (tyl­ko z ostroż­no­ści nie powiem zawsze”) pozo­sta­ją te same: doku­men­ta­cja ope­ru­ją­ca języ­kiem klien­ta, zro­zu­mie­nie potrzeb użyt­kow­ni­ków (któ­re nie­ko­niecz­nie są torż­sa­me z wyra­ża­ny­mi ocze­ki­wa­nia­mi), przej­rzy­stość metod i wery­fi­ko­wal­ność efek­tów pracy.

    Około poło­wy pro­jek­tów, w któ­rych bra­łem udział była w mode­lu t&m. I to były te, któ­re naj­czę­ściej koń­czy­ły się dobry­mi wyni­ka­mi – cho­ciaż­by dla­te­go, że tego typy kon­trak­ty dowo­dzą spo­koj­nej sytu­acji, duże­go pozio­mu zaufa­nia i spo­rej tole­ran­cji dla wyni­ków. Były to też zle­ce­nia typu zrób­cie coś, żeby roz­wią­zać pro­blem i zado­wo­lić klienta”.

    Dużo spro­wa­dził­bym do pozio­mu tole­ro­wa­nia ryzy­ka przez Sponsora (może być wewnątrz orga­ni­za­cji albo Klient). Jeżeli Sponsor akcep­tu­je, że mając:
    – pomysł
    – tro­chę wia­ry we wła­sne siły
    – sta­ty­stycz­ne dane o podob­nych pro­jek­tach (pocho­dzą­ce z naszej organizacji)
    – usys­te­ma­ty­zo­wa­ną rela­cję dostaw­ca-klient, opie­ra­ją­cą się na poro­zu­mie­niu co do tego, że niko­mu nie opła­ca się koń­czyć kon­trak­tu w sądzie, zamiast wdrożeniem;
    to może zaak­cep­to­wać krót­ką ana­li­zę, przy­ro­sto­we two­rze­nie sys­te­mu, tole­ran­cję zmian pod­czas wyko­na­nia i mnó­stwo małych ryzyk, któ­re spro­wa­dza­ją się do koniecz­no­ści wyko­na­nia nie­zbęd­nych dzia­łań jak najszybciej.

    • Jarek Żeliński 4 października 2012 at 08:55

      Jeżeli cho­dzi o wska­za­ne para­dyg­ma­ty to jest z tym pro­blem, bo zbie­ra­jąc wnio­ski z pro­jek­tów mają­cych pro­ble­my mogę powie­dzieć, że w 100% przy­pad­ków moż­na odha­czyć to, że źró­dłem wyma­gań byli przy­szli użyt­kow­ni­cy, ana­li­ty­cy w zasa­dzie tyl­ko prze­twa­rza­li” ich potrze­by” do posta­ci zgod­nej ze sto­so­wa­ną meto­dą pra­cy (naj­czę­ściej tabel­ki z zesta­wie­nia­mi lub przy­pad­ki uży­cia). Druga przy­czy­na pro­ble­mów do odha­cze­nia: pro­gra­mi­ści budo­wa­li model dzie­dzi­ny, w efek­cie był zawsze zbyt uprosz­czo­ny (bo mniej kla­pa­nia w kla­wi­sze i łatwiej­szy w imple­men­ta­cji, jak ja to czę­sto sły­szę) co skut­ko­wa­ło blo­ka­dą przy­szłych zmian i roz­sze­rzeń. Osobiście uwa­żam, że powyż­sze meto­dy są naj­bar­dziej ryzykowne.

      Projekty T&M nie są złe z zasa­dy, one po pro­tu z zasa­dy wyma­ga­ją bar­dzo dużych narzu­tów na nie­wie­dze na eta­pie ich kon­trak­to­wa­nia, rzecz w tym, że para­dok­sal­nie pro­jek­ty fixed pri­ce wycho­dzą taniej, są reali­zo­wa­ne szyb­ciej i dają nie gor­sze pro­duk­ty :). Od lat mam do czy­nie­nia ze skła­da­ny­mi ofer­ta­mi na moje i wcze­śniej­sze u klien­tów zapy­ta­nia, zary­zy­ku­je tezę, że regu­łą jest iż ofer­ty T&M są kosz­tow­niej­sze a pro­jek­ty w efek­cie potem trwa­ją dłużej. 

      Daleki jestem od tezy, że T&M two­rzy złe (gor­sze pro­duk­ty), ale po 20 latach sta­wiam tezę, że są pra­wie zawsze kosz­tow­niej­sze i trwa­ją dłu­żej. Kluczem jest tu stwier­dze­nie, że pro­jek­ty T&M wyma­ga­ją dużej dozy tole­ran­cji” z czym wypa­da mi się zgo­dzić. Ta tole­ran­cja jed­nak to nic inne­go to akcep­to­wa­nie fak­tu, że dostar­czo­ny pro­dukt (nawet w ter­mi­nie i budże­cie) ma mniej­szą lub wręcz inną funk­cjo­nal­ność niż zakła­da­no na począt­ku projektu. 

      Piszę to gene­ral­nie z per­spek­ty­wy klien­tów (pra­wie zawsze repre­zen­tu­ję wła­śnie ich). Oni mówią czę­sto o pro­gra­mi­stach (fir­mach) jed­no: faj­na fir­ma, faj­ni ludzie, moż­na się z nimi doga­dać i bez pro­ble­mu im zapła­ci­li­śmy. Więc z per­spek­ty­wy dostaw­cy mamy suk­ces. Problem w tym, że moja tam obec­ność bie­rze się stąd, że oni nadal nie mają tego co było pier­wot­nie celem a chcą i potrze­bu­ją tego… W 100% przy­pad­ków moich pro­jek­tów (bo pra­wie nikt nie zain­we­stu­je w ana­li­ty­ka za pierw­szym razem, zresz­tą naj­czę­ściej odra­dza­ją to sami dostaw­cy opro­gra­mo­wa­nia) sły­szę: teraz chce­my przed roz­po­czę­ciem pro­jek­tu mieć doku­ment, któ­ry opi­su­je co zamawiamy.

  7. Jacek Rybicki 4 października 2012 at 12:08

    Wszystko ład­nie dzia­ła zanim nie poja­wi się wynik pra­cy dostaw­cy 🙂 Problem poja­wia się pod­czas wdro­że­nia tego, co zosta­ło zamó­wio­ne, gdy oka­zu­je się, że ocze­ki­wa­nia były inne.
    Mamy dwie dro­gi – lep­sza ana­li­za, co w wie­lu wypad­kach prze­kła­da się na czas, albo szyb­sze wdro­że­nie umoż­li­wia­ją­ce szyb­kie uzy­ska­nie infor­ma­cji zwrot­nej. Fixed pri­ce sprzy­ja pierw­szej dro­dze, T&M drugiej.

    Fixed pri­ce sprzy­ja więk­szej kon­cen­tra­cji uwa­gi na począt­ku pro­jek­tu. Sprzyja też nad­mia­ro­wej spe­cy­fi­ka­cji wymagań.

    • Jarek Żeliński 4 października 2012 at 12:52

      Zgadzam się z tym, że Fixed pri­ce sprzy­ja więk­szej kon­cen­tra­cji uwa­gi na począt­ku pro­jek­tu. Sprzyja też nad­mia­ro­wej spe­cy­fi­ka­cji wyma­gań.”. Z tym dru­gim trze­ba wal­czyć, bo nie raz jest to prze­jaw bez­sen­sow­nie sto­so­wa­nych tak zwa­nych cięż­kich” meto­dyk i bra­ku kom­pe­ten­cji masko­wa­ne­go ilo­ścią doku­men­tów. Nie lubię sło­wa Agile bo czę­sto rodzi wie­le nie­po­trzeb­nych emo­cji, ale ana­li­zy też powin­ny być zwin­ne”, rzecz w tym, by z peł­ne­go arse­na­łu narzę­dzi i dia­gra­mów wybrać tyl­ko te, któ­re pro­wa­dzą do celu a celem jest obni­że­nie ryzy­ka pro­jek­tu a nie wytwo­rze­nie doku­men­ta­cji. Już poja­wi­ły się Agile RUP itp… Ja cały czas trak­tu­ję (poza pra­ca­mi badaw­czy­mi) T&M jako sku­tecz­ny spo­sób na bra­ki kom­pe­ten­cji pro­jek­to­wych po obu stro­nach pro­jek­tu (głów­nie pro­jek­to­wa­nie i pla­no­wa­nie), bo nie­ste­ty czę­sto tak­że Klient moc­no przy­kła­da rękę do poraż­ki swo­je­go pro­jek­tu. Z mojej per­spek­ty­wy szko­dli­we jest to, że fir­my pro­gra­mi­stycz­ne podej­mu­ją się pro­jek­tu widząc już na począt­ku sła­bość klien­ta”. Rozumiem że muszą” mieć przy­cho­dy, ale czy aby na pew­no za wszel­ka cenę”?

  8. Jacek Rybicki 4 października 2012 at 19:23

    Jak słyszę/czytam Agile, to mam dresz­cze. Zwłaszcza to pisa­ne z dużej lite­ry czy wyma­wia­ne z emfa­zą. Zainteresowałem się tema­tem kil­ka lat temu i zdą­ży­łem już się dowie­dzieć, żę nie jest waż­ne czy ster­ta rze­czy do zro­bie­nia to bac­klog, a nawet czy kon­trakt jest T&M czy FP. A na pew­no nie chcę brać udzia­łu w dys­ku­sji pod tytu­łem czy to jest agi­le?”. To jest dla mnie przy­kład nie­wła­ści­wie posta­wio­ne­go pytania.

    Problem z T&M mam taki, że pocią­ga za sobą kosz­tow­ne koro­wo­dy z pod­cho­da­mi kto tu się bar­dziej wysta­wia”. Lepszym roz­wią­za­niem wyda­je mi się cost plus, czy­li T&M z bonu­sem zapew­nia­ją­cym zysk dla dostaw­cy. Wtedy stra­te­gia prze­grać wszyst­ko albo wygrać wszyst­ko zamie­nia się na nie stra­cić albo wygrać jesz­cze wię­cej. Bo zamiast dostaw­cy wypeł­nia­ją­ce­go dokład­nie warun­ki zamó­wie­nia (i czę­sto nie mają­ce­go moty­wa­cji do zro­bie­nia cze­goś lepiej niż zamó­wio­no) dosta­je­my dostaw­cę dążą­ce­go jak naj­szyb­ciej do wspól­ne­go celu.

    • Jarek Żeliński 4 października 2012 at 19:54

      Ta stra­te­gia, T&M i bonus wyda­je się być sen­sow­na bo obie stro­ny mają moty­wa­cję. Ryzyko jakie widzę cza­sa­mi pole­ga na tym, że Klient czę­sto nie ma kom­pe­ten­cji by mery­to­rycz­nie nad­zo­ro­wać wyko­naw­cę więc musi pole­gać na jako­ści pra­cy i ety­ce wyko­naw­cy. Jak bume­rang wra­ca temat nad­zo­ru autor­skie­go, brzy bra­ku pier­wot­ne­go pro­jek­tu nad­zór już nie jest autor­ski” a jedy­nie mery­to­rycz­ny… ale każ­da dro­ga pod­nie­sie­nia jako­ści jest słusz­na. Myślę, że gene­ral­nie pro­blem ten doty­czy nie­uczci­wych firm… po obu stro­nach bary­ka­dy zresztą.

Dodaj komentarz

Twój adres email nie zostanie opublikowany

Komentuj i zadawaj pytania autorowi.

Identyfikator *
E-mail *
Witryna internetowa

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.