RePo – relikt przeszłości!?


„RePo” w slangu analitycznym to oczywiście pojęcie oznaczające repozytorium analityczne, bazę wiedzy, wspierającą zarządzanie informacją o realizowanych przedsięwzięciach. Dlaczego warto posiadać repozytorium analityczne? W świecie „zwinności” często pojawia się pogląd, że jest to relikt przeszłości i że ‚damy radę zwinnie’. Niniejszy chciałbym jednak przytoczyć kilka argumentów na to, że to błędne założenie.

Oto kilka z nich:

Zachowanie „know how”

Mitygacja ryzyka utraty „know how” to w dzisiejszym świecie zdominowanym przez „milenialsów” (z całym szacunkiem) wartość najwyższa. „Data is new oil”. Wiedza o realizowanych przedsięwzięciach bywa ulotna (niestety) i odchodzi wraz z wyżej wymienionymi. Tym samym posiadanie trwałej bazy wiedzy, hierarchicznej i uporządkowanej, staje się koniecznością. Co nam po najlepszych rozwiązaniach, jeśli może się okazać, że wraz z utratą ludzi, którzy je tworzyli, w razie potrzeby dalszego rozwoju będziemy zmuszeni budować wszystko od początku?

Wiedzę należy gromadzić na bieżąco, by koszty tego procesu były najniższe. Odbudowywanie dokumentacji post factum bywa kosztowne i często z perspektywy menadżerów uznawane za niepotrzebne. Niemniej nigdy nie jest za późno, by zebrać wiedzę o tym, co i jak zostało zrobione.  Rzecz w tym, aby forma i treść tych zabiegów nie wygenerowały kosztów, które przerosną wartość samego rozwiązania.

 

Propagacja informacji

Jednym z większych wyzwań jest efektywne dzielenie się wiedzą w organizacji. Posiadanie repozytorium analitycznego znacznie poprawia propagację informacji o realizowanych przedsięwzięciach. Niemniej posiadanie informacji to jedno, a korzystanie z wartości, jaką sobą przedstawiają – to drugie. W tym miejscu kryje się krytyczna kwestia w zarządzaniu projektami, zwłaszcza jeśli są to większe złożone rozwiązania, w rozproszonej architekturze.

W przypadku małych projektów, realizowanych w zespołach kilkuosobowych, dzielenie się wiedzą nie stanowi większego wyzwania. Wystarczą tablica, Kanban, czasem JIRA i – mówiąc kolokwialnie – można „lecieć z tematem”. Ale co jeśli system jest rozwiązaniem klasy enterprise, w architekturze rozproszonej? Mnożą się pytania. Jak zarządzać architekturą rozwiązania? Co z modelem korowym? Jak ocenić wpływ jednej inicjatywy na drugą? A może już mamy takie rozwiązanie lub część jego funkcjonalności, tylko nikt w organizacji się tym nie „pochwalił”?

Statyczne repozytoria typu Confluence mogą poprawiać sytuację, ale nieznacznie. Potrzebne jest narzędzie, które zapewni dostęp do informacji z takiej perspektywy, jak analiza wpływu, analiza luk, status realizacji poszczególnych funkcjonalności i tak dalej. I najważniejsze: wszystko to powinno być dostępne najlepiej w przeglądarce internetowej i spięte z aktualnymi informacjami o realizowanych projektach, o sposobie realizacji, na różnym poziomie szczegółowości.

Wyzwanie wydaje się karkołomne, kosztowne i z góry skazane na niepowodzenie…? Otóż nie! Są takie rozwiązania i tylko od determinacji osób zaangażowanych w zasilenie ich informacją, będzie zależał końcowy efekt. Z mojego doświadczenia wynika, iż największym wyzwaniem jest współdzielenie tych samych informacji na różnym poziomie szczegółowości opisu. Tu z pomocą może przyjść dobry metamodel definiujący klasy informacji oraz atrybuty je opisujące.

Przykładowy metamodel opisujący architekturę informacji repozytorium analitycznego

Narzędzie wsparcia decyzji

