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.

Edżajl 2018 (level Corpo, level hard)

agile2018mediumDługo nosiłem się z zamiarem powrotu do pisania. W końcu to nastąpiło, ale po raz kolejny sprawdziła się zasada, że rzecz raz odłożona dalej odkłada się już sama. Ostatecznie, zaniosłem się i idąc za ciosem postanowiłem kontynuować wątek zwinności. Dlaczego? Bo chyba nie da się go nie kontynuować, obserwując wszechobecne uzwinnianie się zespołów, metod pracy i całych organizacji. I ten ostatni poziom wydaje się być groźny. I o tym, w skali korporacyjnej, poniżej.

Co to jest ten Edżajl?

No właśnie. Na początku mojej przygody z tym trendem, było to nic innego jak sposób organizacji pracy w zespole projektowym. Kilka prostych zasad, proste narzędzie (stosowaliśmy ScrumDesk) i można było się w to pobawić. Fundamentalnych usprawnień nie odnotowaliśmy, ale miałem wrażenie, że w jakimś stopniu wzrosło poczucie świadomości stanu prac w zespole. Od strony inżynierskiej Scrum nie wpłynął na stosowane metody pracy. Tak było wiele lat temu.

Tymczasem mamy rok 2018. Mamy Edżajl. I tego Edżajla już nie rozumiem. Co oznacza, że nie rozumiem większości otaczającego mnie świata zawodowego.

Poziom IT

Co o nim wiem. Wiem, że Edżajl to klimat pracy. Ma być korzystny. O klimat troszczą się Edżajlkołczowie. Piękni dwudziestoletni, którzy są w stanie powiedzieć jakie metody pracy stosować, a jakie nie, bo się nie sprawdzają. Sprawdzają się metody proste albo nowe. Nie sprawdzają się metody kojarzone z Łoterfolem – siedliskiem zła, który kreatywnych ludzi wciskał w tryby biurokratycznej machiny i pozbawiał wpływu na cokolwiek.

Skąd to wiedzą? Wiedzą stąd, że spotykają się w swoim gronie pięknych dwudziestoletnich i dyskutują. Na tych spotkaniach panuje dobry klimat, skutkujący szczerą, otwartą rozmową, z której to powstają nowe pomysły. W sposób otwarty Edżajlkołczowie komunikują swoje przemyślenia zespołom edżajlowym. Ponieważ pracujemy w duchu akceptowania zmian i poprawek, nie przejmujemy się tym, że nowe pomysły często przeczą starym pomysłom. Refaktor idei, czyli pozytyw.

Edżajlkołczowie pracują ze swoimi zespołami. Zespoły mają ograniczoną liczebność, gdyż zespoły zbyt duże są nieefektywne. Przy większych przedsięwzięciach, powstaje wiele zespołów mających realizować wspólny cel. Ale zespoły są autonomiczne i nikt, ale to Nikt Spoza Zespołu, nie może czegokolwiek wrzucić do Baklogu. Tak więc zespoły muszą się ze sobą dogadywać. Customer collaboration over contract negotiation. Tako rzecze Manifest. Jak się uda, to się dogadają. Jak się nie uda, to zespół, który liczył ale się przeliczył, w swojej autonomiczności musi czekać na autonomię innego zespołu. Ale tym się nie martwimy, bo ważne, że klimat rozmów był korzystny. Kiedyś się dowiezie. Na razie zaślepimy, wdrożymy, i jakoś to będzie. Responding to change over following a plan. No przecież.

W dużych organizacjach systemów jest dużo. Najczęściej zmiana pociąga za sobą zmianę w więcej niż jednym systemie. Autonomiczny zespół musi więc posiadać u siebie specjalistów, którzy będą w stanie dokonać zmian w każdym z systemów. Ale nie zawsze się da. Bo jeśli zmiana dotyka kilkunastu systemów, to posiadanie choćby jednego specjalisty u siebie spowodowałoby przekroczenie maksymalnej liczby osób w zespole. Co więcej, może się także nie udać z racji tego, że system jest z gatunku centralnych i z założenia ma być dobrem wspólnym. A jeśli dobro wspólne, to nie prywatne. I na przykład sposób specyfikowania wymagań dla takiego dobra wspólnego może się różnić od tego, który wypracował zespół autonomiczny. Co więcej, zespół systemu centralnego może mieć całkiem rozbieżne z zespołem edżajlowym priorytety. I znowu trzeba czekać. I zaślepiać.

