Przejdź do głównej zawartości

Klient dobrego analityka nie jest jego panem, a raczej pacjentem. Analiza Biznesowa. Praktyczne modelowanie organizacji.

Dziś kolejna (tak, mogę już napisać, że to kolejna) recenzja.

Pomiędzy robieniem paznokci na sylwestra i szykowaniem ekstra kiecki udało mi się znaleźć czas na rzeczy ważne i poważne 😉 czyli czytanie literatury „branżowej”.

Myślę, że ta recenzja będzie o tyle ciekawa, że książkę Analiza Biznesowa, Praktyczne modelowanie organizacji czytałam dwa razy w różnych warunkach. Postaram się opisać ją z dwóch perspektyw.

  •      Przed „zakochaniem się” w analizie biznesowej i poznaniu blogowo/książkowego świata Analityków
  •      Po „zakochaniu się” w analizie i poznaniu tego świata troszkę bliżej



Ad1. Lektura jak każda inna, trochę teorii zebranej w przyjemnej formie krótkich felietonów, które prowadzą do wspólnych wniosków. Analiza jest potrzebna/ ważna i dzięki niej jesteśmy w stanie zaoszczędzić trochę gotówki 😉

Ad2. Zrozum zanim zaproponujesz rozwiązanie – to hasło przewodnie całej lektury i chyba całej działalności Pana Jarosława. Przed przeczytaniem po raz drugi tej książki miałam przyjemność bycia na konferencji BPM trends, gdzie wysłuchałam wykładu na temat analizy biznesowej (dokładny opis głównych założeń wykładu znajdziesz w tutaj), później obejrzałam dwa wykłady, pierwszy dotyczy długu projektowego, możecie go odsłuchać tutaj tutaj , drugi natomiast opowiada o architekturze i o tym jak ważna jest dla powodzenia projektu. Zobacz wykład.
 
Książka wydaje się być zebraniem tych wszystkich myśli blogowo/wykładowych w jedną mniej lub bardziej spójną całość. Z wieloma rzeczami się nie zgadzam, bo nie ma jednej słusznej drogi prowadzenia analizy, ale niewątpliwie czuć, że lektura została napisana przez osobę doświadczoną, która przeszła przez „kilka” projektów zanim zdecydowała się opublikować swoje praktyki.

Odczuwam jednak pewien niedosyt, tytuł wskazywałby, że książka pomoże mi w „praktycznym modelowanie organizacji”, pokaże ścieżki i drogi, którymi należałoby przejść aby przeprowadzić prawidłową analizę a lektura przedstawia jedynie początek tej drogi. 
Czy to dobrze ? ciężko powiedzieć, na pewno „świeży” analityk nie wyciągnie z tej lektury żadnej „twardej” nauki. Nie dowie się też jakie książki powinien przeczytać, albo do jakich artykułów zajrzeć bo nie ma żadnych odnośników literaturowych, co nie niewątpliwie mnie zdziwiło i zaskoczyło.

 Ale chyba najbardziej mnie uderzyła, może nie niechęć, ale stwierdzenie autora, że programiści będą musieli „bujać” się w kilku iteracjach, zanim dojdą do poprawnego rozwiązania i stworzenia systemu, który odpowiada potrzebom klienta, a sprawny analityk dotrze do poprawnych wniosków już przy pierwszym podejściu.

Hm, nie bagatelizowałabym tak programistycznych głów. Fakt, ich ludzki interfejs bywa zawodny, ale pomysły to oni mają genialne i nie ukrywam, że to właśnie od nich uczę się najwięcej. 😊

Niemniej lektura napisana jest bardzo dobrze, przyjemnie się ją czyta,  i jeśli ktoś kiedyś był choć na jednym wykładzie Pana Jarosława to na każdej stronie wyczuje jego charyzmę. 
Niecałe 30 zł to kwota, którą zdecydowanie warto wydać na te pozycję. Śmiało można ją traktować jako umilenie długich, zimowych wieczorów. :)



