Podstawowa przyczyna problemów w komunikacji między Klientem a Dostawcą wynika z rozbieżności między tym, co klient mówi, a tym czego rzeczywiście potrzebuje.

W przypadków rozwiązań technologicznych Klient sugeruje się najczęściej rozwiązaniami, które obejrzał w internecie, bądź próbuje przepisać dotychczasową funkcjonalność istniejącego systemu wraz z jej błędami i regułami.

Dlatego umiejętne korzystanie z technik w procesie identyfikacji wymagań pozwoli na uniknięcie niedopowiedzeń czy domysłów, które najczęściej pojawiają się na ostatnim etapie projektu IT- testów przez Klienta.

Podczas testów Klientowi wydawało się, że coś zostanie zaimplementowane, Dostawca jest nie tyle zdziwiony, co poddenerwowany tym, że w trakcie rozmów dane wymaganie nie zostało przez Klienta wypowiedziane.

Czy podczas etapu identyfikacji wymagań muszę korzystać ze wszystkich dostępnych technik? Odpowiedziałabym jak typowy handlowiec – “to zależy”. Zależy od Klienta, specyfiki projektu, ale również od poziomu naszej wiedzy dziedzinowej. Istnieją jednak “żelazne zasady”, a raczej techniki, których użycie podczas spotkania z biznesem minimalizuje ryzyko pominięcia ważnych dla niego kwestii.

W artykule przedstawiam wybrane techniki, które sprawdzą się w środowisku zwinnym, ale wynikają z tradycyjnego podejścia do tworzenia oprogramowania.

1. Co rozumiemy poprzez etap pozyskiwania i identyfikacji wymagań w projekcie?

Pozyskiwanie wymagań – proces identyfikowania wymagań pochodzących z różnych źródeł za pośrednictwem rozmów, warsztatów, grup fokusowych, obserwacji, analiz dokumentów oraz innych mechanizmów.

Celem identyfikacji wymagań jest:

1. Identyfikacja wszystkich pożądanych funkcji, charakterystyk, ograniczeń oraz oczekiwań
2. Zorientowanie wymagań względem wizji projektu
3. Uszczegółowienie wymagań wysokopoziomowych i jasne opisanie funkcji oraz usług
4. Wyłączenie funkcji i cech, których klient nie potrzebuje

Na początkowym etapie prac nad projektem analityk biznesowy czy inżynier wymagań (analityk biznesowo-systemowy) powinien zaplanować, jakie będzie jego podejście do pozyskiwania wymagań. Dzięki planowaniu unikniemy sytuacji, w których uczestnicy procesu będą odrywani od swoich zajęć w celu wykonania innych czynności.
Plan pozyskiwania wymagań obejmuje techniki, które będziesz stosować oraz wskazania, kiedy w i jakim celu chcesz z nich skorzystać.

Zagadnienia, o których musisz pamiętać:

1. Strategia pozyskiwania i planowane techniki

a) Zdecyduj z jakich technik będziesz korzystać w odniesieniu do każdej grupy interesariuszy
b) Łącz ze sobą techniki pozyskiwania

2. Harmonogram i oszacowanie zasobów

a) Zidentyfikuj osoby po stronie klienta i dostawcy, które będą brały udział w poszczególnych aktywnościach- sprawdź ich dostępność
b) Oszacuj czas jaki będziesz potrzebować na przygotowanie się do pozyskiwania wymagań oraz analizy materiałów

3. Spodziewane efekty

Podziel pozyskiwanie wymagań względem grup interesariuszy i rodzaje dokumentów, jakie mają być wytworzone w ramach współpracy.

4.Ryzyko związane z pozyskiwaniem

a) Zidentyfikuj czynniki uniemożliwiające pozyskiwanie wymagań zgodnie z planem

b) Znajdź rozwiązanie i zaplanuj aktywności minimalizujące ryzyko

5.Klasyfikowanie informacji pozyskanych od użytkownika

a) Nie oczekuj, że użytkownicy przedstawią zwięzłą, kompletną i dobrze zorganizowaną listę swoich potrzeb
b) Analityk musi klasyfikować otrzymane informacje wg. kategorii, dzięki czemu będzie mógł je rozwijać
c) Podczas identyfikacji wymagań może natrafić na zagadnienia, które wymagają dodatkowych wyjaśnień
d) Podczas przeglądania tak zaklasyfikowane wymagania biznesowe klienta pozwolą Ci na sprawdzenie czy są kompletne, czy są kwestie otwarte, czy są wymagania ze sobą sprzeczne

2. Kryteria, którymi należy się kierować przy wybieraniu technik zbierania wymagań

Prezentowane techniki uwzględniają następujące kryteria:

Kryterium 1 – Technika pozwala na zrozumienie podstawowych funkcji, jakie ma posiadać produkt. Jest to wartość bazowa,na której możemy budować kolejne funkcjonalności zaoszczędzając w przyszłości czas na dyskusję o podstawowych potrzebach Klienta.
Kryterium 2 – Zainwestowana praca jest proporcjonalna do uzyskanej dzięki niej wartości biznesowej
Kryterium 3 – Użyta technika pozwala zespołowi wytwarzającemu oprogramowanie skupić się na potrzebach biznesowych i wynikających z nich wymaganiach funkcjonalnych

3. Przegląd technik identyfikacji wymagań podczas spotkań z Klientem

Poniżej zostały zaprezentowane techniki wraz z bezwzględną kolejnością ich stosowania:

Krok 1: Przepływ procesu biznesowego

Analityk biznesowy, ale również inżynier wymagań (analityk biznesowo-systemowy) podczas zbierania wymagań musi upewnić się, aby każdy proces biznesowy dostarczał wartość biznesową. Proces też musi posiadać interesariusza (aktora) wykonującego określone zadanie, dane wejściowe oraz wyjściowe.

Podczas zbierania wymagań nie chodzi o to, tym bardziej w podejściu zwinnym, aby rysować proces biznesowy za pomocą języka BPMN (aczkolwiek nikomu tego nie zabronię).

Warto skupić się w pierwszej kolejności na kilku elementach:

