Analiza przyczyn źródłowych analitycznie

To o czym mówią specjaliści dziedzinowi, to nie są wymagania. Nie można ich tak traktować, gdyż szybką ścieżką prowadzi to do problemów w projekcie. Specjaliści dziedzinowi przekazują nam informacje. Ważne, ale jednak informacje. Mogą wśród nich być kandydaci na wymagania. Mogą być propozycje rozwiązań. Mogą być opinie na jakiś temat. Mogą być też problemy. Tym razem na dłużej chciałbym się zatrzymać przy tych ostatnich.

Słownik PWN definiuje termin Problem następująco:

1. «trudna sytuacja, z której należy znaleźć jakieś wyjście»
2. «poważna sprawa, która wymaga przemyślenia i rozstrzygnięcia»

W naszej sytuacji, pierwsza definicja wydaje się być bardziej pasująca do kontekstu. Mamy zgłoszony problem, który należy rozwiązać. Rewolucyjna czujność analityczna natychmiast powinna się w takim momencie zaktywizować, by świadomie odpowiedzieć sobie na pytanie czy to, o czym mówią specjaliści dziedzinowi, to problem źródłowy, czy też, bezpośredni albo pośredni, efekt takowego. Ale skąd mamy to wiedzieć, mógłby pomyśleć początkujący analityk. Jak to skąd, odpowiedziałby analityk bardziej doświadczony. Znasz fajf łaj?

5 Why

Po co 5 Why? Ano po to, by w dość prosty sposób zweryfikować, czy mówimy o problemie źródłowym, czy raczej o jego skutkach.

Mnóstwo czasu i nerwów tracimy na łączenie się z usługami zewnętrznymi.
O kurcze, to mamy problem. Dlaczego tak się dzieje?

Aaaaaa, bo usługa zewnętrzna rzuca błędami.
Dlaczego?
Bo okazuje się, że nie wszystkie parametry podałem tak, jak jest to wymagane.
Zapomniałeś o czymś?
Nie, nie wiedziałem.
Dlaczego nie wiedziałeś?
Bo analitycy mi nie powiedzieli.
Analitycyyy, dlaczego nie powiedzieliście?
Bo nie wiedzieliśmy.
Ale jak to?
Bo nie ma czasu na tak pogłębioną analizę.
Nie, a dlaczego?
Takie są ustalenia kierownika produkcji.

Przenosząc rozmowę na omawianą technikę, moglibyśmy uzyskać strukturę jak poniżej. Analizę zaczynamy od problemu. Następnie kolejno odpowiadamy na pytanie Dlaczego (tak się dzieje). Po osiągnięciu zadowalającej odpowiedzi, którą uznajemy za przyczynę źródłową kończymy serię pytań. Oczywiście liczba pytań dla danego problemu może być różna od 5.

W konsekwencji tej analizy, powinniśmy wskazać dodatkowo środki zaradcze, które przełożą się na usunięcie przyczyny źródłowej problemu (w przykładzie jest to usprawnienie procesu produkcyjnego).

Rys. Struktura przykładowego wnioskowania

Struktura wnioskowania nie w każdym przypadku będzie jednowątkowa – może się bowiem okazać, że odkryjemy kilka odpowiedzi na jedno pytanie Dlaczego. Taką sytuację prezentuje ilustracja poniżej.

Rys. Rozbudowana struktura przykładowego wnioskowania

Rozwijając wariantowość poszukiwań, warto mieć na uwadze, iż już pierwszy pytanie Dlaczego spowoduje, że rozpoczniemy osobną gałąź drzewa poszukiwań przyczyny źródłowej. W takiej sytuacji przydatnym może się okazać…

Diagram Ishikawy

Diagram Ishikawy, krótko mówiąc, jest techniką, która podpowiada kategorie problemów, od jakich można rozpocząć analizę przyczyn źródłowych. Po zidentyfikowaniu głównej kategorii dalej wykorzystujemy już znane nam 5 Why.

Oryginalna wersja Diagramu Ishikawy nawiązuje do typowych zagadnień produkcyjnych. Wydaje się, że dużo bardziej interesującą z punktu widzenia Analizy Biznesowej może być wersja zaproponowana przez McKinsey (7S). Taksonomia ta została wykorzystana do rozwinięcia omawianego problemu o kolejne przyczyny. Jak widać, w każdym przypadku stosujemy technikę 5 Why, natomiast konary zaproponowanego drzewa pozwalają na na ukierunkowanie kierunku myślenia na określone kategorie.

Rys. Diagram Ishikawy dla omawianego przykładu

Diagramy Ishikawy można także z powodzeniem dekomponować. Na przykład, gdyby się okazało, że dla przyczyny Programiści błędnie podają parametry wywołania usług, jest jeszcze kilka rozgałęzień, diagram stałby się mało czytelny. W takiej sytuacji można pokusić się o stworzenie diagramu traktującego tę przyczynę jako problem. Tworzy się go zgodnie z omówionymi zasadami, oczywiście mając na uwadze, iż faktyczny problem jest na diagramie pierwotnym.

Rys. Przykładowa dekompozycja

Analiza problemu może nas doprowadzić do wskazania wielu przyczyn źródłowych. Gdyby się okazało, że nie jesteśmy gotowi na usunięcie wszystkich, można przeprowadzić na przykład krótką analizę wartościującą środki zaradcze względem ich wpływu na usunięcie problemu oraz kosztów ich realizacji.

Rys. Przykład analizy atrakcyjności wdrożenia środków zaradczych

Podane techniki wyszukiwania przyczyn źródłowych mają wiele zalet. Są w miarę proste, stanowią zarówno narzędzie analityczne jak i facylitacyjne, więc mogą być z powodzeniem stosowane w trakcie pracy grupowej. Należy jednakże mieć na uwadze, iż jakość wniosków będzie bezpośrednim odzwierciedleniem jakości naszej facylitacji oraz doboru uczestników warsztatów.

Rozmawiając o problemach podczas prac analitycznych pamiętajmy, że specjaliści dziedzinowi niekoniecznie przekazują nam gotowy materiał analityczny. Informacje, to ‚tylko’ informacje. Jeśli jesteśmy informowani o problemie, bądźmy rewolucyjnie czujni i upewniajmy się, czy to faktycznie problem, czy jedynie skutek czegoś głębszego.

Bring Your Own Problem jako rama szkolenia

Szkoleniem analityków biznesowych mam przyjemność zajmować się ponad 20 lat. Pamiętam pierwsze szkolenia prowadzone z podstaw analizy systemowej z wykorzystaniem OMT – jednej z pierwszych rozpowszechnionych notacji obiektowych. Potem przyszły przypadki użycia Jacobsona, Yourdon…i tak rozwijała się analiza oparta o modelowanie w paradygmacie obiektowym. Prowadzone wówczas szkolenia w dużej mierze opierały się o poznawanie notacji i zrozumienie jak różne ich aspekty można ze sobą połączyć. W zasadzie wszystko było nowe.

20 lat później krajobraz analityczny wygląda zupełnie inaczej. Analiza Biznesowa, poprzez szerokie jej potraktowanie w ramach działań IIBA, stała się dyscypliną o bardzo szerokim zasięgu. Z drugiej strony, projekty prowadzone w dużych organizacjach (a głównie na rzecz takich pracuję) wymagają synchronizacji prac (i co ważniejsze, artefaktów w ich ramach powstających) z różnymi obszarami, zarówno merytorycznymi jak i technicznymi. Istotne stają się coraz bardziej kompetencje, pozwalające na skuteczną komunikację z różnymi interesariuszami projektów, jako że coraz bardziej rozrastają się korporacje a wraz z nimi powstają nowe księstwa, które nie zawsze mają interesy zbieżne z interesem organizacji. Na to wszystko nakładają się zmiany kulturowe (choćby wdrażane w różnej formie i skali podejścia zwinne czy też popularyzacja pracy zdalnej) oraz mnogość narzędzi wykorzystywanych do prowadzenia prac analitycznych, które często pokrywają się funkcjonalnościami i nie zawsze są zintegrowane w taki sposób, jakiego byśmy oczekiwali. A jeśli na to nałożymy fakt, iż nawet wewnątrz jednej organizacji różne zespoły mogą pracować według różnych zasad, to mamę w miarę pełny ogląd sytuacji. I jak w takiej sytuacji podnosić kompetencje?

Szkolenia tradycyjne

