Jeżeli chcesz otrzymywać informacje na temat naszych szkoleń, podaj swoje dane.

Powoli, lecz systematycznie, część 3

Glenn R. Brule

W poprzednim artykule w ramach tego trzyczęściowego cyklu cytowałem jedno z moich ulubionych chińskich przysłów: Daj człowiekowi rybę, a zapewnisz mu pokarm na cały dzień. Naucz go łowić ryby, a zapewnisz mu pokarm na całe życie. Ten artykuł chciałbym rozpocząć od podobnego cytatu – podobnego, a przy tym nieco innego: Daj komuś młotek, a cały świat stanie się dla niego gwoździem.
Moim celem było omówienie w tym cyklu artykułów ludzi, procesów i narzędzi związanych z analizą biznesową. Pierwszy artykuł poświęciłem procesom, przypominając potrzebę dobrze sprecyzowanych środków określania i zarządzania wymaganiami. W drugim artykule skupiłem się na osobach, które w rzeczywistości realizują te procesy – na ludziach – starając się położyć nacisk na wiedzę i umiejętności potrzebne do tego by zostać skutecznym analitykiem biznesowym. Wreszcie, w tym artykule nadszedł czas na narzędzia.
Chciałbym jednak zacząć od pewnego ostrzeżenia. Nie zamierzam bowiem omawiać tu najnowszych trendów technologicznych ani rekomendować takich, czy innych pakietów oprogramowania. Każdy analityk biznesowy powinien tego rodzaju decyzje podejmować samodzielnie. Postaram się natomiast z całych sił wskazać w tym artykule pewne kierunki dotyczące podstawowych narzędzi potrzebnych do przejścia od momentu rozpoczęcia przedsięwzięcia do punktu, w którym otrzymuje się w nim końcowe produkty. Po drodze trzeba zająć się rozpoznaniem źródłowych wymagań, wyborem modeli, z których będzie się korzystać oraz uświadomieniem sobie, w jakich okolicznościach powinno się wybierać określony model. Naturalnie, poświęcimy również trochę miejsca i czasu różnym dokumentom potrzebnym w celu weryfikacji zebranych wymagań, a także testom akceptacyjnym i prototypom stosowanym w celu walidacji wymagań.
Od czego zacząć?
Na początku każdego projektu powinniśmy zadać sobie pytanie, jakie zadania powinien uwzględnić analityk biznesowy, kiedy opracowuje wymagania. W tym kontekście istotny staje się również sposób przeprowadzenia każdego z tych zadań, który pozwoli stworzyć jasny i zwięzły dokument.
Odpowiedzi na te pytania daje nam International Institute of Business Analysis (IIBA). Organizacja ta określiła w swym Kompendium wiedzy o analizie biznesowej (Business Analysis Body of Knowledge – BABOK) następujące główne obszary wiedzy:
1. Analizę przedsiębiorstwa
2. Planowanie i zarządzanie wymaganiami
3. Uzyskiwanie wymagań
4. Analizę i dokumentację wymagań
5. Ocenę i walidację rozwiązania
6. Komunikację wymagań
7. Kwestie podstawowe
Dla potrzeb tego artykułu, szczególną uwagę zwrócę na punkty 3–5 z powyższej listy.
Określanie wymagań
Uzyskiwanie, czyli wydobywanie od innych – w ten sposób BABOK opisuje proces, od którego rozpoczynamy określanie wymagań. W tym kontekście istotne staje się uwzględnienie naszych źródeł wymagań oraz sposobu ich uzyskiwania z każdego z tych źródeł. Niewątpliwie najbardziej oczywistym źródłem wymagań są zwykle interesariusze. Trzeba jednak mieć na uwadze również i inne źródła, w tym na przykład umowy o świadczeniu usług, rejestry usterek i błędów, raporty serwisu pomocy technicznej, podręczniki użytkownika i materiały szkoleniowe, dokumenty wymagań biznesowych czy też przedmioty, które pomagały stworzyć poprzednie wydania produktu.
Starając się uwzględnić pozyskanie wymagań z tak różnorodnych źródeł, nie sposób pominąć tak podstawowego narzędzia, jakim jest lista źródeł. Przykład takiej listy przedstawia diagram 1.

Diagram 1

 

