Pod arty­ku­łem Plansza do gry w sza­chy, zna­lazł się mię­dzy inny­mi taki komentarz:

Kolejna kwe­stia to taka, że nie widzę war­to­ści w tak nisko­po­zio­mo­wej ana­li­zie. Diagram dzie­dzi­ny i ilu­stra­cja Inicjacji gry są nie­zro­zu­mia­łe dla mnie jako laika i tak samo będą nie­zro­zu­mia­łe dla moje­go klien­ta. Nie wiem więc cze­mu dokład­nie słu­żą i co wnoszą.

Powyższe to typo­we podej­ście zama­wia­ją­ce­go lub (i) spon­so­ra pro­jek­tu. To co tu teraz napi­szę, to abso­lut­nie nie jest kry­ty­ka auto­ra powyż­szej wypo­wie­dzi. To ste­reo­ty­po­we, stan­dar­do­we podej­ście wie­lu zama­wia­ją­cych (i nie raz ich pośred­ni­ków) sys­te­my IT: sam zama­wiam i sam odbieram.

To trosz­kę tak, jak by pod­miot inwe­stu­ją­cy w biu­ro­wiec w cen­trum mia­sta sam podej­mo­wał się oce­ny doku­men­ta­cji tech­nicz­nej wyko­na­nej przez archi­tek­ta, algo gorzej: uznał, że sko­ro tej doku­men­ta­cji nie rozu­mie to jej po pro­tu nie chce! Paradoksalnie, powyż­sze podej­ście to naj­częst­sza przy­czy­na pora­żek pro­jek­tów (budow­nic­two wypra­co­wa­ło praw­ne zasa­dy, IT się jesz­cze bro­ni gło­sa­mi dostawców).

W czym pro­blem? Dokładnie w tym, z czym spo­ty­ka­my się kupu­jąc samo­chód: kupu­ją­cy uwa­ża, że rozu­mie to co widzi i cze­go potra­fi użyć (przy­po­mnę, że każ­dy kie­row­ca uży­wa w samo­cho­dzie skrzy­ni bie­gów ale nie każ­dy rozu­mie jej dzia­ła­nie). Pokazanie (opi­sa­nie) w salo­nie, jaki samo­chód jest nam potrzeb­ny, to góra kil­ka godzin. Przekonanie się o tym, co na praw­dę kupi­li­śmy, to już co naj­mniej kil­ka­set (a nie raz kil­ka tysię­cy) prze­je­cha­nych kilo­me­trów. Prawdę o tym co kupi­li­śmy powie nam dopie­ro mecha­nik po zaku­pie, jest to jed­nak za póź­no na zmia­ny. Kto z Państwa sko­rzy­stał z pora­dy dobre­go mecha­ni­ka przed zaku­pem samo­cho­du? Pamiętajmy, że samo­chód to tysią­ce współ­pra­cu­ją­cych pod­ze­spo­łów, któ­re z nich zna­cie, rozu­mie­cie i widzi­cie? A wszyst­kie mają wpływ na walo­ry użyt­ko­we samochodu.

Projekty IT wyglą­da­ją bar­dzo podob­nie, mało kto – przed wybo­rem dostaw­cy opro­gra­mo­wa­nia – pła­ci za ana­li­zę, pra­wie nikt za pro­jekt, któ­re­go nie rozu­mie, ale pra­wie każ­dy sam zama­wia (opi­su­jąc cza­sem jakieś swo­je wyma­ga­nia) i nie­ste­ty pra­wie każ­dy pro­jekt (przy­po­mnę, że to ponad 75%) to kło­po­ty dla kupu­ją­ce­go i na koszt kupującego.

Odpowiedź na zarzut cytowany na początku

W pro­jek­tach ana­li­tycz­nych mamy trzy klu­czo­we eta­py: ana­li­za, pro­jek­to­wa­nie oraz wytwo­rze­nie. Analiza to coś co zro­zu­mie każ­dy zama­wia­ją­cy, bo jej efek­tem jest opis jego wła­snej dzia­łal­no­ści. Powstaje po to, by nikt nie miał wąt­pli­wo­ści jaki jest biz­ne­so­wy cel pro­jek­tu i jak będzie on reali­zo­wa­ny (ale celem biz­ne­so­wym pro­jek­tu nie jest zakup opro­gra­mo­wa­nia!, to jeden z moż­li­wych spo­so­bów jego reali­za­cji). W mię­dzy­cza­sie powsta­je model pro­ce­so­wy, to doku­ment dla ana­li­ty­ka. Celem jego two­rze­nia jest mini­ma­li­za­cja ryzy­ka nie­kom­plet­no­ści i nie­spój­no­ści pro­jek­tu i doku­men­ta­cji wyma­gań. Nie jest praw­dą, że zama­wia­ją­cy ma tu coś do spraw­dze­nia, ale praw­da jest, że zama­wia­ją­cy bie­rze udział w jego testo­wa­niu (spraw­dze­niu popraw­no­ści). Model pro­ce­sów to for­mal­ny opis wyma­ga­ją­cy już pew­nej wiedzy. 

Podstawowym błę­dem jaki popeł­nia­ją zle­ce­nio­daw­cy ana­liz, jest pró­ba for­so­wa­nia zmian w mode­lach w rodza­ju ​„pro­szę mi dopi­sać jesz­cze, że cza­sa­mi ten doku­ment tra­fia do…”. 

