Zapewnianie skutecznego gromadzenia wymagań w podejściach adaptacyjnych

Nancy Y. Nee, PMP

Wymagania jakościowe przyczyniają się do sukcesu przedsięwzięć zarządzanych zarówno w sposób adaptacyjny, jak i zgodnie z metodami tradycyjnymi. Wprawdzie proces określania wymagań przeprowadzany w tradycyjnym podejściu do zarządzania projektami różni się od procesu tworzenia scenorysów opartych na cechach użytkowych typowego dla metod adaptacyjnych, ale jednocześnie oba te procesy łączy wiele cech wspólnych. Sam proces stosowany w celu określenia i zebrania wymagań może być odmienny, jednak kryteria dotyczące wymagań jakościowych pozostają niezmienne. Na czym polegają wspomniane podobieństwa i różnice w procesach gromadzenia wymagań? Jak zmienia się rola analityka biznesowego w podejściach adaptacyjnych?
Wymagania pozostają wymaganiami, niezależnie od tego, czy stosuje się podejście adaptacyjne, czy tradycyjne. Chcąc zrozumieć różnice między procesami precyzowania i zarządzania wymaganiami w metodach adaptacyjnych oraz tradycyjnych, trzeba najpierw jasno zdefiniować pojęcie wymagania, a następnie zrozumieć podstawowe zasady precyzowania i zarządzania wymaganiami.

Co to jest wymaganie?
Ponieważ pojęcie wymagania stanowi klucz do zrozumienia potrzeb użytkownika trzeba jasno zdefiniować to pojęcie. BABOK® Guide definiuje wymaganie jako (IIBA®, 5): 
1.Uwarunkowanie lub zdolność potrzebna interesariuszowi do rozwiązania problemu lub osiągnięcia celu.

2. Uwarunkowanie lub zdolność, jakie musi spełniać lub posiadać rozwiązanie lub jego komponent, by osiągnąć zgodność z kontraktem, normą, specyfikacją lub innymi formalnie narzuconymi dokumentami.

3. Udokumentowane przedstawienie uwarunkowania lub zdolności, o jakich mowa w poprzednich punktach.

Analitycy biznesowi powinni mieć świadomość, że wymagania można przypisać do jednej z czterech kategorii i dwóch subkategorii (IIBA®, 5–6)

• Wymagania biznesowe: Ogólne stwierdzenia określające potrzeby, zamierzenia i cele przedsiębiorstwa. Powody, dla których zainicjowano przedsięwzięcie.

• Wymagania interesariuszy: Stwierdzenia opisujące, w jaki sposób dany interesariusz będzie wykorzystywać rozwiązanie.

Wymagania interesariuszy stanowią łącznik między wymaganiami biznesowymi oraz innymi klasami wymagań rozwiązania.

• Wymagania rozwiązania: Właściwości lub atrybuty opisujące rozwiązanie spełniające wymagania biznesowe oraz wymagania interesariuszy. Często dzieli się je na subkategorie:
- Wymagania funkcjonalne: zachowanie i informacje, którymi będzie zarządzać rozwiązanie – konkretne działania lub reakcje systemu

- Wymagania niefunkcjonalne: uwarunkowania otoczenia, w ramach których musi funkcjonować system – określane także mianem wymagań jakości obsługi.

Uwarunkowania te nie dotyczą bezpośrednio zachowań lub funkcjonalności rozwiązania.
• Wymagania przejściowe: Tymczasowe zdolności ułatwiające przejście od stanu istniejącego do stanu przyszłego. Określanie i precyzowanie tych wymagań odbywa się na ogół poprzez ocenę i walidację rozwiązania
W jaki sposób – przy tak wielu typach wymagań – zadbać o poprawne ich zebranie niezależnie od stosowanej metodyki zarządzania projektem?

Precyzowanie i zarządzanie wymaganiami
Dziedziny analizy biznesowej i analizy przedsiębiorstwa skupiają się na działaniach związanych z zarządzaniem i precyzowaniem wymagań. Działania te występują we wszystkich typach przedsięwzięć. Sposób przeprowadzania precyzowania wymagań zależy od sposobu podejścia do zarządzania projektem. W wypadku metod adaptacyjnych precyzowanie wymagań składa się z podobnych działań, jednak ich rygorystyczność jest inna niż w metodach tradycyjnych.
Model zapewniania zarządzania i precyzowania wymagań (diagram 1) ilustruje sekwencje kluczowych działań, które trzeba przeprowadzić na każdym etapie cyklu życia projektu (niezależnie od tego, czy stosuje się w nim metodykę adaptacyjną, czy tradycyjną) by ostatecznie osiągnąć zamierzenia i cele biznesowe.

