Why Organizations Need Business Analysts
We have always been fascinated by the exceptional business analysts who can create order out of total chaos. (za Ambiguity, Uncertainty or Both? > Business Analyst Community & Resources).
Why Organizations Need Business AnalystsModernAnalys.com to jeden z moich ulubionych serwisów w sieci. W tego typu serwisach najbardziej fascynuje mnie, że w zasadzie (w pewnym sensie i ja także w moim blogu) traktuje o rzeczach oczywistych.
Powyżej kolejny cytat z tego serwisu: “Zawsze fascynowała nas nieprzeciętna zdolność analityków biznesowych do porządkowania totalnego chaosu”. Tytuł artykułu brzmi “Po co organizacjom Analityk Biznesowy”.
Autorzy słusznie zwracają uwagę, że pojęcie niepewności i niejasności (dwuznaczność) to odrębne pojęcia. Niepewność ma swoje źródło w statystyce i oznacza, ryzyko. Niejasność to pojęcie związane z komunikacją (precyzja języka) i oznacza “niejednoznaczność treści”.
Ale nie jest tu moim celem tłumaczenie tego tekstu na polski. Postanowiłem dodać coś od siebie. Ryzyka znamy (statystyka nieudanych projektów IT) więc co z tymi dwoma pojęciami? Zaryzykuje tezę:
“Im większa niejednoznaczność dokumentu wymagań tym większe ryzyko, że projekt będzie miał kłopoty”.
Powyższe nie stanowi żadnego odkrycia co nie zmienia faktu, że jakość większości dokumentów wymagań (owe 70%) jest słaba, na co wskazują sami ankietowani.
Rola Kierownika Projektu to między innymi zarządzanie ryzykiem. Statystyki są nieubłagane, więc brak dobrego analityka i dobrej analizy wymagań spycha projekt w kierunku kłopotów. No to mamy kolejne badanie: Znaczenie i zapotrzebowanie na specjalistów wg. Forrestera: 70% badanych decydentów uważa, że Analityk Biznesowy to kluczowa postać w projekcie. Jednak nie dlatego, że jest ważniejszy od np. kierownika projektu, bo nie jest ważniejszy. Dlatego, że od jakości jego produktu (analiza i specyfikacja wymagań) zależy właśnie ryzyko całego projektu.
Co jest wadą większości analiz biznesowych?
To, że są one tak na prawdę uporządkowanym zapisem wywiadów z klientem a nie faktyczną analizą organizacji, jej potrzeb (bo raczej nie koniecznie jej pracowników!) i celów biznesowych.
- Jakie są treści tekstowego lub tabelarycznego zapisu wywiadów? NIEJEDNOZNACZNE!
- Jakie są niesformalizowane, swobodnie tworzone diagramy procesów? NIEJEDNOZNACZNE!
- Jakie są słowne opisy struktury oprogramowania jakie ma powstać? NIEJEDNOZNACZNE!
Co zrobić? Używać już na etapie analizy biznesowej i projektowania sformalizowanych narzędzi takich jak standardowe notacje i metodyki, wtedy opisy będą JEDNOZNACZNE. Czy to trudne? Tak, w końcu te 70% porażek to nie przypadek…
A na poprawę humoru i na dowód, że powyższe jednak warte jest uwagi, przykład niejednoznaczności w tekście czyli jak intencje rozmijają się z …
Na zakończenie przytoczę słowa jakie na podobny temat wygłosił [[Alfred Tarski]]:
Dysputy tego rodzaju [co jest czym, przyp. mój] wcale nie ograniczają się do pojęcia prawdy. Występują we wszystkich dziedzinach, gdzie – zamiast ścisłej naukowej terminologii – używa się języka potocznego, z jego niejasnością i wieloznacznością: są one zawsze pozbawione sensu, i dlatego daremne.
![Read more about the article Dokument jako nośnik danych i metoda zarządzania danymi – agregat doskonały [preprint]](https://it-consulting.pl/wp-content/uploads/2013/07/documentation.jpg)
Warto po przeczytaniu tego artykułu na ModernAnalyst, wrócić na chwilę do komentarzy do poprzedniego artykułu zatytułowanego “How Detailed Should Requirements Be? – Part 1”. Pojawia się tam sformułowanie, że tak naprawdę komunikacja wystarczy i w sumie chaosu nie trzeba porządkować, a jak widać z cytatu powyżej warto poświęcić czas, aby potwierdzić te ustalenia w postaci dokumentu, bo inaczej rośnie ryzyko projektu.
Fakt, standardowe metodyki i notacje powodują, że wymagania są dokumentowane. Dzięki temu wiemy na czym stoimy. Podobnie jak budując dom oczekujemy standardowego projektu architektonicznego, a nie przypadkowo opracowanego tekstu. Niestety wiele osób ze świata IT ciągle uważa, że rola IT polega na programowaniu. A cała reszta to jakieś bzdury. Specyfikacja? Phi! Wymagania? Phi!? Traceablility? Phi! Zmiany? Yyyyy w czym?… 🙂
Czasami ciśnie mi się na usta pytanie do zespołów agile: czy zamieszkał byś w domu zbudowanym tak jak oprogramowanie, które teraz piszesz?
Jeśli obie strony ustalą, że chodzi o szałas, to na pewno Agile jest OK 🙂
E.Yourdon proponuje w swoich książkach budę dla psa w takich projektach…;)
Bardzo podoba mi się ten artykuł. Rzeczywiście nie jest to proste dla firm. Być może nie ma osoby dedykowanej do analizy (robią to ludzie w innych rolach/na innych stanowiskach “przy okazji”), a może te, które są, “nie wierzą” w systemy pojęciowe, notacje. Spotkałam się z opiniami, że “I tak każdy UML rysuje po swojemu” albo lepiej – “Gdyby programiści myśleli, analitycy nie byliby potrzebni”.
Na studiach dziwiła mnie tak duża formalizacja opsiu wymagań, ale teraz, patrząc na kolejne projekty, rzeczywiście przyznaję rację – to ważne. A nawet chciałoby się pójść jeszcze dalej – precyzować jeszcze bardziej.
Gdzieś wspominał Pan o pracy doktorskiej na ten tamat. Jak ma się ona do możliwości narzędzi takich jak Paradigm/Enterprise Architect? Jakie widzi Pan niewykorzystywane do tej pory w praktyce możliwość/korzyści?
🙂 narzędzia są, wystarczy używać, w czym problem? Hm…. to troszkę jak z praniem i dobrą pralką: po pierwsze trzeba czytać instrukcję obsługi, po drugie trzeba się do niej stosować, po trzecie trzeba czytać wszyte fiszki w ubraniach i prać zgodnie z zaleceniami producenta. W przeciwnym wypadku dobre ubranie, zniszczone podczas prania, leci do koszta, przepłacamy kupując nowe…
Są narzędzia, są systemy pojęciowe, są notacje, są języki programowania,… trzeba czytać. Mamy jednak coś co ja nazywam syndromem Lotto: w zasadzie wiadomo, że szansa jest nikła, granie jest bez sensu a mimo to rzesze ludzi próbują… tu podobnie: w zasadzie wiadomo jak prowadzić projekty, dokumentację itp. a mimo to wielu próbuje “na skróty”… Drugi problem dotyka nieco początków nauki w szkole i ocen: trzeba się tego nauczyć i zrozumieć.
W sumie możliwości modelowania są takie:
– wymagania dzielimy na funkcjonalne i jakościowe (ograniczenia, niefunkcjonalne, inne nazwy),
– funkcjonalne można modelować i przetestować bez pisania nawet linijki kodu co bardzo obniża koszty projektu,
– jakościowe wymagają testów i doświadczenia (wydajność, znajomość platformy itp.)
– dostawcy (większość) oprogramowania nie są zainteresowani obniżaniem wartości projektów bo to obniża ich przychody.
I na koniec: rola analityka to:
– analiza i identyfikacja celu biznesowego
– opracowanie projektu realizacji wymagań funkcjonalnych (use case’y to za mało, powinna być modelowana obiektowo cała logika biznesowa jaką trzeba zaimplementować, nikt inny tego nie zrobi, na pewnie nie jest to rola programisty),
– spisanie listy wymagań jakościowych (ograniczeń)
Rola developera to wycena i implementacja powyższego.