Komentarze

  1. Z jakich narzędzi analitycznych korzysta się obecnie najczęściej? Czy można wybrać te skuteczniejsze lub bardziej "na czasie"? Czy SAP HANA link byłby dobrym wyborem? Czy rodzaj narzędzia może wpłynąć na efekty pracy?

    OdpowiedzUsuń

Prześlij komentarz

Popularne posty z tego bloga

Jak Pani przeprowadza analizę? Pytania rekrutacyjne na Analityka Biznesowego

Na moim ulubionym  blogu o analizie znajduje się post z 99 pytaniami, które mogą pojawić się na rozmowie kwalifikacyjnej na stanowisko analityka biznesowo/systemowego. Przejdź do pytań   Od dziś będę opracowywać pytania znajdujące się na tej liście, co w konsekwencji pozwoli mi na sporządzenie obszernego materiału, który ułatwi przygotowanie się do skomplikowanego procesu rekrutacyjnego.   Oczywiście zdaje sobie sprawę z tego, że ile firm tyle różnych procesów i pytań kwalifikacyjnych, ale zagadnienia znajdujące się na liście „99 pytań” są na tyle uniwersalne, że można z dużym prawdopodobieństwem założyć, że część z nich zostanie użyta w trakcie rozmów wstępnych. No to lecimy :) pytanie na dziś to     Jak Pani przeprowadza analizę? Pierwsze co mi się nasunęło na myśl: „ To zależy ” 😉 , ale żeby na tym nie kończyć, to może napiszę od czego to tak naprawdę zależy. Ostatnio miałam przyjemność być na warsztatach Przewodnik po analizie dla zdezorientowanych- J

Jakie znasz rodzaje diagramów UML – lista 99

Dziś post krótki ale treściwy! Takie podobno cieszą się największym zainteresowaniem 😊 Jakie Pani zna rodzaje diagramów UML ? No i może ktoś się zdziwi, ale wszystkich diagramów UML jest 13 😉 ale oczywiście korzystanie ze wszystkich na raz często mija się z celem, bo projekt np.: nie zakładał tworzenia diagramu rozlokowania, albo wymagane były tylko diagramy przypadków użycia, klas i sekwencji.  Ale ! ale! ale ! to nie jest do końca tak, że jak czegoś na co dzień nie używamy to jest nieistotne i mało ważne.   Bo jeśli np.: okaże się, że w ramach dokumentacji ma powstać jakiś „rysunek” obrazujący relacje pomiędzy odpowiednimi częściami systemu to nie zaczniemy tworzyć nowego typu diagramu tylko skorzystamy z diagramu Struktur Połączonych (bo na kiego grzyba koło na nowo wymyślać). A dlaczego z niego skorzystamy ? bo wiemy, że istnieje i do tego właśnie powinien zostać użyty. A gdybyśmy o nim nigdy nie słyszeli to prawdopodobnie tworzylibyśmy nowe, nikomu

User Stories i Przypadki Użycia na liście 99

Dziś połączymy odpowiedź do trzech pytań z listy 99 😊 Proszę napisać wymganie w formie user stories.  Proszę zapisać wymaganie w formie przypadku użycia. Czym są sytuacje wyjątkowe w opisie przypadków użycia ? No to może zanim zabierzemy się za konkretną odpowiedź, musimy wiedzieć (chociaż tak pokrótce), czym jest User Stories , a czym Use Case . User Stories (US) – inaczej historyjki użytkownika (po angielsku zawsze lepiej to brzmi), są krótką notatką z konwersacji/wywiadu na temat działania systemu. Dzięki User Stories doprecyzowujemy wymagania z rozmowy z klientem. Tylko pamiętajmy, że nie są one po to, aby szukać winnych w razie ewentualnych niedomówień i nie powinny stanowić dowodów w „kwitach” na naszych klientów 😉. [2] User Stories mają w sposób syntetyczny opisywać warunki, jakie powinny zostać spełnione z perspektywy użytkownika i cel, w jakim ta funkcja ma zostać przygotowana.  (definicję tę znalazłam w kursie Specjalistów Analizy )[3]. Ważne jest to,