Spis treści
Proszę się dokładnie zapoznać z poniższą treścią, ten dokument to standardowy sposób komunikacji w każdym moim projekcie.
Wprowadzenie
Podstawowym celem tej komunikacji jest dostarczanie mi materiałów i recenzowanie (uwagi do treści) powstającej lub aktualizowanej, dostępnej on-line, dokumentacji analityczno-projektowej. Dotyczy to zespołu organizacji analizowanej, później także zespołów dostawców rozwiązań. Wymiana treści jest w 100% prowadzona pisemnie (materiały źródłowe, dyskusje powiązane z elementami treści powstającego opracowania). Na życzenie recenzentów organizowane są tele- lub video- konferencje, jednak nie zastępują one pisemnej formy przekazania mi materiałów źródłowych. Spotkania służą wyłącznie do prowadzenia uzgodnień, wyjaśnień, szkoleń.
Narzędzia i metody w projekcie
Podobnie jak wielu analityków na świecie, zrezygnowałem z wywiadów i cyklicznych grupowych warsztatów w lokalizacji klienta, na rzecz zdalnej pracy opartej na przekazanych mi pisemnie materiałach (dokumentach źródłowych) a także (patrz: niska efektywność spotkań i ich ogromne koszty), zaś standardowo zdalna praca w moich projektach to obecnie 100%.
Dzięki temu łączna pracochłonność (szczególnie po stronie kadr zamawiającego) i koszt projektu, są nawet o 70% niższe, w porównaniu z cyklicznymi spotkaniami i używaniem oprogramowania biurowego (email, edytor tekstu, arkusz kalkulacyjny) do komunikacji i wymiany treści! (przeczytaj też: Dlaczego nie używam poczty elektronicznej do przekazywania materiałów).
Jeżeli Zamawiający nalega na spotkania i warsztaty są one rozliczane jako dodatkowe zlecenia.
Zrezygnowałem także z prostych metod opisowego specyfikowania wymagań bazujących wyłącznie na wywiadach z przyszłymi użytkownikami, bo są to metody nieskuteczne, tak powstające specyfikacje są niekompletne, stwarzają ogromne ryzyko dla projektu .
W trakcie projektu nie używam pakietów biurowych, nie tworzę arkuszy kalkulacyjnych ani dokumentów w edytorach tekstów. Produktem „do czytania” (i do ewentualnego druku) jest dokument PDF stanowiący pełną specyfikację z diagramami i opisującym je tekstem. Jako produkt pracy przekazuję także edytowalny plik źródłowy w formacie XMI zawierający wszystkie opracowane modele i struktury, wyrażone w notacjach BPMN i UML.

Do zdalnej pracy wykorzystuję, i udostępniam klientom, jedno z najlepszych narzędzi wspierających takie projekty na rynku: oprogramowanie PostMania firmy Visual-Paradigm, z którego korzystają największe koncerny na świecie (lista i referencje wybranych użytkowników pakietu Visual-Paradigm, bezpieczeństwa wykorzystywanego repozytorium VP). Visual-Paradigm to narzędzie CASE (ang. Computer Aided System Engineering, komputerowe wspomaganie inżynierii systemów). Stosuję go w całym procesie analizy i modelowania, oraz w toku tworzenia dokumentacji projektowej i zarządzania nią.
Wszystkie przesłane mi dokumenty są chronione (kodowane), ich kopie zapasowe są wykonywane w trybie dobowym. Powstające treści są wersjonowane, wprowadzane zmiany są śledzone i dokumentowane. Każda nowa treść lub jej zmiana (zwana korektą – revision) jest odnotowywana, oznaczona w czasie i numerowana.
Zapoznaj się z opisem: Visual Paradigm PostMania – Przewodnik Recenzenta.
Komunikacja
Poniżej porównanie tradycyjnej metody pracy (po lewej) i pracy on-line z użyciem platformy komunikacyjnej Postmania (po prawej):

Proces wymiany informacji
Wymiana informacji w projekcie polega na iteracyjnym procesie dostarczania informacji i materiałów źródłowych do analizy oraz zgłaszaniu uwag i potrzeb zmian do powstającego na ich podstawie opracowania: modeli i ich opisów. UWAGA! Notatki ze spotkań stanowią dostarczany materiał, więc z zasady robi je i przekazuje strona udzielająca informacji.
Na etapie audytu i projektowania w procesie tym bierze udział zespół pracowników analizowanego podmiotu. Po podpisaniu umowy z dostawcą rozwiązania, także zespół dostawcy. Od tego momentu zaczyna się etap nadzoru autorskiego prowadzonego przez Autora projektu rozwiązania (Analityk). Proces komunikacji obrazuje poniższy diagram:

- Członkowie zespołu Zamawiającego, w odpowiedzi na moje pytania, odpisują lub przekazują określone informacje w formie dokumentowej (przykłady dokumentów, dokumenty źródłowe, opisy itp.), a następnie zgłaszają swoje uwagi do powstających schematów blokowych i powiązanych z nimi opisów, tak powstają kolejne rozdziały wykonywanego raportu z audytu i specyfikacji wymagań (schematy blokowe i ich opisy), które na bieżąco udostępniam do weryfikacji członkom zespołu Zamawiającego (recenzenci); na każde żądanie uczestników projektu, wysyłam aktualny draft Opracowania w postaci pełnego tekstu jednolitego (plik pdf).
- Po zakończeniu etapu analizy i specyfikowania rozwiązania wybierany jest dostawca Rozwiązania. Dostawca rozwiązania (integrator, developer), po otrzymaniu Wymagań (produkt Analizy Biznesowej), jeżeli potrzebuje dodatkowych informacji, zgłasza takie pytania, w odpowiedzi otrzymuje uzupełnione opracowanie Analiza Biznesowa i Projekt Techniczny. Wszelkie uzupełnienia powstają z udziałem Podmiotu audytowanego, opisanego w Wymaganiach.
- Tak aktualizowany dokument: Analiza Biznesowa i Projekt Techniczny, jest jedyną formą przekazywania informacji podmiotowi dostarczającemu rozwiązanie. Dzięki temu Zamawiający ma stale aktualizowaną dokumentację opisującą jego działalność, a Dostawca ma spójny i kompletny opis wymagań w postaci jednego zwartego opisu.
- Dostawca na podstawie treści dokumentu Analiza Biznesowa i Projekt Techniczny, opracowuje swoją Koncepcję Wdrożenia. Ewentualne notatki spisywane np. na spotkaniach przez Dostawcę, nie stanowią sobą żadnych uzgodnień o wymaganiach. Jedynym źródłem informacji o podmiocie audytowanym jest Analiza Biznesowa i Projekt Techniczny, jako spójny, niesprzeczny i kompletny opis biznesowy i opis wymagań Zamawiającego.
Wymagania biznesowe czyli potrzeby Zamawiającego
Po wykonaniu audytu i modelu procesów biznesowych oraz opracowaniu rekomendacji ewentualnych zmian, określane są Potrzeby Zamawiającego. Są to wymagania wobec rozwiązania, wyrażone przez Zamawiającego językiem naturalnym z perspektywy przyszłego użytkownika rozwiązania. Zarówno w sferze poprawy efektywności na etapie analizy procesów biznesowych, jak i w stosunku do oprogramowania, jeżeli jego zakup i wdrożenie okażą wymaganym rozwiązaniem.
Zamawiający co do zasady dostarcza mi materiały źródłowe, jednak gorąco odradzam samodzielne projektowanie rozwiązania informatycznego czyli spisywanie „co i jak system ma coś robić” albo, co gorsza, samodzielne tworzenie schematów blokowych i opisów procesów czy systemów IT, gdyż przynosi to więcej szkody niż pożytku: samodzielne opracowywanie tych schematów prostymi programami biurowymi, przez nieprzygotowane do tego i niedoświadczone osoby, jest pracochłonne a uzyskane efekty rzadko kiedy wnoszą wartość do projektu . Lepiej więc, gdy Zamawiający zrobi to co bardzo dobrze potrafi: spisze swoje potrzeby.
Kluczowe pojęcie na tym etapie to
potrzeba: funkcja, której brakuje do osiągnięcia celu lub wykonania działania
Powstaje zestawienie wymagań biznesowych wyrażonych jako «potrzeby interesariuszy». Zestawienie to należy dostarczyć w postaci tabeli:
Źródło wymagania | Potrzeba | Obecny problem |
Dyrektor Logistyki | Zarzadzanie dostawami niezależnie dla każdego zamówienia | Brak możliwości nadzoru bieżącego stanu częściowej realizacji zamówień |
Dyrektor Handlowy | Dokumentowanie sprzedaży promocyjnej | Ręczne wstawanie do faktur cen innych niż katalogowe |
Prezes | Bieżące śledzenie wartości przychodów | Brak wiedzy o bieżącej wartości sprzedaży w określonym okresie |
Zalecanym uzupełnieniem jest określenie biznesowego celu projektu na tle misji i wizji organizacji (patrz: Audyt spójności wizji i misji organizacji z jej działaniami):
- misja: (jak sobie wyobrażamy nasz przyszły rynek),
- wizja: (nasz wkład w osiągnięcie powyższego stanu rzeczy),
- cel biznesowy organizacji: (planowana pozycja na rynku, fuzja, inne),
- kluczowy problem: (co jest głównym powodem inicjacji projektu).
Wymagania biznesowe są podstawą rozpoczęcia projektowania rozwiązana.
Rola Recenzenta
Wprowadzenie

