Wiedza to wszystko to co wiemy 🙂 (truizm). Pytając kogoś o drogę możemy usłyszeć: idź prosto drogą przez las, za samotną brzozą skręć w lewo a potem kieruj się na wieżę ratusza i dojdziesz do miasta. Tak powie człowiek, który zna mój cel podróży: wie gdzie idę oraz wie którędy iść (wiedza). Ma to miejsce wtedy, gdy człowiek ten,  przeszedł tę drogę co najmniej raz, zaś kolejna podróż, tu moja, ma ten sam cel i odbywa się w tych samych warunkach. Może się  jednak okazać, że napotkany nie zna celu bo jeszcze tam nie był, jednak wiele podróżuje i zna “lasy i doliny”, rozumie las i radzi sobie dobrze nawet w tym lesie, który widzi pierwszy raz. Mimo, że nie był u celu, który jest naszym celem, ma doświadczenie i też ma dużą wiedzę ale inną: to jest tak zwany [[survival]] czyli też wiedza (w tym doświadczenie) ale nieco inna. (kto był harcerzem i brał udział w biegach na orientację?).

Przeżycie w lesie wymaga nie tylko wiedzy o tym co robić ale także o tym czego nie robić. Ta druga zresztą – paradoksalnie – bywa cenniejsza, bo nie raz ratuje życie. Wchodząc do lasu zapewne nie dowiemy się jakie zwierzęta spotkamy ale doświadczony wędrowca powiem nam “nie dotykaj kolorowych węży” bo wie, że te są z reguły bardzo jadowite. Jak nazwiemy wtedy zaczepianie każdego kolorowego stworzenia w lesie? Jest to antywzorzec postępowania – ich znajomość, antywzorców, to także cenna wiedza.

Skąd się biorą antywzorce? Jak się nie trudno domyśleć, najczęściej nie z własnego doświadczenia a z cudzego. Owszem samemu także można się poparzyć i przeżyć, ale znacznie bezpieczniej jest przeczytać kilka razy o poparzeniach, zrozumieć dlaczego do nich “wtedy” doszło, i samemu omijać “okazje” do poparzeń.  Jednak omijanie nie oznacza “nicnierobienie”, a nie robienie tego co prowadzi (z dużym prawdopodobieństwem) do poparzeń.

Zapewne w tym momencie odezwą się piewcy dość znanego cytatu:

?Wszyscy wiedzą, że czegoś nie da się zrobić, i przychodzi taki jeden, który nie wie, że się nie da, i on właśnie to robi.? (Albert Einstein)

Jednak słowa te nie mają nic wspólnego  z tym co się często Einsteinowi tu przypisuje i  o czym ja tu piszę. Ja piszę o antywzorcach a Einstein o rezygnacji z niewiedzy. Antywzorzec to “wzór” postępowania prowadzącego (z dużym prawdopodobieństwem) do porażki. Rezygnacja to zwykłe zaniechanie, którego przyczyną jest często niewiedza (lub strach).

Klasyczną sytuacją użycia antywzorca jest ta, w której ktoś stosuje w swoim projekcie “wzorzec” postępowania dający 80% szans na porażkę. Einstein zaś pisze o kimś, kto jest przekonany, że coś jest niemożliwe i z tego powodu nie podejmuje się tego. W nauce niema rzeczy “niemożliwych”, są jedynie  “jeszcze niezrozumiane”. To przekonanie w prawdziwej nauce powoduje, że naukowiec nie zaniecha, jednak nie należy tego mylić z postępowaniem niemądrym.

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

W projektach  z dziedziny IT znana jest statystyka mówiąca, że ok. 70% projektów to klęski czyli niedotrzymane terminy, przekroczone budżety i niezrealizowane plany, a są raporty mówiące nawet o 80%. Tak więc jaki jest ten antywzorzec? Znamy go z badań ankietowych – metody pracy jakie stosowano w nieudanych projektach. Oto on – Antywzorzec analizy biznesowej:

83% projektów korzysta z dokumentów tekstowych oraz arkuszy kalkulacyjnych do przechowywania wymagań, 40% projektów korzysta z emaili do zbierania wymagań i komunikacji z klientem. […]

Twierdzenia, że nie da się inaczej, klienci nie wiedzą czego chcą, dokumenty tekstowe to jedyne możliwe opisy wymagań itp. są prostu nie prawdą, to usprawiedliwienia braku kompetencji albo zawyżania kosztów projektów (a raczej pokrywania braku kompetencji pieniędzmi z kieszeni klientów).

