Nie raz pojawiały się tu (mój blog) odniesienia do tak zwanego ideału (idealizacja ) jako wzorca lub szkieletu. W artykule o studium wykonalności pisałem:

Brak wiedzy o stanie idealnym możliwym i brak modelu, czyni analizę wykonalności bardzo ryzykowną, więc praktycznie bezwartościową. (Źródło: Studium wykonalności ? czym naprawdę jest | | Jarosław Żeliński IT-Consulting)

Dzisiaj kilka słów o jednym z “kilerów” projektów analitycznych: utrata panowania nad szczegółowością.

Detale, detale…

Praktycznie zawsze w toku odbioru wyników prac analitycznych słyszę: “ale tu nie ma wielu rzeczy”. I jest to prawda, ale nie ma (zostały po protu pominięte) rzeczy nieistotnych z perspektywy analizy i jej celu. Firmy istnieją i rozwijają się latami, nie raz nawet kilkadziesiąt lat. W tym czasie “obrastają” w różne lokalne “sposoby”, mnóstwo wariantów osiągania konkretnych, tych samych celów, nawet tych malutkich lokalnych. Bywają ich setki. Bardzo popularnym, wśród firm dostarczających oprogramowanie, sposobem “analizowania” jest pisanie tak zwanych user story (historyjki użytkownika). Są to, opisane słowami pracownika analizowanej firmy,  zdarzenia stanowiące podstawę “zrozumienia” jak dana organizacja działa. Metoda ta jest obciążona poważną wadą:

User story to perspektywa użytkownika i to skażona jego ograniczoną wiedzą lub jej brakiem oraz ograniczonym doświadczeniem lub brakiem doświadczenia. Duże, zdobyte w jednym miejscu, doświadczenie pracownika, bez głębszej i szerszej analizy, też nie poprawia sytuacji, częściej ją jeszcze pogarsza (bo nikt nie podejmuje dyskusji z tym ?dużym doświadczeniem?). (Źródło: User story czyli nic nie poprawić a może nawet bardziej skomplikować | | Jarosław Żeliński IT-Consulting

Opisy te bywają nie raz bardzo bogate, zebrane w toku wielogodzinnych, tak zwanych, warsztatów lub ankiet. Spisywane są nie raz ogromne ilości detali, które zamiast cokolwiek wyjaśnić, zaciemniają istotę rzeczy.

Jajko1

Powyższe zdjęcie przedstawia coś co nazwę “stanem obecnym”. To widok jaki zastaje ktoś, kto spojrzy na daną organizację “teraz”.  Opisanie tego co widzimy może zająć elokwentnej osobie nawet wiele stron tekstu. Czy opis ten przybliży nas choć troszkę do odpowiedzi na pytanie “co to jest i jak to działa”?

Celem analizy jest zrozumienie, z czym na prawdę mamy do czynienia. Analityk swoją pracą powinien doprowadzić do powstania dokumentu (modeli…) obrazujących  “istotę rzeczy”, powinien w końcu odkryć, że powyższe to jest to:

Jajko0

Owszem, lata rozwoju badanej firmy, zawsze doprowadzą do powstania ogromnej masy detali towarzyszących celowi biznesowemu, jednak ten cel się nie zmienia (cały proces powstawia tej pisanki: źr. http://kursykrokpokroku.blogspot.com/2016/02/koszyczek-na-jajko-pisanke-kurs-krok-po.html).

Jeżeli więc mamy opracować rekomendacje do zmian, zaprojektować oprogramowanie, to albo zrozumiemy co i po co dana firma robi, czym na prawdę jest, albo zabrniemy w dokumentowanie ogromnej liczby detali, dotychczasowych sposobów osiągania celów, co potrafi “zabić projekt” swoją szczegółowością (i zabetonować, nie koniecznie dobry, stan obecny).

Przeprowadzenie analizy ma jeden cel: zrozumieć. Nie jest jej celem “opisywanie” czegokolwiek. Niestety wiele firm pomija analizy, idzie ścieżką “opiszemy co robimy i wystarczy”.

Czego się spodziewać po projekcie, gdy słyszę: nie ma czasu na analizę, myśmy już podpisali umowę z wykonawcą bo nasza firma  nie ma czasu. Niestety najczęściej taki projekt trwa znacznie dłużej niż planowano, pieniądze oszczędzone na ?zbędnym? projektowaniu ideału z ogromna nawiązką są wydawane na kolejne modyfikacje i poprawki (Źródło: Utopia ? czyli model ideału pomaga w projektach | | Jarosław Żeliński IT-Consulting)

Tak więc, dokumentacja zawierająca 10 diagramów procesów biznesowych prawie zawsze będzie lepsza od tej zawierającej 100 diagramów. Ta, która nie zawiera żadnego, jednak będzie znacznie gorsza…..

Polecam świetną książkę na ten temat, w której autor pisze we wstępie:

Projektowanie ideału jest takim sposobem myślenia o zmianie, który można przedstawić w sposób: w rozwiązywaniu problemów, praktycznie dowolnego rodzaju, można uzyskać najlepsze wyniki dzięki wyobrażeniu sobie idealnego rozwiązania, a następnie cofnięciu się aż do miejsca, w którym znajdujesz się w chwili obecnej. Dzięki temu unikniesz urojonych przez siebie przeszkód, zanim jeszcze w ogóle pojmiesz, jaki ma być ideał. .

A na koniec polecam referat:

Alan Kay, 2015: Power of Simplicity

Źródła

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).

Ten post ma 3 komentarzy

  1. Michał

    Zgodzę się, że drążenie detali na początku analizy jest bezcelowa i zawsze warto wyjść od procesów, zrozumieć cele firmy i reguły, które w niej funkcjonują. Ale męczy mnie pytanie – co dalej? Przecież jakieś oprogramowanie trzeba jednak wytworzyć, a na podstawie samych modeli procesów i reguł, nawet najlepiej udokumentowanych, może być ciężko.
    Czy po zamodelowaniu przedsiębiorstwa praca analityka się kończy? Czy nie powinien brać udziału we właściwej produkcji rozwiązania, w analizie jego funkcjonalności? Czy wtedy właśnie wspomniane wyżej user stories (mając na uwadze nadrzędność analizy procesów) nie stają się przydatne?

    1. Jaroslaw Zelinski

      1. Zaczynanie od procesów biznesowych i bazowanie na nich pozwala zweryfikować poprawność logiki całości i uniknąć odkrywania wymagań w trakcie wdrożenia, pozwala samemu zamawiającemu ocenić sens tego co zamawia. Przypominam, że modele procesów zawierają także: wzory dokumentów i reguły biznesowe.
      2. Oprogramowanie to: interfejs użytkownika, formularze i ich zawartość (pola) oraz logika biznesowa (reguły przetwarzania zawartości tych pól), to tego ewentualne integracje (gdy jakąś logikę realizuje inne oprogramowanie).

      Doskonałym wręcz sposobem jest podejście polegające na zaprojektowaniu przez analityka architektury logicznej oprogramowania. Metoda dobrze opisana w literaturze, bazuje na notacjach BPMN (procesy) a później UML (logika aplikacji). Pozwala przetestować całą logikę i wychwycić ewentualne błędy zanim jeszcze powstanie kod.

      Moim zdaniem (i tak robię) analityk nie może “uciec” z projektu, od momentu rozpoczęcia implementacji staje się “product ownerem” (nadzór autorski i zarządzanie zmianą, kontakt z biznesem i developerem). Z mojego doświadczenia user story z ust przyszłego użytkownika ma taką wartość jak wyobrażenia blondynki (sorry ;)) o nowym samochodzie. Użytkownicy nie są specjalistami z zakresu inżynierii programowania a nawet z obszaru zarządzania…

      Patrząc na gotowe oprogramowanie widać, że składa się ono ze skończonej ilości wprowadzanych informacji, grupowanych w formularze. Produktem pracy oprogramowania są te same (archiwum) dane lub dane nowe lub zmienione będące wynikiem przetwarzania. Przetwarzanie to reguły biznesowe i ewentualne wzory matematyczne.

      Złożoność tkwi w ilości związków między tymi danymi a nie w pracy ludzi. Analiza polega na zrozumieniu tych związków i udokumentowaniu ich a nie na zapisaniu co robią ludzie w firmie (bo robią masę rzeczy na masę różnych sposobów). Ewentualne detale i “bajery” w aplikacji zaprojektuje projektant GUI (UX designer).

Dodaj komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.