Ten arty­kuł to nie zamie­rzo­na kon­ty­nu­acja poprzed­nie­go. Coraz czę­ściej utoż­sa­miam ana­li­zę z pro­jek­tem gdyż w sumie pro­duk­tem ana­li­zy jest jakiś pro­jekt czy­li model tego co ana­li­zo­wa­no, model tego co reko­men­du­ję by powsta­ło. Analiza sama z sie­bie nie jest samo­wy­star­czal­na (to zna­czy samo ana­li­zo­wa­nie nie jest war­to­ścio­wym pro­duk­tem samym w sobie). Problemy z pro­jek­ta­mi obser­wu­je nie ja jeden. W każ­dym kolej­nym pro­jek­cie sta­ram się szu­kać przy­czyn, zro­zu­mieć pro­blem i pod­jąć pró­bę roz­wią­za­nia. Problem w zasa­dzie jest zna­ny. Autor pew­ne­go blo­ga, pisze:

Chciałoby się powie­dzieć, żeby zro­bić coś dobrze trze­ba wie­dzieć dokład­nie co się robi. Być może taka praw­da spraw­dza się w pew­nych dzie­dzi­nach życia? Niestety jed­nak w świe­cie opro­gra­mo­wa­nia naj­czę­ściej nie mamy tego luk­su­su, aby widzieć cały obra­zek na począt­ku. Większość pro­jek­tów IT, nie­za­leż­nie od przy­ję­tej meto­do­lo­gii, zaczy­na się od roz­mów z ?klien­tem? (któ­ry w szcze­gól­nych przy­pad­kach może być oso­bą, któ­ra two­rzy softwa­re sama dla sie­bie). Wszystko po to, aby dowie­dzieć się, o co cho­dzi w tym pro­jek­cie, jaki jest cel, jakie mają być funk­cje i kto ma tego uży­wać. […] Jeśli zro­bi­my super ana­li­zę na począt­ku (upfront) i się w niej zamknie­my, to nisz­czy­my pro­jekt zanim się jesz­cze na serio roz­pocz­nie. Potem jest już tyl­ko gorzej.

Ma wie­le racji. Po pierw­sze wie­dza ​„co nale­ży zro­bić” jest bez­cen­na :). Pytanie brzmi, dla­cze­go nie mamy tego luk­su­su? Kluczem jest tu chy­ba zda­nie ​„Większość pro­jek­tów IT, nie­za­leż­nie od przy­ję­tej meto­do­lo­gii, zaczy­na się od roz­mów z ?klien­tem?”. Niewątpliwie nale­ży zapy­tać zama­wia­ją­ce­go po co mu to, ale nie jestem pewien czy nale­ży go pytać ​„jak mamy to wyko­nać”. W koń­cu to lekarz po wywia­dzie i bada­niach wypi­su­je recep­tę pacjen­to­wi a nie odwrotnie.

Kolejny pro­blem wie­lu pro­jek­tów to szcze­gó­ło­wość wyma­gań i spo­sób prze­ka­za­nia tych szcze­gó­łów. Autor słusz­nie pisze:

Specyfikacja wyma­gań i ogól­nie wstęp­na wizja sys­te­mu wyso­kiej jakość powin­na więc być lek­ka. Możliwie spój­na i kom­plet­na, popar­ta fak­ta­mi i bada­nia­mi ? ale przede wszyst­kim lek­ka. Zarówno meta­fo­rycz­nie (czy­li nie sta­wia cięż­kich, twar­dych ogra­ni­czeń) jak i dosłow­nie (jest lek­ka, czy­li krót­ka). Oczywiście moż­na pole­mi­zo­wać ? jeśli jed­nak jesteś bar­dzo moc­no przy­wią­za­ny do budo­wa­nia zaawan­so­wa­nych for­ma­li­za­cji wstęp­nych wyma­gań do sys­te­mu, to znajdź taki doku­ment z toczą­ce­go się pro­jek­tu i porów­naj go z tym co sta­ło się w pro­jek­cie po 6, 9 albo 12 mie­sią­cach. Ciekawy jestem czy cokol­wiek zga­dza się z pier­wot­nym obraz­kiem. Wątpię.