Nazwa dokumentu	Właściciel	Data utworzenia	Numer wersji	Cel dokumentu	Opis i uwagi
SLA_25czerwca1990	Dyrektor ds. informatyki	25 czerwca 1990	v.012.2	Dokument ten określa wszystkie ustalenia prawne regulujące wykorzystanie oprogramowania firmy ABC, które ma być zainstalowane i wdrożone w firmie DEF.	<<Wstawić spis treści dokumentu>>
Wprowadzenie do narzędzi CRM firmy ABC	Firma ABC	15 listopada 1985	v.3.5	Ten podręcznik wykorzystuje się w celu szkolenia użytkowników systemu CRM	<<Wstawić spis treści dokumentu>>

 

Dokumenty i zasoby są wprawdzie ważne, ale z chwilą kiedy przejdziemy do tworzenia listy interesariuszy może okazać się, że warto najpierw utworzyć kategorie interesariuszy. Pomoże to w rozpoznaniu grup osób, z którymi trzeba skontaktować się w celu uzyskania wymagań. Lista ta okaże się również nieoceniona przy ustalaniu technik, za pomocą których będziemy uzyskiwać wymagania od interesariuszy.
Uzbrojeni w tę listę zdajemy sobie sprawę, że koniec końców liczą się w istocie tylko dwa typy użytkowników – ci, którzy płacą za wyroby i usługi dostarczane w projekcie oraz ci, na których te wyroby i usługi wpływają. Na tej podstawie możemy łatwo stworzyć podkategorie, określając je mianem użytkowników bezpośrednich lub użytkowników pośrednich. Lista użytkowników bezpośrednich obejmować będzie wszystkich, którzy mogą pobierać, otrzymywać lub wprowadzać informacje do systemu. Lista użytkowników pośrednich natomiast, składać się będzie z osób, na których rezultaty działania systemu będą wpływać za pomocą raportów lub faktur.
Po utworzeniu takiej listy, w szybkim ustaleniu kryteriów sukcesu oraz technik uzyskiwania wymagań, które wykorzystamy w kontaktach z interesariuszami pomoże nam stworzenie profilów interesariuszy. Taki profil powinien zawierać przynajmniej: role, obowiązki i kryteria sukcesu. Diagram 2 pokazuje, jak ja stworzyłbym taką listę.

Diagram 2

 

Interesariusz	Rola	Obowiązki	Kryteria sukcesu	Wrażliwość	<<inne>>
Dyrektor ds. informatyki	Sponsor wykonawczy ze strony odbiorcy	Zapewnia środki pieniężne na dostarczenie nowego systemu CRM	Skrócenie cyklu sprzedażowego oraz zwiększenie przychodów	Łatwa integracja z bazą danych działań marketingowych

 

Techniki uzyskiwania wymagań
Po rozpoznaniu interesariuszy powinniśmy zastanowić się nad technikami uzyskiwania wymagań, za pomocą których wydobędziemy od nich potrzebne informacje. Technik, z jakim można tu korzystać jest bardzo wiele, trzeba jednak zawsze mieć na uwadze czas, nakład pracy oraz poziom fachowej wiedzy potrzebny do tego, by móc z nich korzystać.
Poniżej przedstawiam krótką listę wraz z argumentami za i przeciw:
Wywiady – kontakt osobisty
• Za: Wywiady można przeprowadzić niezależnie od lokalizacji geograficznej – albo przez telefon, albo osobiście.
• Przeciw: Technika ta może być bardzo czasochłonna, szczególnie kiedy mamy do czynienia z dużymi grupami interesariuszy. Dlatego trzeba zawsze mieć na uwadze czas potrzebny do przeprowadzenia wywiadów oraz olbrzymie ilości sprzecznych ze sobą informacji, jakie można uzyskać przeprowadzając wywiady z dużą grupą interesariuszy.
Ankiety – wywiad kontrolowany
• Za: Ankiety pozwalają zebrać dużą liczbę wymagań w stosunkowo krótkim czasie.
• Przeciw: Trzeba bardzo starannie dobierać typ ankiety oraz rodzaj zawartych w niej pytań. Ankiety również mogą okazać się bardzo czasochłonne.
Współprojektowanie – zgromadzenie tęgich głów
• Za: Interakcja w grupie sprzyja budowaniu zaufania i konsensusu, a działania te można przeprowadzać z względnie dużą częstotliwością.
• Przeciw: Zebranie wszystkich interesariuszy w tym samym pomieszczeniu, w tym samym czasie, może okazać się sporym wyzwaniem, jeśli w ogóle jest możliwe. Wiele zależy od ich lokalizacji oraz istniejących układów. Krótko mówiąc – współprojektowanie to technika dla odważnych.
Obserwacja – patrz i ucz się
• Za: Obserwowanie innych w trakcie pracy i kierowania swoimi zespołami pomaga wyjaśnić wątpliwości i doprecyzować przebieg procesów, które mogą wydawać się niezrozumiałe po zebraniu wyników ankiety.
• Przeciw: Poziom i jakość informacji zebranych w wyniku obserwacji może ograniczać poziom wiedzy fachowej obserwowanej osoby. Technika ta może również okazać się czasochłonna – wiele zależy od wielkości obserwowanej grupy.
Modelowanie wymagań
Kolejnym, po uzyskaniu wymagań, krokiem jest opracowanie modelu wymagań, pozwalającego pokonać bariery związane z terminologią, przeprowadzić walidację i hierarchizację potrzeb i utworzyć pomocnicze diagramy.
Poniżej zamieszczam zwięzłe zestawienie pomagające w doborze odpowiedniej techniki opracowywania diagramów. Trzeba po prostu zadać sobie pytania: kto, co, kiedy, dlaczego i jak. Przykłady pokazuje diagram 3.