1. <Aktorzy> uczestniczący w procesie biznesowym,
2. <Krok procesu>, jaki wykonywany jest przez <aktora>
3. <Narzędzia>, które używane są w ramach danego kroku
4. Jakie <dane wejściowe> potrzebuje <aktor>, aby wykonać <zadanie> w danym <kroku procesu>?
5. Kto <aktor> przygotowuje te <dane>?
6. Jakie <dane wyjściowe> są wytwarzane przez <aktora> w danym <kroku procesu>?
7. Czy <narzędzie>, z którego korzysta w danym <kroku procesu> generuje <dokumenty>? Jeśli tak, to jakie? Jak są przechowywane? Kto <aktor> ma do nich dostęp? Kto <aktor> nie powinien mieć do nich dostępu? W przypadku danych warto sprawdzić je pod kątem RODO.
8. Co musi się stać, aby <aktor> nie mógł rozpocząć wykonywanie swojego <kroku procesu>?
9. Czy są wyjątki od standardowego postępowania w danym <kroku procesu>? (Przypis: takie pytanie jest dość ogólne. Najczęściej Klient odpowie: “Nie ma wyjątków”. Warto zatem powyższe pytanie przekształcić w pytania pomocnicze, np. Jak wygląda <krok procesowy> jeśli nie masz kompletnych <danych wejściowych>? Jak wygląda <krok procesowy>, jeśli <narzędzie> nie wygenerowało dokumentu? itp.

W pierwszym kroku rozmawiamy z Klientem, który opowiada o procesie biznesowym, jaki obecnie funkcjonuje (AS-IS). Najczęściej jest to proces niewydajny, który należy zoptymalizować. Czasem wydajność procesu biznesowego jest zadowalająca, lecz potrzeba pojawienia się rozwiązania informatycznego wynika z rozwoju organizacji Klienta.

Zanim dojdziesz do optymalizacji, w której bierze udział Twój produkt, który zaprojektujesz, musisz zrobić jeszcze jeden krok- porozmawiać z Klientem o procesie docelowym (TO BE). Pamiętaj! To nie jest proces docelowy. Jest to jedynie “przymiarka” do docelowego procesu biznesowego widziany oczami Klienta. Bardzo często jest jeszcze mniej wydajny niż ten pierwotny (AS-IS), bo przesiąknięty przyzwyczajeniami Klienta. Jednak nie pomijaj tego kroku, bo dzięki niemu dowiesz się do jakiego rozwiązania dąży Klient. A przyzwyczajenia Klienta mogą okazać się ważnym elementem docelowego systemu, bądź “ukrytym” wymaganiem.

Z drugiej strony jako analitycy (analityk biznesowy i inżynier wymagań) mamy tendencję do “przegrzewania” funkcjonalności, czyli dostarczanie funkcjonalności, których klient nie potrzebuje, ale wydały nam się “fajne”. Etap rozmowy z Klientem o docelowym rozwiązaniu pozwala nam “tylko” oprogramować niektóre funkcje bez ich zbędnego rozdmuchiwania 🙂 Oczywiście nie popadajmy w drugą skrajność, czyli zamiast analizy spisujemy to co powiedział Klient i implementujemy 1:1. Dlatego tak ważne jest, aby skupić się  również na regułach biznesowych.

Na czym zatem polega cała optymalizacja procesu biznesowego. Tutaj kryje się cała filozofia rodem z filozofii Agile 🙂 Optymalizacja procesu biznesowego to w skrócie jak najszybsze dostarczenie wartości końcowej (usługi, bądź produktu procesu biznesowego) przy użyciu minimum kroków. Jeśli w procesie biznesowym udział bierze system, jego zadaniem jest przejęcie niektórych <kroków procesu>, które do tej pory wykonywał <aktor>, jeśli są one powtarzalne.

Krok 2: Diagram kontekstowy i mapa ekosystemu

Rozmowę z Klientem bezwzględnie rozpoczynamy od ustalenia przepływu procesu biznesowego. Bowiem w nim znajdują się <narzędzia>, którymi mogą być systemy, jakie powinniśmy wziąć pod uwagę przy projektowaniu naszego rozwiązania.

Diagram kontekstowy oraz mapa ekosystemu pozwala na określenie prawdziwego zakresu projektu. Wszystko przedstawione jest w formie graficznej.

Mapa ekosystemu pokazuje wszystkie systemy mające związek z Twoim projektowanym rozwiązaniem. Mapa ekosystemu pokazuje dodatkowo “otoczenie systemowe”, czyli również te systemy, które nie muszą być bezpośrednio związane z Twoim systemem lecz mogą na niego pośredni wpływ. Twój system również może mieć wpływ na poprawne działanie ww. systemów poprzez konieczność generowania danych niezbędnych do podstawowych funkcjonalności tych systemów.

Diagram kontekstowy pokazuje jak nowe rozwiązanie systemowe “wpasowuje się” w środowisko. Definiuje on granice oraz interfejsy pomiędzy nowym systemem a już istniejącymi systemami, aktorami, ale również używanymi danymi.

Najczęściej podczas pracy w projekcie IT napotykamy sytuację, kiedy potrzebny jest np. raport w systemie zewnętrznym niepowiązanym bezpośrednio z naszym systemem.

Dlatego ważne, jest aby mapa ekosystemu i diagram kontekstowy były częścią analizy, jaką wykonujesz w projekcie. To zewnętrzny niepowiązany system jest źródłem nowych wymagań, o których nie pamięta najczęściej Klient. Wróć! Pamięta, ale dopiero w fazie testów 🙂

Krok 3: Reguły biznesowe

O powiązaniu między wymaganiem biznesowym a regułą biznesową pisałam tutaj: https://analizawymagan.pl/wymaganie-biznesowe-a-regula-biznesowa/

Krok 4: Diagram przepływu danych

Mając wykonane następujące kroki: przepływ procesu biznesowego -> mapa ekosystemu -> diagram kontekstowy —>reguły biznesowe czas na diagram przepływu danych, w którym przyjmuje się podejście do analizy systemów polegające na dekompozycji funkcjonalnej.

Dzięki takiemu podejściu jesteśmy w stanie zidentyfikować brakujące <dane> w <kroku procesu biznesowego>.

Diagram przepływu danych dodatkowo pokazuje kontekst wymagań funkcjonalnych związany ze sposobem, w jaki użytkownik wykonuje określone zadania w <kroku procesu>.

Sprawdź wspólnie z Klientem, czy na diagramie przepływu danych znajdują się wszystkie dane wejściowe i wyjściowe, które są mu znane. Zweryfikujcie czy procesy przetwarzające dane zostały poprawnie opisane oraz czy nie narysowano niepotrzebnych przepływów. Podczas weryfikacji może się zdarzyć, że uda Wam się zidentyfikować nowych <aktorów>, procesy biznesowe czy nawet połączenia z systemami.

4. Dodatek: Dokumentowanie podczas spotkań z biznesem

Technika ta jest jedynie wsparciem i pokazaniem, w jak prosty, szybki i efektywny sposób można wspólnie z Klientem zamodelować reguły biznesowe opierając się na rzeczywistym modelu, słowniku pojęć oraz listą reguł.

Dla przykładu zamodelujmy reguły biznesowe w procesie zamawiania przez Klienta auta w leasingu

W bardzo dużym uproszczeniu proces biznesowy wygląda następująco:

Po rozmowie Handlowca z Klientem na podstawie warunków finansowych,modelu pojazdu, Handlowiec przygotowuje ofertę z kalkulacją. Klient akceptuje ofertę, która staje się wnioskiem. Handlowiec po uzupełnieniu dodatkowych informacji, np. zgody na sprawdzenie w BIK i KRD wysyła wniosek do analizy ryzyka przez Analityka Ryzyka. Po analizie wydawana jest decyzja o finansowaniu.

Wystarczy tylko narysować powiązania między pojęciami, aktorami jakie wynikają z opisu.(Kliknij w obrazek, aby powiększyć).