.png)
Istnieje wiele źródeł opisujących dobre praktyki i metody analizy biznesowej. Pewien wzorzec procesów analitycznych wprowadza IIBA w BABOK® czy BCS, The Chartered Institute for IT, IREB i standardy (choćby ISO/IEC/IEEE 29148) dostarczają praktyk dotyczących stricte inżynierii wymagań, istnieje wiele całkiem dobrych poradników i wskazówek (patrz choćby publikacje Karl Wiegers Tom Gilb i innych ekspertów, którzy praktykują w tej branży od lat).
A czego nie robić? Jakie błędy popełniamy? Oto moja subiektywna lista TOP TEN.
Niezrozumienie biznesu: analityk biznesowy to z definicji osoba, której zadaniem jest identyfikacja potrzeb biznesowych i proponowanie rozwiązań, które wnoszą wartość dla biznesu. Brak wiedzy biznesowej, lub mylne przekonanie o jej posiadaniu (czytaj - brak pokory i zbytnia wiara we własną nieomylność), bardzo skutecznie zmniejsza jakiekolwiek szanse na dostarczenie wartościowych wyników.
Brak wiedzy metodycznej: często słyszę opinie: “praktyka jest lepsza niż teoria, nie czytaj, nie szkol się - najlepiej nauczysz się w pracy projektowej”. I równie często widzę konsekwencje w stylu:
brak analizy interesariuszy
brak odpowiedniego procesu/metodyki
fatalnie dobrane metody i techniki
braki warsztatowe dotyczące przeróżnych czynności analitycznych
wynikające bezpośrednio z braku wiedzy. Praktyka jest bardzo ważna - ale nie poparta odpowiednimi podstawami i wiedzą, może być praktyką bardzo złą.
Teoretyzowanie: nadmierne teoretyzowanie i fanatyczne wręcz trzymanie się danej metodyki / źródła / podejścia, również może być szkodliwe. Dla przykładu, wspomniany już BABOK® jest wspaniałym źródłem informacji. Ale to wcale nie oznacza, że skoro BABOK® mówi, że należy wykonać te i te czynności, przy użyciu tych i tych technik, to jest to ZAWSZE właściwe i skuteczne.
Syndrom Zosi Samosi: ja wiem lepiej, ja zrobię sama. Pracujemy zwykle w zespole i warto pracować zespołowo. Analityk nie musi (wręcz nie powinien) wykonywać wszystkiego sam. Dlaczego? Bo może mieć zwyczajnie nie wystarczające ku temu kompetencje.
Brak słownika: język to zestaw symboli. Uproszczonych symboli, które w zależności od kontekstu można interpretować inaczej Podstawą komunikacji jest porozumienie się - a nie porozumiemy się skutecznie jeśli:
mówimy o tych samych rzeczach innym językiem
mówimy tym samym językiem a co innego mamy na myśli
Myślisz o kliencie “klient”? To dość naturalne. Ale dla Twojego klienta klientem jest prawdopodobnie ktoś zupełnie inny. Chcesz się porozumieć? Zacznij od słownika projektowego.
Robienie założeń: założenia to bardzo istotny produkt pracy w analizie. Proponujemy interesariuszom rozwiązania, które przyniosą wartość przy pewnych założeniach (i w ramach ograniczeń rzecz jasna). Założenia to sposób obsługi ryzyka i kontroli zakresu. Jednak zakładanie, że:
ja wiem lepiej niż klient, czego klientowi potrzeba
klient powiedział wszystko co istotne, a to czego nie powiedział jest nieistotne
wykonanie analizy zgodnie z podręcznikiem :) wystarczy do zapewnienia super wyników
to prosta droga do katastrofy.
Nieuwzględnianie potrzeb interesariuszy: oprócz “standardowych” wymagań biznesowych czy systemowych, istnieją wymagania innego rodzaju. Wymagania dotyczące komunikacji, procesu, informacji. Przykładem są wymagania informacyjne dotyczące np. zawartości czy formy dokumentacji wymagań. Nie tworzymy dokumentacji dla siebie - nie można więc decydować o jej formie i treści bez porozumienia z odbiorcami.
Ignorowanie feedbacku: programista mówi, że Twoje wymagania są niejasne? Tester dopytuje o scenariusze alternatywne, których nie opisałeś? Traktuj to jako feedback dotyczący Twojej pracy. Skoro Twoje produkty pracy nie zawierają potrzebnej odbiorcom informacji, to najprawdopodobniej nie spełniają swojego celu. Czyli? Masz pole do usprawnienia :)
Brak kontroli jakości swojej pracy: nie wstydźmy się prosić o pomoc, nie bójmy się przekazywać nasze produkty pracy do oceny, przeglądu, opiniowania. Te praktyki dają w zasadzie same korzyści - z jednej strony możliwość wczesnego wykrycia usterek, luk, nieścisłości i ich poprawy (czyli i niższy koszt naprawy), z drugiej informacje których możemy użyć do doskonalenia swojego warsztatu pracy. Brak kontroli jakości niestety dość często wiąże się przerośniętym ego zainteresowanego - niektórzy analitycy popadają w zbytnią pewność siebie i uznają, że ich produktów nie trzeba sprawdzać, ponieważ oni nie popełniają błędów :)
Brak walidacji: tworzysz model / dokument i po prostu przekazujesz go interesariuszom z prośbą o zapoznanie się i akceptację? To pierwszy krok do popełnienia poważnego błędu. Dlaczego? Bo może się okazać, że interesariusze nie rozumieją treści czy formy opisu, a obawiają się zapytać i po prostu uznają, że “jest dobrze”. Ty będziesz żył w błogiej nieświadomości i przekonaniu, że się porozumieliście, po czym na późniejszym etapie okaże się, że interesariusze zaakceptowali coś, czego nie rozumieją i mieli inne oczekiwania / potrzeby względem rozwiązania. Skuteczniejszym rozwiązaniem jest prezentacja produktu pracy, wyjaśnienie interesariuszom treści i formy i zbieranie feedbacku podczas interaktywnej sesji.
I na zakończenie:
Zapatrzenie w technologię: nasza praca nie polega na “wciskaniu” klientowi nowinek, gotowych narzędzi i technologii o super mocach, a na zaproponowaniu rozwiązań, które wnoszą wartość przy uwzględnieniu specyficznego kontekstu klienta. Jeśli usprawnienie operacji klienta może być zrealizwane przy pomocy 3 odpowiednio zaprojektowanych arkuszy Excel, albo przez przestawienie kolejności działań w procesie biznesowym, po co oferować klientowi wdrożenie systemu klasy ERP czy wytworzenie nowego dedykowanego rozwiązania (oczywiście przez naszą firmę)? Jeśli problem można rozwiązać przy pomocy narzędzi i środków, w których posiadaniu jest klient, zaproponujmy to rozwiązanie. Nie pełnimy roli sprzedawcy czy marketera, a poniekąd doradcy biznesowego - priorytetem jest wartość dla biznesu a nie spełnienie naszych własnych potrzeb.
Comentarios