Oczywiście, zawsze można sobie wyobrazić obszar, w którym naszą wiedzę możemy podnieść uczestnicząc w tak zwanym tradycyjnym szkoleniu (wykład, przygotowane przez prowadzącego ćwiczenia, omówienie). Jeszcze większe korzyści można uzyskać z takich szkoleń w sytuacji, gdy chcemy przystąpić do jakiejś certyfikacji, która najczęściej wymaga przyswojenie dużej ilości nowej wiedzy. Pewne ‚dedykowanie’ materiału szkoleniowego można także uzyskać, zamawiając szkolenie zamknięte w ramach organizacji. Zawsze jednak będzie się ono opierało o wcześniej przygotowany materiał, lekko dostosowywany materiałami lub komentarzem do sytuacji organizacji. Można się także pokusić o przygotowanie całkowicie dedykowanego szkolenia dla wybranej grupy osób, ale po pierwsze, przygotowanie dobrego szkolenia to spory nakład pracy (tym samym, spory koszt dla zamawiającego) a po drugie, prowadzona podczas szkolenia ‚pogłębiona’ dyskusja może doprowadzić do wniosku, że szkolenie powinno dotyczyć jednak czegoś innego. Kilkukrotnie sam znalazłem się w takiej sytuacji, którą delikatnie można określić jako niekomfortową dla wszystkich stron.

Co w takim razie w zamian?

Bring Your Own Problem

Kilka lat temu po raz pierwszy prowadziłem szkolenie w takiej formie. Pamiętam tremę – jechałem do zacnej instytucji, z którą wcześniej omówiłem stojące przed nimi wyzwania i mając tego świadomość obawiałem się, czy szukanie przyczyn źródłowych oraz możliwych rozwiązań nie wykroczy poza moje kompetencje. Jedyne co miałem ze sobą, to komputer ze wszystkimi szkoleniami jakie do tej pory prowadziłem.

Szkolenie okazało się tak trudne, jak udane. Było zaplanowane na 6 godzin, trwało…11. Wszyscy wyszliśmy umęczeni ale zadowoleni z efektów. Spotkaliśmy się w tym samym gronie jeszcze kilka razy.

Tego typu szkolenia mają swoją specyfikę. Po pierwsze, nie mają zaplanowanego materiału do przekazania, ale zagadnienie w ramach którego będziemy prowadzili rozmowy. Oczywiście, pomysł na poprowadzenie musi być, ale to jakie treści będą przekazywane dynamicznie wynika z przebiegu rozmów. Po drugie, najczęściej są prowadzone w niezbyt licznym gronie. Im mniejsze, tym lepsze. Zwykle w szkoleniu uczestniczą kluczowe osoby z punktu widzenia omawianego zagadnienia. Po trzecie, szkolenia BYOP nie mogą być prowadzone przez ‚trenera z zawodu’, lecz doświadczonego praktyka o kompetencjach trenerskich. Po czwarte, zwykle mają swoją kontynuację.

Jeśli więc jesteś doświadczonym analitykiem i udział w tradycyjnych szkoleniach nie przynosi już korzyści, może warto pomyśleć o tego rodzaju ścieżkach podnoszenia kompetencji?

Grafika: Business photo created by rawpixel.com – www.freepik.com

Licencja Creative Commons
Ten utwór jest dostępny na licencji Creative Commons Uznanie autorstwa – Bez utworów zależnych 4.0 Międzynarodowe.

Na ratunek Metodyka

Metodyka to takie słowo, które aktualnie budzi strach i odrazę, gdyż kojarzy się z tak zwanym Łoterfolem. Może nie u wszytskich, gdyż żyją jeszcze ludzie, którzy z Metodykami mieli praktyczne do czynienia. I od czasu, do czasu o tym wnukom swym opowiadają. A króluje…nie metodyczność a zwinność.

A dlaczego miałoby być inaczej?

Planowanie

Metodyka to usystematyzowana propozycja sposobu pracy. Jeśli przystępujemy do jakiegoś przedsięwzięcia, to na bazie naszej wiedzy o nim staramy się z Metodyki wybrać te działania, które w tym przedsięwzięciu będą uzasadnione. Proste? Proste. Jaka z tego wynika wartość?

Ano taka, że jeśli metodyka uwzględnia tego typu przedsięwzięcie, to wybierzemy z niej fragment, który będzie logicznie spójny i procesowo przewidywalny. Co z tego?

Nasz plan na realizację przedsięwzięcia będzie miał określony, logiczny ciąg działań wyspecyfikowane produkty i okeślone, wymagane role. To już jest niezła baza do szacunków.

Realizacja

Mając Metodykę, możemy rozpocząć działania z nadzieją, że jeśli nie zdarzy się nic, co wpływa na jej dobór (okrojony do konkretnego kontekstu), bedą one prowadzone według dobrze ustalonego planu, To daje pewien komfort zarówno od strony zarządczej jak i wykonawczej.

A co, jeśli w trakcie prac zmieni się sytuacja? Do pewnego stopnia, nic. Należy sięgnąć do Metodyki i wybrać z niej takie elementy, które odzwierciedlają nowe uwarunkowania.

I tak iteracyjnie. I przyrostowo.

Post Mortem

A co, gdy zakończy się przedsięwzięcie? Jak to co? Należy usiąść, przysyskutować zrealizowane działania i zastanowić się, czy to co się wydarzyło, nie powinno wpłynąć na metodykę. Jeśli tak, zmodyfikujemy ją. Następnym razem będzie jeszcze bardziej przewidywalnie.

Ale czy to nie jest za ciężkie?

Czy to nie ogranicza swobody działania? Czy to nie powoduje, że ludzie są pozbawienie szansy na kreatwyność?

No właśnie? Jak to jest z tymi Metodykami? Moim zdaniem….

Licencja Creative Commons
Ten utwór jest dostępny na licencji Creative Commons Uznanie autorstwa – Bez utworów zależnych 4.0 Międzynarodowe.

Czy reguła biznesowa to wymaganie?

Wielokrotnie spotkałem się z sytuacjami, w których reguły biznesowe oraz wymagania wobec IT były traktowane jako różne rodzaje tej samej koncepcji. A to niedobrze, gdyż z wielu powodów nie powinno się tych pojęć tak traktować, jako że prowadzi to do…o czym poniżej.

Definicji reguł biznesowych jest całkiem sporo. Co ciekawe, nawet wśród tych samych autorów, definicje zmieniają się z czasem. Mi najbardziej odpowiada ta, zaproponowana przez Business Rules Group.

Business Rule is a directive that is intended to influence or guide business behavior. 

Business Rules Group, 1998

Definicja wyraźnie wskazuje, że celem specyfikowania reguł biznesowych jest jawne określenie zasad, które powinny być brane pod uwagę podczas prowadzenia działań biznesowych. Rozpatrując reguły biznesowe z punktu widzenia siatki Zachmana, należy uznać, iż stanowią element drugiej z perspektyw, na równi z modelem pojęć, czy modelem przebiegów procesów biznesowych.

Spróbujmy przeanalizować zależności łączące reguły biznesowe z innymi aspektami architektury biznesowej, w tym architektury IT. Załóżmy, że zajmujemy się tematem zakładania rachunku bankowego w instytucji finansowej. Hipotetycznie, możemy przyjąć, że o założenie rachunku bankowego może wnioskować tylko osoba pełnoletnia. Aby to założenie biznesowe zapisać w terminach reguł biznesowych, posłużymy się stylistyką RuleSpeak. Reguła mogłaby wówczas przyjąć brzmienie:

Wniosek o założnie rachunku bankowego MOŻE złożyć TYLKO osoba, która jest pełnoletnia.

Co taka reguła oznacza z punktu widzenia architektury biznesowej. Po pierwsze, mamy tutaj odwołania do dwóch pojęć oraz jednego faktu je łączącego. Pojęcia to Wniosek o założenie rachunku bankowego oraz Osoba. Fakt, to składa. Dbając o porządek w repozytorium architektury biznesowej, powinniśmy mieć odnotowane te zależności, co mogłoby przyjąć następującą postać.

Przykładowy model pojęć
Rysunek 2 Reguła biznesowa odwołująca się do modelu pojęć

Niektóre narzędzia służące do tworzenia modeli architektury biznesowej automatycznie rozpoznają, czy we wprowadzanej treści reguły biznesowej znajdują się odwołania do modelu pojęć i łączą zidentyfikowane frazy z pojęciami. Przykłd tego typu funkcjonalności dostępnej w narzędziu Visual Paradigm prezentuje Rysunek 2.

