Tego rodzaju metodyki, słowne opisy zamawiającego, są często stosowane przez zespoły programistów chcących uniknąć lub ograniczyć dotychczasowe swoje kłopoty (ryzyka) związane z komunikacją pomiędzy zamawiającym a wykonawcą. Kluczowym problemem jest fakt ogromnej różnicy pomiędzy domenami pojęciowymi zamawiającego (zarządzanie i marketing) a wykonawcy (inżynieria programowania, modelowanie i projektowanie obiektowe, inne). Nie jest to absolutnie krytyka inżynierów a tylko tej ścieżki rozwiązywania tego problemu. Myślę, że doskonałym obrazem i metaforą tego zjawiska jest anegdota o słoniu analizowanym po ciemku. Przytoczę ją w całości.

Grupa osób natknęła się w nocy na słonia, dwaj przewodnicy, każdy po ciemku, rękoma trafił na inną cześć ciała słonia. Jako że musieli podjąć decyzje o dalszej drodze i postępowaniu zebrali swoje opinie. Osoba, która trafiła na nogę uznała, że dotknęła jakiejś kolumny, zapewne są u progu jakiejś świątyni więc musza ją obejść, zaś by nie niepokoić jej kapłana proponuje  by zrobić to od razu i nadrobić drogi. Druga osoba trafiła na trąbę, szybko uznała, że to duży wąż i zaleciła natychmiastowy odwrót i wybór innej drogi. W efekcie stracili wiele czasu, ograniczone zasoby wody i jedzenia spowodowały, że kilka osób zmarło z powodu przedłużającego się marszu.

Wszyscy mieli dobre chęci, burza mózgów zalecana jako metoda rozwiązywania takich problemów została prawidłowo wykorzystana, na bazie posiadanej wiedzy i wniosków podjęto racjonalną decyzję (unikanie zagrożenia), więc gdzie błąd? Byli doskonałymi piechurami, mieli ogromne doświadczenie w survivalu, widzieli nie jedną pustynię i nie jedno pustynne zwierze, jednak idąc do dżungli nie mieli w swoim gronie zoologa, który znając swoją dziedzinę po zebraniu tych informacji mógłby odkryć, że to słoń i należy tylko w spokoju dać mu przejść. Nie zabrali zoologa gdyż uznali, że taka wyprawa wymaga tylko kondycji a tę posiadają. W życiu nie widzieli słonia wiec nie zaplanowali tego ryzyka, niestety zignorowali cenna radę: zabierzcie kogoś kto zna się na stworzeniach żyjących w dżungli i na pustyni.

Co prawda podobno wystarczyło by zapalić światło ale nie ma latarni w dżungli, po drugie zobaczyli by słonia pierwszy raz w życiu i prawdopodobnie także by uciekli.

Jaki z tego wniosek? Moim zdaniem taki, że niezależnie od doświadczenia programiści (osoby odpowiedzialne za powstanie kodu programu) nie powinni realizować części analitycznej (projektowanie rozwiązania) projektów w obszarze specyfikacji wymagań. Po raz kolejny okazuje się, że wypracowane przez tysiąclecia metody pracy w budownictwie i inżynierii lądowej się sprawdzają i warto je przenosić na pole inżynierii oprogramowania.

Pomysłodawca (inwestor) precyzuje swój cel architektowi, ten analizuje oczekiwania, wykonuje poglądowy projekt (makietę), który zatwierdza zamawiający. Po uzyskaniu akceptacji projektuje konstrukcję. Opis konstrukcji przekazuje specjalistom inżynierom do opracowania szczegółów i zbudowania budowli. Jakież to proste? Zamawiający zatwierdza kolory ścian, układ pomieszczeń, doświadczony architekt realizuje życzenia ale także dba by się to nie zawaliło i radzi jak ewentualnie poprawić funkcjonalność pomieszczeń, proponuje nowoczesne rozwiązania. Gotowy projekt dostaje developer, który już nie podejmuje dyskusji czy ściany mają być tam gdzie są, bo nie znając intencji i gustu zamawiającego nie ma podstaw by takie uwagi czynić, co najwyżej może z architektem dyskutować dostępność użytych w projekcie materiałów i technologii.

A co robią firmy programistyczne? Analityka i architekta się pomija jako zbędny koszt, zaś niewiedza zamawiającego gra na korzyść wykonawcy. Proponuję samemu sobie odpowiedzieć na pytanie jak prowadzić takie projekty i podyskutować nad potrzebą pracy analityka i architekta.

