Wiedza to wszyst­ko to co wie­my 🙂 (tru­izm). Pytając kogoś o dro­gę może­my usły­szeć: idź pro­sto dro­gą przez las, za samot­ną brzo­zą skręć w lewo a potem kie­ruj się na wie­żę ratu­sza i doj­dziesz do mia­sta. Tak powie czło­wiek, któ­ry zna mój cel podró­ży: wie gdzie idę oraz wie któ­rę­dy iść (wie­dza). Ma to miej­sce wte­dy, gdy czło­wiek ten, prze­szedł tę dro­gę co naj­mniej raz, zaś kolej­na podróż, tu moja, ma ten sam cel i odby­wa się w tych samych warun­kach. Może się jed­nak oka­zać, że napo­tka­ny nie zna celu bo jesz­cze tam nie był, jed­nak wie­le podró­żu­je i zna ​„lasy i doli­ny”, rozu­mie las i radzi sobie dobrze nawet w tym lesie, któ­ry widzi pierw­szy raz. Mimo, że nie był u celu, któ­ry jest naszym celem, ma doświad­cze­nie i też ma dużą wie­dzę ale inną: to jest tak zwa­ny [[survi­val]] czy­li też wie­dza (w tym doświad­cze­nie) ale nie­co inna. (kto był har­ce­rzem i brał udział w bie­gach na orientację?).

Przeżycie w lesie wyma­ga nie tyl­ko wie­dzy o tym co robić ale tak­że o tym cze­go nie robić. Ta dru­ga zresz­tą – para­dok­sal­nie – bywa cen­niej­sza, bo nie raz ratu­je życie. Wchodząc do lasu zapew­ne nie dowie­my się jakie zwie­rzę­ta spo­tka­my ale doświad­czo­ny wędrow­ca powiem nam ​„nie doty­kaj kolo­ro­wych węży” bo wie, że te są z regu­ły bar­dzo jado­wi­te. Jak nazwie­my wte­dy zacze­pia­nie każ­de­go kolo­ro­we­go stwo­rze­nia w lesie? Jest to antyw­zo­rzec postę­po­wa­nia – ich zna­jo­mość, antyw­zor­ców, to tak­że cen­na wiedza.

Skąd się bio­rą antyw­zor­ce? Jak się nie trud­no domy­śleć, naj­czę­ściej nie z wła­sne­go doświad­cze­nia a z cudze­go. Owszem same­mu tak­że moż­na się popa­rzyć i prze­żyć, ale znacz­nie bez­piecz­niej jest prze­czy­tać kil­ka razy o popa­rze­niach, zro­zu­mieć dla­cze­go do nich ​„wte­dy” doszło, i same­mu omi­jać ​„oka­zje” do popa­rzeń. Jednak omi­ja­nie nie ozna­cza ​„nic­nie­ro­bie­nie”, a nie robie­nie tego co pro­wa­dzi (z dużym praw­do­po­do­bień­stwem) do poparzeń.

Zapewne w tym momen­cie ode­zwą się piew­cy dość zna­ne­go cytatu:

?Wszyscy wie­dzą, że cze­goś nie da się zro­bić, i przy­cho­dzi taki jeden, któ­ry nie wie, że się nie da, i on wła­śnie to robi.? (Albert Einstein)

Jednak sło­wa te nie mają nic wspól­ne­go z tym co się czę­sto Einsteinowi tu przy­pi­su­je i o czym ja tu piszę. Ja piszę o antyw­zor­cach a Einstein o rezy­gna­cji z nie­wie­dzy. Antywzorzec to ​„wzór” postę­po­wa­nia pro­wa­dzą­ce­go (z dużym praw­do­po­do­bień­stwem) do poraż­ki. Rezygnacja to zwy­kłe zanie­cha­nie, któ­re­go przy­czy­ną jest czę­sto nie­wie­dza (lub strach).

Klasyczną sytu­acją uży­cia antyw­zor­ca jest ta, w któ­rej ktoś sto­su­je w swo­im pro­jek­cie ​„wzo­rzec” postę­po­wa­nia dają­cy 80% szans na poraż­kę. Einstein zaś pisze o kimś, kto jest prze­ko­na­ny, że coś jest nie­moż­li­we i z tego powo­du nie podej­mu­je się tego. W nauce nie­ma rze­czy ​„nie­moż­li­wych”, są jedy­nie ​„jesz­cze nie­zro­zu­mia­ne”. To prze­ko­na­nie w praw­dzi­wej nauce powo­du­je, że nauko­wiec nie zanie­cha, jed­nak nie nale­ży tego mylić z postę­po­wa­niem niemądrym.

Czym jest więc ten Antywzorzec, o któ­rym chcę dziś napisać? 

W pro­jek­tach z dzie­dzi­ny IT zna­na jest sta­ty­sty­ka mówią­ca, że ok. 70% pro­jek­tów to klę­ski czy­li nie­do­trzy­ma­ne ter­mi­ny, prze­kro­czo­ne budże­ty i nie­zre­ali­zo­wa­ne pla­ny, a są rapor­ty mówią­ce nawet o 80%. Tak więc jaki jest ten antyw­zo­rzec? Znamy go z badań ankie­to­wych – meto­dy pra­cy jakie sto­so­wa­no w nie­uda­nych pro­jek­tach. Oto on – Antywzorzec ana­li­zy biznesowej:

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. […]

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 klientów).

Z dru­giej stro­ny pewien zna­jo­my, współ­wła­ści­ciel pew­nej fir­my pro­gra­mi­stycz­nej, napi­sał mi niedawno:

?korzy­ści z takie­go [sfor­ma­li­zo­wa­ne] 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 (Raport Jama Sofware ? O wyma­ga­niach).