Mając już regułę biznesową opartą o model pojęć, możemy zastanowić się, co w praktyce mogłaby oznaczać część definicji reguły biznesowej, nawiązująca do jej wpływu na działania biznesowe. Spójrzmy najpierw na jeden z najbardziej typowych elementów architektury biznesowej – modele procesów biznesowych. Zwykle prezentują one działania realizowane przez ich uczestników oraz kolejność realizacji działań. Dla przykładu, Rysunek 3 prezentuje początek hipotetycznego procesu biznesowego, mającego na celu założenie rachunku bankowego. Proces jest inicjowany przedłożeniem przez osobę wnioskującą wypełnionego wniosku. Pracownik Biura Obsługi Klienta następnie weryfikuje ten wniosek i jeśli wszystko jest poprawnie wypełnione przekazuje go do dalszej realizacji. Zakładając na początek, że nie posiłkuje się tutaj żadnym systemem, obowiązkiem pracownika będzie zdobycie kompetencji pozwalających na pełną weryfikację wniosku. Między innymi pod kątem pełnoletniości.

Jak można byłoby zinterpretować to z punktu widzenia tworzonego modelu? Na przykład, tak jak na poniższym rysunku – możemy uznać, iż wprowadzona przez nas reguła biznesowa powinna być powiązana z tym krokiem procesu, gdyż w jego ramach może zostać … złamana. Wprawdzie reguły istnieją niezależnie od kroków procesów, aczkolwiek warto je łączyć tylko z tymi, w których mają jakiekolwiek znaczenie.

Rysunek 3 Reguła biznesowa powiązana z krokiem procesu biznesowego

A co w sytuacji, gdybyśmy wraz z planowaniem nowego przebiegu procesu zamierzali wdrożyć system informatyczny, który wesprze pracę uczestników procesu? Musielibyśmy jakoś umieć wkomponować w powstający, docelowy model funkcjonowania organizacji oczekiwania wobec IT. W metodyce AION, pierwszy etapem specyfikowania tego typu wymagań, jest ich zogniskowanie wokół tych kroków procesu, które wymagają wsparcia. Rysunek 4 prezentuje diagram wymagań, zgodny z podejściem AION dla omawianego przykładu. Na bazie kroku biznesowego, w którym miałaby nastąpić rejestracja wniosku w systemie, zdefiniowane zostało wymaganie dotyczące konieczności weryfikacji wniosku względem reguł biznesowych. Warto zwrócić uwagę, iż w treści wymaganie nie zostały wprowadzone warunki, względem których wniosek należy zweryfikować. Zamiast takiego zabiegu (wprowadzałby on redundancje informacji do modelu), wprowadzono zależność łączącą wymaganie z istniejącą regułą biznesową. Gdyby reguł było więcej, w dalszym ciągu pozostałoby jedno wymaganie, które byłoby skojarzone z większa liczbą reguł biznesowych. Tak wyspecyfikowane wymaganie jest następnie powiązane relacją <<satisfy>> z przypadkiem użycia, który w analizie systemowej będzie prezentował sposób realizacji wymagania. Oczywiście, aby przykład był kompletny, do modelu powinno się wprowadzić więcej wymagań związanych z krokiem. W przypadku niniejszego wpisu koncentrujemy się jednakże jedynie na zależnościach pomiędzy wymaganiem a regułą biznesową, więc uzupełnianie nie wydaje się być konieczne.

Rysunek 4 Diagram wymagań prezentujący zależności pomiędzy elementami architektury biznesowej oraz systemowej w omawianym przykładzie
Rysunek 5 Diagram przypadków użycia dla omawianego przykładu

Jak należałoby rozszerzyć model, gdyby się okazało, iż funkcjonalność związaną z wprowadzaniem wniosku chcielibyśmy udostępnić w kanałach elektronicznych, przerzucając ciężar prac z pracownika BOK na Klienta instytucji? Z pewnością należałoby uzupełnić model procesów o scenariusz, w którym Klient wykorzystuje dobrodziejstwa IT, dzięki czemu w procesie nie występuje już Pracownik BOK. Zapewne, w dalszym ciągu obowiązek pełnoletności powinien być spełniony, więc, wykorzystamy już istniejącą regułę biznesową do tego, by skojarzyć ją z nowym krokiem biznesowym. Wyprowadzając z kroku wymagania dla nowego systemu, zdefiniujemy nowe wymaganie do weryfikacji, ale powiążemy je z istniejąca regułą, gdyż ona się nie zmieniła. Dzięki takim zabiegom, mamy jedną regułę biznesową i wiele miejsc w modelu, które się w różnych kontekstach do niej odwołują. Utrzymywanie powiązań pomiędzy elemenatmi w modelu znacząco ułatwi analizę wpływu zmiany reguły biznesowej na architekturę biznesową i IT.

Czy reguły biznesowe to wymagania? Nie. Czy są z nimi związane? Mogą być.

Koniec pandemii? A jeśli tak, to co dalej?

Dawno nie miałem tak ciekawej rozmowy jak wczoraj. Do pewnego stopnia była to rozmowa przełomowa, gdyż może wskazywać, że powoli kończy się trwająca od lat pandemia. Oczywiście pojawiają się pytania, jak duże mamy straty i czy uda się odbudować świat po pandemii? A jeśli się uda, jak długo to będzie trwało. Ale, od początku…

Wczorajsze popołudnie rozpoczęło się od odebrania telefonu od nieznajomej osoby. W pierwszych słowach rozmówca przedstawił się jako lider zespołu wytwarzającego oprogramowanie dla bardzo wymagającego Klienta. Zespół jest dość spory – łącznie, kilkadziesiąt osób podzielonych na mniejsze grupy. System także jest spory. Rozwijany w dużych przyrostach, przez lata. Z jednej strony, ciągle dodawane są do niego nowe obszary funkcjonalne. Z drugiej – do istniejących funkcjonalności wprowadzane są zmiany.

Sytuacja, wydawałoby się, dość jasna i powszechna. W czym więc problem? Otóż, zespół doszedł do wniosku, że powoli przestaje panować nad całą złożonością, a dalszy rozwój oraz utrzymanie zaczynają być na tyle uciążliwe, że skutkuje to zauważalnym spadkiem efektywności i skuteczności prac, a co za tym idzie, rosnącą frustracją członków zespołu. Na tyle dużą, że część z nich postanowiła opuścić zespół z tego właśnie powodu. Ponieważ problem nie jest nowy, więc, jak mi powiedziano, był wielokrotnie dyskutowany. Efektem tych dyskusji było spostrzeżenie, iż aktualny sposób prowadzenia prac, oparty o historyjki i epiki, pomimo ‚dokręcania’ ich zgodnie z rekomendowanymi technikami, bardzo utrudnia prace analityczne. Jednym z objawów tych trudności jest poświęcanie coraz większej ilości czasu na przeszukiwanie narzędzia wykorzystywanego do zarządzania specyfikacją, w celu znalezienia opisu aktualnej funkcjonalności systemu oraz wprowadzanie zmian do niej. Spostrzeżeń, oczywiście było więcej, bo i problem jest niemały.

Szukając metod poprawy sytuacji, członkowie zespołu, uczestniczyli w wielu szkoleniach, spotkaniach branżowych oraz, jak mi powiedziano, przeczytali cały Internet dwa razy. I stwierdzili, że w zasadzie, niewiele nowego się dowiedzieli. Wprawdzie doczytali o nowych technikach, możliwych zmianach w sposobie zapisu, nowych narzędziach. Wiele z takich zaleceń wprowadzili do swojej pracy, ale jakościowej zmiany nie zaobserwowali.

Szczerze mówiąc, usłyszawszy to, mocno się zdziwiłem. Internet jest bowiem pełen opisów technik , które pozwalają na usprawnienie prac nad tego typu przedsięwzięciem, czym podzieliłem się z rozmówcą. I w tym momencie rozpoczął się kolejny interesujący wątek.

Wszystkie dotychczasowe poszukiwania metod mogących usprawnić prace były skoncentrowane na podejściu agile’owym. Na pytanie dlaczego, padła odpowiedź, że tylko takie znają. Cały zespół jest bowiem z pokolenia, które weszło na rynek, na którym niepodzielnie panuje agile. Odruch, by szukać tylko wśród technik agile’owych był tak naturalny, że nikt przez dłuższy czas nie myślał, by sięgnąć gdzie indziej. Bo czym jest gdzie indziej? Historią, jak stwierdził z uśmiechem rozmówca.

Rany, jaki ja jestem stary, pomyślałem.

