Podczas analizy powinno się tworzyć słownik pojęć i model dziedziny. Tak. O tym, jak bardzo wartościowe jest wykonywanie pewnych czynności z kategorii dobrych analitycznych praktyk często możesz przeczytać w książkach. Każdą z takich objawionych prawd rozważasz w kontekście przydatności w Twoich projektach. Nic jednak tak nie przekonuje jak sparzenie się na tym, że postąpiłeś niezgodnie z zaleceniami i ściągnęło to na Ciebie spore kłopoty. Może w swoich wspomnieniach znajdziesz jakiś wspólny mianownik z poniższymi historiami?

Historie optymistyczne

Historie optymistyczne, bo często wierzymy, że będzie dobrze bez tego przerostu formy nad treścią i pisaniny. Wiadomo przecież o co chodzi i to nie takie skomplikowane. A jak to bywa w praktyce? W praktyce kwestie związane z definicjami potrafią sporo namieszać.

Ci tak, a ci tak

Historia 1: Pewnego dnia podczas prezentowania dzieła ostatnich dwóch tygodni, zespół z dumą pokazywał zmiany wprowadzone na życzenie klienta. Wszystko działało dokładnie tak, jak w wymaganiach. Z sali jednak padło pytanie skonsternowanej osoby – analityka. Działało tak, jak miało działać, tylko nie tam, gdzie trzeba. Okazało się, że w nomenklaturze klienta i zespołu funkcjonowało słowo „priorytet”, ale znaczyło dwie różne rzeczy! Oznaczało to trzy razy więcej pracy – przygotowanie niepożądanej zmiany, odkręcenie niepożądanej zmiany, wprowadzenie pożądanej zmiany. Ech.
Historia 2: Pewnego zwyczajnego dnia w pracy, w projekcie jakich wiele, rzucone zostało pytanie: „Pakiet to zbiór usług?”. Nie pozostało bez odpowiedzi: „Nie, to pojedyncza usługa. Zbiór to paczka.” Pytającym był programista, który zabierał się za przygotowywanie struktury dla nowo powstającego systemu. Wprowadźmy element grozy: co by się stało, jeśli nie zadałby tego pytania? Jak zrozumiałby kolejne wymagania? Jak przygotowałby rozwiązanie, którego podwalinami była ta właśnie struktura? Był to wyjątkowo rozmowny
programista, zjawisko, stereotypowo rzecz biorąc, nieczęsto spotykane. Idąc dalej – co by się stało, gdyby analityk nie siedział z nim biurko w biurko? To również niekoniecznie najczęstsza opcja.
Wydawać by się mogło, że tak niefortunne mylenie pojęć nie stanowi poważnego ryzyka w pokaźnym procencie przypadków. Jednak czy na pewno? Czy przyjęcie takiego założenia zbytnio nie usypia naszej czujności?

Użytkowników mamy takich i takich

Historia 3: Analityk był zadowolony z przebiegu pierwszego większego projektu. Wydawało się, że wszystko idzie we właściwym kierunku, wymagania są zaakceptowane, klienci zadowoleni, zespół gotowy do działania. Wydawało się. Analityk nie wiedział jeszcze, żeby nie chwalić projektu przed zachodem, tzn. odbiorem, wdrożeniem i popracowaniem na gotowym rozwiązaniu. W każdym razie, trwał właśnie odbiór pewnej, bardzo ważnej, części systemu. Nagle, pomimo wcześniejszej weryfikacji, po tym, jak wszyscy zgodzili się ze sobą, okazało się, że model rozliczeń użytkowników, nie uwzględnia wszystkich ich rodzajów. Oznacza to zmianę działania skomplikowanego modułu, dla którego ta struktura była fundamentem. Nowe typy użytkowników i zupełnie odmienne sposoby ich rozliczania. Miało być tak pięknie, a wyszło jak zawsze – wywraca się nasz zaimplementowany świat.

Firmowa wiedza plemienna

