Optymalne środowisko pracy analityka

Jacek 30 stycznia 2022 2 Comments

Optymalne środowisko pracy analityka?

Dużo piszę i mówię o repozytorium analitycznym i jego przeznaczeniu. Temat jest mi o tyle bliski, że od lat szukam sposobu, aby przybliżyć świat trosk i wyzwań analityków szerszej grupie osób zaangażowanych w dostarczanie rozwiązań dla biznesu. W tym również rozwiązań IT.

Poszukiwania te skłoniły mnie do następujących wniosków:

  1. Repozytorium analityczne jest potrzebne (zwłaszcza dla dużych projektów)!
  2. Czy zwinnie, czy klasycznie – baza wiedzy ma rację bytu!
  3. Architektura informacji na miarę potrzeb a nie aspiracji!
  4. Narzędzia CASE nie są przeszkodą – dobrze stosowane mogę uzdrowić sytuację…!

I na tym ostatnim chciałbym się skupić.

Z racji moich doświadczeń ale też wiedziony pasją do poznawania coraz to nowych rozwiązań i technologii od lat poszukuję sposobu aby ułatwić życie zawodowe sobie ale też może przy okazji innym. Nie lubię wykonywać tej samej pracy po kilka razy. Lubię dzielić się wiedzą i tym co udało mi się zrobić raz i dobrze. Cenię sobie informację zwrotną i rzeczową dyskusję oraz konstruktywną krytykę. Wyznaję zasadę „robić coś dobrze, albo wcale!”.

W powyższym kontekście w mojej pracy zawodowej postawiłem na narzędzie CASE firmy Sparx Systems – Enterprise Architect (w skrócie EA), jako rozwiązanie moich problemów z pracą u podstaw. Okazało się, że wiele z moich problemów z zarządzaniem dużym zakresem informacji, formułowaniem wniosków, analizą wielowymiarowych zagadnień znalazło swoje rozwiązanie w tym właśnie narzędziu i jego wykorzystaniu.

EA jako narzędzie CASE bardzo mocno rozwinął się na przestrzeni kilku ostatnich lat. Do wersji 11 stosunkowo niewiele się tak naprawdę działo. Głównie pojawiały się nowe dodatki (tzw. MDG – Model Driven Generation, zestawy przyborników wspierających metodyki, ramy architektoniczne i inne pojawiające się nowinki).

Od wersji 12 zaczął się naprawdę dynamiczny rozwój a kolejne wersje i pojawienie się PCS (Pro Cloud Server) to już istna rewolucja. Wreszcie pojawiła się możliwość pracy grupowej, przeniesienia repozytoriów do chmury, współdzielenia danych. Niemniej EA wywodzi się ze świata projektowego i cały czas ta specyfika jest tu obecna. Mówiąc wprost dalej jest to dość zaawansowane i techniczne narzędzie. Dla współpracy z biznesem raczej trudne do zaakceptowania począwszy od sposobu zbierania i utrzymana informacji aż po formy jej prezentacji. Według mnie rzecz gustu i przyzwyczajenia ale faktycznie wymaga trochę czasu oswojenie się z interfejsem graficznym. Co gorsza firma Sparxsystems cały czas zmienia ten interfejs poszukując optymalnego rozwiązania i muszę przyznać – idzie im coraz lepiej. W ostatniej wersji (14.0) położono bardzo duży nacisk na ergonomię i sposób prezentowania informacji. Pojawiło filtrowanie kontekstowe, różne listy, widoki kontekstowe – niemniej to dość zaawansowane funkcjonalności.

To czego przez cały czas mi brakowało w tym narzędziu i co dalej pozostaje trudnodostępne, to łatwości w dzieleniu się zebranymi informacjami i wnioskami, jakie na ich podstawie formułuję.

I tak oto znalazłem dwa narzędzia:

eaDocX to generator dokumentacji z repozytorium analitycznego jakim jest Enterprise Architect. Wbudowany w EA narzędzie do generowania dokumentacji jest dość skomplikowane i mało intuicyjne. Stąd też tak wiele inicjatyw mających na celu przygotowanie własnych narzędzi do wyciągania z EA informacji. Na rynku polskim swego czasu funkcjonowało narzędzie „Tormigo” firmy „Modesto”, autorstwa Michała Wolskiego. Była to całkiem udana próba zbudowania zestawu narzędzi raportowych, niemniej oferowała pewien zamknięty zakres raportów jakie przewidział autor i z mojej perspektywy okazało się to niewystarczające – musiałem szukać dalej.

Po wielu próbach z wbudowanym w EA generatorem natrafiłem w końcu na eaDocX – i to był przełom.

Wreszcie mogłem zdefiniować własny metamodel repozytorium i na jego podstawie przygotować punkty widzenia interesujące z perspektywy odbiorców mojej pracy. Co więcej, udało mi się odchudzić dokumentację i przejść z podejścia holistycznego, zbierającego wszystkie informacje umieszczone w pakietach w repozytorium analitycznym na podejście kontekstowe, bazujące na interesujących mnie informacjach, spiętych metamodelem. Eureka! Wreszcie! Nota bene później, ze względów sentymentalnych tak nazwałem metodykę pracy z repozytorium analitycznym, czerpiącą z moich doświadczeń. Metodyka ta stosowana jest w firmie Atena.