W końcu, ktoś z zespołu otworzył pozycję historyczną. W Internecie, oczywiście. Usłyszałem, że to było o UMLu. Pozycję znam, więc bynajmniej nie dotyczy tylko UMLa. Kilka osób z zespołu stwierdziło wówczas, że miało jakieś zajęcia z UMLa na studiach, ale nikt jakoś poważnie tego nie traktował. Raczej na zasadzie, nauczyć się, by zaliczyć. Pomimo tego, zespół postanowił temat podrążyć. Stworzono nawet malutki projekt pilotażowy, którego celem było wypróbowanie nowopoznawanych technik do realizacji prac projektowych. Dwie osoby równolegle z resztą zespołu, po nowemu i na boku, opisywało analizę. Wniosków z tego ćwiczenia było wiele. Te ważniejsze, to:

  • początkowo, dwuosobowy zespół gros czasu poświęcał na opisanie tego, jak jest aktualnie, by w ogóle móc myśleć o opisaniu nowej funkcjonalności,
  • zespół eksperymentatorów stwierdził po jakimś czasie, że to nie jest takie proste, a potwierdzeniem tych słów była informacja o czasie, jaki był poświęcany na poprawę tego, co zrobili,
  • doczytywanie w Internecie o stosowanych technikach skutkowało wnioskami w stylu a tutaj robią to trochę inaczej, choć niby to to samo,
  • wykorzystywane narzędzie do modelowania sprawiało na początku wiele problemów wynikających z jego złożoności.

Interesujące było to, że swoimi doświadczeniami zespół postanowił podzielić się w trakcie jednego z branżowych spotkań. I okazało się, że nie są sami z problemem. Co więcej, ich wystąpienie spotkało się z bardzo pozytywnym odbiorem a kilka osób stwierdziło, że spróbuje u siebie porozmawiać o możliwości wdrożenia tego typu metod pracy. Ale, jak to stwierdził rozmówca, na sali, pomimo ponad sześćdziesięciu osób, nikt (sic!) nie miał praktycznego doświadczenia z metodami pracy opartymi o modelowanie.

Pod koniec rozmowy przeszliśmy do tematu praktycznego wdrożenia takiego podejścia w zespole. Poruszyliśmy temat metodyki – pojęcia które wywołało od razu reakcję ale nie takiej sztywnej! Więc zapytałem, skąd obawa, że będzie sztywna? Odpowiedź, bo stare metodyki były sztywne. To sobie chwilę i o tym porozmawialiśmy. A na koniec padło pytanie, o szacunkowy czas wdrożenia takiego podejścia w całym zespole (kilkadziesiąt osób, przypomnę).

Tiaaaa, i dotknęliśmy trudnego tematu. Oczekiwania były takie, by zaspół zaczął pracować opierając się o modelowanie po miesiącu, maksymalnie dwóch. Ja stwierdziłem, że to niemożliwe, gdyż z tego co słyszę, wdrożenie ma dotyczyć zarówno opisywania procesów jak i całej analizy systemowe. Zespół bowiem doszedł do wniosku, że albo zrobią wszystko, albo nie zaczynają, bo to nie ma sensu. Chwilę o tym porozmawialiśmy i na koniec pojawił się jednak pomysł, jak do tematu podejść przyrostowo. Rozmówca zrozumiał wówczas, dlaczego myślenie w perspektywie miesiąca nie jest zbyt użyteczne. Że to bardziej temat na lata, by w pełni wypracować i wdrożyć metodykę ( w tym, narzędzia do pracy zespołowej). Natomiast podzielenie tego procesu na przyrosty, opracowywane w sposób uwzględniający stan docelowy, zostało uznane za słuszne.

A jak zabezpieczyć się przed ryzykiem pójścia w maliny, padło pytanie na koniec. Odrzekłem, że trzeba mieć w zespole doświadczoną osobę, która będzie mistrzem dla czeladników. A skąd ją wziąć, padło kolejne.

Hmmmm, dobre pytanie, pomyślałem. Pandemia agile’owa spowodowała, że wytworzyła nam się luka pokoleniowa. Osoby, które mają takie doświadczenie, to moim zdaniem ludzie w wieku 45+ (oczywiście z wyjątkami). Sam znam kilkadziesiąt takich osób. Z szeroką wiedzą, dużym doświadczeniem w konsekwentnym stosowaniu procesów wytwórczych opartych o modelowanie w różnego typu przedsięwzięciach. Część z nich…jest już na emeryturze. Ci, którzy nie są, pracują w firmach i raczej nie wspomogą innych firm. I taka mnie tkła myśl, że jeśli rzeczywiście pandemia ma się ku początkowi końca i firmy zdecydują się na to, by usprawniać swoją pracę posiłkując się zdroworozsądkowo technikami, które lata temu zostały uznane za niewłaściwe, to pojawi się problem kompetencyjny. Bo zabraknie mistrzów, którzy mogliby przez dłuższy okres zabezpieczać pracę wdrażających się zespołów. A bez nich, firmy staną przed dylematem, wymyślać koło od nowa, czy nie? A jeśli nie, to co? Bo same książki (jakie by nie były dobre) i szkolenia (jakie by nie były dobre) to za mało.

To była ta mało optymistyczna część naszej rozmowy.


Licencja Creative Commons
Ten utwór jest dostępny na licencji Creative Commons Uznanie autorstwa – Bez utworów zależnych 4.0 Międzynarodowe.

Grafika: House photo created by master1305 – www.freepik.com

Od historyjek do epików wstępująco (ang. bottom-up)

Moda na Edżajl trwa i na razie nic nie zwiastuje rychłego zakończenia trendu. Jednym z tego efektów jest konieczność wpisania elementów procesów wytwórczych opartych o bardziej zaawansowane narzędzia w proste elementy skramomopochodne. Oczywiście, przed takimi wyzwaniami (ponieważ rzecz dzieje się w korporacji, więc o problemach nie ma mowy) i mi przychodzi stawać. I stąd niniejszy wpis.

W stosowanym od lat podejściu, usprawnienie określonego obszaru biznesowego zwykle skutkuje powstaniem obrazu docelowego procesu biznesowego. W zależności od sytuacji, może to być zarówno duża reorganizacja procesów, jak i drobna ich modyfikacja. Efekt, z analitycznego punktu widzenia, jest we wszystkich przypadkach taki sami – powstaje komplet – procesy biznesowe oraz stojący za nimi aparat pojęciowy (model pojęć).

Jeżeli w ślad za zmianami w procesach podążać mają zmiany w rozwiązaniach IT, model jest uzupełniany o kolejny wymiar – oczekiwania wobec funkcjonalności IT zdefiniowane w kontekście poszczególnych kroków procesu. Dlaczego tak? Uzasadnieniem dla takiego podejścia jest chęć uniknięcia wymagań precyzowanych w bliżej nieokreślonym kontekście (często na wyrost). Bazując na krokach, rozważamy konkretny, nieduży zakres procesu i tym samym, co pozwoli na łatwiejsze uzasadnienie istnienia wymagania i korzyści z niego wynikających. Technicznie, technika skutkuje powstaniem diagramu wymagań, na którym z krokiem skojarzone są wymagania. W przypadku języka SysML, diagram taki mógłby wyglądać, jak poniżej.

Diagram wymagań ilustrujący koncepcję łączenia kroków w procesie i wymagań

Jak widać, definicja wymagań może nawiązywać do proponowanej stylistyki historyjkowej, nie tracąc nic na swojej mocy. Wprawdzie fragment JAKO nazwa roli jest redundantny i jest powieleniem relacji krok procesu – tor reprezentujący rolę, na której się znajduje, ale przy dostatecznej stabilności przebiegu procesu, redundancja nie powinna sprawiać problemu.

Zwykle, po wykonaniu tych działań, kolejnym elementem procesu wytwórczego jest powiązanie wymagań z opisem funkcjonalności systemów, które będą uczestniczyły w ich realizacji (np. przypadki użycia, usługi, itp.). W przypadku podejścia edżajlowego, wymagane jest jednakże zgrupowanie wymagań w kategorie, nazywane epikami. Z punktu widzenia procesu wytwórczego opartego o modele jest to krok zbędny, ale oczekiwania procesu edżajlowego są w tym momencie bezwzględne – historyjka musi być elementem epiku.

Epik to element grupujący. Kryteria grupowania są subiektywne. Pojawia się więc pytanie – jak zgrupować wymagania w zbiory? Ponieważ takie podejście, jakie proponuję jest jakby wbrew zstępującemu procesowi edżajlowemu (najpierw epiki, potem historyjki), więc wskazówek w edżajlowych bazach wiedzy nie znalazłem. Ale, z pomocą przychodzi znana od dziesiątek lat technika diagramu podobieństw (ang. affinity diagram). Wykorzystajmy ją wprost. Bez jakichkolwiek modyfikacji. Uzyskamy pożądane epiki. Jeśli ktoś nie zna techniki – załączam odnośnik do krótkiego wykładu na Jutjub.