Diagram 1: Model zapewniania zarządzania i precyzowania wymagań

Enterprise Analysis = Analiza przedsiębiorstwa
Solution Development = Opracowywanie rozwiązania
Elicitation = Uzyskiwanie
Analysis = Analiza
Assessment = Ocena
Planning = Planowanie
Management = Zarządzanie
Interaction = Wykorzystanie
Business Goals & Objectives = Zamierzenia i cele biznesowe

Analiza przedsiębiorstwa stanowi wstępną pracę, którą trzeba wykonać, by spełnić zamierzenia i cele biznesowe. Przypomina to proces tworzenia wizji w metodach adaptacyjnych (diagram 2). Proces ten – podobnie jak analiza przedsiębiorstwa – skupia się na treści przedsięwzięcia oraz na tym czemu ma ono służyć i czego się od niego oczekuje.





Diagram 2: Proces tworzenia wizji

Niezależnie od wybranej metodyki zarządzania projektem, wszelkie prace związane z wymaganiami powinno się poprzedzić określeniem zamierzeń i celów biznesowych. Zarówno analiza przedsiębiorstwa, jak i tworzenie wizji rozpoczynają się od sprecyzowania procesów tworzenia produktu, czy też rozwiązania. Innymi słowy, od określenia, jak będzie się wykonywać poszczególne prace.

Czy „user story” i „use case” są tym samym?
Model zapewniania zarządzania i precyzowania wymagań pokazuje, że wymagania powinno się uzyskać, przeanalizować i ocenić. W zależności od stosowanego podejścia do zarządzania projektem procesy uzyskiwania, analizy i oceny mają różną postać. Tabela 1 podsumowuje najważniejsze czynniki różnicujące gromadzenie wymagań w podejściach adaptacyjnych i tradycyjnych. 

 Tabela 1: Gromadzenie wymagań w metodach adaptacyjnych i tradycyjnych

Na tym etapie zaczynamy rozumieć różnice pomiędzy technikami gromadzenia wymagań, a także pomiędzy rolami i obowiązkami oraz stosowanymi narzędziami – w wypadku metod adaptacyjnych są to user stories (zwane po polsku niekiedy „historiami użytkowników”), natomiast w wypadku metod tradycyjnych – przypadki użycia (use cases). Skuteczna realizacja dowolnego przedsięwzięcia musi uwzględniać uprzednie określenie wszystkich typów wymagań. Mając to na uwadze warto zastanowić się, jak każde z tych narzędzi pasuje do systematyki wymagań.
User stories skupiają się na cechach użytkowych, których obecności w końcowej wersji produktu oczekują użytkownicy. Kluczowym elementem tych „historii” jest właśnie skoncentrowanie się na cechach użytkowych cenionych i bezpośrednio wykorzystywanych przez użytkowników. Mając to na uwadze możemy odwołać się do zawartej w BABOK definicji wymagań interesariuszy, określanych także wymaganiami użytkownika. Taki sposób podejścia, który można określić jako tworzenie rozwiązania na bazie cech użytkowych, zakłada że użytkownicy potrafią opisać swoje oczekiwania za pomocą nieformalnego, prostego języka. Cechy użytkowe produktu uszczegóławiają i precyzują w kolejnych iteracjach twórcy rozwiązania prezentując swoim odbiorcom powstające stopniowo rozwiązanie. W procesie tym, w naturalny sposób pojawiają się wówczas także nowe pomysły.