Zamawiający (a później także dostawca rozwiązania) dostaje do zapoznania się dokument Analiza Biznesowa i Projekt Techniczny Rozwiązania, zawierające opisy i schematy blokowe. Lokalni eksperci, członkowie zespołu Zamawiającego (organizacja analizowana i opisywana), oraz później także zespołu Dostawcy Rozwiązania, występują w roli recenzentów: dostają dostęp do poszczególnych elementów tej dokumentacji i zgłaszają uwagi i pytania.
Dokument Analiza Biznesowa i Projekt Techniczny to schematy blokowe wraz z ich opisami, są one także dostępne ad-hoc jako jednolity dokument PDF oraz on-line, do bieżącej pracy, za pośrednictwem systemu recenzji Postmania. Są to schematy jak te poniżej.
Struktura organizacyjna

Powyższy schemat to sformalizowana struktura organizacyjna zobrazowana jako „drzewo zależności przełożony-podwładny”.
Przepływ pracy czyli procesy biznesowe

Na powyższym schemacie pokazano proces biznesowy: aktywności oraz ich dane wejściowe i wyjściowe. Wszelkie dodatkowe detale niosą dokumenty (symbole z zagiętymi rogami na diagramie powyżej), reguły biznesowe (spisywane w postaci zestawienia w treści opracowania lub na schematach np. powyżej: Budżetowanie. BR002).
Dokument i jego treść
Struktury dokumentów są dokumentowane jako ich uproszczone szablony, np. jak ten poniżej:
![Diagram: DOC Karta Wypożyczenia Każdy formularz ekranowy i wydruk muszą być udokumentowane w sposób pozwalający na zapewnienie spełnienia wszystkich wymagań biznesowych zamawiającego. Wszystkie atrybuty dokumentów muszą być zdefiniowane w Biznesowy słownik pojęć [SBVR] a logika biznesowa w Reguły Biznesowe [SBVR]. Struktura poszczególnych atrybutów jest definiowana jak typy strukturalne (patrz: Biblioteka DTO i typy).](https://it-consulting.pl//wp-content/uploads/2020/05/diagram-doc-karta-wypozyczenia-kazdy-formularz-e.png)
Struktury dokumentów niosą najwięcej detalicznych informacji o przetwarzanych danych i związkach miedzy nimi.
Biznesowy słownik pojęć
Podstawą zrozumiałości i jednoznaczności dokumentacji jest jednolity, spójny i kompletny słownik pojęć dla całego projektu (generalnie dotyczy całej organizacji). Celem jest zapewnienie jednoznaczności treści nie tylko dokumentacji projektowej ale też wszystkich elementów na modelach procesów i systemu jakim jest oprogramowanie. Co do zasady słownik ma postać alfabetycznej listy, jednak kluczowe dla zrozumienia i interpretacji pojęcia, dodatkowo weryfikujemy z pomocą tak zwanego modelu pojęciowego (diagram klas UML, lub model faktów SBVR, ). Jest to schemat blokowy, na którym umieszczamy kluczowe pojęcia i łączymy je związkiem generalizacji lub określonym faktem (predykat). W ten sposób sprawdzamy, czy pojęcia te tworzą poprawne i prawdziwe zdania w języku naturalnym danej dziedizny. Np. poniżej:
Powyższe czytamy:
- kopia dokumentu i oryginał dokumentu to rodzaj (typ) dokumentu
- faktura jest typem dokumentu
- system kancelaryjny zapewnia poprawny obieg dokumentów
- dokument jest przyporządkowany do sprawy
UWAGA! Ten diagram to nie jest proces biznesowy!
Mechanizm działania systemu
Mogą sie pojawić inne, uzupełniające schematy blokowe:

Dokument (każdy obiekt lub komponent w systemie) mogą mieć stany i statusy, modelowane jak poniżej:

Powyższe to treści adresowane do pracowników organizacji analizowanej. Są częścią raportu z Audytu Procesów Biznesowych Organizacji.
To co system ma robić czyli wymagane usługi aplikacji i zakres projektu
Wymagania Zamawiającego (biznesowy kontekst i otoczenie projektu) dokumentowane są jako model usług aplikacji:

Następująca po niej część dokumentacji, zatytułowana Opis Techniczny Oprogramowania, także zawiera schematy blokowe, są to jednak specjalistyczne modele adresowane do dostawcy oprogramowania, który składając ofertę musi oświadczyć, że zna standardowe techniki analizy i modelowania systemów informacyjnych (w tym systemy notacyjne BPMN i UML).
Spotkania
W ramach realizowanej usługi odbywają się spotkania statusowe (ustalenia planowanych działań w projekcie). Wszelkie dodatkowe warsztaty inicjowane przez Zamawiającego stanowią dodatkowe płatne spotkania.
Spotkania są realizowane jako video- i tele- konferencje. Standardowo wysyłam link do spotkania on-line. Jeżeli macie Państwo w swojej firmie wdrożony swój własny system wideokonferencyjny, może być on używany w projekcie. Jedynym ograniczeniem jest brak konieczności instalowania dedykowanego oprogramowania na moim komputerze.