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.
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.
Michał Mroczek
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.
m
@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ąć?
Michał Mroczek
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.”
Hania Wesołowska
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.
Michał Mroczek
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”.
Rafał
@ 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…
Hania Wesołowska
“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.
Hania Wesołowska
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.
Michał Mroczek
A proszę bardzo, np. https://www.infoq.com/articles/standish-chaos-2015
Agile vs. Waterfall 🙂
Hania Wesołowska
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?
Rafał
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.
Michał Mroczek
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.
Rafał
Ż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ć.
Hania Wesołowska
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.
Może zaciekawi Cię także:
Kulisy badania zarobków #1 przygotowanie danych
541 osób wzięło udział w badaniu zarobków i kompetencji analityków 2021. Żeby umilić czekanie na wnioski, przedstawiam kulisy badania –
Zmiany w certyfikacie ECBA IIBA
Zobacz co IIBA zmienia w zakresie egzaminu ECBA. Co to oznacza dla z zdających? Kiedy zmiany wchodzą w życie? Skąd
Książki, które polecam z 2020 roku
Polecam 7 spośród książek, po które sięgnęłam w 2020 roku. Może posłużą i Tobie. Książki uczą, poszerzają horyzonty i wywracają
Zapisy na III edycję Kursu Zdobądź Certyfikat ECBA IIBA
Zapisy na III edycję Kursu Zdobądź Certyfikat ECBA IIBA skończyły się 31.01.2021 r. Z 3-cią grupą uczymy się do połowy
Badanie Zarobków i Kompetencji Analityków Biznesowych 2021
Rusza badanie zarobków i Kompetencji Analityków 2021. Weź udział i dowiedz się ile powinieneś zarabiać. Poznaj lepiej analityków w Polsce.
Badanie Zarobków 2021 – Jakie pytania?
Badanie Zarobków i Kompetencji Analityków Biznesowych analiza IT odbyło się na początku lat 2016, 2017 i 2018. Po 3 latach
Materiały o analizie, których potrzebujesz – badanie
Chcę przygotowywać dla Ciebie materiały edukacyjne, których naprawdę potrzebujesz. Zamiast się domyślać co to jest, po prostu Cię zapytam. 🙂
Zmiany w Scrum Guide i analiza – pierwsze wrażenia
Wczoraj ogłoszono zmiany w Scrum Guide – przewodniku po najszerzej stosowanej metodzie pracy zespołów deweloperskich w IT (i nie tylko).
Aktor na diagramie przypadków użycia UML
„Stanęłam przed wyzwaniem analizy wstecznej systemu, w którym wszystkie procesy są wywoływane przez system, nie ma żadnych użytkowników biznesowych. System
Bezpańskie wymagania
Pamiętam pierwszą zaskakującą lekcję o wymaganiach. Wyciągnęłam pieczołowicie przygotowaną moją pierwszą specyfikację wymagań. Zebraliśmy wymagania przez wywiad z klientem –
Kurs Analiza w 7 krokach
Badania pokazują, że jedną z najczęstszych przyczyn porażek projektów są problemy z wymaganiami. Mimo wielu lat doświadczeń w branży, wciąż nie
Książki o analizie biznesowej i nie tylko
Na goodreads zebrałam książki, które przeczytałam lub chcę przeczytać. Zajrzyj, może któraś Cię zaciekawi. Podziel się swoimi wrażeniami. Poleć coś
Lean Coffee Analityków #4
Wpadaj na 4. spotkanie analityków i przynieść swój temat 🙂 Spotkamy się w formie Lean Coffee – każdy dorzuca temat,
Kurs Trafnych Wyborów
Wydaję Kurs Trafnych Wyborów, w którym nauczę Cię jak przygotowywać profesjonalne uzasadnienie biznesowe i podejmować najlepsze decyzje. Sama w ten
Jak pracować z przeszkodami?
Co łączy Scrum Mastera, lidera i strategicznego analityka biznesowego? Każdy z nich próbuje usuwać przeszkody stojące na drodze grupy osób,
aw3m #017 Kiedy inny zespół ma Twoją zmianę głęboko w backlogu
Co zrobić, kiedy Twoje zadanie zależy od części, jaką dostarcza inny zespół, ale on ma swoją część głęboko w backlogu?
Komunikacja – co może pójść nie tak?
„Zaczynam myśleć, że to największy problem ludzkości” – powiedział znajomy. Mnie również każdego dnia przytłacza nieskuteczna komunikacja – u siebie,
Jak radzić sobie z aspektami prawnymi w projektach IT?
W pracy analityka biznesowego zdarza się, że analizuje on projekty zahaczające o aspekty prawne. Często jednak nie ma wystarczającej wiedzy
BABOK Guide v.3 – IIBA
Jeśli jeszcze nie znasz (na pamięć 😉 BABOK Guide, zapraszam do nagrania – co to za książka, co w niej znajdziesz
aw3m #016 Optymalizacje lokalne
Masz pomysł na uprawnienia w pracy? Czy jesteś pewien, że to będzie dobre? A może jedynie przesuniesz problem w inne
aw3m #015 Wymagania jakościowe
Wymagania jakościowe (niefunkcjonalne, pozafunkcjonalne, NFR) – czym są, jak je znaleźć, z kim uzgodnić? Zobacz analizę w 3 minuty. Wymagania
aw3m #014 Analiza wteczna – jak ogarnąć nieudokumentowany system
Jak ogarnać istniejący, nieudokumentowany system, kiedy musimy go zmieniać, utrzymywać, rozwijać, a dokumentacji brak i nie wiadomo jak działa? Kilka
aw3m #013 Dzień analityka
Zastanawiasz się jak wygląda dzień z życia analityka? Co robimy? Określamy problemy i cele Planujemy zadania analityczne Robimy analizę interesariuszy
aw3m #012 Najczęstsze błędy w analizie
Jakie są najczęściej popełniane błędy w analizie biznesowej? Zobacz ranking.Masz przed sobą ranking najczęstszych błędów w analizie biznesowej. Można kłócić
aw3m #009 Waterfall
Waterfall – już jest największą obelgą, a niedługo zaczniemy nim straszyć dzieci 😉 Czym jest a czym nie jest waterfall?
aw3m #008 Jak nie przeprowadzać spotkań
Jak nie przeproadzać spotkania? Kilka wskazówek – czego nie robić przed, w trakcie i po spotkaniu, żeby zmarnować czas. Najwyżej
aw3m #007 Jak zbierać wymagania
Jeśli klient nie wie, czego chce, wymagania ciągle się zmieniają, dałeś im to, co chceli, a nadal są niezadowoleni… to
analiza w 3 minuty #005 Jak współpracować ze specjalistami UX
Jak współpracować ze specjalistami UX? Trudno o tym w 3 minuty :P, ale cóż – próbuję 🙂 A w tym
Analiza w 3 minuty #004 Jak sprawdzać realizację celu
No, dobra, 3 minuty to naprawdę niewiele 😛 Ale cóż – wyzwanie to wyzwanie. W galopie poszło dziś o weryfikacji
Analiza w 3 minuty #003 Jak zacząć w nowej firmie
Jak zacząć pracę analityka w nowej firmie? Czego się dowiedzieć? Zapraszam na 3 odcinek z serii “analiza w 3 minuty”
Czy analitycy wyginą?
Czy analitycy wyginą? Bo przecież agile i w ogóle. To pytanie zadał Radek. I teraz pewnie żałuje, bo jak przystało
Analiza w 3 minuty #002 Jak określać cel
Jak określać cele? W 3 minuty streszczam: > po co to robić > co zazwyczaj robimy źle > 3 techniki,
Analiza w 3 minuty #001 Hello World
Jeśli ktoś subskrybował kanał YouTube, to się po 100 latach doczekał czegoś nowego 🙂 Ruszam z serią “analiza w 3
Myślenie systemowe – recepta na strzały znienacka
Masz czasem wrażenie, że świat projektów IT jest cholernie nieprzewidywalny? A gdyby tak nie popadać w paranoję i ogarnąć to,
Zostań swoim własnym zewnętrznym konsultantem – myślenie lateralne
We wszystkich profesjach spotykamy się na co dzień z różnymi problemami, a żeby rozwiązywać te problemy skutecznie, musimy umiejętnie korzystać
Jak zweryfikować wiedzę analityka? Certyfikat ECBA IIBA wg Mikołaja
Funkcja analityka biznesowego w firmach oraz projektach IT w Polsce pojawiła się dość niedawno. Zakres obowiązków na tym stanowisku oraz
Raport Zarobków i Kompetencji Analityków Biznesowych 2018
Przed Tobą wyniki III edycji Badania Zarobków i Kompetencji Analityków Biznesowych 2018! Po raz trzeci zapytaliśmy kilkuset analitków biznesowych w Polsce
NA006: Zarządzanie zmianą w organizacji
„Bądźcie bardziej agile”. To, z grubsza, początek i koniec instrukcji od Ważnego Managera, jakie dotarły do większości pracowników jednej z
Analityk płakał #15 Product Owner nie reklamuje
Badanie satysfakcji klienta – czy naprawdę robisz dobrą robotę?
Chcę Cię zczelendżować 😛 Znaczy się postawić przed niewygodnym zdaniem. Wyniki mogą zepsuć Ci humor. Ale jeśli tak się stanie,
Agile Analityk w Scrumie
Wielu analityków zastanawia się jak pogodzić swoją pracę z podejściem agilowym, a zwłaszcza popularnym Scrumem, który nie ma roli analityka.
Czy analityk robi głuchy telefon?
Spotkałam się ostatnio ze stwierdzeniem, że analityk źle wpływa na komunikację w projekcie tworząc efekt tzw. głuchego telefonu. Niepotrzebnie staje
Plebiscyt – Zasłużeni dla analizy
Czy jest ktoś, kto szczególnie na Ciebie wpłynął? Ktoś, dzięki komu jesteś takim analitykiem jak dziś? Teraz masz szansę podziękować,
Kurs UML Michała Wolskiego do 9 stycznia!
Chcesz nauczyć się UML? Ale tak na serio? 🙂 michalwolski.pl wypuścił kurs internetowy! 13 diagramów, 5h godzin wideo, 4 webinary,
NA005: Tworzenie i rozwój produktu – Olga Springer i Tomasz Tomaszewski
[podcast src=”https://html5-player.libsyn.com/embed/episode/id/6033918/height/360/width/450/theme/standard/autonext/no/thumbnail/yes/autoplay/no/preload/no/no_addthis/no/direction/forward/” height=”360″ width=”450″ placement=”top” theme=”standard”] Jak zasubskrybować podcast? Słuchaj go z komputera: na tej stronie na YouTube na iTunes
Badanie Zarobków i Kompetencji Analityków Biznesowych 2018
Masz przed sobą 3. już edycję Badania Zarobków i Kompetencji Analityków Biznesowych Analiza IT. W tym roku od grudnia 2017
Badanie Zarobków Analityków Biznesowych 2018 – zapowiedź
Pamiętasz badanie zarobków i kompetencji analityków biznesowych? Ostatnio wzięło w nim udział 382 osoby, co było niemalże spełnieniem postawionego celu
Relacja z ReQuest 2017
ReQuest zapowiadało się dobrze – w agendzie pojawiło się wiele znajomych nazwisk. Kolejny plus – do Torunia bliżej niż do
Certyfikat Professional Scrum Product Owner I
Wielu analitykom (i nie tylko) chodzi pewnie po głowie, żeby zrobić certyfikat na Product Ownera (Professional Scrum Product Owner). Pojawia
Podejście zwinne czy sterowane planem
Nie trudno zauważyć, że projekty różnią się od siebie. Zamiast działać “na jedno kopyto”, można z większym powodzeniem realizować projekt
Książka "Inżynieria wymagań. Studium Przypadków"
Naczytałeś się już o wymaganiach i analizie, ale nadal brakuje Ci konkretów? Chciałbyś podejrzeć przez ramię jak faktycznie pracują inni
Analityk płakał # 14 Bardziej agile i bardziej fixed-price
Czego można się nauczyć pracując nad utrzymaniem aplikacji
– Może po prostu na początku mówmy im szczerze jak to wygląda, żeby nie mieli złudzeń i się nie rozczarowywali.
Model rozwoju kompetencji analityka biznesowego IIBA
Właśnie wyszło świeżutkie opracowanie modelu rozwoju kompetencji analityka biznesowego wg IIBA! 😀 Co to dla Ciebie oznacza? Jeśli: rozpoczynasz pracę
Jak doradzać, żeby doradzić
Wyobraź sobie taką sytuację… Od ponad godziny próbujesz przekonać klienta do swojego punktu widzenia. Ty wiesz, że masz rację, a
Kurs Podstaw IT
Kurs Podstaw IT dla analityków właśnie wystartował! 🙂 ? ? ? ? ? Znając wyzwania analityków, którzy nigdy nie mieli styczności
Nowe trendy w zarządzaniu procesami – IV spotkanie s3GA
Serdecznie zapraszamy na IV Spotkanie Trójmiejskiej Grupy Analitycznej! Prelegentem będzie Zbigniew Misiak – wybitny specjalista z zakresu Business Process Managment,
Analityk płakał # 13 odpowiedzialnego brak
Kalkulator zarobków Analityków Biznesowych – Ile powinieneś zarabiać?
Chciałbyś wiedzieć ile powinieneś zarabiać? Czy przypadkiem nie zarabiasz zbyt mało w porównaniu z innymi analitykami? Jaką kwotę podać na rozmowie
Problemy analityków – Praca magisterska Wojtka
Zapraszam Was do wzięcia udziału w badaniu problemów analityków, które przeprowadza Wojtek Ślesiński w ramach swojej pracy magisterskiej. Wygląda na
Wnioski z Badania Zarobków i Kompetencji Analityków Biznesowych 2016
Po długich bojach niezmiernie cieszę się publikując wyniki z 203-stronicowego raportu z Badania Zarobków i Kompetencji Analityków Biznesowych 2016. W badaniu
Trójmiejska Grupa Analityczna (s3GA) i spotkanie Yet another (User) Story Part 2
Słyszałeś już o Trójmiejskiej Grupie Analitycznej (s3GA)? To ludzie z Trójmiasta zafascynowani analizą, którzy organizują przestrzeń do wymiany doświadczeń. Przyjdź 11 kwietnia na 3-cie
Zanim znajomy zrobi Ci stronę WWW lub system IT
Kilkudziesięcioosobowa organizacja z dużą rotacją. Stawiają nową stronę. Znajomy znający się na IT spada z nieba i oferuje pomoc. Tworzy
Czego Analityk może nauczyć się od Product Managera i vice versa?
Rzadko spotykamy się w jednym projekcie. Chociaż nasza praca ma w dużej mierze zbliżony charakter, PM-owie zabierają się za swoje
Młodszy Analityk Biznesowy i Stażysta – staż, wiek, zarobki
W ramach oczekiwania na pełny Raport Zarobków i Kompetencji Analityków Biznesowych 2016, nieco o Młodszych Analitykach i Stażystach w analizie.
Naucz się rozmawiać z programistami – Kurs IT dla analityków – 2 lekcje do pobrania
“Zmerdżuj mastera do swojego brancza i zrób zielony bild.” Masz problem ze zrozumieniem programistów? IT to dla Ciebie czarna magia
NA002: Prezentacja o projekcie
Zapraszam do słuchania drugiego odcinku podcastu Najpierw analiza o tym jak przygotować prezentację o projekcie. Masz pytania, komentarze? Daj znać!
Utrzymanie aplikacji, maintenance, indycenty, defekty, CRy
Słowo wyjaśnienia pojęć dla zielonych i nowych w branży. Kiedy ludzie wpadają na genialny pomysł wykonania nowej aplikacji, zazwyczaj mają
Analiza biznesowa. Praktyczne modelowanie organizacji – książka Jarosława Żelińskiego
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
Badanie Zarobków i Kompetencji 2016
Pozdrowienia z kawiarni, gdzie powstała II edycja – Badanie Zarobków i Kompetencji Analityków Biznesowych 2016! 🙂 Posłuchaj co nowego czeka na Ciebie
BA bingo
Musisz być na spotkaniu, na którym wiesz, że nic się nie wydarzy? Chcesz porywalizować z kolegami? Wyczuwasz piątek? Zagraj w
Analityk w procesie sprzedaży i współpraca ze sprzedawcami
Jaka jest rola analityka w procesie sprzedaży? Możesz poznawać klienta, jego problem i proponować najlepsze rozwiązanie, które przygotuje Twoja firma.
Analityk płakał # 12 Grafika angażująca zmysły
Kusi, żeby zrobić konkurs na kryteria akceptacji dla grafiki “angażującej zmysły” 😛 😀 Dzięki za podesłanie Michał Bartyzel http://gettingthingsprogrammed.pl
Kanban w pracy analityka
Zarządzanie wymaganiami jest jednym z najważniejszych etapów procesu wytwórczego oprogramowania. Zaczyna cieszyć, że wielu organizacjach rola analityka jest coraz bardziej
Jak to jest między biznesem a IT
Mówimy, że analityk stoi między biznesem a IT. Często przychodzi nam wtedy do głowy obraz ludzi rozmawiających innymi językami, a
Żarty z analityków
Śmiejemy się z innych w serii “Analityk płakał jak analizował“, ale też pośmiejmy się z siebie 😉 Jak śmieją się
Zalety pracy z analitykiem. Czy z Tobą też?
Dzień dobry ? Każdy poranek to nowy start, nowa energia (choć u niektórych dopiero po mocnej kawie albo dopiero po 9:00). Dziś
Analityk to nie dyktafon. Łatwo powiedzieć
Przeglądając jedną z lekcji kursu internetowego Hani Wesołowskiej dla specjalistów (https://analizait.pl/kurs-specjalistow-analizy/) pomyślałam: “Skąd taki analityk, który, załóżmy, pracuje 2-3 lata
5 rzeczy, których programista potrzebuje od analityka
5 rzeczy, które powinny znaleźć się w Twoich materiałach z analizy i komunikacji z zespołem. Zapraszam do polubienia nowego kanału
Czy dręczysz ludzi Twoimi nazwami statusów?
Nazwa ma znaczenie. Dziś pastwię się nad niedbałymi nazwami statusów. Zamówienia, zgłoszenia, dokumenty w obiegu. Nowe, do zatwierdzenia, zatwierdzone, anulowane,
Jak być zwinnym analitykiem – recenzja ze spotkania Agile3M
17 października, godz. 18:00, klub Atelier, Sopot – dobry czas i miejsce by w fajnym gronie pogadać o analizie w
Badanie potrzeb tematów treści, kursów i szkoleń
Badam jaki temat jest dla analityków najbardziej palący i ciekawy. Podziel się proszę tym, z czym się teraz zmagasz, co
Prawo
Jeżeli prace na ustawami toczą się jeszcze w ministerstwach lub rządzie, projekty można znaleźć na stronie rządowego centrum legislacji (https://legislacja.rcl.gov.pl/) lub
7 poziomów dojrzałości analizy
Klient mówi: „Proszę wykopać dziurę”. Pytasz „Jak głęboką?” czy raczej „A po w ogóle taka dziura?”. Poznaj 7 poziomów dojrzałości
Księgowość
Wprowadzenie do księgowości dla analityków biznesowych. Strona będzie rozwijać się z biegiem czasu. Jeśli chcesz dodać informacje na ten temat, napisz do
Marketing
Wprowadzenie do marketingu dla analityków biznesowych. Strona będzie rozwijać się z biegiem czasu. Jeśli chcesz dodać informacje na ten temat, napisz
Sprzedaż
Wprowadzenie do sprzedaży dla analityków biznesowych. Strona będzie rozwijać się z biegiem czasu. Jeśli chcesz dodać informacje na ten temat, napisz do
Controlling
Wprowadzenie do controllingu dla analityków biznesowych. Strona będzie rozwijać się z biegiem czasu. Jeśli chcesz dodać informacje na ten temat, napisz do
Telekomunikacja
Wprowadzenie do telekomunikacji dla analityków biznesowych. Strona będzie rozwijać się z biegiem czasu. Jeśli chcesz dodać informacje na ten temat, napisz do
Bankowość
Wprowadzenie do bankowości dla analityków biznesowych. Strona będzie rozwijać się z biegiem czasu. Jeśli chcesz dodać informacje na ten temat, napisz do
Ubezpieczenia
Wprowadzenie do ubezpieczeń dla analityków biznesowych. Strona będzie rozwijać się z biegiem czasu. Jeśli chcesz dodać informacje na ten temat, napisz do
Transport, spedycja
Wprowadzenie do transportu dla analityków biznesowych. Strona będzie rozwijać się z biegiem czasu. Jeśli chcesz dodać informacje na ten temat, napisz do
Energetyka
Wprowadzenie do energetyki dla analityków biznesowych. Strona będzie rozwijać się z biegiem czasu. Jeśli chcesz dodać informacje na ten temat, napisz do
Analityk płakał # 10 przecież działa
Wszystkiego najlepszego z okazji Dnia Urody 😉 Oby Twoje interfejsy zachwycały, przyciągały i okręcały sobie użytkowników wokół palca 🙂
Analityk płakał # 9 fatalny system
Wszystkiego najlepszego z okazji Dnia Urody 😉 Oby Twoje interfejsy zachwycały, przyciągały i okręcały sobie użytkowników wokół palca 🙂
Co myślą o analitykach testerzy, programiści i kierownicy
Zapytaliśmy programistów, testerów, kierowników projektów i osoby w innych rolach o współpracę z analitykami. Odpowiedziało 110 osób. Zobacz jak ocenili
Jaka firma i projekt do Ciebie pasują?
Zastanawiałeś się jak pracuje się w firmach i projektach innych niż Twoje? Jakie zalety i wady ma praca w małych
Kurs Specjalistów Analizy
Pierwszego września ruszył Kurs Specjalistów Analizy (poziom 2). Kontynuuje on Kurs Adeptów Analizy (poziom 1 – dla juniorów i aspirujących
Analityk płakał jak analizował # 8 Skrty
Brnę przez pełne skrótów dokumenty, prezentacje, interfejsy i zastanawiam się. Czy to miejsca było szkoda? W Wordzie przejść do nowej
Analityk płakał jak analizował # 7 Robiliśmy scrumowo
Seria memów z sytuacjami, które doprowadzają analityków do załamania 😉 Więcej znajdziesz na fanpage’u na Facebooku. Zapraszam do nadsyłania swoich załamujących
Czy stosujesz odpowiednie diagramy?
Masz czasem wrażenie, że tworzysz diagram, który nie wnosi wiele nowego? Może produkujesz wiele diagramów, ale wciąż brakuje ujęcia sedna
Ankieta: Analiza i analitycy oczami innych
Developerze, testerze, kierowniku (i inni pracujący z analitykami), jak powinna wyglądać analiza, która pomaga Ci w pracy? Pomóż nam dawać
Twoje 5 min dla dobra Nauki
Spotkałam Szymona na spotkaniach o BABOK Guide. Uśmiechnięty i zaciekawiony. Prywatnie – bardzo pozytywny i zakręcony młody człowiek 🙂 Szymon
Rożne typy analityków
Są dwa rodzaje analityków. A w zasadzie nieco więcej. W każdym razie jest kilka kwestii, wobec których my i nasi
Spotkanie, które nie zmarnuje czasu
Przed Tobą spotkanie! Czy wiesz, jak się je przygotować, żeby nie było stratą czasu? Idziesz na żywioł i liczysz, że “jakoś to
Kurs Specjalistów Analizy
Niedługo ruszy Kurs Specjalistów Analizy! Znajdziesz w nim 30 lekcji dla analityków na poziomie specjalisty, przygotowujących się do awansu lub chcących
PAM Summit 2016 – Open Space Conference
Trzecia edycja PAM Summit zbliża się wielkimi krokami! Jest to już kolejne spotkanie dla wszystkich zainteresowanych projektami (a zwłaszcza analityków
Jak docierać 10 x dalej, 10 x skuteczniej i sprzedawać 10 x więcej? Oda do Content Marketingu
Słyszałeś kiedyś cel projektu pod tytułem “Chcemy zwiększyć sprzedaż” lub “Chcemy powiększyć bazę potencjalnych klientów“? Mi trafił się kiedyś “Chcemy
13 powodów, żeby nie marnować życia w analizie biznesowej
Do tego wpisu zainspirował mnie jeden z ostatnich artykułów Harvard Business Review. Mówił o tym, że żyjesz mrzonkami, bo nie
Humor analityczny
Rozmowy o analizie potrafią zejść na nieoczekiwane tory 😀 Pozdrowienia dla autorów 😉 – Naszym rozwiązaniem na ten problem
Książki dla analityków biznesowych
Odsłonią przed Tobą tajniki zawodu. Sięgniesz po nie kiedy chcesz. I wrócisz do nich w razie wątpliwości. Zobacz które książki warto
Jak zostać analitykiem biznesowym
Olśniło Cię, że ten fascynujący zawód może być dla Ciebie? Tylko jak się do tego zabrać? Od czego zacząć? Jak
Jak pracować z Trudną Osobą?
Masz wrażenie, że wsadziłby Ci nóż w plecy. Normalnie odciąłbyś się od takiej osoby. Teraz jednak nie możesz. Pracujecie nad
Raport Zarobków Analityków Biznesowych 2015
Ile powinieneś zarabiać? Przeczytaj Raport Zarobków Analityków Biznesowych 2015 Nie wiesz jaką kwotę podać na rozmowie kwalifikacyjnej? Zastanawiasz się czy
Jak stawać się doskonałym analitykiem bez stresu i wysiłku – część 2
Awans, wyższe zarobki, zagraniczne projekty, ogromne przedsięwzięcia. Możesz osiągnąć Twoje ambitne cele bez wysiłku i stresu! Wystarczy, że przyjmiesz jedną
Jak stawać się doskonałym analitykiem bez stresu i wysiłku
Awans, wyższe zarobki, zagraniczne projekty, ogromne przedsięwzięcia. Możesz osiągnąć Twoje ambitne cele bez wysiłku i stresu! Wystarczy, że przyjmiesz jedną
Raport z badania zarobków i kompetencji Analityków Biznesowych 2015
Wiemy już to, co czym się nie mówi! Wysokość wynagrodzenia pozostaje tematem tabu. A jednak od wiedzy ile zarabiają inni
Początki w modelowaniu procesów
Obserwujesz sytuację biznesową i chcesz zrozumieć jak działają jednostki organizacyjne firmy? A może sam jesteś częścią procesu i zastanawiasz się
Czego szukają firmy u analityków? – wywiad z pracodawcami
Przygotowuję właśnie pytania do wywiadu o cechach, umiejętnościach poszukiwanych u analityków przez pracodawców. W wywiadzie weźmie udział kilka do kilkunastu
Jakość analizy
Wróciłam właśnie z gdyńskiego spotkania z Andrzejem Bliklem. Urzeczona, jak zwykle, kiedy mam okazję zobaczyć na własne oczy kogoś, kogo
Kurs Adeptów Analizy – 30 lekcji dla początkujących
Potrzebujesz uporządkowania wiedzy i jasnego przeprowadzenia krok po kroku przez analityczne podstawy? Mam coś dla Ciebie: Zapraszam do zapoznania się
Potrzeby
Jedną z podstawowych umiejętności analityka jest odkrywanie potrzeb. Musimy umieć sprawnie zastępować to, co usłyszymy – czego człowiek chce, tym,
Badanie zarobków i kompetencji Analityków Biznesowych 2015!
Zakończyliśmy właśnie Badanie Zarobków i Kompetencji Analityków Biznesowych 2015. Jest ono ściśle dopasowane do zawodu analityka, dlatego tak dokładnych wniosków nie
Stażyści w analizie – warto czy nie warto?
Czy warto zatrudniać stażystów do prac analitycznych? Wdrożenie młodej osoby w tajniki naszej firmy i samej analizy może być bardzo
Seminarium IIBA w Krakowie – Business Analyst & Project Manager
Szanowni Państwo, Z przyjemnością informujemy, że 21.10.2015 IIBA WPC w Krakowie wspólnie z firmą UBS organizuje kolejne seminarium z analizy biznesowej. Tym razem tematem
Domain-Driven Design – Eric Evans
W końcu przyszedł czas na dogłębne wgryzienie się w temat Domain-Driven Design. Pod głównym założeniem mogę podpisać się obiema rękami:
Krytyczne myślenie
Krytyczne myślenie – jedna z podstawowych kompetencji liderów. Dla analityków również niezbędna. Potocznie bywa mylnie rozumiana, dlatego też pragnę ją
Analiza biznesowa – magazyn IIBA
Polski oddział IIBA (International Institute of Business Analysis) opublikował właśnie pierwsze wydanie magazynu Analiza Biznesowa! A w nim artykuły związane z
Po czym poznać dobrego analityka?
Kolega kierownik projektu powiedział, że dzieli analityków na dwa typy: tych, którzy jak dostaną temat, to go dowożą i tych,
Gotowość organizacji na przyjęcie rozwiązania
Wyobraź sobie doskonałe rozwiązanie, które opracowałeś w pocie czoła i prezentujesz je z przepełniającą Cię dumą. Co, jeśli jest tak
Jak typy analityczne zadręczają normalnych ludzi szczegółami
Oczywistym jest, że ludzie są różni-przeróżni 🙂 A jednak czasem zdarza się zapomnieć, że różnice między nami mogą stanowić pewne
Drogi do analizy – zbiór sylwetek analityków
Drogi Analityku! Oto przekazuję Ci ideę podzielenia się czymś cennym, co posiadasz – doświadczeniem z Twojej zawodowej drogi. Jest to
W poszukiwaniu dobrego analityka. Jak go rozpoznać?
Jesteś liderem/kierownikiem zespołu analityków? A może masz firmę i planujesz zatrudnić analityka? Zastanawiasz się jakich kompetencji szukać i jak je
Podstawowe kompetencje analityka
Zastanawiasz się jakie kompetencje zdobyć lub rozwijać, aby być lepszym analitykiem? IIBA na podstawie wieloletniej wymiany doświadczeń analityków z całego
5 perspektyw analizy i potrzebne kompetencje
5 perspektyw pracy analityka wyróżnionych przez BABOK Guide, w których skupiamy się w sposób szczególny na wybranych aspektach analizy to:
Co robić z pojawiającą się zmianą wymagań
Mówi się, że nic w nie jest tak pewne jak ZM_ _N_. Kupuję samogłoski: zmiana. Co powiemy na zmianę w
Co robić, kiedy nie wiesz, co zrobić?
Co robić, jak żyć? Znalazłeś się w sytuacji, w której nie wiesz co dalej? Jak do tego podejść, jak to
Fuckup Nights – o moich analitycznych fuckupach
W ramach Fuckup Nights Trójmiasto opowiadałam o swoich analitycznych fuckupach. Zapraszam do uczenia się na błędach – najlepszych, bo cudzych
Weryfikacja wymagań
W projekcie każdy ma swoje ważne zadanie, w którym musi dać z siebie wszystko. Na końcu czeka osoba, która potrzebuje
Techniki analizy biznesowej BABOK Guide 3.0
Jakie są tajne triki analityków? Poznaj techniki analizy biznesowej, jakie podsuwa nam BABOK Guide 3.0 – przewodnik po dobrych praktykach
Słownik pojęć
Zdarzało Ci się robić słownik pojęć biznesowych? Nie brzmi sexi? Zależy jak na to spojrzeć 🙂 Jeśli musisz to zrobić dla świętego
Czy to rozwiązuje problem?
Tempo, w jakim pracujemy, nie sprzyja długim, dogłębnym rozważaniom na temat sensu. A sens właśnie jest zasadniczym elementem pracy analityka
BPMN Poster
BPMN – najbardziej popularna notacja do modelowania procesów. Znana w IT i po stronie biznesu. Jak się jej nauczyć? Można
Kategorie wymagań
Wymagań mamy kilka rodzajów. Różnią się one poziomem szczegółowości, źródłem pochodzenia i etapem zaawansowania projektu/analizy, na jakim jesteśmy w stanie
2 pomysły na zapobieganie niskiej jakości
Czasem bywa tak, że okazuje się, że wynik analizy odbiega od ideału. Pośpiech, natłok spraw, rozproszenie różnymi tematami, zmęczenie, bagatelizowanie
Praca, spełnianie wymagań i analiza w firmie z produktem
Moje dotychczasowe doświadczenia brały się z firm skoncentrowanych na realizacji projektów na zamówienie. Pracę w firmach utrzymujących i rozwijających produkty
BA Core Concept Model
BABOK Guide 3 wprowadził podstawowe pojęcia związane z analizą biznesową i ubrał je w Business Analysis Core Concept Model. Stanowią
Co ma analityk do kierownika projektu?
Zarządzanie projektami – niby temat gdzieś obok analizy biznesowej. Ale czy na pewno? Analitycy ściśle współpracują z kierownikami projektów. Wiele aspektów
Czy na pewno wiesz czym jest jakość?
Czy wiesz czym jest jakość i jak powinniśmy ją określać? Wg książki “Doktryna jakości”, najczęstszym błędem popełnianym przez firmę jest
Słownik pojęć i model dziedziny
Podczas analizy powinno się tworzyć słownik pojęć i model dziedziny. Tak. O tym, jak bardzo wartościowe jest wykonywanie pewnych czynności z kategorii dobrych analitycznych
Uzasadnienie biznesowe
Czy rozpoczynając nowe przedsięwzięcie wiesz z pewnością, że jest ono warte zachodu? Często rozpoczyna się projekty nie posiadając rzetelnego potwierdzenia,
Walidacja, czyli jak sprawdzić czy masz właściwe wymagania
Napracowałeś się przygotowując wymagania rozwiązania. Specyfikacja, rejestr produktu czy projekt w innym narzędziu dopięte na ostatni guzik. Wymagania są spójne
Blogi, strony, organizacje i wydarzenia dla analityków
Jesteś już analitykiem. Co dalej? Czujesz potrzebę rozwoju, wymiany doświadczeń? Choć analityk do popularnych zawodów wciąż nie należy (ok 15
PMBOK vs. PRINCE2 (i Scrum)
Czym różnią się jedne z najbardziej znanych standardów związanych z zarządzaniem projektami? Zobacz 11 różnic dotyczących głównych założeń, podejścia do
Kontrola czy swoboda użytkownika, czyli filozofia projektowania systemów, cz.2 – przykłady
Użytkownik powinien mieć pełną kontrolę nad oprogramowaniem W poprzednim artykule opisywałem sposób myślenia polegający na uznaniu wyższości użytkownika nad oprogramowaniem.
Kontrola czy swoboda użytkownika, czyli filozofia projektowania systemów
Analizując wymagania i modelując funkcjonalność przyszłych systemów informatycznych stoimy często przed trudnymi decyzjami – czy szukać idealnego rozwiązania, czy też
Jak wykorzystać analizę biznesową do zapewnienia jakości projektów IT [cz. 2]: Analiza w firmach
artykuł jest kontynuacją – część pierwsza: https://analizait.pl/2014/jak-wykorzystac-analize-biznesowa-do-zapewnienia-jakosci-projektow-it-cz-2-analiza-w-firmach/ Zmieniające się znaczenie rozwiązań IT w przedsiębiorstwach Ostatnie kilkadziesiąt lat pokazuje, że rola
Jak wykorzystać analizę biznesową do zapewnienia jakości projektów IT [cz. 1]: Wprowadzenie
W przedsięwzięciach informatycznych przywiązuje się różną wagę do pracy analitycznej. Wiele czynników i przyjętych kryteriów ma na to wpływ. W
REQB. Requirements Engineering Qualifications Board – w trzech aktach
Uwaga! Ten certyfikat nie jest już dostarczany jako REQB. Zobacz IREB: https://www.ireb.org/ Prolog W pewnym momencie kariery zawodowej – czy to
Analiza IT – dzień z życia praktyka
Przed Tobą prezentacja o pracy analityka biznesowego w Asseco Poland i warsztaty z UML prowadzone przez nas. Koło Zarządzanie IT
Metoda FURPS, czyli 29 rzeczy do przemyślenia w każdym projekcie IT
“To aplikacja nie będzie działała na smartfonach?”, “Przecież to oczywiste, że powinna być możliwość rozbudowania systemu o pluginy!” – jak
Traceability, czyli potęga narzędzi CASE
Traceability, czyli zdolność do śledzenia, to jedna z najważniejszych funkcji narzędzi do modelowania systemów informatycznych. Stanowi ona jedną z przewag
Podsumowanie roku 2013
Za nami drugi rok działania Analizy IT! Polubiliście nas 3 razy bardziej, zaglądaliście do nas 4 razy częściej, zapisaliście się
Drogi do analizy – zbiór sylwetek i historii analityków
Ruszamy z nowym pomysłem! Chcemy stworzyć zbiór historii o drogach różnych osób do analizy. Będziesz mógł w nim znaleźć osoby
Początkujący czy ekspert analizy – na jakim jesteś poziomie? – wywiad z jednymi z najlepszych analityków w Polsce
Jak ocenić na jakim poziomie zaawansowania wykonujesz swoją pracę? Zadaliśmy pytania trzem znakomitym ekspertom, postaciom, które wniosły wielki wkład w
OCUP Fundamental – certyfikat podstaw UML
Usłyszałam kiedyś, że nie warto sprawdzać znajomości UML, bo i tak każdy rysuje diagramy po swojemu. Czy to znaczy, że
UX Pomerania – warsztaty z użytecznego projektowania interfejsów dla amatorów
Jako zagorzali zwolennicy UX polecamy UX Pomerania! W szczególności, jeśli nie dysponujesz w projekcie tak wartościowym zasobem jak własny UX,
Wstęp do wzorców projektowych
“Po co wymyślać koło na nowo?” – to znane z życia codziennego powiedzenie aktualne jest także podczas realizacji projektów IT.
Jeśli nie Scrum, to co?
Firmy zrażone ciągnącymi się latami projektami, które dostarczają nie to, co było potrzebne, są otwarte na alternatywy. Wykonawcy wychodzą naprzeciw
Mity na temat PRINCE2
Dla niektórych PRINCE2 brzmi profesjonalnie, innych przeraża swoją wielkością. Na temat tej metodyki krąży kilka mitów, które warto obalić, by
Analiza interesariuszy – nie pomiń nikogo!
Jeśli pominiesz ważne osoby, grupy czy organizacje, tracisz źródła wymagań i ryzykujesz, że rozwiązanie nie spełni swojego zadania. Pomoże Ci
Dlaczego projekty w sektorze publicznym się nie udają?
Wczoraj na blogu Tomka Tomaszewskiego (blog.tomaszewski.it) pojawił się wpis z porównaniem sukcesu projektów w sektorach prywatnym i publicznym w Polsce.
Biznes i nauka
Jak dwie połówki doskonałej jedności – biznes i nauka rozpaczliwie potrzebują się nawzajem, choć tak trudno im się odnaleźć i
Znaczenie analizy w projektach IT
Po co firma ma wydawać pieniądze na analityka? Przecież do tej pory jakoś realizowaliśmy projekty i wszystko bez niego jakoś
Model dziedziny – porządkujemy rzeczy ze świata użytkownika
Ostatnio kolega zapytał mnie przystępując do tworzenia systemu “a czym jest ta multiagencja?”. “Kurczę”, pomyślałam, “rzeczywiście przewijała się w rozmowach,
Metodyka zwinna – po czym ją poznać?
Agile uwalnia i pozwala tworzyć. To powód, dla którego posiada masy zwolenników. Jednak zwinne podejście to nie tylko ulga z
CRACK – wybieramy reprezentanta projektu
Zamawiasz oprogramowanie? Zazwyczaj nie wystarczy poprosić i zapomnieć o sprawie. Wyznaczasz osobę albo tworzysz zespół odpowiedzialny za projekt po Twojej
Jak nie puścić firmy z torbami
Analiza trwa zbyt długo? A może jej brakuje – zaskakują Cię nowe założenia, są uszczerbki w jakości? Jedno i drugie
Diagram komponentów
Za pomocą diagramu komponentów można przedstawić konstrukcję systemu z najwyższego poziomu abstrakcji. Po co? Aby rozpocząć projektowanie struktury i główne
Szybko, szybko!
Ile powinna trwać analiza? Tak długo, aż każda kwestia stanie się dla Ciebie jasna jak słońce. Aż zrozumiesz i poczujesz
Techniki pozyskiwania wymagań
W jaki sposób można pozyskiwać informacje od klientów, dla których przygotowujesz rozwiązanie? Poznając techniki pozyskiwania wymagań zobaczysz jak wiele masz
Techniki pozyskiwania wymagań
W jaki sposób można pozyskiwać wymagania? Jest wiele możliwości. Poniżej lista najbardziej znanych metod
Materiały z seminarium "Analityk i sekretarka – znajdź 10 różnic!"
I po spotkaniu. Cieszę się, że przybyło Was tak wielu. Wszelkie zażalenia proszę kierować do mnie na maila lub do
Zaproszenie na seminarium "Analityk i sekretarka – znajdź 10 różnic"
“Analityk robi notatki i stosy niepotrzebnych papierów.”, “Przerost formy nad treścią.”, “To jak zostać sekretarką.”, “Atrybuty – Word i drukarka.”,
Diagram stanów
Ze stanami, statusami mamy do czynienia w zamówieniach, wizytach, ubezpieczeniach, obiegu dokumentów, czyli w praktycznie każdym systemie. Bywa, że tworzymy
Modelowanie zakresu
Ile znasz rzeczy w projektach gorszych od zmiany zakresu? Według badań PMI to najczęstsza przyczyna niepowodzeń! Problemy te występują w
Analiza dokumentów – jak znaleźć igłę w stogu siana?
Praktycznie każdy projekt stawia nas przed zadaniem przestudiowania dokumentów. Mogą to być zapytania ofertowe, dotychczasowe rozwiązania, notatki ze spotkań, biznesowe
Lessons Learned – jak działać lepiej?
Dobrze jest uczyć się na błędach. Można na cudzych, ale bardziej chyba zapadają nam w pamięć własne. Powtarzając jakiś proces,
Analiza SWOT
Prosta, a zarazem bardzo pomocna – pozwala dostrzec to, co najważniejsze. Analiza SWOT. Z pewnością zdarzyło Ci się nie raz