Ten artykuł to nie zamierzona kontynuacja poprzedniego. Coraz częściej utożsamiam analizę z projektem gdyż w sumie produktem analizy jest jakiś projekt czyli model tego co analizowano, model tego co rekomenduję by powstało. Analiza sama z siebie nie jest samowystarczalna (to znaczy samo analizowanie nie jest wartościowym produktem samym w sobie). Problemy z projektami obserwuje nie ja jeden. W każdym kolejnym projekcie staram się szukać przyczyn, zrozumieć problem i podjąć próbę rozwiązania. Problem w zasadzie jest znany. Autor pewnego bloga, pisze:

Chciałoby się powiedzieć, żeby zrobić coś dobrze trzeba wiedzieć dokładnie co się robi. Być może taka prawda sprawdza się w pewnych dziedzinach życia? Niestety jednak w świecie oprogramowania najczęściej nie mamy tego luksusu, aby widzieć cały obrazek na początku. Większość projektów IT, niezależnie od przyjętej metodologii, zaczyna się od rozmów z ?klientem? (który w szczególnych przypadkach może być osobą, która tworzy software sama dla siebie). Wszystko po to, aby dowiedzieć się, o co chodzi w tym projekcie, jaki jest cel, jakie mają być funkcje i kto ma tego używać. […] Jeśli zrobimy super analizę na początku (upfront) i się w niej zamkniemy, to niszczymy projekt zanim się jeszcze na serio rozpocznie. Potem jest już tylko gorzej.

Ma wiele racji. Po pierwsze wiedza „co należy zrobić” jest bezcenna :). Pytanie brzmi, dlaczego nie mamy tego luksusu? Kluczem jest tu chyba  zdanie „Większość projektów IT, niezależnie od przyjętej metodologii, zaczyna się od rozmów z ?klientem?„. Niewątpliwie należy zapytać zamawiającego po co mu to, ale nie jestem pewien czy należy go pytać „jak mamy to wykonać”. W końcu to lekarz po wywiadzie i badaniach wypisuje receptę pacjentowi a nie  odwrotnie.

Kolejny problem wielu projektów to szczegółowość wymagań i sposób przekazania tych szczegółów. Autor słusznie pisze:

Specyfikacja wymagań i ogólnie wstępna wizja systemu wysokiej jakość powinna więc być lekka. Możliwie spójna i kompletna, poparta faktami i badaniami ? ale przede wszystkim lekka. Zarówno metaforycznie (czyli nie stawia ciężkich, twardych ograniczeń) jak i dosłownie (jest lekka, czyli krótka). Oczywiście można polemizować ? jeśli jednak jesteś bardzo mocno przywiązany do budowania zaawansowanych formalizacji wstępnych wymagań do systemu, to znajdź taki dokument z toczącego się projektu i porównaj go z tym co stało się w projekcie po 6, 9 albo 12 miesiącach. Ciekawy jestem czy cokolwiek zgadza się z pierwotnym obrazkiem. Wątpię.

Nie wiem w jakim znaczeniu autor użył słowa „formalizacja”, mam nadzieję, że miał na myśli zawartość opasłych dokumentacji i ich obowiązkowo wypełnianego spisu treści (nawet jeżeli w danym przypadku istnienie jakiegoś podrozdziału jest kompletnie bez sensu). Niedawno spotkałem się z zarzutem potencjalnego klienta: „To co Pan nam prezentuje ma za mało szczegółowe”. Większość ludzi (klienci oprogramowania) szermuje twierdzeniem, że diabeł tkwi w szczegółach, w związku z tym należy jest wszystkie spisać. Problem w tym, że szczegóły szczegółom nierówne. Jedne dotyczą tego nad czym się pracuje a inne tego jak to robimy. Te drugie są tu paradoksalnie mało istotne, gdyż to „jak to robimy” to robimy MY a nie SYSTEM. Po sieci krążą specyfikacje na systemy ERP mające nawet ponad 6 tys, cech! Po pierwsze nikt tego potem nie czyta, po drugie znaczna większość jest ignorowana w przypadku wdrożenia systemu gotowego i zmieniana w przypadku projektowanego. I tu zgadzam się z autorem: miernikiem jakości dokumentacji wymagań jest jej zgodność z tym co faktycznie zostało dostarczone!

Nauczeni doświadczeniem z pracy z klientem, który jest w stanie zmienić zdanie 3 razy w czasie jednej rozmowy ? musimy tą obiektywną rzeczywistość odzwierciedlić w architekturze.

Tu moja uwaga: po pierwsze Klient musi mieć na każdym kroku świadomość swojej roli w projekcie: nie jest jego projektantem a przyszłym użytkownikiem. Innymi słowy rolą Zamawiającego jest „zamawianie funkcji systemu” a nie ich realizacji (ale dokument powinien zawierać logikę działania – to jednak element domeny, dalej o niej). Po drugie Klient powinien brać aktywny udział w projekcie, mam tu na myśli powinie ponosić konsekwencje wprowadzanych zmian na równi z wykonawcą.

Ale wezmę także Klienta w ochronę: Klient nie zna się na inżynierii oprogramowania i ma do tego prawo. Kluczem jest analiza zakończona projektem a nie tylko „analiza” bo ona sama z siebie faktycznie jest nie raz jakimś „papierowym potworem”. Jaki projekt powinien powstać?