Manifest rzecze także  Working software over comprehensive documentation. Każdy przedszkolak, nie mówiąc o Edżajlkołczach, wie, że do produkcji softu potrzeba epików, storysów i tasków. Można też kanwasy, łajefrejmy i inne persony. Komunikacja, komunikacja, lekkość, zwinność. Tego nam potrzeba. Życie takiego bytu jest tak burzliwe, jak krótkie. Dyskusja, spory, poprawki, dyskusja, poprawki, zaimplementowane, DOD spełnione, poszło! A po roku jakiś inny, Obcy zespół musi sięgnąć do koncepcji rozwiązania. I męczy, i dręczy, i nawet próbuje się wbić do Baklogu autonomicznego systemu, ale ten ma przecież swoje, autonomiczne priorytety. Się uda, się wbije. Się nie uda, to powstanie kopia, łata, cokolwiek, co pozwoli Obcemu zrealizować swoje, autonomiczne plany. Że to niepotrzebne? Że to nadmiarowe? Kozioł ofiarny, by móc pracować w dobrym klimacie.

W bardzo dużych organizacjach, systemów i zespołów potrafi być bardzo dużo. Wprawdzie każdy jest zmotywowany, skoncentrowany na celu, ale jakaś kontrola – pardon, liderszip – być musi. Ktoś komuś jakiś raport na biurko czasami musi wrzucić. Najlepiej jakby z terminami, kosztami. Oczywiście wszystko edżajlowo, ale tak gdzieś pod spodem, jakby jakiegoś Ganta? Tylko, żeby nikt nie widział.

Poziom organizacji

No ale jak to zrobić? Ha! Proste! Tu do akcji wkraczają piękni trzydziestoletni – mistrzowie fechtunku słowem i pałerpojntem. Ci, którzy karierę pięknych dwudziestoletnich mają za sobą i doradzają. Oni mają wiedzę Świata, gdyż w takich organizacjach pracują, co to taką wiedzą dysponują. I oni wiedzą, że taka jedna firma, to kiedyś, podzieliła się na Trajby, Składy, Czaptery. I oni wiedzą, że tak trzeba postąpić, aby duch edżajla spłynął na całą organizację, a nie tylko na ajti. Wprawdzie piękni dwudziestoletni nie ogarnęli jeszcze zagadnienia współpracy w skali mikro, ale nie przeszkadza to we wdrażaniu zmiany w skali makro.

BPRRolnictwo w Polsce ma długą historię. I co, jak co, ale orki nikt nie musi nas uczyć. Zaorajmy więc dotychczasowe struktury i wdrażajmy podejścia autonomiczne na poziomie biznesu. Piękni trzydziestoletni nie pamiętają jednak, że tego typu radykalne zmiany historia zarządzania zna i ma za sobą. Jedną z najbardziej zbliżonych do Rewolucji Edżajl jest teoria Business Process Reingeenering, opisana przez Hammera i Champy’ego w latach dziewięćdziesiątych w książce Reengineering the Corporation: A Manifesto for Business Revolution. Doświadczenia z  wdrażania tej metody dały w efekcie łagodniejsze podejścia typu Business Process Improvement. Ale to było dawno, a teraz jest Edżajl. Będzie Pan zadowolony.

Tak więc, mamy nowe struktury organizacji edżajlowej. Wywiedzione wprost z koncepcji budowy oprogramowania, metody edżajl zaczynają rządzić biznesem. Edżajl to prostota, wobec czego wraz z nowymi strukturami dekretowane są redukcje (czytaj, uproszczenia) ról i stanowisk. Wprawdzie pracę trzeba wykonać, ale będzie jakoś prościej, bo stanowisk i ról mniej. Poza tym, edżajl to wymienność, więc zawsze można komuś obok coś wrzucić – niech czuje, że ma Edżajla. Czyli prościej i w dobrym klimacie. Nowe struktury są autonomiczne. Nie troszczą się szczególnie o inne, wszystko hermetyzują u siebie i dla siebie. Oczywiście za wyjątkiem tych obszarów, których ukryć się nie da. Ale tutaj jakoś trzeba się dogadać.