Wyobraźcie sobie Państwu remont swojej łazienki (albo co gorsza budowę domku jednorodzinnego), który zlecacie od razu murarzom a to jak ma wyglądać efekt końcowy opisujecie murarzowi słownie, ten spisuje to prozą w umowie. Efekt zobaczycie dopiero po tym jak murarze skończą i zapłacicie im za roboczogodziny.

Podam przykład z jednaj z konferencji na ten temat. Podczas tej konferencji wyraziłem wątpliwości co do potrzeby bezwzględnego stosowania bezpiecznego podpisu elektronicznego w komunikacji z urzędami (i nie tylko). Pewien inżynier odparł, że technologia użyta i wymagana w ustawie daje niemalże 100% gwarancję itp. Owszem, tego nie neguję bo to prawda. Jednak to ja ustalam ryzyko mojego pisma. Paradoksalnie, powszechnie stosowany, podpis odręczny jest stosunkowo łatwy do podrobienia, urzędy nie zatrudniają grafologów więc fałszerstwo jest proste i łatwe a mimo to nadużyć z tego powodu jest co kot napłakał a do tego są one łatwo wykrywalne, bo sprawdzenie pisma po obu stronach (u nadawcy i u odbiorcy) od razu wykaże różnice.

Nikt (mam takie wrażenie) nie wykonał analizy rentowności i oceny ryzyka czyli nie zastanowił się nad tym jakie straty może spowodować potencjalne fałszerstwo czyli nie określił maksymalnej sensownej wartości inwestycji w zapobieżenie temu fałszerstwu. W efekcie podpis i sam przepis są w zasadzie martwe bo mało kto chce zainwestować w posiadanie bezpiecznego podpisu (a podobno z faktami nie dyskutujemy). Testem tej hipotezy może być kwietniowa (2009 rok) decyzja o możliwości złożenia deklaracji PIT bez podpisu elektronicznego. Ponad 80 tys. deklaracji złożonych tą drogą przez zwykłych obywateli w trzy tygodnie, to chyba więcej niż wszystkie formalne dokumenty wysłane do urzędów w wersji elektronicznej razem wzięte od początku obowiązywania ustawy (nie licząc tych do ZUS?a). Zabezpieczenie było bardzo proste: należało podać dane weryfikujące, w tym pewną wartość z deklaracji z poprzedniego roku znaną praktycznie tylko jej nadawcy.

Dlaczego akurat ten przykład? Po pierwsze boli mnie wyrzucenie państwowych (więc i moich) pieniędzy w błoto czyli inwestycje w e-podpis . Po drugie jest to moim zdaniem doskonały przykład wymagań na system opracowany przez doskonałych inżynierów. Zabrakło jednak wiedzy biznesowej?

Spójrzmy na nasze drzwi do mieszkań i to jakie mamy w nich zamki? powtarzając opinie biegłych z policji: typowy zamek w drzwiach chroni nas wyłącznie przed chuliganami bo wprawny włamywacz otworzy go w czasie od pięciu do piętnastu minut zależnie od klasy zamka. Używanie sztab antywłamaniowych jest bez sensu bo żaden złodziej przy zdrowych zmysłach, nie będzie czynił wielkiego hałasu wywarzaniem drzwi, a mimo to firmy ubezpieczeniowe wymagają takich zabezpieczeń. Dobry złodziej jak już, to kradnie tylko miliony ? bo to dopiero jest warte tego ryzyka. Kto trzyma w domu miliony?

Tak więc wymagania na oprogramowanie powinny być określone przez dialog biznesowy zaś specyfikacja oprogramowania przez dialog technologiczny. I tu łyżka dziegciu: wiele razy byłem świadkiem gdy to zamawiający psuł projekt uważając, że wie lepiej jak się tworzy oprogramowanie. Zjawisko to (tu bardzo niebezpieczne dla życia ludzi) także zna inżynieria budowlana dlatego prawo budowlane wymaga projektu architekta a jego projekt chroni nie tylko prawo budowlane ale także i autorskie.

Nie zmienia to jednak faktu, że wiele projektów programistycznych to nadal projekty, w których to inżynierowie budowlani decydują o tym jak ma wyglądać dom, rozliczają się za czas pracy i budują tak długo aż spodoba się inwestorowi. Co ciekawe ich odpowiedzialność gdy się potem coś zawali mają bardzo ograniczoną. Cytując E. Yourdona, guru inżynierii oprogramowania i modelowania: bardzo wiele firm [programistycznych] nadal buduje ogromne biurowce zabierając się do tego jak do zbijania budy dla psa.