Nie wiem w jakim zna­cze­niu autor użył sło­wa ​„for­ma­li­za­cja”, mam nadzie­ję, że miał na myśli zawar­tość opa­słych doku­men­ta­cji i ich obo­wiąz­ko­wo wypeł­nia­ne­go spi­su tre­ści (nawet jeże­li w danym przy­pad­ku ist­nie­nie jakie­goś pod­roz­dzia­łu jest kom­plet­nie bez sen­su). Niedawno spo­tka­łem się z zarzu­tem poten­cjal­ne­go klien­ta: ​„To co Pan nam pre­zen­tu­je ma za mało szcze­gó­ło­we”. Większość ludzi (klien­ci opro­gra­mo­wa­nia) szer­mu­je twier­dze­niem, że dia­beł tkwi w szcze­gó­łach, w związ­ku z tym nale­ży jest wszyst­kie spi­sać. Problem w tym, że szcze­gó­ły szcze­gó­łom nie­rów­ne. Jedne doty­czą tego nad czym się pra­cu­je a inne tego jak to robi­my. Te dru­gie są tu para­dok­sal­nie mało istot­ne, gdyż to ​„jak to robi­my” to robi­my MY a nie SYSTEM. Po sie­ci krą­żą spe­cy­fi­ka­cje na sys­te­my ERP mają­ce nawet ponad 6 tys, cech! Po pierw­sze nikt tego potem nie czy­ta, po dru­gie znacz­na więk­szość jest igno­ro­wa­na w przy­pad­ku wdro­że­nia sys­te­mu goto­we­go i zmie­nia­na w przy­pad­ku pro­jek­to­wa­ne­go. I tu zga­dzam się z auto­rem: mier­ni­kiem jako­ści doku­men­ta­cji wyma­gań jest jej zgod­ność z tym co fak­tycz­nie zosta­ło dostarczone!

Nauczeni doświad­cze­niem z pra­cy z klien­tem, któ­ry jest w sta­nie zmie­nić zda­nie 3 razy w cza­sie jed­nej roz­mo­wy ? musi­my tą obiek­tyw­ną rze­czy­wi­stość odzwier­cie­dlić w architekturze.

Tu moja uwa­ga: po pierw­sze Klient musi mieć na każ­dym kro­ku świa­do­mość swo­jej roli w pro­jek­cie: nie jest jego pro­jek­tan­tem a przy­szłym użyt­kow­ni­kiem. Innymi sło­wy rolą Zamawiającego jest ​„zama­wia­nie funk­cji sys­te­mu” a nie ich reali­za­cji (ale doku­ment powi­nien zawie­rać logi­kę dzia­ła­nia – to jed­nak ele­ment dome­ny, dalej o niej). Po dru­gie Klient powi­nien brać aktyw­ny udział w pro­jek­cie, mam tu na myśli powi­nie pono­sić kon­se­kwen­cje wpro­wa­dza­nych zmian na rów­ni z wykonawcą.

Ale wezmę tak­że Klienta w ochro­nę: Klient nie zna się na inży­nie­rii opro­gra­mo­wa­nia i ma do tego pra­wo. Kluczem jest ana­li­za zakoń­czo­na pro­jek­tem a nie tyl­ko ​„ana­li­za” bo ona sama z sie­bie fak­tycz­nie jest nie raz jakimś ​„papie­ro­wym potwo­rem”. Jaki pro­jekt powi­nien powstać?

Użytkownik czy­li nasz Klient, to oso­ba, kto­ra uży­je tego opro­gra­mo­wa­nia do zre­ali­zo­wa­nia jakie­goś dzia­ła­nia, dla­te­go z jego per­spek­ty­wy mówi się o Przypadku Użycia. Nasz System nale­ży zapro­jek­to­wać, więc ana­li­za powin­na dać Projekt jako pro­dukt. Ale po kolei. Użytkownik wyar­ty­ku­ło­wał swo­je wyma­ga­nie czy­li do cze­go chce użyć sys­te­mu, czy­li to jakich efek­tów ocze­ku­je. Może być wyma­ga­ne jesz­cze to co ​„da od sie­bie” (dane). Za to odpo­wia­da Interfejs użyt­kow­ni­ka, stan ekra­nu przed i po pra­cy. W zasa­dzie jest to, okre­śle­nie tego, robo­ta dla Zamawiającego (np. poda­je dane do fak­tu­ry i otrzy­mu­je popraw­ną fakturę).