Licencja Creative Commons
Ten utwór jest dostępny na licencji Creative Commons Uznanie autorstwa – Bez utworów zależnych 4.0 Międzynarodowe.

Sezon na Architekturę i Analizę Biznesową

Tym razem, zamiast merytorycznego wpisu zapraszam na cykl bardzo merytorycznych spotkań. Naszym zamierzeniem jest stworzenie miejsca, w którym w atrakcyjnej formie, w niedużym gronie doświadczonych osób będzie można dyskutować o nietrywialnych problemach z szeroko pojętej Architektury Biznesowej oraz Analizy Biznesowej.

Cykl będzie podzielony na sezony, w ramach których będą się odbywać 3 spotkania koncentrujące się na jednym temacie. W przypadku tematów, które zostaną uznane za wyjątkowo interesujące, będziemy starali się podsumować sezon konferencją, w której będzie mogła wziąć udział większa liczba osób.

Serdecznie zapraszam do udziału w pierwszym spotkaniu, które odbędzie się we Wrocławiu 07.03.2019. Odnośnik do strony wydarzenia Architekci biznesowi, analitycy procesowi, analitycy biznesowi – sprzymierzeńcy czy konkurenci?

OCeeL, teoretyczna teoria, czy praktyczna praktyka?

Zupełnie niespodziewanie przeprowadziłem dzisiaj ponad godzinną rozmowę ze studentem podejmującym decyzję o temacie pracy magisterskiej. Pytanie, z jakim zadzwonił, można streścić jednym zdaniem Czy OCL to już odległa historia, czy coś, czym warto się jeszcze zająć? Ponieważ dziś sobota, więc nie spodziewałem się telefonu w takiej sprawie, ale doszedłszy do siebie, już chciałem odpowiedzieć, że jak to historia? , ale powstrzymałem się i zapytałem a skąd pytanie? Odpowiedź była do przewidzenia – wszyscy mówią, że to czysta teoria i tak nikt nie pracuje.

To jak się pracuje?

Takim pytaniem postanowiłem podrążyć temat. I usłyszałem, że po pierwsze, OCL to już programowanie, po drugie, bez sensu jest dokumentować każdą linijkę kodu, i po trzecie, dlaczego analityk ma narzucać programiście, co ma robić.

OCL to już programowanie

Tak może powiedzieć tylko ktoś, kto nie ma pojęcia, czym jest OCL. Wytłumaczywszy studentowi, że OCL ma się tak do programowania, jak wzór w Wordzie do zapisów w silniku reguł biznesowych, usłyszałem – o dziwo – odpowiedź tak mi się wydawało.

Dokumentowanie a analiza

Na temat tego typu sformułowań można byłoby książkę napisać. Analiza to nie dokumentowanie! Analiza to proces tworzenia koncepcji rozwiązania. To co pozostaje po wykonanej analizie, można nazwać dokumentacją, ale jest to poniekąd efekt uboczny a nie cel. Tutaj student poprosił o wyjaśnienia, ale na koniec stwierdził, że rozumie (a dokładniej, zakminił).

Wpływ na programistę

Dlaczego analityk ma narzucać programiście, co ma robić? Hmmm…dlatego, że taka jego rola. Odpowiedzialnością analityka jest doprowadzenie do powstania koncepcji rozwiązania. W tym celu musi komunikować się z szeroko pojętym zestawem interesariuszy. W ich skład wchodzi zarówno tak zwana strona biznesowa jak i technologiczna, z programistami włącznie. Nie zmienia to faktu, że to analityk jest odpowiedzialny za stworzenie koncepcji. Ta koncepcja jest następnie przekazywana do zaprogramowania. Bez narzucania metod, ale z narzuceniem celu.

Ale przecież programista może stwierdzić, że można to zrobić lepiej! Oczywiście, że może. Ale to analityk powinien finalnie potwierdzić koncepcję. Zdanie programisty, to zdanie jednego z interesariuszy. Analityk musi uwzględnić zdanie wszystkich, którzy mają wpływ. I dokonywać korekt każdoroazowo, gdy taka konieczność nastąpi. Czyli do samego końca procesu produkcyjnego.

Ten temat zajął nam najwięcej czasu. Mam jednakże wrażenie, że rozmówca ostatecznie zrozumiał znaczenie OCL w całym procesie wytwórczym. Zresztą, nie tylko OCL. 

Ale dlaczego warto pisać o takiej rozmowie?

Kto poddał w wątpliwość?

To jest powód powstania niniejszego wpisu. Wątpliwość bowiem podniósł opiekun przyszłej pracy. Pracownik naukowy. Osoba, która powinna rozumieć. Poszerzać horyzonty studentów. Inspirować. Nie poddawać się modom. 

To był jakiś dzban (tak się chyba teraz mówi o osobach, które nie w pełni rozumieją, co mówią), pomyślałem. Zaproponowałem, aby student jeszcze raz porozmawiał z opiekunem i wyjaśnił powody dla których chciałby się zająć OCeeLem.

Niesmak pozostał. A wraz z nim pytanie dokąd zmierza świat naukowy?


Licencja Creative Commons
Ten utwór jest dostępny na licencji Creative Commons Uznanie autorstwa – Bez utworów zależnych 4.0 Międzynarodowe.

Wybór dostawcy, umowa, realizacja

ContractXS

Ha! Startujemy z projektem. Będziemy mieli nowy system. Jeszcze tylko przetarg, rozmowy i zaczynamy. Wybór dostawcy, umowa, realizacja. Naturalny porządek rzeczy. To co teraz? Spisujemy wszystkie wymagania. Ogłaszamy światu, że szukamy dostawcy. Spływają oferty, krótka lista, rozmowy z handlowcami i ich dyrektorami. Negocjacje cenowe zadowalające. Stała cena ustalona. Wszyscy uśmiechnięci. Jeszcze tylko dobra umowa (bo to prawie gwarancja sukcesu). I zaczynamy. Potem już tylko…

Tak można by rozpocząć Baśń o projekcie. Trudniej jednak wyobrazić sobie końcówkę i wszyscy żyli długo i szczęśliwie.

To jeszcze raz. Naturalny porządek rzeczy. Spisujemy wszystkie wymagania.

Wszystkie wymagania

No tak. Trzeba je spisać. Tak aby o niczym nie zapomnieć, bo potem będzie problem. Ale jak? Jak to jak? Dajemy naszym ludziom zadanie. W szablonie ekselowym tworzymy wzór opisu. Uczymy, tych co jeszcze nie brali udziału w takim przedsięwzięciu, co to ten SMART. Jeśli idziemy w nowym duchu, to możemy i jakiś beklog wprowadzić i wyszkolić ludzi w stosowaniu formułki jako, trzy kropki chcę, trzy kropki, tak aby trzy kropki. Ludzie znają swoją robotę, to napiszą co trzeba. No co? Jakoś trzeba. Projekt nietrywialny to i wymagań sporo. Przeglądy, akceptacje. W końcu można wysłać zapytanie ofertowe.

Po drugiej stronie panika. Jest potencjalny kontrakt, mamy 126-stronicowy dokument, czytamy, więcej pytań, niż odpowiedzi. No, ale jakąś ofertę trzeba przygotować. Staramy się o spotkanie.  Od nas 6 osób, od nich 8. Bite sześć godzin nasiadówki. Wszystko grzecznie. Zadajemy zapytania. Odpowiadają. Jest wrażenie, że nie wszystko zostało ustalone po ich stronie. Dużo ze sobą dyskutują. Ale w końcu odpowiedzi są. Spisujemy notatkę. Uwzględniamy w ofercie.

Klasyka. O czym tu pisać?

