Książka inspiruje, skłania do rewidowania swojego podejścia i korygowania popełnianych błędów. Pan Żeliński przygotował wyjątkowy zbiór felietonów. Bazuje on na treściach z bloga o analizie IT-Consulting z najdłuższą historią w Polsce.
Tytuł „Analiza biznesowa. Praktyczne modelowanie organizacji” świetnie zgrywa się z hasłem wpisanym na odwrocie książki: „Zrozum, zanim zaproponujesz rozwiązanie”. To właśnie, w moim odczuciu, główne przesłanie książki (jak i analizy biznesowej) – abyśmy jako analitycy biznesowi, managerowie czy prezesi, nie rozwiązywali problemów bez zrozumienia jak organizacja działa, jakich dokładnie zmian potrzebuje i jaki one wywrą wpływ na inne części firmy. Organizacja to w końcu system naczyń połączonych. Wprowadzane zmiany oddziałują na inne jednostki, procesy i systemy. Często te, które nie przyszły nam do głowy.
Książka porusza dwa problemy: weryfikowanie, czy rozwiązujemy właściwy problem organizacji oraz wskazówki jak ten problem rozwiązać w sposób właściwy, prawidłowo stosując analityczne narzędzia.
Autor wychodzi od sytuacji bardzo często spotykanych na rynku, na których notorycznie wykłada się biznes i analitycy. Czy zakup dobrze zareklamowanego rozwiązania rzeczywiście pomoże firmie? Czy będzie pasowało do jej funkcjonowania? Czy rozwiązuje właściwy problem? Błędy na tym polu powodują, że wprowadzane systemy IT wręcz firmom szkodzą.
Autor przedstawia proste kroki pomagające zrozumieć działanie organizacji a następnie przejście do zaproponowania właściwego rozwiązania. Dalej omawia najczęściej wykorzystywane techniki analizy (przypadki użycia, modele procesów, diagramy komponentów, sekwencji, modele faktów, pojęć, itd.) tłumacząc na przykładach ich właściwe i praktyczne zastosowanie.
Wielokrotnie krytykowane jest podejście do analizy polegające na spisywaniu wywiadów, tworzeniu setek stron dokumentów, w których znajdziemy opisy konkretnych zaobserwowanych przypadków (choć pewnie nie wszystkich możliwych), brakuje tam natomiast zrozumienia ogólnych zasad działania. Jeśli zrozumiemy zasady funkcjonowania, możemy przewidzieć dowolną sytuację i zaplanować reakcję na nią. Przy podejściu zapisywania poszczególnych przypadków jesteśmy zdani na to, czy nasze setki stron spotkaną sytuację opisują czy pomijają. Jeśli pomijają, to wtedy nie mamy odpowiedzi na pytanie „i co teraz?”.
Problem w tym, czy analitykowi uda się to zrozumienie osiągnąć, odkryć wzór, mechanizm rządzący organizacją. Wiem, że to niekiedy bardzo trudne. Z wielu powodów. Za mało znamy działanie firm w ogólności, daną firmę, ograniczenia. Nie potrafimy jednoznacznie opisywać wniosków z analizy, docierać do źródeł, syntezować informacji, uogólniać zależności. Niektórzy wręcz zakładają, że takie pełne zrozumienie jest nieosiągalne i nie próbują. Nastawiają się bardziej na podejście eksperymentalne, przyrostowe, z częstą informację zwrotną od ekspertów dziedzinowych czy użytkowników.
Podobnie niełatwe było odkrycie przez Kopernika, że tory ruchu planet, dotychczas obserwowane z Ziemi i rozumiane jako dziwnie pokręcone, nie dające się dobrze opisać żadnym równaniem, w rzeczywistości są banalnie proste – to okręgi wokół Słońca. Takie zrozumienie tak wiele upraszcza. Umiejętność zrozumienia i tworzenia prostych zasad to powód, dla którego warto czytać pana Żelińskiego. Co prawda droga do tego jest często wyzwaniem intelektualnym i sprawdzianem odpowiedniego zaopatrzenia w narzędzia.
W książce spotkamy też krytykę opierania analizy jedynie na licznych wywiadach. Widzę podobne zagrożenie. Jesteśmy ludźmi, a co za tym idzie, mylimy się, przekręcamy fakty, zapominamy i bazujemy na przypuszczeniach. Jeśli omawiamy kwestię, której źródło leży gdzie indziej – w przepisach, w bazie danych, w funkcjonowaniu systemu, warto sprawdzać informacje u źródła, by zminimalizować ryzyko pomyłki. Kontakt z przyszłymi użytkownikami jest niezastąpiony i szalenie cenny. Warto jednak wiedzieć, jak, kiedy i do czego wykorzystywać go optymalnie. W dużych organizacjach działalność może być bardzo rozległa, a osoby prezentujące jednostki, choć są ekspertami w swoich tematach i choć nawet bardzo angażują się w projekt z najlepszymi intencjami, niekoniecznie muszą wiedzieć o wszystkich wpływach wywieranych na inne części organizacji, w szczególności, jeśli nie są one dla nich ewidentne. Analityk ma za zadanie składać obraz całości, rzeczywistości, działania organizacji ze skrawków dostarczanych z różnych perspektyw („To drzewo”. „Nie, to wąż”. „Nie, to słoń”) i brać odpowiedzialność za ocenę skutków wprowadzania zmian.
Pan Żeliński pokazuje swoją bogatą wiedzę i znajomość przeróżnych technik, notacji i podejść. Z tekstu płynie też niespotykane zrozumienie ich przeznaczenia i właściwego zastosowania. Ponadto widać także znakomitą umiejętność porządkowania pojęć. Docenią to w szczególności ci, którzy doświadczali już jak brak jasności w myśleniu przekładał się na zagmatwanie w projektach.
Prezentowane w książce podejście doskonale sprawdza się w projektach informatyzowania działalności organizacji. Projekty takie angażują ogromne zasoby i pewnie większość specjalistów i budżetów.
Spotykamy także inne typy projektów wymagających eksperymentów i dużej dozy kreatywności. Nie bazują one na stanie obecnym organizacji. Może to być innowacyjny produkt lub atrakcyjny, sprzedający produkty lub usługi interfejs czy serwis informacyjny z banalną logiką (zapis i odczyt prostych informacji z bardzo prostym przetwarzaniem). Nie znalazłam w książce odniesienia do takich sytuacji. Sądzę, że w takich projektach krytykowany proces prototypowania znajduje jednak zastosowanie. Jednakże tu również można czerpać z uniwersalnych metod analizy prezentowanych w książce na przykładach.
Czytając artykuły Pana Żelińskiego czytelnik napotyka co chwilę nazwy stosowanych podejść czy notacji. Skłania to do poszukiwania, odkształcania się i poszerzania horyzontów. Gdyby nie to, myślę, że metody te nie rozprzestrzeniałyby się tak szybko i szeroko w Polsce.
Jeśli jesteś osobą początkującą i masz nadzieję, że znajdziesz tu wyjaśnienie analizy od A do Z, to niestety nie ten adres. Jak napisał autor – książka to zbiór felietonów i tak właśnie należy ją traktować. Książka jest raczej dla praktyków, którzy mogą się już odwołać do swoich doświadczeń z projektów i do wiedzy na temat UML i różnych technik. Początkujący również mogą dowiedzieć się z niej ciekawych rzeczy, zyskać wartościową perspektywę, jednak nie zastąpi to czytania wielu innych pozycji na temat podstaw oraz specyfikacji języków modelowania.
Ta książka to przede wszystkim inspiracja, nawołanie do przemyślenia tego co i jak robimy w analizie oraz źródło do stworzenia listy lektur obowiązkowych takich jak specyfikacje metod i języków modelowania. Jednak czytanie samej teorii nie gwarantuje jej właściwego zrozumienia i zastosowania. Książka Pana Żelińskiego wypełnia tę lukę – pokazuje praktyczne zastosowanie, częste wypaczenia i przypomina nieustannie o prawdziwym celu pracy analityka.
Analiza biznesowa. Praktyczne modelowanie organizacji – książka Jarosława Żelińskiego
Zbuduj fundamenty pracy marzeń jako analityk
Dołącz do 6000 analityków i otrzymaj PDF ze wskazówkami.
Poznaj też serię innych bezpłatnych materiałów i aktualizacje o bieżących projektach
Cześć, jestem Hania.
Jako strategiczny analityk biznesowy na pograniczu zarządzania i IT zapewniam, że projekty i działania w organizacji przynoszą wartość biznesową. Dostarczam kompetencji analitycznych managerom i zarządom z Polski, Niemiec i Szwajcarii przy tworzeniu strategii oraz wdrażaniu jej w kilkuset osobowej międzynarodowej organizacji.
0 komentarze “Analiza biznesowa. Praktyczne modelowanie organizacji – książka Jarosława Żelińskiego”
Po takiej recenzji, nie miałem wyjścia. Musiałem sprawdzić sam co i jak :-). Poświęciłem więc 30 pln i cały wieczór na przeczytanie tej książki.
Zacznę od tego, co mi się podobało. Na pewno wartościowy jest przegląd najważniejszych modeli i pokazanie kiedy i z którego modelu warto skorzystać, a także jak one uzupełniają się między sobą (BTW, mam nadzieje, że jest to fundament, którego uczą już na studiach, a nie dopiero w pracy). Cenne jest podkreślenie, że niejednoznaczność analizy oznacza bardzo duże problemy i jest chyba najcięższym grzechem w tym zawodzie. Każdy, kto wchodzi w rolę analityka, musi umieć z kakofonii mniemań, poglądów i opinii wyciągać fakty, a z nich – definiować ogólne zasady działania organizacji. Modele zaś, co podkreśla autor, mają mu w tym pomóc. Kluczem do sukcesu jest metodyczne i zdyscyplinowane podejście do dziedziny, którą się zajmujemy. Inaczej osoba w roli analityka ryzykuje bycie „dyktafonem”, co nie ma nic wspólnego z faktyczną analizą i kończy się najczęściej rozczarowaniem interesariuszy.
I to by niestety było tyle pozytywów. Z rzeczy, do których można się przyczepić, choć pewnie nie są jeszcze dyskwalifikujące, to:
1. brak powoływania się na źródła (np. raport Forrrestera bez wskazania nawet roku, w którym badania zostały przeprowadzone ani ich dokładnej nazwy, str. 102);
2. brak odwołania się do uznanej literatury czy dobrych praktyk. Nie mogę pojąć jak autor, który cały rozdział poświęca przypadkom użycia (str. 71) nie znalazł odrobiny miejsca, aby przynajmniej wspomnieć, że warto sięgnąć do A. Cockburna, aby przedstawić różne szablony opisywania przypadków (nie tylko własny!), wyjaśnić czytelnikom znaczenie takich elementów jak cel przypadku, zdarzenie inicjujące, warunki wstępne, lub aby wyjaśnić z jakimi innymi artefaktami pracy analitycznej można je łączyć (np. prototypy). Nawet jeśli autor hołduje podejściu zakładającemu redukowanie opisu do minimum, warto przynajmniej wspomnieć, że są też inne szkoły i pokazać ich źródła, albo chociażby, że są różne dobre praktyki (np. używanie nazw w trybie rozkazującym, „złota 7” przy dekompozycji. itp.), z których czytelnik może chcieć skorzystać. Znalazło się za to miejsce, by wspomnieć o cloud computing (sic!);
3. wybiórcze posługiwanie się cytatami (np. bardzo kłuje w oczy powoływanie się w książce, która w tak krytyczny sposób odnosi się do metodyk zwinnych, na Deana Leffingwella, który jest gorącym orędownikiem agile’a i historyjek, twórcą jednego z bardziej popularnych framework’ów do skalowania zwinnego wytwarzania, autorem książki „Agile Software Requirements”);
4. myślenie życzeniowe (np. „diagram przypadków użycia ma fundamentalne znaczenie bo zostanie przeczytany i jest zrozumiały”, str. 31), fundamentalizm pozbawiony naukowej weryfikacji („niezależnie od doświadczenia programiści nie powinni realizować części analitycznej projektów, bo dziedzina ich klienta nie jest ich dziedziną”, str. 58), nierealne oczekiwania (np. rozpoczynanie analizy od opisania całego przedsiębiorstwa, aby dopiero potem przejść do wdrożenia systemu, str. 14) albo zwyczajne mijanie się z prawdą (jak opis na czym polega programowanie zwinne ze str. 119 i sugerowanie w nim, że w zwinnym podejściu cały zespół będzie potrzebował kilku iteracji by dojść do tego, co analitykowi zajmie 1 dzień – wciąż nie rozumiem, za co autor tak strasznie nienawidzi programistów i dlaczego uważa ich za tępe bezmózgi, których jedyną dziedziną jest machanie łopatą, a jak się wezmą za analizę – to na pewno zepsują);
5. brak trzymania się tych samych konwencji nazewniczych (np. autor czasem opisuje relacje pomiędzy klasami czasownikami, a czasem – nie wiedząc czemu – używa rzeczowników, str. 49);
6. literówki (choć to pewnie bardziej świadczy o redaktorze książki, niż o autorze);
7. uwiarygadnianie się m.in. członkostwem w IIBA, a jednocześnie tworzenie własnej definicji analizy biznesowej, która, delikatnie mówiąc, kładzie akcent na coś zupełnie innego (JŻ: „Analiza biznesowa prowadzona jest w celu stworzenia modelu (…) funkcjonowania i zrozumienia zasad działania.” vs. IIBA: „practice of enabling change (…) by defining needs and recommending solutions that deliver value to stakeholders.”); w pierwszym przypadku celem jest wyspecyfikowanie wymagań i budowa modeli, w drugim – jest to jedynie narzędzie do prawdziwego celu, jakim jest rozwiązanie dające wartość interesariuszom. Nie mam nic przeciwko tworzeniu własnych definicji, ale wydaje mi się, że warto przynajmniej wspomnieć tę najbardziej uznaną i wyjaśnić czemu się z nią nie zgadzamy;
8. nic niewnoszący bełkot („Całość będzie zgodna z fazami CIM/PIM. Projekt dziedziny (…) będzie spełniał zasady SOLID projektowania obiektowego, projektowania przez kompozycję (zamiast dziedziczenia) i DDD.” str. 103)
To wszystko co powyżej, to są jednak wciąż detale. A teraz, wg mnie, grzechy kardynalne.
Niewłaściwy tytuł. Książka powinna być zatytułowana: „Analiza wymagań na systemy IT w podejściu obiektowym”, bo tylko taki wąski wycinek analizy biznesowej rozważa. Do tego podejście OOAD traktuje bezkrytycznie, nie wskazując też ani słowem, że można inaczej. Utrwala szkodliwy stereotyp, że miejsce każdego analityka jest w projekcie, pomiędzy biznesem a programistą (bo przecież to są ludzie z 2 różnych światów i potrzebują proxy, aby się dogadali). Nie ma ani słowa o analizie organizacji, strategicznej, architekturze korporacyjnej, czyli o ogromnych połaciach poza-projektowych, gdzie analiza biznesowa również występuje. Ani nawet jak umiejscowić analizę, jeśli oprogramowanie jest wytwarzane zwinnie. Jest tylko o tym, że zwinność jest zła 😉
Mało praktycznych porad. W podręcznikach o BPMN, UML, przypadkach użycia, historyjkach znajdziemy o wiele więcej szczegółów jak korzystać z tych technik. To czego ja oczekiwałem po książce, która praktyczność ma w tytule, to wskazanie rozmaitych tips&tricks, które stosowane w modelach czy opisach zwiększają ich przejrzystość, np. wspomniane już konwencje nazewnicze (na poziomie klas, atrybutów, przypadków użycia), sztuczki przy graficznym przedstawianiu modelu (włącznie z pokazaniem jak ważne jest stosowanie kolorów, pogrubień, wyrównań do osi/marginesu), zestawienie dobrych/złych praktyk (tak rób vs. tak nie rób), pokazanie wzorców dla różnych powtarzalnych zachowań procesu (np. pętle, zdarzenia asynchroniczne, obsługa wyjątków, itp.) – czyli właśnie rzeczy, których analityk nie znajdzie w ogólnych podręcznikach, a których najbardziej brakuje jak się zaczyna pracę w tym zawodzie i ma się do wyspecyfikowania rzeczywisty problem w rzeczywistym projekcie.
Od książki, która chce być praktyczna, oczekiwałbym zdecydowanie większego rozwinięcia opisu różnych odcieni zawodu analityka, wskazania czym się różni praca analityka po stronie dostawcy od tej wewnątrz zamawiającego albo od tej w firmie consultingowej, na co zwracać uwagę gdy jest się bardziej analitykiem od danych, a co jeśli bardziej zajmujemy się procesami. Na co zwracać uwagę gdy się buduje rozwiązania od zera, a na co – gdy się wdraża systemy z pudełka. O czym pamiętać gdy się wdraża hurtownie, a o czym gdy systemy core, workflow albo rozwiązania portalowe/mobilne. Oczekiwałbym opowiedzenia czego oczekują architekci, deweloperzy, testerzy, a czego interesariusze biznesowi, jak z nimi rozmawiać, na co zwracać uwagę, jakich słów nie używać, co jest ważny gdy specyfikuje się interfejs plikowy, a co gdy WS, itp. To jest dopiero praktyczna strona tego zawodu.
Intelektualizm i racjonalizm. Autor reprezentuje ewidentnie podejście do analizy jako do procesu w pełni racjonalnego, pozwalającego poprzez spekulację zaprojektować kompletne, całościowe i optymalne rozwiązanie. Gdzie potem wystarczy usiąść i zakodować jednym strzałem. Tyle tylko, że ponad 30-letnie doświadczenie w budowaniu złożonych systemów IT mówi nam co innego. Badania Standish Group pokazują, że zaledwie 3% dużych projektów realizowanych w ten sposób kończy się sukcesem (w przypadku podejścia zwinnego – 18%).
Autor przywołuje metaforę budowy domu, która jest chybiona. Bo każdy, kto budował dom wie doskonale, że po wprowadzeniu się do niego i rozpoczęciu korzystania, wychodzi cała lista rzeczy, które zrobiłoby się inaczej, a o których się nie myśli dopóki się w tym domu nie mieszka. I sztuką jest złapać równowagę między tym, co jest niezbędne by zacząć prace (np. konstrukcja nośna, technologia budowy, przyłącza, itp.), a tym, co może być ustalone później. Glazurnik, parkieciarz czy gipsiarz, który potrafi zamawiającemu doradzić i wprowadzić zmiany na etapie wykończenia, zamiast bezmyślnie kierować się tylko tym, co architekt narysował w projekcie, to dopiero prawdziwy skarb. Nie znam zamawiającego, który by się z tym nie zgodził. Zaś najlepsze efekty zawsze powstają z rozmowy architektów i budowlańców, zwłaszcza gdy pojawia się problem. Nie z pochylania się nad nawet najlepszym projektem i zastanawiania się, co autor miał na myśli. Tylko z tego, że ludzie siądą i zaczną ze sobą rozmawiać.
Zupełnie nie rozumiem, jak ktoś z takim doświadczeniem analitycznym może widzieć tak czarno-biały świat. Przecież cała nasza praktyka zawodowa uczy nas poruszania się w sferze niuansów, odcieni szarości, eklektyzmu łączącego zarówno metody analityczne, jak i kreatywne. Uczy nas pracy z ludźmi, którzy są po prostu zagubieni. Którym ich przełożeni stawiają coraz bardziej ambitne cele, a oni nie wiedzą czego potrzebują, by je osiągnąć. I nie potrafią, spekulując nad czystą kartką, dojść do tej wiedzy w sposób czysto racjonalny, wnioskując logicznie na podstawie zebranych informacji. Większość ludzi nie ma predyspozycji analitycznych, przyjmują opinie za fakty, nie potrafią (lub nie mają czasu) oddzielić bełkotu od istotnych informacji. Bo też nie od tego są. Są od zarabiania pieniędzy. Założenie, że pomimo tego będą w stanie zanurzyć się w model analityczny i zatwierdzić go raz a dobrze jest wg mnie błędem tej metody. I szkodzi naszemu zawodowi. Trendy bowiem pchają nas w zupełnie inną stronę, ale o tym w tej książce nie ma ani słowa.
Anachronizm. W pełni podpisuję się pod recenzją, która pojawiła się na stronie Heliona. Książka przeciętna, chaotyczna, istnieje wiele innych, znacznie lepszych pozycji. A do tego spóźniona o jakieś 20 lat. Wybaczyłbym gdyby była pisana w XX wieku. Ale że A.D. 2016 ktoś całkowicie ignoruje takie trendy jak agile (tendencyjność rozdziału poświęconego user stories zasługuje na zupełnie osobną recenzję), UX, architektura korporacyjna jest dla mnie nie do pomyślenia. Nie ma tam nawet najmniejszej próby pokazania/wytłumaczenia jak analiza biznesowa może wyglądać we współczesnym świecie, ani jakie są kluczowe kompetencje i umiejętności, by zmiany, które się obecnie toczą, nie okazały się dla analityków zabójcze.
Czytając tę książkę, stanął mi przed oczami jeden z moich wykładowców, uczący socjologii polityki na początku XXI wieku z pożółkłych, 25-letnich skryptów, i odwołujący się w nich do osiągnięć marksizmu-leninizmu. Można? Można. Tylko po co?
Jeśli ktoś wiąże swoją przyszłość z tym zawodem i ma wystarczająco dużo ambicji, by grać w ekstraklasie (czytaj: zarabiać tak, jak zarabiają analitycy górnego kwartyla, a nie ciągnąć się w ogonie przeciętniaków), zdecydowanie odradzam lekturę, bo ryzykuje później bolesne zderzenie z rzeczywistością. Lepiej kupić dobry podręcznik, aby się nauczyć wybranej techniki, a potem, szukając inspiracji dla swojej roli; sięgnąć do źródeł, do takich autorów jak R. Pichler, S. Blais, D. Leffingwell, czy J. Appelo. I zobaczyć w którą stronę to wszystko zmierza.
@Michał Mroczek
Dzięki za podzielenie się opinią. Korci mnie jedno tylko pytanie.
Odnosząc się do tego, że napisałeś „Zupełnie nie rozumiem, jak ktoś z takim doświadczeniem analitycznym może widzieć tak czarno-biały świat” – jaki wniosek z tego należy wyciągnąć?
Najpiękniejsze w wolnym świecie jest to, że każdy może wyciągać takie wnioski, jakie chce. Dzięki różnym wnioskom jest o czym rozmawiać. Ja dla siebie na pewno kilka wyciągnąłem, np. że mam dużo za dużo wolnego czasu, skoro popełniłem tak długi tekst 🙂 Albo, że jestem już stary, bo sam pamiętam jak 10 lat temu bezkrytycznie przyjmowałem wszystko, co pojawiało się na blogu it-consulting. Albo, że pewnie mam spaczone podejście, bo jestem tylko i wyłącznie praktykiem, który nie raz w projektach szedł na kompromisy, na które iść nie powinien. Ale też, że jestem ogromnym szczęściarzem, że nigdy nie utknąłem w żadnym dogmacie… i mam nadzieję, że nigdy nie utknę 🙂 W. E. Deming miał rację pisząc: „It is not necessary to change. Survival is not mandatory.”
Apropos uwag od developerów (i architektów) to jestem za. Warto chociaż zapytać co sądzą o proponowanym rozwiązaniu. W najgorszym razie się z tej uwagi nie skorzysta. W najlepszym – poprawisz dzięki temu coś, co wnosiło ryzyko albo zwiększało koszty. Różne są sytuacje. Zależy też co i gdzie analizujemy. Czasem programiści mają merytoryczną przewagę, np.
– kiedy wprowadzasz zmiany do systemu, który oni budowali od lat i znają go bardzo dobrze, a Ty nie
– kiedy są w danej branży znacznie dłużej niż Ty
– mogą szybko sprawdzić ograniczenia rozwiązania
– kiedy spędzają w danym module 100% swojego czasu a Ty 5% z doskoku
– mają świetne z relacje z otoczeniem, znają wiele osób, szybko docierają do ważnych informacji, a analityk z jakiegoś powodu nie
W kwestiach ogarniania strategii, znajomości rynku, planów zarządczych, analizy procesów, znajomości przepisów, polityk, użytkowników, wolałabym, żeby analityk coś wiedział czy sprawdził zamiast polegać na tym, że developerowi się wydaje inaczej. Niektóre propozycje zmian wynikają z nie brania pod uwagę ważnych czynników biznesowych. Po prostu z perspektywy developera niektórych rzeczy nie widać albo nie wydają się istotne. Zdarzą się programiści, którzy się tym interesują i na coś zwrócą uwagę – ile ludzi, tyle przypadków. Więc w zasadzie to warto posłuchać i zweryfikować jak jest naprawdę.
Jeszcze ciekawa jest kwestia czy musimy przeanalizować całą firmę w czasie analizy? Wydaje się przesadnie pracochłonne. Jednak niektóre rzeczy wystarczy zrobić raz i korzystać przez wiele lat. Np. jak często można spisywać plany strategiczne firmy? Jak często tworzy się i zmienia mapę procesów? Jak często zmieniają się procesy na wysokim poziomie ogólności? Jak często wywracamy do góry nogami raz opisaną architekturę korporacyjną? To są zasoby przydatne do każdej inicjatywy prowadzonej w organizacji, nie tylko pod konkretny projekt czy zadanie.
Czy trzeba to wszystko robić w analizie „dodajcie tu pole X”? Niby nie. Czasem od razu widzisz, że to banał. Albo zapisz, odczytaj formularz. Przelicz coś wg standardowego wzoru. Czasem nie trzeba nic pisać, nad niczym myśleć, bo wszyscy wiedzą jak to zrobić.
Czasem jednak pojawiają się inny scenariusze.
Np. w połowie pracy nad dużym modułem ktoś się orientuje, że on wprost przeciwstawia się celowi projektu. Po roku pracy wstrzymują kilkadziesiąt osób.
Np. mamy zautomatyzować działanie całego pionu, ale że nikt dokładnie nie zna ich procesów, więc zaczyna się kreatywne uszczęśliwianie nietrafionymi ficzerami
Np. do zmiany było jedno pole. Ktoś w podskokach przygotował krótką i przyjemną analizę. Potem zaczynają się błędy z produkcji i sypie z bardziej i mniej oczekiwanych miejsc. Kto by się spodziewał, że to pole wpłynie na niedostępność sprzedawanych klientom produktów? Zależności są ogromne. Słysząc prawdziwy impact biznes nakrywa się nogami. Przecież ostatnio zrobiliśmy to w 1 dzień! Ale pominęliśmy analizę skutków. To jest częsty przypadek zbytniego optymizmu i skracania sobie pracy. Pominięcia, nieprzewidziane sytuacje i błędy z produkcji.
Np. wdróżmy sobie system. Nie wiadomo w jakim celu, nie wiadomo jak teraz działamy, ale będzie fajnie.
Np. mamy nowe przepisy regulacyjne. Tylko gdzie je wdrożyć? Do którego z tych 100 systemów? Nie wiadomo. Czy uwzględniliśmy wszystko i przejdziemy audyt.
True story.
Albo ciekawe dylematy:
– Naprawcie problem wydajnościowy.
– Ale czy faktycznie mamy problem wydajnościowy? [?] Czy wymaganie jest zdefiniowane poprawnie? [TAK] Czy wymaganie jest osiągalne? [NIE] Zatem trzeba zmienić wymaganie na osiągalne. Ale jakie jest osiągalne? Trzeba przetestować wartości graniczne funkcji systemu. Trzeba poznać też rzeczywistą ilość wprowadzanych danych. Trzeba sprawdzić w bazie produkcyjnej stan dotychczasowy. Trzeba dowiedzieć się od biznesu jakie są plany na przyszłość – będzie tych danych więcej czy mniej? Okazuje się, że biznes używa systemu niezgodnie z przeznaczeniem. Co wynika z działania innych systemów realizujących podobną funkcję. Jeśli analizowany system przejmie rolę wiodącą, wtedy danych będzie X, jeśli strategią jest zostawienie obu, to wtedy Y. W zależności od odpowiedzi podejdziemy do tego inaczej. Jest jeszcze jedna opcja poprawy wydajności – zmiana sposobu współdziałania z innymi komponentami aplikacji. Wpłynie to jednak na 4 inne aplikacje i działanie 3 pionów firmy. Czy warto robić optymalizację? Czy zmienić sposób wprowadzania danych, a co za tym idzie proces biznesowy? Czy wprowadzić zmiany we współpracy głównych pionów firmy?
– Bez zastanowienia nad tym, rzucilibyśmy się do pracy nad optymalizacją funkcji pod źle zdefiniowane wymagania wydajnościowe.
Także, warto wiedzieć, co się dzieje wyżej. Nie za każdym razem trzeba tę wiedzę budować od zera.
Jestem jak najbardziej za tym, aby przy okazji analizy porządkować informacje i odkładać wiedzę w taki sposób, aby była ona potem re-używalna. Tylko znowu, skoro książka miała być praktyczna, to brakuje w niej komentarzy kiedy i jak warto to robić. Chociażby banalny przykład struktury repozytorium analitycznego byłby pomocny dla młodych analityków, rekomendacje jak porządkować dokumenty projektowe i artefakty analityczne, podpowiedzi które informacje bardziej się przydają po zakończeniu projektu i warto je porządkować od razu z myślą o re-używalności, a które nie, kiedy warto robić pełną dokumentację up-front, a kiedy można ją zrobić po developmencie – to są prawdziwie praktyczne wskazówki. Bo oczywiście, jak się jest analitykiem-firmą to można klientowi powiedzieć: „pracuję tak i tak, a jak się wam nie podoba – to wynocha”, ale większość analityków nie ma takiego komfortu. Większość z nich musi się dostosować do otoczenia. A co za tym idzie, potrzebują odrobiny sprytu, cwaniactwa, dyplomacji i doświadczenia, by przekonać innych, że warto robić tak, jak oni proponują.
Są projekty, zwłaszcza na wczesnym etapie rozwoju, gdzie można sobie pozwolić na zadawanie pytań o strategię, cele, podważać zakres projektu, szukać i porównywać różne rozwiązania. I udowadniać, że jest potrzebny albo że nie jest potrzebny CRM. Ale są też i takie projekty, w których jest już absolutnie za późno na takie ćwiczenia (z różnych powodów, nie tylko merytorycznych), albo projekt przypomina chodzenie po polu minowym. I dobry analityk musi być w stanie rozpoznać w jakiej sytuacji się znajduje, rozumieć np. że zupełnie inna jest awersja sponsorów do ryzyka w projektach R&D, a zupełnie inna w projektach regulacyjnych gdzie np. ryzykują własną odpowiedzialność karną, że zupełnie inaczej wygląda realizacja projektu narzuconego przez właściciela, a zupełnie inaczej, gdy firma ma pełną autonomię, że zupełnie inaczej wygląda realizacja projektu małego, realizowanego pół-amatorsko albo zajmującego się realizacją „quick-win’ów” w perspektywie kilku tygodni-miesięcy, a zupełnie inaczej realizacja wieloletniego, strategicznego projektu transformacji przedsiębiorstwa.
Ocenę otoczenia i sytuacji robi się po to, aby: a) dobierać właściwie środki i metody – a przez to być bardziej skutecznym, b) nie roztrzaskać się na najbliższej ścianie (np. z napisem „Zarząd”) szarżując 100 km/h, bo właśnie się odkryło, że ten projekt, co to go zarząd z pompą odpalił się nie spina, więc przecież to oczywiste, że cała firma będzie nas nosić na rękach za to odkrycie 🙂
I to jest właśnie dla mnie „praktyczne modelowanie organizacji”.
@ Michał Mroczek
Dziękuję za tę recenzję.
Podpisuję się pod zdaniem „jestem już stary, bo sam pamiętam jak 10 lat temu bezkrytycznie przyjmowałem wszystko, co pojawiało się na blogu it-consulting” i między innymi dlatego wahałem się czy aby autor nie będzie forsował idyllicznego modelu z czasów „masz tu 7-o cyfrowy budżet i minimum pół roku i wyanalizuj mi wszystko w raporcie na 160 stron”.
Cóż, w pierwszej dekadzie XXI w wszyscy byliśmy piękni, młodzi i wkrótce bogaci, więc za różne rzeczy się płaciło (lub się je wykonywało – klient płacił). Miło powspominać. A z resztą, może wciąż gdzieś jeszcze są takie wielkie projekty strategiczne z analizą na pół roku czy więcej, ale moje codzienność jest zupełnie inna.
Raz jeszcze dziękuję za recenzję, oszczędzony czas przeznaczę na kolejną powtórkę Gherkina. Zdecydowanie bardziej praktyczna część analizy…
„masz tu 7-o cyfrowy budżet i minimum pół roku i wyanalizuj mi wszystko w raporcie na 160 stron”
To jest przykład przekonania, którego się ktoś kiedyś nabawił i trzyma się go, nie zaglądając do książki, chociaż fakty są wprost przeciwne. W książce Jarka jest właśnie podejście krytykujące zbyt długi czas analizy i zbyt długie dokumenty.
A przy okazji – ciekawi mnie skąd pewność, że w projektach, w których analiza jest robiona w trakcie projektu minimalistycznymi środkami wyrazu (odczytuję, że taką preferujesz?) nie powoduje, że budżet pompuje się do 7-cyfrowej kwoty i wydłuża się o pół roku?
Konstrukcja zdania może wyglądać zaczepnie, ale nie – faktycznie mnie to ciekawi.
A proszę bardzo, np. https://www.infoq.com/articles/standish-chaos-2015
Agile vs. Waterfall 🙂
Dzięki za linka. Rozumiem, że raport jest do wglądu za ok 4000 zł (1000$). Ktoś z Was go widział?
Kilka rzeczy mnie ciekawi – nie widzę informacji o tym, ale może wiesz/wiecie:
1. Jeśli sukces projektu jest określany jako w budżecie, w czasie, a w agilu nie wiem z góry jaki będzie budżet i czas, to jak mogę ocenić czy projekt był w czasie i budżecie?
2. Jeśli sukces projektu jest określany jako „z zadowalającymi rezultatami” to kto z jakiej perspektywy ocenia czy rezultat jest zadowalający w tym badaniu?
3. Jak są zdefiniowane agile i waterfall?
Jeśli mam projekt np. podzielony na etapy, którego kierunek jest znany, ale dokładne wymagania są opracowywane częściami przed wdrażaniem, nie w 2-tygodniowych, ale kilkumiesięcznych cyklach, użytkownicy są angażowani do pracy, ale nie na 100% i nie bezpośrednio z developerami, praca odbywa się częściowo u klienta, za sukces management uważa wdrożenie, ale dokumentacji jest niemało, cały czas działa proces zarządzania zmianami, choć jest ustalony (sformowalizowany) to to jest agile czy waterfall?
Ha, słynny CHAOS do którego każdy nawiązuje, choć mało kto go widział! Niestety, ja również nie miałem okazji go przeczytać, dlatego odpowiadając na pytania jedynie moim zrozumieniem, a nie definicjami Standish Group.
Ad 1
Au contraire! Z góry wiesz jaki masz budżet i czas, choć nie do końca wiesz co konkretnie w tym czasie zrobisz.
To takie proste, a jednocześnie tak niezgodne z akademickim podejściem do analizy, że zajęło mi dobry rok zanim mój mózg się z tym pogodził. Ale gdy to się w końcu stanie – cały ten „agile” zaczyna mieć sens.
Ad 2
O ile wiem, Standish pracuje nad redefinicją wartości i satysfakcji ta gdzieś od 2014. Nie wiem czy to już zrobił, bo nie stać mnie na ich raport. Nie stać mnie też na czekanie aż go stworzą, dlatego mam własną, bardzo prostą definicję „zadowalającego rezultatu” – otóż zawsze decyduje klient.
Bo klient wie czego chce. Choć zwykle nie wie czego potrzebuje na początku projektu (dlatego właśnie czas i budżet są stałe, a zakres zmienny), gdy już to zobaczy to będzie wiedział, że to jest to czego potrzebuje aby osiągnąć to czego chce.
Ad 3
Ha, z gatunku „wielkie pytanie o życie, wszechświat i całą resztę”. O ile pamiętam odpowiedź to: 42. Ale może imię jego 44?
A tak na serio to… nie podejmę się definicji. Sądzę, że osobą książkę można by napisać.
I tu by musiało być o wymaganiach (bo one są w agile), o priorytetach, o właścicielstwie biznesowym i decyzyjności, o tym co stanowi wartość dla klienta, o iteracyjności, a nawet o dokumentacji (bo ona też istnieje w agile).
A na końcu okazałoby się, że to i tak nie ma znaczenia. Bo w sumie to jaka to różnica czy jesteś agile czy nie? Kluczowa jest satysfakcja klienta, bo to on zleca i on płaci.
I tu znów powrót do punktu pierwszego – z mojego doświadczenia klient zwykle ma określony budżet (zarobię X o ile nie wydam więcej niż Y) i czas (zarobię jeśli wejdę na rynek w czasie Z), natomiast żadko wie czego (w sensie systemów IT) potrzebuje aby osiągnąć swój cel.
Zwinne metody wytwórcze stawiają akcent na szybkim dostarczaniu działających części systemów IT, dzięki czemu dają szansę natychmiastowej weryfikacji hipotez o tym co faktycznie stanowi realizację zdefiniowanej na starcie potrzeby biznesowej. Moim zdaniem tu kryje się ich największa wartość i aktualna popularność (bo rynek stał się bardzo szybko zmienny).
To oczywiście nie wyklucza istnienia takich dziedzin rynku, gdzie szybka reakcja nie ma specjalnie znaczenia, a wartości stanowi dopiero dostarczenie kompletnego rozwiązania, którego działanie daje się przewidzieć od A do Z jeszcze przed rozpoczęciem prac. Osobiście jednak nie widziałem takiego przypadku od ładnych kilku lat. Widziałem za to całkiem sporo „rozjazdów” między tym co się komuś wydawało potrzebne, a co faktycznie było używane po wdrożeniu.
Najważniejsze:
Ad. 1 Jak pisał Rafał, stały budżet jest absolutnie podstawowym punktem wyjścia do wytwarzania w agile
Ad. 2 Jak się poszuka w google to można znaleźć kilka stron opisu metody raportu, ale bez szczegółów. Jak znam takie firmy, to pewnie jest to badanie ankietowe, z opisową definicją np. zadowalających rezultatów. I każdy kto wypełnia „uznaniowo” ankietę, podpiera się takimi definicjami. Nikt nie liczy z kalkulatorem w ręku wyników każdego projektu.
Ad. 3 I teraz jest najciekawsze. Hania, niestety nadal umyka Ci istota agile’a. Na poziomie pryncypiów, sposobu rozumienia świata. Na poziomie kilometry powyżej sposobów organizacji pracy. Redukujesz agile do mechaniki czynności (dzielenie zakresu, kolokacja, itp.). A clue jest gdzie indziej!! Muszę zacząć od historii, więc niestety będzie długo.
Historycznie, najpierw był waterfall (lata 70-te), potem pojawiły się podejścia iteracyjne jak np. RUP (lata 80-te), a potem agile np. XP, SCRUM (lata 90-te). BTW, to co dziś nazywamy waterfallem często jest podejściem iteracyjnym. Czystej kaskady chyba już nikt nie używa 😉 „Agile” po polsku można określić jako „podejście adaptacyjne”. To polskie określenie lepiej tłumaczy istotę, więc będę tutaj się go trzymał.
Główna różnica między kaskadą/iteracją a podejściem adaptacyjnym jest różnicą na poziomie epistemologicznym czyli tzw. teorii poznania. Upraszczając, teorie są dwie: racjonalizm i empiryzm. Pozostałe dziedziczą z którejś z nich 😉 A wszystko zaczęło się od Platona i Arystotelesa, więc trochę już trwa.
Podejście adaptacyjne zakłada, że na początku nie jesteśmy w stanie w całości rozumieć przedmiotu (wymagań), z którymi się mierzymy. Tu nie chodzi o to, że przy odpowiedniej ilości czasu (plan), bylibyśmy w stanie taką analizę wykonać (racjonalizm), ale nie robimy tego ze względów ekonomicznych, tylko o to, że choćbyśmy się starali ze wszystkich sił i mieli nieograniczone zasoby, to i tak nam to nie wyjdzie i będziemy musieli uczyć się tych wymagań w trakcie (ciągły re-planning, podejście adaptacyjne, empiryzm). To jest istota! Nie to jak zorganizujemy projekt, czy podzielimy na etapy, itp.
Skoro będziemy musieli się adaptować, to musimy wmontować w cały proces uczenie się, wyciąganie wniosków, dostosowywanie. Jeśli mam zespół, który przechodzi od fazy do fazy, jak po sznurku (czyt. jak po diagramie Gantta), nie zastanawiając się nad swoją produktywnością, nie sprawdza czy to działa na produkcji, itp., to jest to czyste podejście iteracyjne.
Dalej, skoro zakładamy adaptację, to zmiana w ramach adaptacji jest czymś naturalnym, traktujemy jako coś pozytywnego (!), cieszymy się z niej, bo to oznacza, że umiemy się adaptować, że proces działa, że nasze rozwiązanie jest coraz lepsze. Jeśli natomiast zakładamy, że zmiana jest czymś co przeszkadza (w planach, w zarządzaniu, itp.), staramy się by było jej jak najmniej, bo przecież uznajemy, że przystępujemy do projektu z pełną wiedzą o wymaganiach – to jest to podejście kaskadowe/iteracyjne.
Dalej, skoro zakładamy adaptację, to przedmiot na podstawie którego się uczymy (software) musi być dostarczony jak najszybciej, cały czas musi działać, od początku ma być zintegrowany ze swoim otoczeniem, itp. Bo inaczej nie będzie nam dostarczać informacji o tym, co jest nie tak. Jeśli natomiast zakładamy, że integrowanie i uruchomienie systemu to tylko jakiś punkt w czasie, który możemy sobie zaplanować i dojdziemy do niego zgodnie z planem – to jest to podejście kaskadowe/iteracyjne.
I najważniejsze! Skoro podejście adaptacyjne, to musimy ciągle dostawać feedback czy to, co dowozimy, jest ok. Bo inaczej nie będziemy się adaptować do otoczenia (czy. potrzeb klienta, które on sam też odkrywa w trakcie). Skupiamy się więc na tym, by jak najszybciej dostarczyć kawałek, a nie na tym jaki zakres sobie zaplanowaliśmy na początku. Jeśli natomiast punktem wyjścia jest zaplanowany zakres i Twoje iteracje (fazy) mają na celu co najwyżej dowieźć go, jedna po drugiej – to jest to podejście iteracyjne.
Jeśli uważasz, że mając:
a) nieograniczoną ilość czasu
b) dostępnych użytkowników
c) narzędzia analityczne (diagramy pojęć, stanów, sekwencji, wymagania, itp.),
jesteś w stanie opisać dowolne rozwiązanie, po które przyszedł do Ciebie klient, to wierzysz w potęgę ludzkiego rozumu (racjonalizm). To, że sobie to podzielisz na kawałki aby było bardziej zarządzalne, mniej ryzykowne, miało większe ROI, nie zrobi z Ciebie agile’owca. Bo nadal zakładasz, że jesteś w stanie a priori stworzyć to, czego potrzebuje klient.
Jeśli natomiast masz:
a) nieograniczoną ilość czasu
b) dostępnych użytkowników i
c) narzędzia analityczne
a mimo to, nadal uważasz, że pełne opisanie rozwiązania jest niewykonalne, a to co robisz to budowanie hipotez, a nie wiedzy – jesteś „agile” 😉
p.s.
Świat oczywiście nie jest czarno-biały i wszędzie tutaj są odcienie szarości. Szufladkowanie, takie jak zrobiłem powyżej, równiutko, wg linijki, nie ma w praktyce większej wartości biznesowej. Przydaje się tylko w pracy naukowej. W biznesie liczy się skuteczność. Jeśli w Twojej firmie działa wkręcanie śrubek młotkiem, to nie ma co tego zmieniać.
A jeśli już o szufladkowaniu mowa… sprawdź coś co się nazywa „CYNEFIN framework”, nie pożałujesz.
Żebyśmy mieli jasność: to nie ja tak preferuje – tego chce mój klient.
Nie znam rzecz jasna całego świata, jeśli gdzieś jest klient skłonny płacić za książkową analizę to wspaniale. Jednak w moim otoczeniu każdy przedstawiciel biznesu, nawet ten najbardziej oddalony od realiów projektów IT, zna pojęcie „analysis paralysis” i nie zamierza za to płacić.
Żywię do pana Jarosława duży szacunek, ponieważ pamiętam że w swoim czasie jego strona internetowa była jedynym sensowym źródłem wiedzy o analizie w polskim internecie. Nie mniej jednak to czego się od niego nauczyłem sprawdziło mi się blisko 10 lat temu, a od kilku lat jest wiedzą zupełnie akademicką – dobrze to wiedzieć, ale nie ma okazji by to praktycznie wykorzystać.
Recenzja pana Michała pokazuje, że w książce znajdę więcej tego co już wiem i nie mam okazji użyć.
Ktoś mi ostatnio powiedział, że jeśli klient płaci za diagramy procesów biznesowych to on je robi, a jeśli klient ich nie chce i nie płaci, to ich nie robi. Myślę, że grunt to zrozumienie, rozwiązanie problemu i zakomunikowanie tego, co kto i do czego potrzebuje. To można robić na wiele sposób. Nie odnoszę nigdzie wrażenia, że inne podejście jest tu proponowane. Kwestia pozostaje taka, żeby wiedzieć jak to można zrobić, znać narzędzie i sięgnąć po odpowiednie. Nie sądzę, żeby to komuś przeszkadzało czy robiło różnicę co sobie robimy w modelach czy notatnikach, jeśli efektywnie rozwiązujemy problem. Jeśli ktoś potrafi nie modelować procesów, modeli dziedziny, struktury i zachowania, wszystko to przetworzyć w głowie, wyprodukować z siebie jedynie Gherkina i wszystko jest fajnie przemyślane – to wow. Jednak wszystkim innym myślę, że nie zaszkodzi wiedzieć, że są też inne metody zrozumienia problemu i dojścia do rozwiązania.