Optymalne środowisko narzędziowe 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 (między innymi):

  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ę…

W tym artykule, na tym ostatnim z powyższych wniosków chciałbym się skupić.

Z racji moich doświadczeń zawodowych, ale też wiedziony pasją poznawania coraz to nowych rozwiązań i technologii od lat poszukuję sposobu aby ułatwić życie zawodowe sobie, a przy okazji również innym? To czego nie lubię, to wykonywać tej samej pracy po kilka razy. Natomiast lubię dzielić się wiedzą i tym co udało mi się zrobić raz a 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 tych wyzwań związanych 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, stosowaniu w codziennej pracy.

EA jako narzędzie CASE bardzo mocno rozwinął się na przestrzeni kilku ostatnich lat. Praktycznie aż do wersji 11 stosunkowo niewiele się 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). Reszta ewoluowała dość ospale.

Dopiero od wersji 12 zaczął się dynamiczny rozwój a kolejne wersje i pojawienie się PCS (Pro Cloud Server) to już prawdziwa 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 w nim  obecna. Mówiąc wprost: dalej jest to dość zaawansowane i techniczne narzędzie. Dla współpracy z biznesem raczej trudne do zaakceptowania. Z moich obserwacji trudności sprawiają podstawowe czynności począwszy od sposobu zbierania i utrzymana informacji aż po formy jej prezentacji. Według mnie jest to rzecz gustu i przyzwyczajenia ale faktycznie oswojenie się z interfejsem graficznym EA wymaga trochę czasu. Co gorsza firma Sparx Systems cały czas zmienia ten interfejs poszukując optymalnego rozwiązania i mimo, iż muszę przyznać że idzie im coraz lepiej, ciągłe zmiany menu są irytujące. 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. Nie zmienia to jednak faktu, że dziś nie wyobrażam sobie pracy i tego czym się zajmuje bez wsparcia tego narzędzia.

To, czego przez cały czas mi brakowało w EA, i co dalej pozostaje w nim trudno dostępne, to łatwość w dzieleniu się zebranymi informacjami i wnioskami, jakie na ich podstawie formułuję.

I tak oto znalazłem dwa pomocnicze narzędzia:

eaDocX to generator dokumentacji z repozytorium analitycznego, jakim jest Enterprise Architect. Wbudowane w EA narzędzie do generowania dokumentacji jest dość skomplikowane i mało intuicyjne (trochę programistyczne). Stąd też tak wiele inicjatyw mających na celu przygotowanie własnych narzędzi do wyciągania z EA informacji. Na polskim rynku swego czasu funkcjonowało narzędzie „Tormigo” firmy „Modesto”. Była to całkiem udana próba zbudowania zestawu narzędzi raportowych, niemniej oferowała 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 dla 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 relacjami zgodnie z wcześniej przygotowanym metamodelem. Eureka! Nareszcie! 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 właśnie 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 (uczestnik projektu). 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 istotny będzie 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, że każda troska biznesowa powinna być zaadresowana (lub świadomie pominięta) w zakresie projektu. Ta informacja powinna być łatwo dostępna dla wszystkich uczestników projektu. Technicznie, wskazujemy na elementy wymagające zmiany lub nowe jakie mają się pojawić w systemie i tak opracowany model jest podstawą do przygotowania koncepcji rozwiązania na poziomie funkcjonalnym i architektury logicznej. A potem już tylko eaDocX… Idziemy na kawę i 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. Ważne, że nie zaczynamy pracy od początku, bo fundamenty specyfikacji systemu powstały na etapie koncepcji. A potem, już tylko eaDocX… Idziemy na kawę 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! 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 i przygotujemy opisu kontekstu zmiany, czyli wpływ na istniejące jego funkcjonalności oraz ewentualne nowe. Nie generujemy całej dokumentacji po raz kolejny a jedynie kontekst tego, co zostało dotknięte zmianą. Nasz odbiorca informacji nie musi przebijać się przez setki stron żeby znaleźć co też się zmieniło, tylko czyta dokument opisujący tylko zmiany. Resztę przecież ma w poprzedniej wersji analizy. Tak więc eaDocX… Idziemy na kawę i możemy wysłać dokument opisujący zakres zmian CR wraz z wyceną i poprosić o akceptację.

Przykłady można mnożyć. Od pomysłowości i konstrukcji architektury informacji zależy, jak zaawansowane i 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. O samym eaDocX też można napisać całą serię artykułów. Kto wie, może się podejmę bo narzędzie jest naprawdę genialne.

Kluczową jednak jest funkcja przygotowania dokumentacji projektowej. Istotne jest też to, że inne informacje (inny zakres) 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. Najważniejsze jest to, że źródło tej wiedzy jest jedno. Spójne. Aktualne. Zbierające i zawierające tyle wiedzy ile potrzeba. Jest to repozytorium EA.

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 osób czytelna, wręcz oczekiwana i spełnia swoją rolę. Natomiast należy inaczej rozłożyć akcenty w procesie analitycznym i projektowym. I na to pozwala właśnie Prolaborate.

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ę. Przygotowanie dokumentu, dystrybucja do osób potencjalnie zainteresowanych, 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. Pozwala zatem obserwować wpływ poszczególnych elementów modelu na pozostałe (śladowanie, impact analysis), widać aktualne statusy i inne atrybuty opisujące te obiekty w przewidzianym, konfigurowalnym zakresie i układzie. Można toczyć dyskusje na temat poprawności i aktualności zapisów dotyczących poszczególnych elementów opisu systemu. Można (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 przez osoby do tego uprawnione.

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 o to, 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. To moja koncepcja tego, 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? i wreszcie jak nie przeładować odbiorcy objętością dokumentacji a jednak dostarczyć kluczowych informacji, jak podnieść komfort pracy i dynamikę działań w dostarczaniu rozwiązań dla biznesu nie rezygnując z ważnych etapów wytwarzania oprogramowania w obszarze analiz?

Wracając do tytułowego pytania; 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ć zarówno możliwości samego Prolaborate jak i przedstawić propozycję konfiguracji środowisk bazujących w różnych konfiguracjach w/w narzędzi.


Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

3 komentarzy do “Optymalne środowisko narzędziowe pracy analityka

  • Roman

    Analiza jest szczególnie ważna w biznesie i to dzięki niej optymalizować możemy różnorodne procesy w przedsiębiorstwie. Praca analityka jest więc szczególnie ważna i przekłada się w pewnym sensie na sukces 😉

  • Kamil

    Biznes bez analizy w dzisiejszych czasach mógłby mieć bardzo pod górkę. Szczególnie w dużych firmach jest ta kwestia niezbędna do przebycia i zrealizowania. Sam pracuję w sporej korporacji IT i takich osób zajmujących się tą kategorią zadań jest kilka. Nigdy do końca nie rozumiałem wyższości ich zadań aż mi nie wytłumaczyli jaki to ma wpływ na przedsiębiorstwo.

    • Jacek
      Jacek

      Tak, to dość kluczowe – zrozumieć, że biznes bez IT dziś nie istnieje ale i odwrotnie. Tym bardziej sprawna komunikacja, pozbawiona obciążeń w postaci nadmiaru informacji oraz inercji jakie wprowadzają chociażby dokumenty staje się największym wyzwaniem dla tej synergii. Ja odnalazłem część odpowiedzi na pytania – jak to usprawnić i udrożnić – właśnie w opisywanym powyżej podejściu.