Użytkownik czyli nasz Klient, to osoba, ktora użyje tego oprogramowania do zrealizowania jakiegoś działania, dlatego z jego perspektywy mówi się o Przypadku Użycia. Nasz System należy zaprojektować, więc analiza powinna dać Projekt jako produkt. Ale po kolei. Użytkownik wyartykułował swoje wymaganie czyli do czego chce użyć systemu,  czyli to jakich efektów oczekuje. Może być wymagane jeszcze to co „da od siebie” (dane). Za to odpowiada Interfejs użytkownika, stan ekranu przed i po pracy. W zasadzie jest to, określenie tego,  robota dla Zamawiającego (np. podaje dane do faktury i otrzymuje poprawną fakturę).

Dalej mamy dwa kluczowe elementy: jak należy to zrobić i czym to coś jest. Tu dodam: są to rozdzielne elementy! Autor cytowanego bloga pisze:

Architektura wysokiej jakości powinna więc od początku zakładać tę płynność. Mamy do dyspozycji mnóstwo wspaniałych narzędzi ? takich jak wzorce projektowe, integracyjne, dobre praktyki czy modelowe rozwiązania. Co więcej, w parze z architekturą idzie z reguły usadowienie jej w jakiejś konkretnej technologii, która dodatkowo narzuca pewne podejścia i koncepty. To wszystko jest dobre i im lepiej zrozumiemy narzędzia, które mamy do dyspozycji, tym lepiej. Ale, podobnie jak w przypadku specyfikacji ? im bardziej się utwardzimy i zamkniemy  w jednej, niezmiennej architekturze, tym gorzej.

Ta „dobra” architektura, tak mi mówi moje doświadczenia z wzorcami i nie tylko, powinna rozdzielać interfejs użytkownika od tak zwanego modelu dziedziny czyli modelu specyfiki firmy. Tu raczej niczego nowego nie powiedziałem. Ale dalej: w modelu dziedziny należy oddzielić specyfikę projektu od tego czego on dotyczy (tego niestety raczej nie zrobi developer, dla niego to wszystko jedno). Dlatego należy  wydzielić w projekcie obiekt o nazwie CośRzeczywistego. To drugie to coś co ma postać niezależną od organizacji klienta. Zaryzykuje tezę, że to jest coś co stanowi w takim projekcie jego większość (są tezy, że paretowskie 80%).

Tak więc rolą Analityka jest zbudować właśnie taki model (projekt). Dlaczego Analityk? A kto inny ma to wszystko wiedzieć i opisać, skoro tylko on siedzi na początku u klienta?

Mój diagram nie zawiera „konkretnej technologii, która dodatkowo narzuca pewne podejścia”, gdyż w moich oczach, jednym z większych błędów jest wybór technologii zanim dowiemy się co należy zrobić. Niestety wybór technologii to nic innego jak przedwczesny wybór wykonawcy (z reguły każdy specjalizuje się w jakiejś). Mój diagram dla uproszczenia nie zawiera także wymagań jakościowych (ograniczeń, wymagania poza-funkcjonalne). Każda technologia ma swoje ograniczenia. Przedwczesny wybór wykonawcy to nic innego jak z góry nałożone ograniczenia na produkt, nie koniecznie zgodne z naszymi.

Dalej mamy same dobre rady, z którymi trudno polemizować:

Wysoka modularność, współpraca wielu niezależnych, lub luźno powiązanych elementów, możliwość wymiany małych części, lub tworzenie różnych wariantów tego samego modułu, to podejścia, które przyniosą nam wartość dodaną.  Ludzie mający do czynienia z monolitami (układ: jedna wielka baza danych i do tego wielki serwer aplikacyjny) z reguły postrzegają podejście rozproszone (dziesiątki lub setki małych kawałków fruwających gdzieś w koło) jako trudniejsze, bardziej skomplikowane i przez to  gorsze i bardziej ryzykowne. Takie spojrzenie to postawienie sprawy do góry nogami.

I tu moim zdaniem autor ma 100% racji. Nie ma chyba nic gorszego niż uznanie, że „jeden wielki zintegrowany system” to zaleta tego Systemu, jest to jego największa wada.

Czytamy dalej:

Wciąż są miejsca, w których prowadzi się wielki ?up-front design? z głęboką wiarą w jego sukces. A problem w tym, że nie można mówić o sukcesie czy porażce rzeczy, która w całości jest fikcją. Słyszałem nie raz skargi programistów i kierowników, że największą bolączką projektu są zmienne wymagania. Nie raz chciało mi się powiedzieć ? ?jakże wielkie szczęście macie, że klient zmienił wymagania, bo przecież były bez sensu!?.

I tu moja uwaga: zmienne wymagania mają dwa źródła: uznanie, że to klient jest ich autorem a nie analityk (przypominam pacjent, recepta i lekarz). Drugie źródło to planowanie wymagań i projektu na okres dłuższy niż rok (około). Wiele wymagań ma swoje źródło w „aktualnej sytuacji”, dlatego szczegółowy Projekt z Ręki Analityka i zakres projektu dla developera powinien obejmować tylko tak zwany quasi-stabilny okres dla firmy. Wszystko to co jest planowane „bardziej w przyszłość” jest w zasadzie z góry skazane na zmiany więc po co to szczegółowo projektować i planować?

A teraz małe ćwiczenie na koniec: po jakiego więc grzyba ogłaszane są przetargi na wieloletnie projekty? Ich mizerne efekty są odpowiedzią… A po co planować zakup wielkiego ERP i wdrożenie na lata? Tu niestety dziennikarze nie mają takiej swobody w opisie efektów jak to ma miejsce w przypadku pieniędzy wydawanych publicznie…a żałujcie Państwa…

P.S.

Cytaty pochodzą ze strony Czym jest jakość oprogramowania? ? Trzecia kawa.

Polecam także ciekawy artykuł: Touching the Void: Kilka spraw, o których powinien wiedzieć analityk.