Historia 4: „Świeżak” na jednym z pierwszych spotkań w firmie siedział z notesem i dopisywał do długiej listy zasłyszane nieznane pojęcia – do dopytania o co chodzi. Jedno brzmiało szczególnie zagadkowo i skomplikowanie. Jednak obserwując innych kompanów codziennej pracy, dało się odczuć spokój i pewność. Każdy, zapytany, potrafił powiedzieć, jak działa ten tajemniczo brzmiący mechanizm. Był on nawet opisany w instrukcji. Co prawda niezbyt rozwlekle, ale był. Kiedy na spotkaniu klient zażyczył sobie modyfikacji
jego działania, nie było problemu – każdy wie o co chodzi, więc sobie z tym poradzimy. Jednak nie było tak prosto. Konsternacja rosła za każdym razem, kiedy zespół wprowadzał do mechanizmu coraz to nowe zmiany a później klient szczegółowo dopytywał o jego działanie, bo po wdrożeniu nie do końca zgadzało się z jego oczekiwaniami.
Niektóre pojęcia funkcjonują w firmie od zarania dziejów. Wyjaśnienie wielu z nich zajmuje 5 sekund (zrozumienie tyleż samo). Schody zaczynają się wtedy, kiedy opisywane jest złożone zjawisko czy mechanizm albo ietypowe słownictwo. Bywa, że takie pojęcia z czasem nabierają więcej cech wspólnych z legendą niż z definicją. Mianowicie: 1) pytając kilka osób otrzymujesz nieco inną wersję 2) nikt nie pamięta skąd to się wzięło 3) nikt nie da sobie głowy uciąć, że tak to właśnie jest, bardziej mu się wydaje. Pojęcie nie zostało ściśle zdefiniowane, bo po co, skoro każdy wie, o co chodzi. Kryzys nadchodzi, kiedy trzeba wytłumaczyć klientowi, czemu to działa inaczej, niż się spodziewał (kto ma słuszność?) albo wprowadzamy zmiany w obszar, w którym funkcjonuje niejasny termin. Pozostając na poziomie „wydaje mi się” lub „prawdopodobnie tak to działa” ryzykujemy naszą reputację u klienta i adekwatnie dużą wartość w odpowiedniej walucie z powodu odkręcania i poprawiania pracy w niewłaściwym kierunku.
Te historie łączy wspólny wątek – przekonanie, że przecież pewne rzeczy są wiadome i nie ma się co nad nimi doktoryzować czy marnować drzew (jak się mówi w opcji bez wydruku?).

Definicje, słowniki definicji, terminów

Niełatwo jest definicjom w naszej obecnej rzeczywistości, gdy panuje powszechne przekonanie o tym, że należy „stawiać działające oprogramowanie ponad obszerną dokumentację”. Jednak idąc z duchem usprawniania procesów, czy nie powinniśmy uczyć się na powtarzających się błędach? Jedna kwestia to – czy warto? Druga – czy kiedy już się za to zabierzemy jako analitycy, to czy zrobimy to dobrze? Często zatrzymujemy się na poziomie – „wypiszę wszystkie trudne pojęcia w porządku alfabetycznym i je z grubsza wyjaśnię”. W czym problem? Otóż jest ich kilka, jeśli pozostajemy z takim rozwiązaniem:

1. Nie wiemy jak się te pojęcia mają do siebie, co znacznie ogranicza ich pełne zrozumienie.
2. Bywa, że znajdują się tam pojęcia bardziej takie, jakie chciałbyś wypisać (skróty, niespotykane słowa), a nie takie, jakie ktoś chciałby wyczytać, tzn. szukający, mimo wielu pozycji w słowniku, nie odnajduje tego, co najbardziej go nurtuje.
3. Luźno przygotowana definicja często satysfakcjonuje bardziej Ciebie (uzupełniłem opis pojęcia wypełniając pustą przestrzeń – odhaczone) niż odbiorców mających z tym pojęciem konkretny problem lub takich, którzy są posiadaczami ponadprzeciętnie dociekliwych umysłów.

Jakie byłyby kryteria dobrej definicji zaspokajającej potrzeby wnikliwych ludzi, którzy już na etapie koncepcji są prawdziwie zainteresowani tworzonym efektem? Jest to w naszym wspólnym, i podkreślę, także w naszym własnym analitycznym interesie, żeby rozwiązywać niejasności jak najwcześniej.

1. Definicje warte zapisania to nie tylko skróty czy niespotykane słowa, ale także:
   pojęcia, które używane na co dzień mają inne znaczenie niż w kontekście analizowanego zagadnienia,
   b. pojęcia, które mają wiele znaczeń, w zależności od kontekstu,
   c. pojęcia, które z innego powodu grożą pojawieniem się nieporozumienia.
2. Definicja powinna być krótka i jasna.
3. Do definicji dołączajmy synonimy. Tłumaczmy jedno pojęcie, a w każdym z synonimów wstawiajmy odwołanie do tego pojęcia. Ułatwito utrzymanie słownika.
4. Definicja musi opisywać dokładnie jedno pojęcie – jeśli po przeczytaniu wyjaśnienia, możemy w miejsce wyjaśnianego pojęcia wstawić więcej niż jeden taki element i będzie to nadal podstawienie prawdziwe, to znaczy, że nie jesteśmy wystarczająco precyzyjni.