Diagram 3

 

Kto?	Co?	Kiedy?	Dlaczego?	Jak?
Kto będzie podlegał wpływom systemu – bezpośrednio lub pośrednio?	Co (jakie inne systemy) będzie wewnętrznie lub zewnętrznie powiązane z rozwiązaniem?	Kiedy system będzie potrzebował lub wpływał na dane chcąc wykonać zadania zgodnie z zasadami biznesowymi?	Dlaczego trzeba przeprowadzać zmiany danych w ramach systemu?	Jak wykonuje się zadania i w jakiej kolejności powinno się je realizować?
Użycie: Kategorie interesariuszy	Użycie: Diagramy kontekstowe lub modele danych	Użycie: Diagramy stanów	Użycie: Reguły biznesowe	Użycie: Diagramy przypadków użycia

Naturalnie liczba dostępnych technik wykorzystujących diagramy jest olbrzymia i zachęcam do zapoznania się z każdą z nich. Z moich doświadczeń wynika wszakże, że prosta metoda Kto, Co, Dlaczego, Kiedy i Jak okazuje się niezwykle skuteczna.
Walidacja
A kiedy wreszcie zbierzemy wszystkie efekty naszych nieprzespanych nocy i dostaniemy zielone światło pozwalające nam przekazać zebrane wymagania zespołowi projektującemu, możemy zastanowić się nad jedną z poniższych technik walidacji:
Ocena partnerska
Pozwala wykryć niejasności i zadbać o to, by to, co znalazło się w dokumencie spełniało zarówno potrzeby użytkownika, jak i potrzeby biznesowe.
Testy akceptacyjne użytkownika
Pomagają określić kryteria ustalania norm jakościowych potrzebne interesariuszom w celu akceptacji dostarczonego rozwiązania.
Walidacja modelu
Pomaga, jeśli poszukuje się słabości danego modelu analitycznego oraz wszelkich wadliwych wymagań, które mogły umknąć uwadze i pozostać w modelach danych oraz modelach reguł biznesowych.
Prototypy
Można je wykorzystać w ramach walidacji wymagań dla określonego obszaru oraz w celu zadbania o spełnienie potrzeb użytkownika i potrzeb biznesowych przez wymagania dotyczące interfejsów zewnętrznych.
Dokładne zrozumienie tych podstaw stanowi nie tylko dobry wzorzec w analizie biznesowej, ale niewątpliwie pozwoli na pewniejsze badanie i ocenę właściwych narzędzi wykorzystywanych przez analityka i organizację w procesie opracowywania i zarządzania wymaganiami.
Zapomnijmy już zatem o rybach i młotkach. Zapewnijmy po prostu analitykowi biznesowemu te podstawy, a przez całe życie będzie gromadził właściwe wymagania.
Glenn Brule pełni funkcję dyrektora ds. rozwiązań dla klientów w ESI International oraz funkcję przewodniczącego International Business Development w ramach International Institute of Business Analysis (IIBA). Z wykształcenia jest instruktorem, specjalistą do spraw komunikacji i konsultantem biznesowym, dzięki czemu mógł udanie współpracować z wieloma klientami przy zleceniach dotyczących zrozumienia, zdiagnozowania i opracowania rozwiązań złożonych problemów biznesowych. Można się z nim skontaktować za pomocą poczty elektronicznej pod adresem gbrule@esi-intl.com.

 

 

Źródło: ESI Horizons. All rights reserved.

w górę