Jedna z kluczowych, o ile nie najważniejsza, rola bazy wiedzy to dostarczanie informacji zarządczej. Chciałbym obalić tu pewien mit, a mianowicie: repozytorium analityczne nie służy przygotowywaniu dokumentacji analitycznej czy projektowej. To jest produkt uboczny procesu analizy zagadnienia (wykonywanej na bazie repozytorium analitycznego). Informacja utrzymywana w repozytorium powinna być zorientowana na tak zwane punkty widzenia, czyli możliwość przygotowania syntetycznych widoków, prezentujących rozważane zagadnienie w sposób obrazowy, pozwalający sformułować wnioski, a na ich podstawie podjąć decyzję: robimy lub nie, dobry pomysł lub nie, zaprowadzi nas to na manowce, można inaczej lub mimo wysokich kosztów inaczej się nie da i tak dalej…

By podejmować takie decyzje, trzeba mieć bazę wiedzy i dbać o utrzymanie jej aktualności. Źródłami wiedzy mogą być poszczególne domeny informacji: od elementów architektury korporacyjnej (np. model motywacji), poprzez specyfikację istniejących rozwiązań na poziomie analitycznym i projektowym, aż po zagadnienia opisywane przez CMDB na poziomie pojedynczych jednostek konfiguracji oraz wymiarów je opisujących (np. EOL, stosy technologiczne, strategie doboru technologii i inne). Dobre narzędzie wsparcia decyzji powinno pozwalać „drążyć” informację i poruszać się od ogółu do szczegółu i odwrotnie. Temu właśnie służą punkty widzenia bazujące na katalogach informacji zbieranych w repozytorium oraz relacje, które je wiążą.

Odniesienie do realizowanej strategii

Nie bez znaczenia pozostaje kwestia zbieżności realizowanych projektów ze strategią. Dość oczywistym, chociaż nie zawsze obecnym w świecie IT, jest fakt, że to, co robimy w IT, ma służyć biznesowi. To biznes zamawia usługi w IT, nie odwrotnie. Tym samym umiejętność powiązania dobrze udokumentowanych trosk biznesu ze wspierającymi je rozwiązaniami informatycznymi daje szansę, by odpowiedzieć sobie na pytanie, czy realizowane przedsięwzięcie jest potrzebne (krytyczne) czy jest tylko wyobrażeniem zaspokajania potrzeby biznesu z perspektywy IT? Niestety zdarza się, że ta odpowiedź wskazuje na niezrozumienie prawdziwych potrzeb biznesu. Wówczas mamy do czynienia z fiaskiem projektu i frustracją sponsorów.

Zarządzanie zakresem i dostępem do informacji

Jeśli jednak uda nam się trafnie zdefiniować, co mogłoby naszego potencjalnego klienta wspomóc, warto pozostawić sobie ten punkt widzenia i przystąpić do definiowania syntezy powyższych wniosków. Posiadanie odpowiednio dobranych narzędzi pozwala na elastyczne przygotowanie informacji dla interesariuszy realizowanych przedsięwzięć. W zasadzie po to kreuje się i utrzymuje repozytoria – aby, operując określonym zakresem informacji, prowadzić dywagacje nad rozwojem rozwiązań w funkcji przyjętej strategii, kosztów, priorytetów (głównie biznesowych) czy też spójności rozwiązania jako całości.

Takie podejście wymusza selekcjonowanie informacji i podawanie ich w formie zrozumiałej dla odbiorcy, w zakresie, który go nie przytłoczy, a jednocześnie pozwoli zaadresować wszystkie istotne kwestie z perspektywy rozważanego problemu. I tak na przykład inne informacje dostarczymy partnerom biznesowym, innych wniosków i informacji zwrotnych będziemy oczekiwali, a jeszcze inaczej należałoby komunikować decyzje i analizować ich konsekwencje wewnątrz zespołów wytwórczych.

Tylu interesariuszy i beneficjentów informacji – jedno repozytorium! Co więcej, powyższe zagadnienia nie powinny być rozpatrywane w oderwaniu od siebie. I tu właśnie mamy do czynienia z siłą narzędzi Case i wspomagających je narzędzi do komunikacji. Jedna baza wiedzy, wiele punktów widzenia – spójne wnioski! Oto niektóre z nich:

  • Troska biznesu, która definiuje cel biznesowy.
  • Wymagania biznesowe precyzujące oczekiwania biznesowe interesariuszy.
  • Macierz dekompozycji funkcjonalnej obrazująca ramy systemu i zakres jego wsparcia dla poszczególnych wymagań biznesowych.
  • Wreszcie analiza szczegółowa, która skupia się na opisie sposobu realizacji funkcjonalności. Tak dochodzimy do zakresu projektu.
  • Ważne, aby informacje podawane były w przejrzysty sposób, aby jedna wynikała z drugiej, a wszystko stanowiło całość.