Dalej mamy dwa klu­czo­we ele­men­ty: jak nale­ży to zro­bić i czym to coś jest. Tu dodam: są to roz­dziel­ne ele­men­ty! Autor cyto­wa­ne­go blo­ga pisze:

Architektura wyso­kiej jako­ści powin­na więc od począt­ku zakła­dać tę płyn­ność. Mamy do dys­po­zy­cji mnó­stwo wspa­nia­łych narzę­dzi ? takich jak wzor­ce pro­jek­to­we, inte­gra­cyj­ne, dobre prak­ty­ki czy mode­lo­we roz­wią­za­nia. Co wię­cej, w parze z archi­tek­tu­rą idzie z regu­ły usa­do­wie­nie jej w jakiejś kon­kret­nej tech­no­lo­gii, któ­ra dodat­ko­wo narzu­ca pew­ne podej­ścia i kon­cep­ty. To wszyst­ko jest dobre i im lepiej zro­zu­mie­my narzę­dzia, któ­re mamy do dys­po­zy­cji, tym lepiej. Ale, podob­nie jak w przy­pad­ku spe­cy­fi­ka­cji ? im bar­dziej się utwar­dzi­my i zamknie­my w jed­nej, nie­zmien­nej archi­tek­tu­rze, tym gorzej.

Ta ​„dobra” archi­tek­tu­ra, tak mi mówi moje doświad­cze­nia z wzor­ca­mi i nie tyl­ko, powin­na roz­dzie­lać inter­fejs użyt­kow­ni­ka od tak zwa­ne­go mode­lu dzie­dzi­ny czy­li mode­lu spe­cy­fi­ki fir­my. Tu raczej nicze­go nowe­go nie powie­dzia­łem. Ale dalej: w mode­lu dzie­dzi­ny nale­ży oddzie­lić spe­cy­fi­kę pro­jek­tu od tego cze­go on doty­czy (tego nie­ste­ty raczej nie zro­bi deve­lo­per, dla nie­go to wszyst­ko jed­no). Dlatego nale­ży wydzie­lić w pro­jek­cie obiekt o nazwie CośRzeczywistego. To dru­gie to coś co ma postać nie­za­leż­ną od orga­ni­za­cji klien­ta. Zaryzykuje tezę, że to jest coś co sta­no­wi w takim pro­jek­cie jego więk­szość (są tezy, że pare­tow­skie 80%).

Tak więc rolą Analityka jest zbu­do­wać wła­śnie taki model (pro­jekt). Dlaczego Analityk? A kto inny ma to wszyst­ko wie­dzieć i opi­sać, sko­ro tyl­ko on sie­dzi na począt­ku u klienta?

Mój dia­gram nie zawie­ra ​„kon­kret­nej tech­no­lo­gii, któ­ra dodat­ko­wo narzu­ca pew­ne podej­ścia”, gdyż w moich oczach, jed­nym z więk­szych błę­dów jest wybór tech­no­lo­gii zanim dowie­my się co nale­ży zro­bić. Niestety wybór tech­no­lo­gii to nic inne­go jak przed­wcze­sny wybór wyko­naw­cy (z regu­ły każ­dy spe­cja­li­zu­je się w jakiejś). Mój dia­gram dla uprosz­cze­nia nie zawie­ra tak­że wyma­gań jako­ścio­wych (ogra­ni­czeń, wyma­ga­nia poza-funk­cjo­nal­ne). Każda tech­no­lo­gia ma swo­je ogra­ni­cze­nia. Przedwczesny wybór wyko­naw­cy to nic inne­go jak z góry nało­żo­ne ogra­ni­cze­nia na pro­dukt, nie koniecz­nie zgod­ne z naszymi.