Jak wiec brzmi recep­ta na porażkę:

Wymagania zbie­raj wyłącz­nie jako efekt burz mózgów i wywia­dów z przy­szły­mi użyt­kow­ni­ka­mi oraz ich prze­ło­żo­ny­mi, niech wszy­scy spi­szą je w posta­ci tabe­li np. w arku­szu kal­ku­la­cyj­nym i edy­to­rze tek­stu. Organizuj dłu­gie spo­tka­nia warsz­ta­to­we, po któ­rych powsta­ją kolej­ne wier­sze w tych tabe­lach i zmie­nia­ne są już wcze­śniej zapi­sa­ne. Wszystkie dodat­ko­we usta­le­nia zała­twiaj mailem ad-hoc. Tak powsta­łą tabe­lę nazwij Wymagania i daj do realizacji. 

Projekty infor­ma­tycz­ne w fir­mach to zawsze nowy cel i nowa dro­ga ale dobrze zna­ne śro­do­wi­sko pro­jek­to­we. Dlatego wzor­ce jak naj­bar­dziej mają sens, ale nie recep­ty bo te tu nie mają zasto­so­wa­nia. Antywzorce, hm…, zna­my sta­ty­sty­ki i mimo to sta­le podej­mo­wa­ne są nowe pro­jek­ty, w któ­rych klu­czo­wą meto­dy­ką pra­cy jest warsz­tat oraz ana­li­tyk-dyk­ta­fon, to czy zapi­su­je­my to jako slaj­dy pre­zen­ta­cji czy z pomo­cą nawet bar­dzo dobre­go narzę­dzia CASE nie ma żad­ne­go zna­cze­nia, jeże­li fak­tycz­nie zapi­su­je­my jedy­nie to, opis i obraz­ki, co podyk­tu­je Święty User.

Na zakoń­cze­nie jed­no zda­nie: poja­wie­nie się metod zwin­nych (rok 2001, Agile Manifesto) nie zmie­ni­ło tej czar­nej sta­ty­sty­ki (a zna­na jest od lat 80-tych) nawet o jotę, więc nic wska­zu­je na to, że są one w czym­kol­wiek lep­sze. Wiadomo zaś, że sto­so­wa­nie metod for­mal­nych jest bar­dzo sku­tecz­ne ale kosz­tow­niej­sze od opi­sa­nych wyżej maili, arku­szy i tek­stów. Jednak jeże­li śred­nie prze­kro­cze­nie kosz­tów pro­jek­tów pro­wa­dzo­nym meto­da­mi nie­sfor­ma­li­zo­wa­ny­mi docho­dzi do 200%, to zna­czy, że jed­nak meto­dy for­mal­ne są per sal­do znacz­nie tań­sze… a są sto­so­wa­ne tam, gdzie ​„ryzy­ko jest duże” a przy­naj­mniej ryzy­ko nie jest igno­ro­wa­ne. Czemu jed­nak tak rzad­ko sto­su­je się meto­dy for­mal­ne? Bo jest róż­ni­ca pomię­dzy wie­dzieć a umieć… Jeżeli więc ktoś mówi, ​„nie rób tego tak, bo to się raczej nie uda” (powyż­sze sta­ty­sty­ki) to war­to tego posłu­chać i zapy­tać o pozo­sta­łe 20% bar­dziej uda­nych projektów.

W kwe­stii humo­ru pro­po­nu­je lek­tu­rę Cynical Agile and Scrum Dictionary.

P.S.

2013-03-17, wpadł mi dzi­siaj w oko wpis kole­gi zaj­mu­ją­ce­go się archi­tek­tu­rą kor­po­ra­cyj­ną. Podał inną, nie tak odle­głą od mojej, recep­tę na porażkę ;)):

To naj­czę­ściej depar­ta­ment biz­ne­so­wy chce ?na szyb­ko dowieźć? roz­wią­za­nie IT (mieć tzw. quick-win’a), nie oglą­da­jąc się na ostrze­że­nia pada­ją­ce z ust archi­tek­ta kor­po­ra­cyj­ne­go ? żeby nie robić roz­wią­zań ?wią­za­nych dru­tem?, żeby uwa­żać na stan­dar­dy, żeby prze­strze­gać pryn­cy­piów archi­tek­to­nicz­nych, żeby zgła­szać wszyst­kie zmia­ny i odstęp­stwa od mode­lu doce­lo­we­go ?. I co ? i wów­czas ?biz­nes? patrzy na takie­go archi­tek­ta i mówi ?co za idio­ta?, chce spo­wol­nić pra­ce, unie­moż­li­wia osią­gnię­cie kwar­tal­nych celów itp… Nie słu­cha go, i podej­mu­je decy­zję o wdro­że­niu roz­wią­za­nia IT, nie­zgod­ne­go z przy­ję­tą w orga­ni­za­cji archi­tek­tu­rą, obo­wią­zu­ją­cy­mi stan­dar­da­mi, pryn­cy­pia­mi. Bardzo czę­sto te pra­ce są jesz­cze przy­spie­sza­ne na sku­tek pod­szep­tów dostaw­cy zewnętrz­ne­go, któ­ry mówi tyl­ko ?miłe słów­ka? biz­ne­so­wi ? że archi­tek­ci to hamul­co­wi, że tyl­ko by się dro­czy­li z biz­ne­sem bo chcą udo­wod­nić swo­ją rolę w orga­ni­za­cji, bo my (tj. dostaw­cy) wdro­ży­my takie roz­wią­za­nie 3x szyb­ciej niż mówi to zespół archi­tek­to­nicz­ny i wewnętrz­ne IT. (Przypowieść o kare­cie a pra­ce archi­tek­ta kor­po­ra­cyj­ne­go | Architektura Korporacyjna).