Każda zmiana ma jakieś skutki uboczne. To oczywiste. Wśród lekko zdezorientowanych skutków ubocznych stoją ramię w ramię osoby zajmujące się procesami biznesowymi, architekci biznesowi, architekci IT. Pojawia się bowiem zasadnicze pytanie – co ma być optymalizowane – praca Trajbów, czy praca całej organizacji? Co, jeśli te cele nie są zbieżne? Idąc dalej, jak tworzyć architekturę biznesową (choćby pojęcia) – dla Trajbu czy organizacji? Mamy architektury IT dla Trajbów czy dla organizacji? Jak wdrażać jednolite standardy w konstelacji autonomicznych jednostek? Senioredżajlkołczowie to wiedzą. Proponują jednostki wskrośtrajbowe. Ale to oznacza, że Trajb nie jest już tak autonomiczny, jak to obiecywali. Ale kto jest ważniejszy – ten od Wskroś, czy ten w Pionie? Pozostaje się dogadać.

I różne takie

Mylnym byłby wniosek, że tak fundamentalne problemy dotyczą jedynie poziomu organizacji. Na poziomach zespołów także mamy dylematy z gatunku dawno rozwiązanych ale w Edżajl fundamentalnych. Czy analiza powinna być elementem sprintów, czy też wyciągnąć ja poza sprinty, gdyż jest trudna do oszacowania. Wyciągnięcie jej poza sprint skutkuje rozpoczynaniem prac ze stabilnymi wymaganiami. Ale w takim razie w ramach czego powinna być prowadzona analiza? Jeśli zaś jest prowadzona w sprincie, opóźnienia stają się nagminne. Czy user story to wymaganie, czy coś innego? Jak się mają te wymagania do innych metod ich specyfikowania. Jak połączyć repozytorium user story z repozytoriami na przykład narzędzi do opisu wymagań technikami inżynierskimi (UML, BPMN, SysML). Czy elementem zmiany jest też poziom organizacji? Jeśli tak, jaki zespół powinien to robić? Ciężko sobie wyobrazić nieduży zespół posiadający w swoim składzie architektów, analityków biznesowych, analityków systemowych, specjalistów od usprawniania procesów, kontroli procesów, itd. Różne zespoły? To jaki produkt jest prezentowany Prodaktołnerom? Diagram? Jakby wbrew fundamentalnym obietnicom Edżajl.

To co to jest ten Edżajl?

No właśnie. Minął rok i dalej nie wiem. Intuicja podpowiada mi, że to prosta droga ku porażce. Że to już było. Że obietnice aż kłują populizmem w oczy. To, że ja nie rozumiem, co to Edżajl, to jeszcze nie problem. Problemem jest to, że wdrażający Edżajl, mam wrażenie, także nie wiedzą, co to tak do końca jest.

Ale kilkudziesięcioletnie doświadczenie mówi też, poczekajmy. Zobaczymy co z tego wyjdzie.  Idąc tym tokiem myślenia, mam wrażenie, że  Edżaj  zakończy swój dynamiczny żywot tak jak inne koncepcje, które miały zrewolucjonizować świat, a ostatecznie stały się małą częścią czegoś większego, dużo bardziej skomplikowanego. Pytanie oczywiście o koszty tej nauki. Ale to już inna bajka.

Ilustracja: https://pl.freepik.com/darmowe-wektory/ręcznie-rysowane-eleganckie-baleriny_849800.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.

The Business Agility Manifesto – jest nadzieja

Open flying old books

Agile (czytaj, ażil) w korporacji, jak na razie, kojarzy mi się z wielkim bałaganem, jeszcze większym nieporozumieniem i niekończącym się poganianiem jednego wzniosłego hasła, innym wzniosłym hasłem uzupełnianym metaforami coach’ów z zupełnie niepasującej bajki. Może trochę przesadzam, ale jeśli przesadzam, to tylko trochę.