Przypadki użycia opisują oczekiwany rezultat, który ma osiągać system lub użytkownik poprzez korzystanie z systemu. Opis ten bliższy jest zawartej w BABOK definicji wymagań funkcjonalnych, stanowiących część ogólnych wymagań rozwiązania.
Na pierwszy rzut oka może wydawać się, że oba narzędzia są podobne do siebie, natomiast w rzeczywistości znacznie się one od siebie różnią. User stories koncentrują się na cechach użytkowych. Cechy użytkowe definiuje się jako właściwości produktu cenione przez końcowego odbiorcę i składające się z przynajmniej jednej funkcji stanowiącej część rozwiązania. Przypadki użycia skupiają się w większym stopniu właśnie na funkcji niż na cechach użytkowych. Funkcję rozumiemy tu w znaczeniu systemowym, czyli jako czynność, jaką wykonuje system w związku z oczekiwaną cechą użytkową. Mówiąc najprościej, narzędzia te różnią się od siebie, ponieważ user stories są źródłem wymagań interesariuszy, natomiast przypadki użycia – wymagań funkcjonalnych.

Czego potrzeba by skutecznie określać wymagania?

User stories to narzędzie ważne dla użytkowników końcowych ponieważ skupia się ono na cechach użytkowych. Użytkownicy na ogół nie wnikają w tajniki powstawania produktu. Chcą po prostu, by produkt funkcjonował zgodnie z ich oczekiwaniami oraz by był w stanie pracować z oczekiwaną wydajnością. Wprawdzie aspekty techniczne mogą mieć kluczowe znaczenie dla wydajności produktu i zazwyczaj są dokumentowane przez użytkownika i analityka biznesowego w tradycyjnym sposobie podejścia do zarządzania projektem, ale w projektach realizowanych metodami adaptacyjnymi użytkownicy nie mają z nimi bezpośredniego kontaktu i nie są one objęte techniką user stories.
Jednocześnie wszyscy mamy świadomość, że techniczne szczegóły dotyczące interakcji cech użytkowych oczekiwanych przez użytkownika z systemem są potrzebne, dlatego warto się zastanowić, w jaki sposób i gdzie określa się te wymagania. Interesujące jest także to, jak zmienia się rola analityka biznesowego w technice opartej na user stories oraz kto zajmuje się przekształcaniem wymagań interesariuszy opisanych przez użytkowników i określających cechy użytkowe na wymagania funkcjonalne. W podejściach adaptacyjnych proces opracowywania user stories prowadzi na ogół kierownik projektu, a nie analityk biznesowy. Natomiast ustaleniem wymagań funkcjonalnych na podstawie user stories przygotowanych przez użytkowników zajmują się twórcy rozwiązania. Rola analityka biznesowego jest zatem podzielona na kierownika projektu a twórców rozwiązania.

Z oczywistych względów można by stwierdzić, że w takich warunkach analityk biznesowy nie jest potrzebny. Czy jednak kierownik projektu oraz twórcy rozwiązania dysponują umiejętnościami i kompetencjami w dziedzinie uzyskiwania, analizy i oceny wymaganymi do najpełniejszego zrozumienia cech użytkowych opisywanych przez użytkowników? Pamiętany, że umiejętności analityka biznesowego obejmują wszystkie aspekty przeprowadzania procesów związanych z moderowaniem, precyzowaniem i zarządzaniem wymaganiami na każdym poziomie. Osoba pełniąca rolę analityka biznesowego może nie być potrzebna jeśli wysoce doświadczony i umotywowany zespół realizujący projekt w podejściu adaptacyjnym potrafi prawidłowo przeprowadzić wszystkie działania związane z analizą biznesową. Skuteczność procesu precyzowania wymagań warunkują zatem doświadczenie i fachowość zespołu i kierownika projektu. Dlatego zanim rozpocznie się proces precyzowania i zarządzania wymaganiami w podejściu adaptacyjnym konieczne jest przeprowadzenie oceny gotowości kierownika projektu i zespołu do skutecznego przeprowadzenia tego procesu.

Nancy Y. Nee, PMP, ma ponad piętnastoletnie doświadczenie w branży konsultingowej i specjalizuje się w konsultingu zarządczym, zarządzaniu projektami, analizie biznesowej, technologiach informatycznych, ciągłym doskonaleniu procesów oraz zarządzaniu zmianami w organizacjach w sektorach prywatnym, publicznym i niekomercyjnym. Jest dyrektorem wykonawczym ds. programów związanych z zarządzaniem projektami i analizą biznesową w ESI International.


Źródła
International Institute of Business Analysis (IIBA®), A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), v2.0, 2009.