Pod artykułem Plansza do gry w szachy, znalazł się między innymi taki komentarz:

Kolejna kwestia to taka, że nie widzę wartości w tak niskopoziomowej analizie. Diagram dziedziny i ilustracja Inicjacji gry są niezrozumiałe dla mnie jako laika i tak samo będą niezrozumiałe dla mojego klienta. Nie wiem więc czemu dokładnie służą i co wnoszą.

Powyższe to typowe podejście zamawiającego lub (i) sponsora projektu. To co tu teraz napiszę, to absolutnie nie jest krytyka autora powyższej wypowiedzi. To stereotypowe, standardowe podejście wielu zamawiających (i nie raz ich pośredników) systemy IT: sam zamawiam i sam odbieram.

To troszkę tak, jak by podmiot inwestujący w biurowiec w centrum miasta sam podejmował się oceny dokumentacji technicznej  wykonanej przez architekta, algo gorzej: uznał, że skoro tej dokumentacji nie rozumie to jej po protu nie chce! Paradoksalnie, powyższe podejście to najczęstsza przyczyna porażek projektów (budownictwo wypracowało prawne zasady, IT się jeszcze broni głosami dostawców).

W czym problem? Dokładnie w tym, z czym spotykamy się kupując samochód: kupujący uważa, że rozumie to co widzi i czego potrafi użyć (przypomnę, że każdy kierowca używa w samochodzie skrzyni biegów ale nie każdy rozumie jej działanie). Pokazanie (opisanie) w salonie, jaki samochód jest nam potrzebny, to góra kilka godzin. Przekonanie się o tym, co na prawdę kupiliśmy, to już co najmniej kilkaset (a nie raz kilka tysięcy) przejechanych kilometrów. Prawdę o tym co kupiliśmy powie nam dopiero mechanik po zakupie, jest to jednak za późno na zmiany. Kto z Państwa skorzystał z porady dobrego mechanika przed zakupem samochodu? Pamiętajmy, że samochód to tysiące współpracujących podzespołów, które z nich znacie, rozumiecie i widzicie? A wszystkie mają wpływ na walory użytkowe samochodu.

Projekty IT wyglądają bardzo podobnie, mało kto – przed wyborem dostawcy oprogramowania – płaci za analizę, prawie nikt  za projekt, którego nie rozumie, ale prawie każdy sam zamawia (opisując czasem jakieś swoje wymagania) i niestety prawie każdy projekt (przypomnę, że to ponad 75%) to kłopoty dla kupującego i na koszt kupującego.

Odpowiedź na zarzut cytowany na początku

W projektach analitycznych mamy trzy kluczowe etapy: analiza, projektowanie oraz wytworzenie. Analiza to coś co zrozumie każdy zamawiający, bo jej efektem jest opis jego własnej działalności. Powstaje po to, by nikt nie miał wątpliwości jaki jest biznesowy cel projektu i jak będzie on realizowany (ale celem biznesowym projektu nie jest zakup oprogramowania!, to jeden z możliwych sposobów jego realizacji). W międzyczasie powstaje model procesowy, to dokument dla analityka. Celem jego tworzenia jest minimalizacja ryzyka niekompletności i niespójności projektu i dokumentacji wymagań.  Nie jest prawdą, że zamawiający ma tu coś do sprawdzenia, ale prawda jest, że zamawiający bierze udział w jego testowaniu (sprawdzeniu poprawności). Model procesów to formalny opis wymagający już pewnej wiedzy.

Podstawowym błędem jaki popełniają zleceniodawcy analiz, jest próba forsowania zmian w modelach w rodzaju “proszę mi dopisać jeszcze, że czasami ten dokument trafia do…”.  

Model to pewna formalna struktura. Model gry w szachy to szachownica, bierki i reguły gry, a nie setki godzin filmów nakręconych podczas rozgrywania realnych partii. Niestety większość widzi i podziwia rozgrywane partie i oczekuje filmu, jednak oprogramowanie BigBlue (komputer z tym programem wygrał w szachy z mistrzem świata) to nie tysiące zapisanych partii gry, a program mający zaimplementowane reguły gry… niestety tak to wygląda.

Analityk może oddać jako wymaganie także przetestowany projekt logiczny oprogramowania. Wtedy wymagana jest także zgodność zachowania się oprogramowania z tą logiką. Po co? By wyeliminować ryzyka, których źródłem jest niezrozumienie biznesu zamawiającego przez developera (to zresztą nie jego rola), oraz ryzyka związane z budowaniem marży po stronie wykonawcy (upraszczanie projektu w celu obniżenia pracochłonności).

Istnieje niestety także bardzo duże ryzyko, którego źródłem jest stosowanie starych, strukturalnych metod wytwarzania oprogramowania czyli “rozbiór” (i projekt) systemu na bazę danych i procedury. Ta praktyka (metoda) niestety daje jako efekt oprogramowanie bardzo kosztowne w projektowaniu i rozwoju. Od metod strukturalnych znacznie lepsze są metody obiektowe,  niestety samo deklarowanie korzystania z .NET czy Java albo notacji UML nie czyni stosowanych metod obiektowymi.

Metody zwinne, to być może doskonałe metody pracy w projektach związanych ze społecznościowymi stronami WWW, ale w projektach biznesowych niestety  są to metody także bardzo kosztowne i nieprzewidywalne, dlatego projekty zwinne to bardzo rzadko projekty o ustalonym w umowie zakresie (opis tego co ma powstać). Po lewej  stronie (diagram ze stron pewnego developera) typowa “zwinna” procedura tworzenia oprogramowania: usuwanie przez developera błędów projektu (szczególnie dotyczących realizowanej logiki biznesowej) może być pętlą nieskończoną, którą tylko wyczerpanie budżetu lub graniczny termin jest w stanie zatrzymać, co może nie dać w efekcie żadnego przydatnego produktu.

Na koniec ku przestrodze cytat pewnego użytkownika systemu: 

Niestety źle dobrany system informatyczny, mający wspierać/automatyzować czynności w procesie, może być powodem powstania całych podręczników procedur nieuzasadnionych biznesowo, dedykowanych użytkownikom tego systemu, stwarzając przy tym pozory, że to sam proces jest ich źródłem 🙁

Niestety tak się często kończą projekty, w których pomięto analizę i projektowanie i od razu wybrano dostawcę i produkt (analiza wykonana przez dostawce to raczej “jak wdrożyć to co mamy” a nie “jak rozwiązać problem użytkownika”).

Problemem większości projektów IT jest założenie, że tylko dostawca/wykonawca usługi ma wiedzę o tym jak to zrobić. Tezę tę forsują najczęściej właśnie wykonawcy (developerzy), a problem polega na tym, że wykonawca dąży tu do sytuacji, w której sam sobie stawia wymagania a potem rozlicza ich realizację. 

Wykonanie analizy wymagań własnymi zasobami (kupującego) z reguły daje złe efekty, powodem są zbyt silne zależności własnych pracowników między sobą i ich zależność od aktualnie posiadanych zasobów. Do tego dochodzi brak obiektywizmu i obciążenie do zachowania własnej pozycji.