Dwa tygodnie temu w ręce moje wpadł Manifest (https://busagilitymanifesto.org/) opracowany przez osoby, które bardziej kojarzą się z tymi niedobrymi czasami twardej inżynierii niźli ze zwinnością. Roger Burlton, Ronald Ross oraz John Zachman po raz kolejny połączyli siły i na bazie swoich doświadczeń wypracowali zestaw zasad dla zwinnego biznesu. I po raz kolejny, trafili w moje potrzeby. Najważniejszą z nich była potrzeba odnalezienia się w tym szaleństwie, które obserwuję i choćby drobnego odniesienia się do fundamentalnych wątpliwości odnośnie prób skalowania sofware’owego agile’a do potrzeb agile’owej korporacji. I postawienia przeciwwagi dla narracji w stylu „ostatecznie liczy się działający soft”. Bo moim zdaniem tak nie jest. Działający soft jest środkiem do celu, ale nie tylko on decyduje o zwinności organizacji. I od oprogramowania chciałbym zacząć analizę zaleceń manifestu, świadom tego, że zaczynam niejako od środka.

Developing software faster is not sufficient, in and of itself, for survival and growth because once operational, such software is likely to prove difficult to continuously and rapidly change without unintended consequences.

Samoorganizujące się zespoły, dobierające techniki głównie pod potrzeby szybkiego dostarczenia oprogramowania, nie zwracające szczególnej uwagi na szeroki kontekst organizacyjny tworzenia i utrzymania oprogramowania miesiąc po miesiącu dozbrajają tykającą od wdrożenia pierwszego przyrostu bombę. Ograniczanie wiedzy o biznesowym kontekście przedsięwzięcia do form akceptowanych w słownomuzycznym backlogu, odżegnywanie się od technik badających spójność biznesową rozwiązania oraz zgodność z otoczeniem, w którym przyjdzie je zastosować oraz stawianie na piedestale potrzeb deweloperów skutkuje zaciąganiem biznesowego i technologicznego długu, którego termin spłaty może nadejść gwałtownie, bez wcześniejszego uprzedzenia.

W moim przekonaniu, aby oprogramowanie mogło wspierać zwinne zarządzanie organizacją, musi być oparte o solidne fundamenty, w szczególności:

  • uwzględniać biznesową interpretację rzeczywistości organizacyjnej (być w zgodzie z modelem pojęć (koncepcji) ),
  • stanowić naturalne rozwinięcie wynikającego ze strategii organizacji łańcucha tworzenia wartości (być w zgodzie z modelem procesowym bądź innym, holistycznym spojrzeniem na opis realizowanych w organizacji działań dostarczających produkt Klientowi),
  • opierać się o solidny fundament analizy systemowej, zapewniający wewnętrzną spójność oprogramowania.

Część z tych tematów znajduje swoje rozwinięcie w materiałach uzupełniających manifest.

True business agility is measured not just by speed of response to requests, changes, or disruption, but also by the coherence of the response.

Spójność, której dotyczy postulat, powinna być traktowana wielowymiarowo – w poziomie, jako wewnętrzna synergia komponentów rozwiązania informatycznego, jak i w pionie – jako zgodność z rozwiązaniem biznesowym. Aby można było to stwierdzić, wymagane jest stworzenie jednoznacznego opisu wymiarów rozwiązania w formie umożliwiającej ich szczegółową analizę w efektywny sposób. Do tego potrzebny jest aparat narzędziowy bogatszy niż szkice i historyjki.

A critical skill for analysts is the ability to engage in dialogs to assess business knowledge for gaps, conflicts, ambiguity, and completeness.

Aparat ten daje szansę na nawiązanie efektywnego i skutecznego dialogu ze wszystkimi stronami wpływającymi na rozwiązanie, nie tylko tymi, którzy są w stanie zrozumieć potrzebę wytwórcy oprogramowania.

Instantaneous change is not the goal. The goal is well-considered change that achieves the desired business effect and avoids unintended side effects.

Frictionless change is not the goal. The goal is change that is dependably shaped according to business strategy, policies, and business obligations and commitments obligations.

Dobrze zaprojektowane rozwiązanie, uwzględniające wymagania wielu stron, pozwoli na jego płynniejsze wdrożenie oraz dłuższe wykorzystywanie, bez konieczności poprawiania go zaraz po wdrożeniu.

Skimping on the quality of business software – creating a tech debt – has no place in businesses striving for change in existing lines of business.

Dobrze zaprojektowanie rozwiązanie nie będzie automatycznie obciążone żadnym długiem, wręcz przeciwnie, będzie kolejnym małym krokiem w kierunku realizacji strategii.

Failing expensively or repeatedly, even if fast, is nonetheless waste to be eliminated.

The value of failing fast in order to learn fast must be balanced against other factors including: impact on business customers, cost of rework, and exposure to risk.

A jeśli już przyjdzie nam od razu poprawiać świeżo opracowany produkt, oznaczać to będzie, iż najprawdopodobniej po prostu źle wykonaliśmy swoją pracę. Strategia Fail fast ma swoje określone miejsce i nie powinna tłumaczyć każdej porażki.

Self-organizing teams and other agile organization schemes alone do not lead to business agility.

Self-organizing teams are a means, not an end. They do not reduce, but rather increase, the need for business strategy, value chain coherence, reuse of business knowledge, and effective portfolio governance.

A i jeszcze te zespoły. Samostanowiące o sobie. Samoorganizujące się. Szlachcic na zagrodzie… Pracujemy w dużej firmie. Musimy dbać o synergię. Musi być ktoś, kto ustanawia reguły, a zespoły samostanowiąc o sobie, muszą się w wyznaczonych ramach mieścić. Musi być ktoś, kto rozlicza ze stosowania się do reguł. Musi być lider. Konsekwentny.

Tyle na pierwszy raz.


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

Warsztaty nieoczywiste – style myślenia i działania a zespoły analityczne

Pod koniec czerwca, wraz z Jolantą Korczowską, poprowadzimy we Wrocławiu dwugodzinne warsztaty z zakresu stylów myślenia oraz działania, w kontekście organizacji pracy zespołów analitycznych. Z punktu widzenia teorii i standardów analizy biznesowej, temat należy uznać za rewolucyjny. Dla nas, jako prowadzących, temat jest sporym wyzwaniem. Mamy jednakże nadzieję, że dla Państwa, jako dla uczestników, temat będzie podróżą w nowym, inspirującym kierunku.

Serdecznie zapraszamy! Aktualności związane z warsztatami są publikowane na stronie IIBA Polska.

Analiza biznesowa jest ą, ę

Notebook and coffee with copy space on a wooden background. selective focus

Słuchałem jakiś czas wywiadu z prof. Bralczykiem na temat języka polskiego. Z wywiadu tego, utkwił mi w głowie fragment dotyczący ewolucji języka, która między innymi skutkuje znacznym zubożeniem słownictwa będącego w powszechnym użyciu. Mnogość określeń bazujących na subtelnościach i niuansach jest zastępowana zwrotami typu wporzo, mega, czy zapożyczeniami w stylu ołmajgod. Tak, wiem, makaronizmy od wieków uzupełniały nasz język, aczkolwiek, jak mi się wydaje, nie w takim stopniu.

Nałożyłem tę sytuację na inne języki – języki wyrazu myśli analitycznej. Od dziesiątek lat rozwijane z myślą o radzeniu sobie w sytuacjach, w których język naturalny jest niewystarczający, gdy zwykły zapis myśli w formie zdań utrudnia pracę, a czasami czyni ją niewykonalną w zadanym czasie i w oczekiwanej jakości. W obszarze tym także widać było pewną ewolucję – strukturalne metodyki wytwarzania oprogramowania zostały płynnie zastąpione paradygmatem obiektowym, poszerzający się zakres technologiczny odnajdywał wsparcie w nowych środkach wyrazu – nowych językach. Kolejne obszary analizy biznesowej, architektury biznesowej, architektury korporacyjnej zostały objęte dedykowanymi językami. Środki wyrazu, jakimi aktualnie dysponuje (a precyzyjniej, powinien dysponować) kompetentny analityk są ogromne. Nic tylko uczyć się, uczyć, uczyć, nabierać doświadczenia i świadomie, płynnie i adekwatnie do sytuacji stosować.

I nagle okazało się, że to wszystko jest niepotrzebne. Że JAKO analityk CHCĘ stosować bardzo proste techniki ABY szybko wdrażać rozwiązania. I niewiele więcej jest potrzebne. I skomplikowane stało się proste. Jak budowa cepa.

OMG! Ja jednak wolę ą, ę. Rili.

 


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

Analityk biznesowy jako lider

Lider. Często określenie to niesie za sobą skojarzenia z charyzmatycznym prezesem firmy, która osiągnęła spektakularny sukces. Bądź z rozpoznawalnym przywódcą partii politycznej. Z drużyną sportową i jej najlepszym zawodnikiem.

W analizie biznesowej, szczególnie w trudnych organizacyjnie projektach, w ramach których podejmowane są niełatwe decyzje analityk biznesowy musi stać się takim liderem. Liderem zmiany. Twarzą tej zmiany. Kompetencje przywódcze będą wymagane w różnych sytuacjach – w trakcie rozmów ze specjalistami dziedzinowymi o aktualnym stanie organizacji, o występujących problemach, w trakcie wypracowywania docelowych rozwiązań, prezentacji rozwiązań innym interesariuszom projektów. Uzyskanie właściwego poziomu dialogu będzie możliwe w sytuacji, gdy specjaliści dziedzinowi oraz osoby oceniające i podejmujące kierunkowe decyzje odnośnie wdrożenia rozwiązania uznają nas za wiarygodnego partnera. Na wiarygodność wpływa wiele kryteriów: wiedza dziedzinowa, kompetencje inżynierskie (analityczne), umiejętność komunikowania się, negocjowania. W ogromnym stopniu wiarygodność buduje postawa lidera, postawa osoby która całym sobą potwierdza zasadność uczestniczenia w pracach.

Analityk biznesowy uczestniczący w nietrywialnym przedsięwzięciu przez cały czas będzie się zmagał z koniecznością motywowania członków zespołu do zaangażowania się w prace, stawić będzie musiał czoła oporowi, który może się pojawić w sytuacjach, gdy uczestnicy zauważą zagrożenie dla swojego aktualnego miejsca w organizacji, będzie negocjował fragmenty rozwiązania z opiekunami obszarów biznesowych, na które zmiana wpłynie. W tego typu sytuacjach ogromną rolę będą odgrywały kompetencje przywódcze, kompetencje które przekonają inne strony do pójścia we wskazanym kierunku.

Liderem nie można zostać w efekcie dekretacji. Lidera wybiera i akceptuje grupa, z którą pracuje. Lider musi do siebie grupę przekonać. Lider musi pokazać, że warto z nim udać się w długą i niełatwą drogę. Lider musi o swoją pozycję dbać (nie mylić, z walką).

Liderem albo się jest z natury, albo trzeba się nauczyć nim być. Pozycja lidera nie jest dana raz na zawsze – o utrzymanie tej pozycji należy stale dbać. Aby dbać o nią skutecznie, trzeba wyrobić w sobie umiejętności zauważania sytuacji, w której wymagana będzie świadoma interwencja mająca na celu podtrzymanie pozycji. Skutecznego interweniowania także należy się nauczyć.

Proces dydaktyczny w tak subtelnej kompetencji, jaką jest przywództwo nie jest łatwy. W szczególności, niełatwo jest ocenić, czy prezentowana postawa jest przekonująca, czy da szanse zbudować wokół siebie zespół. Pomoc w tym zakresie przyszła do nas z zupełnie nieoczekiwanego kierunku. Wiele lat temu, w szeroko pojętym światku hipicznym, pojawił się nurt naturalnych metod pracy z końmi. Zaowocował on zakrojonymi na szerszą niż dotąd skalę pracami w zakresie behawioryzmu tych wrażliwych zwierząt. Potwierdziły one między innymi fakt, iż konie żyją w bardzo hierarchicznym świecie, w którym to od skuteczności lidera zależy dobrobyt, a często i życie grupy. Jest to świat w którym wykluczenie z grupy oznacza śmierć, a proces ustalania miejsca w stadnej hierarchii odbywa się nieustannie. Często sygnały świadczące o próbie zrewidowania miejsca w hierarchii są subtelne – koń „niechcący” delikatnie kogoś przesunął, koń „przypadkowo” nie usłyszał. Koń nie zrobił nic przypadkowo. Koń sprawdza, czy Ten Drugi jest wyżej (i musi go słuchać), czy przypadkiem dzisiaj To Ja jestem wyżej. Koń nie czyta wizytówek. Koń nie wie, kim jest tato, czy ciocia. Koń widzi Tego Drugiego. I sprawdza go.

Na bazie tego typu wiedzy powstały unikalne w swoim charakterze warsztaty budujące kompetencje przyszłych liderów. W trakcie warsztatów trzeba przekonać konie, iż warto nam zaufać. Konie szczerze nam odpowiedzą. A ja szczerze polecam.

Ulotka: Lustro Lidera

Unikalne warsztaty mające na celu budowanie kompetencji przywódczych, w trakcie których ocena uczestników jest dokonywana przez konie.

 

 

Grafika: http://www.freepik.com/free-photos-vectors/background Background image created by Katemangostar – 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.