Przygotowany został zestaw szablonów dokumentów, wypełnianych treścią pochodzącą wprost z repozytorium a zadanie to wykonuję z wykorzystaniem narzędzia eaDocX.

Wystarczy modelować (podkreślam to słowo) w EA, zgodnie z wytycznymi (w tym przypadku metodyki Eureka) a mamy gwarancję, że przygotowane dokumenty będą spójne i zawierały tylko te informacje, których oczekuje dany interesariusz. Zakres i forma tych informacji przewidziany dla danego odbiorcy, adresuje zagadnienia występujące na danym etapie prowadzenia projektu. Na początek skupiamy się na budowaniu koncepcji rozwiązania i tu istotne będą biznesowy cel projektu i partykularne troski biznesu. Aby koncepcja była poprawna, ważne jest aby już na tym etapie referować do elementów modelu odpowiadającym planowanym pracom i zmianom w systemie. Oznacza to, każda troska biznesowa powinna być zaadresowana (lub świadomie pominięta) w zakresie projektu. Wskazujemy na elementy wymagające zmiany lub nowe jakie mają się pojawić w systemie. Tak opracowany model jest podstawą do przygotowania koncepcji rozwiązania na poziomie funkcjonalnym i architektury logicznej. A potem już tylko eaDocX… Mamy gotowy dokument dla klienta – załącznik do oferty.

Po zatwierdzeniu oferty, której integralną częścią jest powyższa koncepcja rozwijane są opisy wymagań  funkcjonalnych i następuje żmudna praca analityczna, skupiona na opisie intencjonalnym tego co system będzie realizował oraz planowaniu sposobu realizacji tych funkcjonalności, czyli przypadki użycia, prototypowanie GUI, opis logiki wewnętrznej systemu, integracji itd. A potem, już tylko eaDocX… I mamy dokument analizy szczegółowej.

Przystępujemy do fazy realizacji no i okazało się, że jednak o czymś zapomniano, coś zostało mylnie zinterpretowane. Pojawia się zgłoszenie zmiany! Należy wrócić do repozytorium i nanieść korekty. Ale uwaga, nie generujemy dokumentacji po raz kolejny a jedynie kontekst tego, co zostało dotknięte zmianą. A potem już eaDocX… no i tu pojawia się prawdziwa siła tego narzędzia! Nie musimy zastanawiać się, które elementy pobrać do dokumentu aby zilustrować skalę zmian. Wystarczy, że wskażemy te element w repozytorium poprzez relacje. A potem to już eaDocX… Możemy wysłać dokument opisujący zakres zmian CR wraz z wyceną i poprosić o akceptację.

Przykładów można mnożyć. Od pomysłowości i konstrukcji architektury informacji zależy, jak zaawansowane do kogo adresowane będą poszczególne zrzuty z modelu – dokumenty projektowe.

Wersja eaDocX bardziej zaawansowana posiada możliwość wersjonowania tych dokumentów oraz współpracy z XLS i wymiany informacji tym kanałem a następnie uzupełniania danych w modelu na podstawie danych wprowadzonych do arkusza – niemniej to funkcja pomocnicza eaDocX.

Kluczową jest funkcja przygotowania dokumentacji projektowej. Istotne jest też to, że inne informacje otrzyma manager a inne projektant, jeszcze inne tester a na koniec i tak można przygotować całościową dokumentację systemu dla określonej jego wersji w podziale na punkty widzenia istotne dla poszczególnych interesariuszy danego przedsięwzięcia ale źródło wiedzy jest jedno. Spójne. Aktualne. Zbierające i zawierające tyle wiedzy ile potrzeba.

Wydawałoby się, że to optymalne rozwiązanie. Ale czy aby na pewno? Nie dając za wygraną wciąż poszukiwałem rozwiązania, które pozwoli mi ograniczyć stosowanie podejścia 'wordowego’ na rzecz pracy w czasie rzeczywistym na aktualnych informacjach o realizowanym przedsięwzięciu. Bliski już byłem napisania własnego dodatku do EA. I tak oto znalazłem…

Otóż, okazuje się, że można lepiej, inaczej, efektywniej. Nie trzeba rezygnować z dokumentacji MS Word bo jest ona dla dużego grona czytelna i spełnia swoją rolę. Natomiast należy inaczej rozłożyć akcenty w procesie analitycznym i projektowym.

Wiadomo, że przygotowanie dokumentacji, nawet z wykorzystaniem tak dedykowanego narzędzia CASE, jakim jest EA wymaga czasu. Co więcej – późniejsza dystrybucja tej informacji zwłaszcza w podejściu klasycznym generuje inercję. Zebranie informacji zwrotnej, naniesienie jej na model, kolejna analiza wpływu… już słyszę 'Waterfall’, 'analityczne muzeum’, 'działajmy zwinnie, po co nam dokumentacja?’… Odpowiedź na te zarzuty mam jedną. Jest nią Prolaborate.

