Dwa lata temu cytowałem:

Jakie są najczęstsze problemy w nieudanych projektach? […] 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.

Brzmi to dla Was znajomo? (źr. Raport Jama Sofware ? O wymaganiach).

Dzisiaj będzie kontynuacja powyższego o tym, dlaczego część projektów kosztuje znacznie więcej niż mogła by kosztować, dlaczego pewne projekty nigdy nie przekroczą pewnego progu jakości. Dzisiejszy wpis adresuje dla wszystkich sponsorów projektów,  którzy chcą wiedzieć co zjada ich pieniądze jak szarańcza plony… To lista antywzorców.

Swego czasu napisałem dokument o wdzięcznej nazwie Metodyka prowadzenia analizy biznesowej i dokumentowania wymagań, który to dokument załączam do ofert a potem do umów. Dlaczego? By uniknąć (na ile to możliwe) cofania się o jakieś 15 a może nawet 20 lat wstecz w rozwoju.

Drugi powód to obrona przed tym, by zamawiający nie niszczył rentowności swojego i mojego także projektu. Jak? Ano narzucając swój, prehistoryczny styl pracy, bo zamawiający najpierw z radością akceptuje  moje metody pracy na etapie wyceny projektu, a potem z nie mniejszą radością twierdzi: ale “u nas w firmie takie są metody pracy i ludzie chcą by się Pan dostosował” czyli po protu niszczył projekt. Jakie to metody?  (Gdy Zamawiający podejmuje próby narzucenia swojego “korporacyjnego” zwyczaju pracy jak forsuje umowę T&M).

Do tej pory o tym nie pisałem,  nie licząc rzadkiego u mnie “zachwalania” korzyści ze stosowania oprogramowania CASE. Wydawało mi się to tematem tak wstydliwym jak i oczywistym zarazem, ale artykuł na stronie Modern Analyst (link w dalszej części) upewnił, mnie że szarańcza ma się dobrze: “większość analityków, nadal opiera się na dokumentach tekstowych i arkuszach kalkulacyjnych by w zespole: oni i badana firma, ręcznie “dziargać” wymagania.

Most BAs, however, still rely on documents and spreadsheets to manually stitch together their requirements. (10 Ways Documents and Spreadsheets Sabotage the Business Analyst?s Career | Modern Analyst).

Ten wpis powstał na bazie powyższego artykułu, polecam cały, a tu tylko kluczowe tezy. Co niszczy analityka i analizy? Analityku:

1. Dokumenty i arkusze kalkulacyjne sprowadzają Cię do roli biurokraty. Praca z dokumentami tekstowymi i arkuszami to permanentne pisanie, wycinanie, kopiowanie, sprawdzanie spójności, stanowi to nawet 85% czasu całej analizy, postała wartościowa praca to 15%.

2. Nikt nie lubi przeglądania tych dokumentów, ich kolejnych wersji i ich setek stron. W szczególności nie lubią tego twoi klienci.

3. Dokumentacja (taka) to wąskie gardło większości projektów.  Z drugiej strony klienci życzą sobie tych dokumentów i arkuszy, wielokrotnie zgłaszają do nich uwagi, dodają do treści notatki, pytania i sugestie. Mnożą się emaile, kolejne wersje dokumentów.

4. Tracisz większość pracy tak pracując nad dokumentem wymagań. Cała historia zmian, pomysłów, powodów ich zgłaszania i usuwania nie była śledzona, ginie.

5. Używanie arkuszy kalkulacyjnych do zarządzania zależnościami pomiędzy wymaganiami, przenosi całe ryzyko błędów na Ciebie, jest także bardzo pracochłonne.

6. Twoje dokumenty podróżują jak towar, z reguły jako załączniki email. Tych maili są dziesiątki, zapychają skrzynki odbiorcze wszystkim i zmuszają do ich czytania.

7. Permanentne pisanie tych dokumentów powoduje, że pracochłonność rośnie wydłużając każdy etap projektu.

8. Zarządzanie zmianą w takich warunkach zabija wszelkie nadzieje na sprawną współprace.

9. Opisywanie wszystkiego tekstem zmusza do bezproduktywnego żmudnego opisywania każdego pomysłu, doprowadzania do zamieniania wszystkiego na tekst (zamiast np. tworzenia diagramów) .

10. Stosując te metody pracy nie posuniesz się ani o krok do przodu w rozwoju.

Cóż, dobrze że nie ja pierwszy o tym piszę. Do sponsorów projektów: Wasze projekty zawsze będą albo niskiej jakości albo bardzo kosztowne, dopóki będziecie akceptowali takie metody pracy. Pomysł w rodzaju: no to rezygnujemy z dokumentacji, jest jednak po stokroć gorszy…

Użycie narzędzi CASE tylko do rysowania diagramów i wklejania ich do dokumentów tylko pogarsza sprawę, bo powyższe pisanie tekstów i tworzenie arkuszy komplikujemy dodatkowym programem. Tworzenie tych diagramów jako zamiennik tekstu, łamiąc zasady używanych (i być może żądanych w projekcie) notacji, jest jeszcze gorsze od samego tekstu  bez diagramów, bo wprowadza do projektu element zbliżony do jazdy drogami publicznymi z pominięcie przepisów ruchu drogowego…

Wiele się pisze o tym, że modelowanie służy do dokumentowania projektów. Otóż nie. Do dokumentowania projektów służy rysowanie, modelowanie służy do prowadzenia analiz poprzez testy modeli, symulacje i analizę scenariuszy. Wobec tego dobre narzędzie CASE to nie ?notatnik? rysownika ale ?symulator? i ?walidator? w rękach analityka (Visual Paradigm Agilian).