Z drugiej strony pewien znajomy, współwłaściciel pewnej firmy programistycznej, napisał mi niedawno:

?korzyści z takiego [sformalizowane] dokumentowania wymagań są ogromne. Wykonawca, który potrafi pracować na modelach ma 2-3 krotnie niższe koszty i 1,5-4 krotnie krótszy czas wykonania (Raport Jama Sofware ? O wymaganiach).

Jak wiec brzmi recepta na porażkę:

Wymagania zbieraj wyłącznie jako efekt burz mózgów i wywiadów z przyszłymi użytkownikami oraz ich przełożonymi, niech wszyscy spiszą je w postaci tabeli np. w arkuszu kalkulacyjnym i edytorze tekstu. Organizuj długie spotkania warsztatowe, po których powstają kolejne wiersze w tych tabelach i zmieniane są już wcześniej zapisane. Wszystkie dodatkowe ustalenia załatwiaj mailem ad-hoc. Tak powstałą tabelę nazwij Wymagania i daj do realizacji. 

Projekty informatyczne w firmach to zawsze nowy cel i nowa droga ale dobrze znane środowisko projektowe. Dlatego wzorce jak najbardziej mają sens, ale nie recepty bo te tu nie mają zastosowania. Antywzorce, hm…, znamy statystyki i mimo to stale podejmowane są nowe projekty, w których kluczową metodyką pracy jest warsztat oraz analityk-dyktafon, to czy zapisujemy to jako slajdy prezentacji czy z pomocą nawet bardzo dobrego narzędzia CASE nie ma żadnego znaczenia, jeżeli faktycznie zapisujemy jedynie to, opis i obrazki, co podyktuje Święty User.

Na zakończenie jedno zdanie: pojawienie się metod zwinnych (rok 2001, Agile Manifesto) nie zmieniło tej czarnej statystyki (a znana jest od lat 80-tych) nawet o jotę, więc nic wskazuje na to, że są one w czymkolwiek lepsze. Wiadomo zaś, że stosowanie metod formalnych jest bardzo skuteczne ale kosztowniejsze od opisanych wyżej maili, arkuszy i tekstów. Jednak jeżeli średnie przekroczenie kosztów projektów prowadzonym metodami niesformalizowanymi dochodzi do 200%, to znaczy, że jednak metody formalne są per saldo  znacznie tańsze… a są stosowane tam, gdzie “ryzyko jest duże” a przynajmniej ryzyko nie jest ignorowane. Czemu jednak tak rzadko stosuje się metody formalne? Bo jest różnica pomiędzy wiedzieć a umieć… Jeżeli więc ktoś mówi, “nie rób tego tak, bo to się raczej nie uda” (powyższe statystyki) to warto tego posłuchać i zapytać o pozostałe 20% bardziej udanych projektów.

W kwestii humoru proponuje lekturę Cynical Agile and Scrum Dictionary.

P.S.

2013-03-17, wpadł mi dzisiaj w oko wpis kolegi zajmującego się architekturą korporacyjną. Podał inną, nie tak odległą od mojej, receptę na porażkę ;)):

To najczęściej departament biznesowy chce ?na szybko dowieźć? rozwiązanie IT (mieć tzw. quick-win’a), nie oglądając się na ostrzeżenia padające z ust architekta korporacyjnego ? żeby nie robić rozwiązań ?wiązanych drutem?, żeby uważać na standardy, żeby przestrzegać pryncypiów architektonicznych, żeby zgłaszać wszystkie zmiany i odstępstwa od modelu docelowego ?. I co ? i wówczas ?biznes? patrzy na takiego architekta i mówi ?co za idiota?, chce spowolnić prace, uniemożliwia osiągnięcie kwartalnych celów itp… Nie słucha go, i podejmuje decyzję o wdrożeniu rozwiązania IT, niezgodnego z przyjętą w organizacji architekturą, obowiązującymi standardami, pryncypiami. Bardzo często te prace są jeszcze przyspieszane na skutek podszeptów dostawcy zewnętrznego, który mówi tylko ?miłe słówka? biznesowi ? że architekci to hamulcowi, że tylko by się droczyli z biznesem bo chcą udowodnić swoją rolę w organizacji, bo my (tj. dostawcy) wdrożymy takie rozwiązanie 3x szybciej niż mówi to zespół architektoniczny i wewnętrzne IT. (Przypowieść o karecie a prace architekta korporacyjnego | Architektura Korporacyjna).