MS Office vs. Enterprise Architect

W rozmaitych okolicznościach spotykam się z zespołami projektowymi, które skomplikowane zagadnienia projektowe dokumentują w postaci dokumentów MS Word i MS Excel. Twórcy takiej dokumentacji wkładają mnóstwo wysiłku w jej wytworzenie i są często z niej dumni.
Dla przykładu spotkałem się z arkuszem MS Excel, który opisuje szczegółowo procesy biznesowe w całej organizacji z uwzględnieniem obecnego i przyszłego wsparcia przez poszczególne funkcje systemów informatycznych w dodatku z rozróżnieniem na różnice w poszczególnych jednostkach organizacyjnych. Imponujące, prawda?
Twórcy takiego arkusza szczycą się tym, że w tym jednym dokumencie opisane są najważniejsze aspekty architektury biznesowej i wsparcia jej przez systemy informatyczne. Zdaję sobie sprawę, że wypełnienie treścią tego ogromnego arkusza poprzedzone zostało wieloma godzinami pracy i konsultacji z klientem.
Ja jednak czytając tego typu dokumenty mam problem, bo zdaję sobie sprawę z tego, że autorzy oczekują podziwu dla ogromu wykonanej pracy, ale ja nie mogę przestać zadawać sobie w kółko jednego pytania: "Dlaczego oni tego nie zrobili w EA?".
Myślałem sobie, że to ja mam skrzywione spojrzenie na rzeczywistość. Na szczęście miałem okazję przeczytać ciekawy wpis Jarka Żelinskiego pod tytułem Sabotaż dokumentacyjny.
Autor przytacza w nim między innymi 10 tez dotyczących prowadzenia dokumentacji w postaci dokumentów MS Word i MS Excel. Pisze między innymi, że:

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.

Autor argumentuje, dlaczego dokumentacja powinna być prowadzona przy użyciu narzędzi CASE, takich jak Visual Paradigm Agilian, czy Enterprise Architect, zamiast w postaci dokumentów i arkuszy.

Jeśli nawet część członków zespołu projektowego wskazuje na chęć wykorzystania Enterprise Architecta zamiast produkowania wielu dokumentów i ich wersji, to rzadko dochodzi do skutku tego typu zmiana.

Dlaczego tak się dzieje?
Jak zwykle mamy do czynienia z wieloma czynnikami. Ja jednak niedawno natknąłem się na jeden zasadniczy problem.

Otóż, gdy zespół stoi przed decyzją: porzucić pracę w MS Office na rzecz Enterprise Architect, czy nie, wówczas taki zespół powinien umieć sformułować zestaw własnych wymagań odnośnie takiego narzędzia.
Czyli, zespół powinien być w stanie określić, co takie narzędzie powinno być w stanie zrobić, żeby oni mogli go używać. Dopiero wtedy będą w stanie wyobrazić sobie, że z niego korzystają i w jaki sposób.

Niestety osoby tworzące skomplikowane dokumenty i arkusze kalkulacyjne nie znają narzędzi CASE, bo gdyby znali, to by ich użyli. Samo zapoznanie się z dokumentacją programu nie jest również wystarczające. Poza tym, z EA można wyciągnąć o wiele więcej, niż to widać na pierwszy rzut oka poprzez umiejętną kastomizację. Do pomocy potrzebny jest ktoś, kto zna Enterprise Architecta, czy inne narzędzie CASE "od deski do deski".

Gdy członkowie zespołu stwierdzą, że potrzebują arkuszy kalkulacyjnych, bo to jest najwygodniejsza forma komunikacji z klientem, to w odpowiedzi mogą usłyszeć, że z EA można na żądanie wyeksportować dane do arkusza.
Gdy członkowie zespołu stwierdzą, że zatwierdzone ustalenia powinny mieć charakter oficjalnego dokumentu, który powinien być podpisany przez obie strony, to w odpowiedzi mogą usłyszeć, że z EA można generować tego typu dokumenty.
Gdy członkowie zespołu stwierdzą, że wprowadzanie danych do EA jest zbyt skomplikowane i mogą powstawać błędy, to w odpowiedzi mogą usłyszeć, że do wprowadzania specyficznych danych można opracować odpowiedni plugin. A do walidacji wykorzystać skrypty i zapytania SQL, które zwrócą listę elementów nie spełniających reguł projektowych.

W takiej sytuacji dyskusja przenosi się z reguły na inny poziom: Kierownik projektu musi oszacować, czy koszty opracowania szablonów raportów i kastomizacji narzędzia są akceptowalne. Oby jeszcze kierownik projektu zgodziłby się z tezą pochodzącą z wyżej cytowanego artykułu o tym, że:

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, pozostała wartościowa praca to 15%.