No dobrze, a gdyby tak inaczej? Dlaczego wszystkie wymagania? Skąd my mamy je znać? A tak w ogóle, to co znaczy wszystkie? Przecież po to robimy projekt, by ustalić co ma być robione. Gdybyśmy to wiedzieli, to zakres projektu byłby o połowę mniejszy. W taki razie, co? Może na przykład cel długoterminowy, jaki chcielibyśmy osiągnąć po wdrożeniu efektów projektu? To może ukierunkować sposób myślenia potencjalnych dostawców o przedsięwzięciu. Ale dlaczego taki cel chcemy osiągnąć? To może poprzedźmy go opisem sytuacyjnym, szansami jakie widzimy, zdiagnozowanymi zagrożeniami i oceną stanu naszej organizacji względem tych czynników. To może jakoś pomóc w ocenie skali przedsięwzięcia. Kluczowe pojęcia. To jeszcze dobrze byłoby zdefiniować, bo jesteśmy trochę specyficzni i nie chcielibyśmy, aby dostawcy nas źle zrozumieli. Można by też opisać cele projektu, jakie naszym zdaniem należałoby osiągnąć przed rozliczeniem prac. Gdyby je uzupełnić o produkty, które naszym zdaniem należałoby wytworzyć, to też moglibyśmy troszkę rozjaśnić dostawcom, co nam po głowie chodzi. Ha! To krok dalej, napiszmy, czym naszym zdaniem te produkty powinny się cechować. Na przykład, Zoptymalizowany proces sprzedażowy. Wiemy, że ma maksymalizować cross-selling różnych linii produktowych. Wiemy, że ma być oparty o bliskie relacje z klientem. Dlaczego? No właśnie, to jeszcze dodajmy uzasadnienie – ano dlatego, że dzięki bliskim relacjom, dużo szybciej poznajemy prawdziwe potrzeby i jesteśmy w stanie zaoferować od razu usługę, na którą klient czeka.

No zaraz, zaraz. Ale na podstawie czegoś takiego, dostawca nie zbuduje nam syste…eeee… Ale, to nie jedyny produkt, który chcemy wytworzyć. Tak wynika z tej krótkiej analizy, którą wykonaliśmy. Ale numer! No dobra, to uzupełniamy informacjami o kluczowych interesariuszach, ograniczeniach przedsięwzięcia i ślemy zapytanie. Po drugiej stronie kilka osób zapoznaje się z 15-stronicowym opisem. Umawiają się na spotkanie. Po ich stronie 3-osoby. Po naszej trzy. Wyjaśniamy cel inicjatywy, aby obydwie strony miały jasność. Czekamy na ofertę.

Wybór dostawcy

Po czterdziestu pięciu dniach, zgodnie z podanym terminem, wpływają oferty. Nie jest źle – mamy czterech oferentów. Wszystkie oferty, punkt po punkcie, odnoszą się do naszych wymagań. Jedni to się postarali – dostaliśmy 620 stron! Uwzględnili nawet niskopoziomowe szczegóły technologiczne. Trochę nam ten Oracle nie leży, ale to się dogada. Wysłaliśmy oferty do technologów – Ci jak zwykle mieszają. Jeszcze się projekt nie zaczął, a już tysiąc pytań. Choć z drugiej strony, jak teraz nie ustalimy wszystkiego, to potem będą zmiany, przesunięcia terminów. Dobra, robimy serię spotkań. Niech Wszyscy, Wszystko wyjaśnią.

Technikalia wstępnie dograne. Uwzględniliśmy cztery warianty. Na wszelki wypadek. Mamy w propozycji zawarte trzy tygodnie analizy. Dostawca oddeleguje dwóch analityków, to pewnie i to finalnie ustalą. Nic to, terminy gonią, negocjujemy umowę. Łatwo nie jest, bo dostawca mówi, że w zależności od wariantu, koszty mogą być rożne. Nasi prawnicy nie zgadzają się na wariantową umowę. Mówią, że dostawca musi zdecydować ile chce kasy. Ryzyko musi wliczyć jakoś w ofertę. Strasznie się to wszystko przeciąga, a ludzie już czekają na rozpoczęcie. Jest. Cena ustalona. Termin też – za dwa i pół roku produkt będzie na produkcji. Wszystkie jedenaście modułów. Umowa podpisana. Zaczynamy. Nie łatwo wybrać dostawcę. Ale inaczej się nie da.

A gdyby jednak inaczej?

Oferta przyszła. 50 stron. Wygląda na to, że całkiem sporo czasu ma zostać poświęcone na analizę. Dostawca chciałby przedyskutować z każdą ze spółek produktowych aktualny kształt procesów z zakresy marketingu, sprzedaży oraz, co dziwne, dostarczania produktów. Ciekawe po co? Do późniejszej decyzji pozostawia konieczność jawnego naszkicowania procesów aktualnych. W ofercie są wzmianki o ujednoliceniu podejścia do oceny atrakcyjności klientów. Gdyby udało się opracować wspólne podejście, wówczas opcjonalnie elementem architektury IT stanie się system do automatyzacji reguł decyzyjnych. Podobnie zresztą jest z systemem do automatyzacji procesów. Można go brać pod uwagę, ale ostateczny kształt procesów i wynikające z tego wymagania wskażą na zasadność jego zastosowania. Zresztą, wykonawca nadmienia, że z racji krytyczności projektu i tworzonego rozwiązania IT, będzie chciał się zapoznać z całą architekturą IT naszej firmy, aby tak dobrać składowe rozwiązania, by były z nią zgodne. Elementem rozważań na etapie analizy będzie także docelowa struktura organizacyjna. Może się bowiem okazać, że zasadna okaże się centralizacja marketingu w ramach jednego działu, z którego będą oddelegowywane osoby do poszczególnych spółek. Odpowiedzialność za marketing byłaby jednakże utrzymywana w jednym miejscu. Być może wpłynie to jakoś na system CRM, który jest już wdrożony w każdej ze spółek. Dostawca wspomina także, że być może analizie powinny zostać poddane procedury reklamacyjne – one także mogą wpływać na efektywność procesów sprzedażowych.

Elementem oferty jest zestaw ról, jakie wystąpią po stronie dostawcy oraz oczekiwania wobec kompetencji nas – zamawiających. Dziwne. To my zamawiamy, a tu oczekiwania w drugą stronę. Chcą, abyśmy potrafili odnieść się do modeli procesowych. Oczywiście gwarantują dostępność swoich analityków – tytułują ich procesowymi – ale oczekują także zrozumienia diagramów po naszej stronie. Będzie architekt rozwiązania IT, wiodący analityk biznesowy, analitycy od poszczególnych rodzajów systemów, główny projektant, programiści. Analiza ma być prowadzona w sposób facylitacyjny – mamy dzięki temu mieć większy wpływ na kształt rozwiązania. Efekty analizy biznesowej od pewnego momentu mają być korelowane z architekturą rozwiązania IT. Tutaj także mają być prowadzone facylitowane warsztaty z naszymi architektami. Strasznie tego dużo. Nie wszystko rozumiemy. Co ciekawe, w ofercie jest zapis, że czas trwania etapów analizy jest w dużej mierze uzależniony od wspólnego tempa prac, którego na tym etapie nie da się oszacować. Jak to?! Oferta Time & Materials?! Choć z drugiej strony, przypominając sobie wcześniejsze projekty na Fixed Price, przez gardło nie przejdzie określenie łatwo i przyjemnie. Może jeśli będziemy kontrolowali przebieg prac, to takie podejście będzie lepsze? Ale jak to kontrolować? Nigdy tak nie pracowaliśmy?

Inspektor nadzoru inwestorskiego

Ale że co? Zatrudnić osobę z zewnątrz? Do kontroli zewnętrznej firmy? A jak się dogadają? [przyp. I to jest ten trudny i kluczowy moment tej historii. Dotykamy bowiem roli, w którą wcielić się powinny osoby cechujące się się zarówno bardzo wysokimi kompetencjami jak i wysoka etyką. O tym za chwilę.]

No dobrze, na budowach często taki model się sprawdza. To może i u nas się sprawdzi. Ale co miałby robić?

Co miałby robić? Pomoc w wyborze dostawcy

Z moich obserwacji wynika, że zamawiający najczęściej jako dostawcę usług traktują firmę. I to jest fundamentalna pomyłka. Projektów nie realizuje firma lecz ludzie. Oczywiście, najczęściej ludzie Ci są kierowani do pracy przez firmę, która kontrakt zdobyła, co nie zmienia faktu, iż nie firma prace będzie prowadzić. Drobna zmiana sposobu myślenia, która w ogromny sposób może zaingerować w sposób wyboru dostawcy.