Na wysokim poziomie abstrakcji (pojęcia biznesowe) stosujemy glosariusz, który abstrahuje od projektów i implementacji – tu przydadzą się słowniki i modele danych.
Niektóre narzędzia CASE (np. Visual Paradigm) posiadają wbudowane wsparcie dla tworzenia definicji. Z dowolnego miejsca modelu można dodać do słownika pojęcie. Każde jego wystąpienie będzie automatycznie stawało się odnośnikiem do słownika. Niestety, w języku polskim dla pełnego skorzystania z tego cudu techniki, trzeba odmieniać słowa przez przypadki i liczby. Można przypomnieć sobie szkolne czasy. Mianownik – kto? co? taryfa, dopełniacz – kogo? czego? taryfy, celownik – komu? czemu? taryfie.
Gdzie szukać pojęć? W procesach, regułach biznesowych, wymaganiach.
Wytężajmy uważnie słuch tam, gdzie rozmawia biznes i szukajmy słów-kluczy.

Model świata (model dziedziny)

Co nam po słowniku, który zawiera losowo wybrane, wyrwane z kontekstu słowa? Całość nabiera kształtu i głębszego sensu wtedy, kiedy obecność definicji w słowniku wynika z wystąpienia elementu w modelach. A czym są te modele? Uchwyceniem najistotniejszych w danym aspekcie elementów i zależności między nimi. Uproszczeniem świata. Mówiąc o świecie mam na myśli interesujący nas wycinek, np. daną dziedzinę, obszar, w jakim działa organizacja czy toczy się projekt.
W świecie występują obiekty i ich zachowania. Np. jest faktura i z taką fakturą można coś zrobić – wystawić, aneksować. W modelach pojęciowych ważne są zarówno rzeczowniki i czasowniki. W zasobniku analityka znajdziemy narzędzie, które przyda się na tę okoliczność: diagram klas UML. O tym, ile wokół niego zamieszania i czym powinien różnić się model pojęciowy od modelu dziedziny, ciekawie napisał Jarosław Żeliński: http://it-consulting.pl/autoinstalator/wordpress/2011/01/18/cholerny-diagram-klas/.
Powiązanych jest też kilka innych artykułów wokół tej tematyki.

Poznawanie świata

Niestety nawet wykonanie doskonałej pracy w kontekście precyzyjnych definicji, dokładnego modelu pojęć i rzetelnego przetestowania, na nic się nie zda, jeśli nie będzie o tym wiedział nikt poza nami. Nie udało mi się dotąd zrobić doskonałego wdrożenia. Wiem natomiast, co nie jest wystarczające (co nie znaczy, że nie jest warte wykonania i nie stanowi ważnego kroku pośredniego).

1. Nie wystarczy przygotować świetne definicje i modele.
2. Nie wystarczy umieścić je w łatwo dostępnym miejscu.
3. Nie wystarczy oznajmić do publicznej wiadomości, że coś takiego zostało przygotowane i gdzie można to znaleźć.
4. Nie wystarczy zebrać grupy potencjalnie zainteresowanych i bezpośrednio przedstawić im opracowane materiały.
5. Nie wystarczy wydrukować najważniejsze rzeczy i powiesić na ścianie osób, które powinny z tego wynieść korzyść.
6. Nie wystarczy przy każdym pytaniu zachęcać do samodzielnego wyszukiwania odpowiedzi, przypominając, gdzie są one dostępne.

Zdaje się, że ludzie muszą sami natrafić na ważny, dręczący ich problem czy wyzwanie, gdzie takie pojęcie będzie odgrywało dużą rolę. Jak pokazują przytoczone historie, o takie przypadki nietrudno. Chodzi jednak o zrozumienie, że ten problem wynika z niedoskonałości czy niedoskonałej znajomości definicji i można temu zaradzić usprawniając obie te rzeczy. Korzystanie z tych cennych dla organizacji czy projektu zasobów oczywiście da już korzyści, kiedy wykorzysta je choćby jedna osoba czuwająca nad merytoryczną poprawnością i spójnością. Pełną moc zdobędzie jednak, kiedy zaczną korzystać z nich
wszyscy. Do tego potrzeba jednak zaangażowania, konsekwencji i przykładu z góry. Jeśli biznes zacznie rozmawiać tymi pojęciami z klientami, architekt komunikować je dalej, tester odsyłać do pojęć programistów, kierownicy wykorzystają je, by określać zakres prac, dopiero kiedy wypracujemy kulturę korzystania z precyzyjnych definicji, rzeczywiście wejdą w życie. W czasem staną się nieodłączną częścią żargonu rozumianą przez wszystkich
w ten sam, precyzyjny sposób. Choć będą one również zawsze dostępne w miejscu, do którego każdy będzie miał w nawyku szybko zajrzeć.
Co jest najlepsze w definicjach i modelach? To, że zostają na długo po tym, kiedy pojęcia ulatują nam z głowy, bo minęło tyle czasu lub odeszło tylu ludzi.