Model to pew­na for­mal­na struk­tu­ra. Model gry w sza­chy to sza­chow­ni­ca, bier­ki i regu­ły gry, a nie set­ki godzin fil­mów nakrę­co­nych pod­czas roz­gry­wa­nia real­nych par­tii. Niestety więk­szość widzi i podzi­wia roz­gry­wa­ne par­tie i ocze­ku­je fil­mu, jed­nak opro­gra­mo­wa­nie BigBlue (kom­pu­ter z tym pro­gra­mem wygrał w sza­chy z mistrzem świa­ta) to nie tysią­ce zapi­sa­nych par­tii gry, a pro­gram mają­cy zaim­ple­men­to­wa­ne regu­ły gry… nie­ste­ty tak to wygląda.

Analityk może oddać jako wyma­ga­nie tak­że prze­te­sto­wa­ny pro­jekt logicz­ny opro­gra­mo­wa­nia. Wtedy wyma­ga­na jest tak­że zgod­ność zacho­wa­nia się opro­gra­mo­wa­nia z tą logi­ką. Po co? By wyeli­mi­no­wać ryzy­ka, któ­rych źró­dłem jest nie­zro­zu­mie­nie biz­ne­su zama­wia­ją­ce­go przez deve­lo­pe­ra (to zresz­tą nie jego rola), oraz ryzy­ka zwią­za­ne z budo­wa­niem mar­ży po stro­nie wyko­naw­cy (uprasz­cza­nie pro­jek­tu w celu obni­że­nia pracochłonności).

Istnieje nie­ste­ty tak­że bar­dzo duże ryzy­ko, któ­re­go źró­dłem jest sto­so­wa­nie sta­rych, struk­tu­ral­nych metod wytwa­rza­nia opro­gra­mo­wa­nia czy­li ​„roz­biór” (i pro­jekt) sys­te­mu na bazę danych i pro­ce­du­ry. Ta prak­ty­ka (meto­da) nie­ste­ty daje jako efekt opro­gra­mo­wa­nie bar­dzo kosz­tow­ne w pro­jek­to­wa­niu i roz­wo­ju. Od metod struk­tu­ral­nych znacz­nie lep­sze są meto­dy obiek­to­we, nie­ste­ty samo dekla­ro­wa­nie korzy­sta­nia z .NET czy Java albo nota­cji UML nie czy­ni sto­so­wa­nych metod obiektowymi.

Metody zwin­ne, to być może dosko­na­łe meto­dy pra­cy w pro­jek­tach zwią­za­nych ze spo­łecz­no­ścio­wy­mi stro­na­mi WWW, ale w pro­jek­tach biz­ne­so­wych nie­ste­ty są to meto­dy tak­że bar­dzo kosz­tow­ne i nie­prze­wi­dy­wal­ne, dla­te­go pro­jek­ty zwin­ne to bar­dzo rzad­ko pro­jek­ty o usta­lo­nym w umo­wie zakre­sie (opis tego co ma powstać). Po lewej stro­nie (dia­gram ze stron pew­ne­go deve­lo­pe­ra) typo­wa ​„zwin­na” pro­ce­du­ra two­rze­nia opro­gra­mo­wa­nia: usu­wa­nie przez deve­lo­pe­ra błę­dów pro­jek­tu (szcze­gól­nie doty­czą­cych reali­zo­wa­nej logi­ki biz­ne­so­wej) może być pętlą nie­skoń­czo­ną, któ­rą tyl­ko wyczer­pa­nie budże­tu lub gra­nicz­ny ter­min jest w sta­nie zatrzy­mać, co może nie dać w efek­cie żad­ne­go przy­dat­ne­go produktu.

Na koniec ku prze­stro­dze cytat pew­ne­go użyt­kow­ni­ka systemu: 

Niestety źle dobra­ny sys­tem infor­ma­tycz­ny, mają­cy wspierać/automatyzować czyn­no­ści w pro­ce­sie, może być powo­dem powsta­nia całych pod­ręcz­ni­ków pro­ce­dur nie­uza­sad­nio­nych biz­ne­so­wo, dedy­ko­wa­nych użyt­kow­ni­kom tego sys­te­mu, stwa­rza­jąc przy tym pozo­ry, że to sam pro­ces jest ich źródłem 🙁

Niestety tak się czę­sto koń­czą pro­jek­ty, w któ­rych pomię­to ana­li­zę i pro­jek­to­wa­nie i od razu wybra­no dostaw­cę i pro­dukt (ana­li­za wyko­na­na przez dostaw­ce to raczej ​„jak wdro­żyć to co mamy” a nie ​„jak roz­wią­zać pro­blem użytkownika”).

Problemem więk­szo­ści pro­jek­tów IT jest zało­że­nie, że tyl­ko dostawca/wykonawca usłu­gi ma wie­dzę o tym jak to zro­bić. Tezę tę for­su­ją naj­czę­ściej wła­śnie wyko­naw­cy (deve­lo­pe­rzy), a pro­blem pole­ga na tym, że wyko­naw­ca dąży tu do sytu­acji, w któ­rej sam sobie sta­wia wyma­ga­nia a potem roz­li­cza ich reali­za­cję. 

Wykonanie ana­li­zy wyma­gań wła­sny­mi zaso­ba­mi (kupu­ją­ce­go) z regu­ły daje złe efek­ty, powo­dem są zbyt sil­ne zależ­no­ści wła­snych pra­cow­ni­ków mię­dzy sobą i ich zależ­ność od aktu­al­nie posia­da­nych zaso­bów. Do tego docho­dzi brak obiek­ty­wi­zmu i obcią­że­nie do zacho­wa­nia wła­snej pozycji.