W przypadku firmy, co najczęściej sprawdzamy? Stabilność finansową, referencje, certyfikaty kluczowych członków zespołu. Stabilność finansowa może wynikać z tak wielu czynników, nieistotnych dla naszego przedsięwzięcia, że ciężko na jej podstawie wnioskować, czy firma sobie poradzi, czy nie. Referencje. Zdobyte przez jakieś osoby w jakimś projekcie. Nie ma gwarancji, że te osoby jeszcze w firmie pracują. Certyfikaty. Mówią jedynie tyle, że osoba wie, co powinna umieć. Pytanie, czy to umie? Weźmy na analityczny przykład certyfikat OCUP. Poniższa tabela prezentuje zakres materiału z zakresu języka UML 2 objętego certyfikacją na poziomie Intermediate. Co z niej wynika? Ano to, że osoba zna język UML 2 w tym zakresie. Certyfikat nie daje odpowiedzi na pytanie, czy potrafi zastosować UML z tego zakresu do poprowadzenia prac analitycznych. Oczywiście, fakt że osoby posiadają certyfikat, oznacza, że w jakiś sposób inwestują w swój rozwój. Ale to niestety warunek konieczny a nie wystarczający z punktu widzenia naszych rozważań.

OCUP

Zakres materiału objętego certyfikacją OCUP 2 IntermediateLevel

Czego natomiast można oczekiwać od firmy? Metodyki. I tego, że znają ja ludzie, którzy będą oddelegowani do pracy w naszym projekcie. A ludzie, to kompetencje. Konkretna osoba, konkretna weryfikacja.

Czyli, co weryfikować? Metodykę? Ludzi? Przecież to jakaś abstrakcja? A może nie. Zapytajmy inspektora.

Aaaaa. Czyli elementem oferty ma być opis metodyki, jaka będzie zastosowana w naszym projekcie? Hmmm. No może. A jeśli napiszą, że metodyka będzie dynamicznie ustalana w trakcie prac? Albo, że jest to tajemnica firmy? Że co? Że to znaczy, że jej nie mają? Że, gdyby mieli, to by napisali? To nie jest oddanie własnej pozycji rynkowej innym? Nie nauczą się w tydzień, miesiąc, rok? Taaaak? To się latami wypracowuje? Czyli naciskać? Taaak? Ale dalej nie chcą? Halllo, nie słyszę panie inspektorze? Że co? Nie brać pod uwagę? Hallo! Haaaaaalo!

Napisali. Niektórzy. Przeglądamy. Razem z inspektorem. Nie rozumiemy, dopytujemy, analizujemy, dopytujemy. Brzmi sensownie. Zresztą, widać po wyniku. Kryteria oceny były wszystkim znane. Ci wypadli najlepiej. To co – mamy dostawcę? Nieeee?! Jak to nie? Mają metodykę. Sam pan mówił. Rozmawiamy dalej ze wszystkimi, którzy są powyżej minimum?

Aaaaaa…niech przyślą ludzi. No i co my z nimi zrobimy? Warsztaty? Jakie warsztaty. Przecież dopiero szukamy dostawcy. Aaaaa, takie przykładowe? Ile? Dwa? Trzy? Aaaaaa…jedne z analizy biznesowej, drugie z czego? Z analizy systemowej? Nie można w jedną analizę? Nie? To rożne analizy? Aaaaaa….inni ludzie będą uczestniczyć. Od nich? I od nas tez? Tak? System, biznes…jasna sprawa. Scenariusze napisać? Aaa, że niby od nas wiedzę muszą wyciągnąć? Nie podpowiadamy? A jak nie wyciągną? Znaczy, że słabo. No fakt, jak nie wyciągną na warsztatach to dlaczego mieliby wyciągnąć w projekcie. Dobrze, to my zaczniemy opisywać jakiś nasz problem. Mówi pan, że z jakiegoś zrealizowanego projektu? Słusznie. To będzie rzeczywisty przykład – łatwiej się będzie odnaleźć. Weźmy ten od samochodów. Tam były niezłe analizy. Szkoda, że post factum.

Trochę się zdziwili dostawcy. Jeden napisał, że oddeleguje ludzi, jak będzie miał kontrakt. No trudno. Odpadł. Dwie firmy się zgodziły. Jedna napisała, że to bardzo ciekawy pomysł. Spotykamy się z nimi siedemnastego listopada. Na trzy dni. W naszym ośrodku szkoleniowym w Ustce.

Zimno jak czort. No ale czego oczekiwać po listopadzie nad morzem. Spotykamy się o poranku. Handlowiec dostawcy jakiś spięty. Ale merytoryczni całkiem okej. Zaczynamy. Początek trudny, bo handlowiec rozpoczął od slajdów o firmie. Nic to, pół godziny i przejdziemy do konkretów.

Podzieliliśmy się na grupy, tak jak zaproponowali merytoryczni. Jedni dostali jako wsad opisane wczoraj procesy aktualne. Drugich poproszono, aby się zupełnie odcięli od tego, co jest, tylko pomyśleli jak taki proces mógłby wyglądać w świecie bez ograniczeń. Dziwny pomysł. Zawsze są jakieś ograniczenia. Ale co tam, mówią, to mają. Poszliśmy po zupełnej bandzie. Gdyby finansowy zobaczył, jak to zaplanowaliśmy, to by nas wszystkich…eeee…pozwalniał. Zostały dwie godziny dzisiejszych warsztatów. Siadamy razem. Pokazujemy nasze rozwiązania. Kurcze, dwa światy! I co , mamy teraz znaleźć odpowiedniki? W sumie, są. Ci z pierwszej grupy mówią, że tak się skoncentrowali na tym, co jest, że nawet nie pomyśleli, że można inaczej. Nieee, no nieźle to wygląda! Kurcze! Ale jazda! Gdybyśmy to wymyślili w poprzednim projekcie to teraz mielibyśmy jeden problem z głowy. Ha! To o to im chodziło z techniką Blue Sky! Niezłe, niezłe. Wcześniejsza firma nam tego nie pokazała.

W ogóle chłopaki są fajne. Otwarci. Wczoraj wieczorem jeden nam opowiadał, jak to było, gdy się certyfikował w Szkocji, Magiel miał niezły. Zresztą widać, że pozostali liczą się z jego zdaniem. Pamiętasz jak on ma na imię? Wszyscy do niego mówią Krokodyl. Adam? No fakt, jest w materiałach.

I jak panie inspektorze? Druga firma lepiej wypadła? Nasze oceny wyraźnie wskazują na drugą? Arkusz oceny, też. To co? Okej, idziemy w kierunku drugiej.

Co miałby robić? Pomoc w stworzeniu umowy

Prawnicy przygotowali umowę. Wzorowali się na poprzednich ,ale mieli sporo wątpliwości odnośnie zapisów, które wymagają naszej bieżącej oceny sposobu prowadzenia prac. Boją się, że dostawca będzie ciągnął analizy w nieskończoność. Tak, tak, wiem, że to w dużej mierze od nas zależy. Ale chyba tak jest fair. Jak będziemy zwlekali, to mamy większe koszty i późniejsze wdrożenie. Ale co to dostawcę? Aaaa, płatność jest po odbiorze prac. No tak. I jeszcze arkusz oceny jakościowej produktu? Całego? Aaaa, wszystkich produktów projektu? Znaczy się, rodzajów produktów? Czyli co? Określimy kiedy uznamy, że proces jest ukończony? I przypadek użycia? I model bazy danych? No dobra. I jeszcze korelacje? Nie do końca czuję, ale jeśli pan ogarnia temat, to jest okej. Przygotujemy to? Taaak? Razem z dostawcą? To będzie załącznik do umowy? W sumie, niezły pomysł. Metodyka też będzie załącznikiem? Aaaa…no tak, na to się umawiamy.

[Minął tydzień]. Mamy problem z tym pańskim przypadkiem użycia. Aaaa, wie pan o tym? Adam jutro będzie u nas? Spoko. Dogadamy się. Okej, pamięta pan, że ja mam jutro wolne. Widzimy się w poniedziałek.

Realizacja