Przykładem narzędzi pozwalających na zarządzanie informacją może być tandem narzędzi : Prolaborate, współpracujący z repozytorium zarządzanym przez „Enterprise Architect”. Jedno z nich stanowi bardzo skomplikowane, ale i efektywne narzędzie do zbierania informacji i syntezy wniosków, drugie zaś pozwala na podanie tych informacji w atrakcyjnej i przystępnej formie. Szczegółowemu omówieniu modelu współpracy tych dwóch rozwiązań poświęcę osobny artykuł.

Dostęp do tzw. analizy wpływu nowych na posiadane rozwiązania

W przypadku mniejszych rozwiązań powyższe zagadanie nie jest aż tak krytyczne, jak dla większych systemów. Analiza wpływu decyzji podejmowanych w jednym obszarze na pozostałe staje się kluczowa i niesie za sobą poważne konsekwencji biznesowe i / lub finansowe. Warto o tym wiedzieć zawczasu i mieć szansę na ewentualne korekty (najlepiej w funkcji przyjętej strategii). Analiza wpływu najczęściej sprowadza się do kontroli sieci powiązań pomiędzy obiektami modelu. To właśnie ta własność narzędzi analitycznych pozwala na szybką ocenę skali zmian potrzebnych do dostarczenia wartości biznesowej, umożliwia zarządzanie ryzykiem utraty ciągłości działania (tak zwany BCM – Business Continuity Management). Warto o tym pamiętać, projektując nowe rozwiązania. Bardzo pomocny w analizie tych zagadnień będzie przemyślany model danych opisujący architekturę informacji utrzymywanych w repozytorium.

Architektura logiczna rozwiązania pozwala zrozumieć zależności pomiędzy obszarami systemu

Analiza luk w obszarze rozwoju

Rozwiązania powinny być kompletne, co wydaje się dość oczywiste. Nie ma nic gorszego niż urwana w połowie customer journey. Brak możliwości przejścia przez cały proces tylko dlatego, że ktoś nie zadbał o kompleksowe spojrzenie na całość rozwiązania, może położyć cały projekt. I tu znowu możemy użyć modeli pozwalających ocenić, czy dane rozwiązanie jest kompletne, czy przepływy danych gwarantuje ciągłość procesu, czy nasze rozwiązanie dostarcza w pierwszej kolejności tych krytycznych funkcjonalności? Szukajmy tych informacji w repozytorium.

 

Macierz dekompozycji funkcjonalnej. Narzędzie pozwala na analizę luk w rozwiązaniu i bada stopień pokrycia trosk biznesu funkcjonalnościami systemu.

Identyfikacja „błędów” na bazie „twardych” zapisów w analizie

Na koniec argument prozaiczny, ale nie mniej istotny, z cyklu „klient zamówił, a dostał…” Posiadanie twardych zapisów jednoznacznie prezentujących uzgodniony zakres bywa koronnym argumentem w takich sytuacjach. Identyfikowane w fazie odbiorów „błędne” działanie rozwiązania ma swoją genezę w procesie uzgodnień i nieprecyzyjnych zapisach. Wtedy powstaje dyskusja: czy to błąd czy też CR? Narzędzie wspomoże nas podwójnie: po pierwsze da twarde informacje, jak było naprawdę na etapie kontraktowania prac, a po drugie – pozwoli oszacować skalę zmian, aby jednak sprostać oczekiwaniom naszych klientów i być może wyjść z twarzą z takiego impasu, biorąc na siebie koszty dostosowania rozwiązania do stanu oczekiwanego.

 

Powyższe przykłady pokazują jedynie wąski wycinek zagadnienia, jakim jest wykorzystanie repozytorium analitycznego w codziennej pracy, ale też w budowaniu strategii, określaniu priorytetów czy też projektowaniu procesu efektywnej komunikacji pomiędzy wszystkim interesariuszami realizowanych przedsięwzięć. Czy warto? Moim zdaniem tak. Co więcej, nie wyobrażam sobie pracy bez takich narzędzi. I mniejsza o to, czy jesteśmy zwinni czy działamy w stylu klasycznym. Baza wiedzy i jej mądre wykorzystywanie zawsze się opłaca. Oczywiście, wymaga to sporo czasu i niemałego zapału, ale nic, co wartościowe, nie może być zdobyte bez ryzyka i wysiłku.

 

Dodaj komentarz

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