Prolaborate to nic innego jak przyjazny użytkownikowi interfejs graficzny do dystrybucji informacji o realizowanym przedsięwzięciach. Bazuje na widokach przygotowanych w EA, natomiast jego największą wartością jest wprowadzenie zwinności do procesu uzgodnień i ograniczenie zakresu informacji, podlegających obróbce. Pozwala na zdefiniowanie widoku (repository) i wybranie z (często olbrzymiego) repozytorium analitycznego interesujących fragmentów informacji a następnie dla zdefiniowanych grup użytkowników określenie poziomu dostępu do tych informacji i pracę na 'żywym organizmie’ jakim jest repozytorium, ze wszystkimi tego konsekwencjami. Czyli pozwala obserwować wpływ poszczególnych elementów modelu na pozostałe (śladowanie, impact analysis), widać aktualne statusy i inne atrybuty opisujące te obiekty. Można toczyć dyskusje na temat poprawności i aktualności zapisów dotyczących poszczególnych elementów opisu systemu. Można ewentualnie w funkcji posiadanych uprawnień dokonywać zmian w owych obiektach bezpośrednio na modelu lub wnioskować o zmiany tych zapisów w ramach toczących się dyskusji.

Prolaborate oferuje bogatą gamę integracji z takimi narzędziami jak JOOMLA, JIRA, CONFLUENCE czy wspomniany już eaDocX (w przygotowaniu kolejne integracje). Co ważne, nie wprowadza redundancji informacji a jedynie w inteligentny sposób wykorzystuje dostęp do informacji w narzędziach, z którymi się integruje i zarządza ich korelacją (korelacją informacji w nich zawartych).

Jeśli komuś nie wystarcza to, co oferuje sam Prolaborate w kontekście komunikacji i dyskusji – można wykorzystać integrację z JIRA. Komunikacja jest dwukierunkowa; z poziomu JIRA bardzo łatwo wrócić do modelu EA – za pośrednictwem linku do repozytorium Prolaborate i w ten sposób nie rozpraszać informacji zarządczej wszędzie gdzie się tylko da a bazować na jednym, spójnym repozytorium analitycznym.

Niniejszym zakres informacji, na którym pracujemy kurczy się. EA zapewnia nam jej konsystencję, możliwość analizy wpływu, analizy luk. Prolaborate wystawia tyle ile trzeba. Stajemy się zwinni, nie ma potrzeby przygotowywać kompletnej analizy. Uzgadniamy mały zakres projektu nie tracąc perspektywy całości. Możemy ten mały kawałek, już uzgodniony  skierować do biur wytwórczych a sami skupić się na kolejnej małej iteracji zakresu funkcjonalnego projektu.

Zaczynamy działać dynamicznie nie tracąc jednocześnie wartości jaką daje nam posiadanie repozytorium analitycznego.

I tu często pojawiają się pytania, czy trzeba mieć komplet informacji w EA? Oczywiście, że nie. Występuje tu tzw. efekt kuli śniegowej. Kolejne iteracje projektu dostarczają kolejnych informacji o realizowanych funkcjonalnościach i uzupełniają model. W konsekwencji wystarczy każdą funkcjonalność systemu „dotknąć” raz a jego obraz będzie w końcu kompletny.

W tym wszystkim pomoże nam Prolaborate jako biznesowy interfejs do naszego repozytorium prowadzonego w EA. Na koniec każdej iteracji procesu warto zadbać o przygotowanie dokumentacji na daną wersję systemu z wykorzystaniem eaDocX i odłożyć ją na witrynie projektowej np. na MS SharePoint, zaewidencjonować i odwołać się, kiedy ktoś zapyta o wersjonowanie i 'co było w wersji 1.12 naszego systemu? Jak działał skoro dziś mamy wersję 2.14?”. Tam należy szukać tej informacji.

Tak w skrócie wygląda podróż po narzędziach analitycznych i ich otoczeniu. Taka jest moja wizja, jak można radzić sobie z dużym zakresem informacji, jak ją efektywnie dystrybuować, jak z niej korzystać i jak na jej podstawie formułować wnioski. Wreszcie jak nie przeładować odbiorcy informacją a dostarczyć jednak kluczowych jej składników aby podnieść komfort pracy i dynamikę działań w dostarczaniu rozwiązań dla biznesu.

Wracając do podtytułu; czy to optymalne środowisko pracy? Zapewne uzupełnione, o to co w danej organizacji stosowane wcześniej (np. JIRA, Confluence itd.) dzięki zastosowaniu Prolaborate – może się takim stać. W kolejnych opracowaniach postaram się przybliżyć możliwości samego Prolaborate jak i przedstawić propozycję konfiguracji środowisk bazujących w w/w narzędziach.