Każdy z opisanych powyżej scenariuszy jest troszkę uproszczony –  za zadanie miał zilustrować problem. Żaden ze scenariuszy nie gwarantuje sukcesu. Natomiast każdy z nich w inny sposób zarządza ryzykiem. Pierwszy, iluzorycznie, stałą ceną. Ale wiadomo, że cena stała, w przypadku problemów, nie będzie ceną ostateczną. Udowadnianie winy (czas, koszty), ciąganie się po komitetach sterujących (czas, koszty), aneksy (czas, koszty), szukanie nowych dostawców (czas, koszty)… Drugi, zrozumieniem, że na początku nie można dokonać ustaleń końcowych i w konsekwencji, zweryfikowaniem dostawcy i bieżącym zarządzaniem pracami. Zaoszczędzamy w dużym stopniu na wyszukiwaniu (często, oczywistych) powodów opóźnień. Zmniejszamy ryzyko zamiatania problemów analitycznych pod dywan (analityk trafił na trop, który należałoby podążyć, ale ponieważ nikt nie zauważył, a czas nagli, to udajemy, że nie słyszeliśmy) i tym samym, wypracowania nieoptymalnego produktu. Ryzykujemy tym, że nie sprawdzi się inspektor. Niezależnie, czy osoba jest zewnętrzna, w stosunku do inwestora, czy nie (choć praktyka pokazuje, że w dużych firmach ciężko znaleźć odpowiednią liczbę osób o szerokiej wiedzy z zakresu procesów produkcyjnych) – na jej barkach spoczywa spora odpowiedzialność za sprawność prowadzonych prac. W zależności od sytuacji, inspektor może nie tylko kontrolować dostawcę, ale także doradzać. Choć w tej sytuacji należy zachować szczególną ostrożność, by nie utracić odpowiedzialności za wytwarzane produkty.

Nic nie stoi, oczywiście, na przeszkodzie, by w pierwszym scenariuszu zweryfikować dostawcę i zatrudnić inspektora. Troszkę to zmniejszy ryzyko, aczkolwiek paradygmaty współpracy są na tyle rożne, że moim zdaniem, fundamentalnych różnic nie uzyskamy.

Proponuję jakieś nowe podejście? Nie. To wszystko już było. Ale, jak to zwykle bywa w historii, te same koncepcje, dylematy wracają raz po raz pod innymi nazwami. Szczególnie teraz warto o tym pamiętać, gdyż popularny edżaj, ten stary i nietrywialny problem, próbuje rozwiązać trywialnymi metodami opisanymi w rożnej maści manifestach. Z drugiej strony podejścia waterfall są temu przeciwstawiane, jako te, które są nieelastyczne, nierealne i niepraktyczne. Wygląda jak wybór między rakiem a cholerą. Ale tak nie jest. Pośrodku jest zdrowy rozsądek i złożona rzeczywistość. Powyższa propozycja próbuje iść w tym kierunku. Niezależnie od sztandaru pod jakim idziemy, nie uciekniemy od problemu kompetencji zespołu (umiejętność pracy wspólnej, kultury), kompetencji poszczególnych jego członków (kompetencje w ramach reprezentowanej w procesie produkcyjnym roli), umiejętności zorganizowania wielu rożnego rodzaju prac wokół metodycznego kręgosłupa (połączenie różnorodności produktów, różnorodności ról, osi czasu w jeden spójny ciąg) oraz umiejętności zarządzania i kontroli procesu produkcyjnego (wychodząc z założenia, że zespół jako taki, sam siebie, jako takiego, raczej nie skontroluje i nie pozarządza). I o tej ostatniej umiejętności nie zapominajmy. Jest bardzo ważna.

Oczywiście, pojawia się pytanie jak znaleźć dobrego inspektora (nie zawsze jest to jedna osoba). Prostej odpowiedzi nie mam. Ale szukać warto.

Ilustracja wpisu – https://pl.freepik.com/darmowe-zdjecie/szczęśliwy-dojrzały-prawnik-wskazuje-przy-podpisu-miejscem-na-kontrakcie-dokumentuje-z-piorem_3140714.htm. Designed by Freepik


Licencja Creative Commons
Ten utwór jest dostępny na licencji Creative Commons Uznanie autorstwa – Bez utworów zależnych 4.0 Międzynarodowe.

Architektura mikrousługowa a analiza systemowa

mikrousługi.jpgAby jakoś zrównoważyć narzekania na korporacyjnego edżajla, drugi dzisiejszy wpis będzie bardziej inżynierski. Ostatnimi czasy mam okazję pracować nad systemami o architekturze mikrousługowej. Oczywiście jako analityk. I z tego analitycznego punktu widzenia, można powiedzieć, że architektura, jak architektura, za jednym wyjątkiem. Wydaje się bowiem, iż w przypadku tej konkretnej architektury, mniejszego znaczenia nabiera klasyk analizy, czyli analityczny model danych, rozumiany jako jednolita struktura opisująca dane, jakimi należy się posługiwać, aby można było zrealizować deklarowane funkcjonalności systemu.

Dlaczego? O tym będzie poniższy wpis.

Usługa

Mikrousługa, z analitycznego punktu widzenia, to usługa jak każda inna. Powinna mieć opisane zachowanie (jak realizuje kontrakt) oraz strukturę danych wejściowych (żądanie) i wyjściowych (odpowiedź). Koncepcyjnie (realizacja może wyglądać różnie w zależności od narzędzia do modelowania, metodyki i wynikających z niej standardów poziomu szczegółowości opisu), model usługi powinien zawierać powiązane ze sobą elementy przedstawione na rysunku poniżej.

Struktura opisu mikrousługi

Struktura opisu mikrousługi

Klient usługi

Załóżmy dla uproszczenia, że analityczną warstwą kliencką usługi będzie klasyczny przypadek użycia. Przebieg realizacji przypadku użycia, będzie zapewne opisany diagramem aktywności lub sekwencji (specyfika stosowanej metodyki). Bez względu na rodzaj diagramu, w momentach, w których zaistnieje zapotrzebowanie na dane, wymagane będzie odwołanie do usługi. Przykład takiej sytuacji prezentuje poniższy rysunek.

Wywołanie mikrousługi z przebiegu przypadku użycia

Wywołanie mikrousługi z przebiegu przypadku użycia

Moment wywołania usługi jest reprezentowany stosowną akcją, która w rożnych narzędziach do modelowania będzie troszkę inaczej wyglądała. Teoretycznie, na pinie wejściowym powinny się znaleźć dane zgodne co do typu z typem REQUEST z modelu opisu usługi. Pin wyjściowy jest zgodny, co do typu, z RESPONSE z modelu opisu usługi. Problem z pinem wejściowym zgodnym z teorią byłby taki, że należałoby albo dodać osobną akcję, która tworzy strukturę żądania na bazie dostępnych danych, albo transformację na przepływie danych, która dokonałaby przekształceń. W naszym podejściu stosujemy delikatne obejście – aby nie komplikować przejść i nie rozbudowywać diagramu o dodatkowe akcje, przypisanie danych pod cechy żądania opisujemy jako pre-condition w akcji wywołania usługi. W języku OCL przyjmuje to następującą postać.

pre:

let req: REQUEST.oclInNew() and
req.cecha1 = daneWejścioweAkcji.cechaA and 
...

Wynik wywołania usługi jest dostępny w pinie wyjściowym akcji. Tak pozyskane dane mogą być wykorzystywane w ramach przypadku użycia. Dostęp do nowych danych wymaga analogicznego wywołania kolejnej usługi.

Specyficzną cechą tego podejścia jest fakt, iż jeśli nawet w różnych usługach zwracamy logicznie te same dane, to faktycznie są one tylko takie same, gdyż znajdują się w różnych obiektach, czy strukturach danych. Specyfika ta powoduje, iż jeden logiczny model danych dla tego typu aplikacji aplikacji byłby tworem czysto abstrakcyjnym, którego zakresem zastosowań byłby jedynie model. Co więcej, odwoływanie się do niego w ramach przebiegów przypadków użycia byłoby okupione dużym wysiłkiem wynikającym z konieczności wiązania danych z mikrousług z jednolitym modelem danych.

Tego typu sytuacja nie ma zwykle miejsca w tradycyjnych, nazwijmy to, architekturach, w których aplikacja składa się z własnego frontendu i własnych danych. W takim kontekście, model danych służy zwykle jako punkt wyjścia dla konstrukcji modelu trwałego (najczęściej relacyjnej bazy danych), czy też, po konwersji do formatu XMI, jako wsad do tworzenia plików mapujących narzędzi OR-mapping. Z modelu logicznego można także generować skryptami MDA fragmenty docelowego kodu źródłowego, w szczególności deklaracje klas, konstruktory, destruktory oraz operacje trawersujące asocjacje.

Nie mając tego typu korzyści, wydaje się, że nie warto inwestować pracy w czysto abstrakcyjną warstwę opisu. Coś oczywiście tracimy, ale zyskujemy bezcenny czas.

 

 

Ilustracja: https://pl.freepik.com/darmowe-zdjecie/abstrakcyjne-geometrycznej-tła-z-futurystyczne-projektu_1104905.htm Designed by Kjpargeter


Licencja Creative Commons
Ten utwór jest dostępny na licencji Creative Commons Uznanie autorstwa – Bez utworów zależnych 4.0 Międzynarodowe.