Dalej mamy same dobre rady, z któ­ry­mi trud­no polemizować:

Wysoka modu­lar­ność, współ­pra­ca wie­lu nie­za­leż­nych, lub luź­no powią­za­nych ele­men­tów, moż­li­wość wymia­ny małych czę­ści, lub two­rze­nie róż­nych warian­tów tego same­go modu­łu, to podej­ścia, któ­re przy­nio­są nam war­tość doda­ną. Ludzie mają­cy do czy­nie­nia z mono­li­ta­mi (układ: jed­na wiel­ka baza danych i do tego wiel­ki ser­wer apli­ka­cyj­ny) z regu­ły postrze­ga­ją podej­ście roz­pro­szo­ne (dzie­siąt­ki lub set­ki małych kawał­ków fru­wa­ją­cych gdzieś w koło) jako trud­niej­sze, bar­dziej skom­pli­ko­wa­ne i przez to gor­sze i bar­dziej ryzy­kow­ne. Takie spoj­rze­nie to posta­wie­nie spra­wy do góry nogami.

I tu moim zda­niem autor ma 100% racji. Nie ma chy­ba nic gor­sze­go niż uzna­nie, że ​„jeden wiel­ki zin­te­gro­wa­ny sys­tem” to zale­ta tego Systemu, jest to jego naj­więk­sza wada.

Czytamy dalej:

Wciąż są miej­sca, w któ­rych pro­wa­dzi się wiel­ki ?up-front design? z głę­bo­ką wia­rą w jego suk­ces. A pro­blem w tym, że nie moż­na mówić o suk­ce­sie czy poraż­ce rze­czy, któ­ra w cało­ści jest fik­cją. Słyszałem nie raz skar­gi pro­gra­mi­stów i kie­row­ni­ków, że naj­więk­szą bolącz­ką pro­jek­tu są zmien­ne wyma­ga­nia. Nie raz chcia­ło mi się powie­dzieć ? ?jak­że wiel­kie szczę­ście macie, że klient zmie­nił wyma­ga­nia, bo prze­cież były bez sensu!?.

I tu moja uwa­ga: zmien­ne wyma­ga­nia mają dwa źró­dła: uzna­nie, że to klient jest ich auto­rem a nie ana­li­tyk (przy­po­mi­nam pacjent, recep­ta i lekarz). Drugie źró­dło to pla­no­wa­nie wyma­gań i pro­jek­tu na okres dłuż­szy niż rok (oko­ło). Wiele wyma­gań ma swo­je źró­dło w ​„aktu­al­nej sytu­acji”, dla­te­go szcze­gó­ło­wy Projekt z Ręki Analityka i zakres pro­jek­tu dla deve­lo­pe­ra powi­nien obej­mo­wać tyl­ko tak zwa­ny quasi-sta­bil­ny okres dla fir­my. Wszystko to co jest pla­no­wa­ne ​„bar­dziej w przy­szłość” jest w zasa­dzie z góry ska­za­ne na zmia­ny więc po co to szcze­gó­ło­wo pro­jek­to­wać i planować?

A teraz małe ćwi­cze­nie na koniec: po jakie­go więc grzy­ba ogła­sza­ne są prze­tar­gi na wie­lo­let­nie pro­jek­ty? Ich mizer­ne efek­ty są odpo­wie­dzią… A po co pla­no­wać zakup wiel­kie­go ERP i wdro­że­nie na lata? Tu nie­ste­ty dzien­ni­ka­rze nie mają takiej swo­bo­dy w opi­sie efek­tów jak to ma miej­sce w przy­pad­ku pie­nię­dzy wyda­wa­nych publicznie…a żałuj­cie Państwa…

P.S.

Cytaty pocho­dzą ze stro­ny Czym jest jakość opro­gra­mo­wa­nia? ? Trzecia kawa.

Polecam tak­że cie­ka­wy arty­kuł: Touching the Void: Kilka spraw, o któ­rych powi­nien wie­dzieć ana­li­tyk.