Wymagania – sedno pracy product owner’a. W zasadzie na tym polega cała ta “zabawa”. Wymagania mogą być różnego rodzaju – zdefiniowane na różnych poziomach.
Co to dokładnie znaczy? I po co Ci konkretnie ta wiedza? Kiedy wiesz, że istnieją wymagania na różnym poziomie, to masz szansę świadomie je zbierać.
Zacznijmy od początku – czym jest wymaganie?
Czym w ogóle jest wymaganie? Zgodnie z definicją jest to “użyteczna reprezentacja potrzeby”. To bardzo ważne, aby skupić się tu na potrzebie, jaka ma być zaspokojona. Lub na wartości, jaka ma być osiągnięta, gdyby wymaganie zostało spełnione.
Jak rozpoznać, że wymagania skupiają się na potrzebach?
Jeżeli Twoje wymagania da się narysować, to znaczy, że masz już propozycję rozwiązania, a nie udokumentowaną potrzebę.
Jakie są rodzaje wymagań wg BABOK?
BABOK wyróżnia różnego rodzaju wymagania i są to:
- Wymagania biznesowe (Business requirements) – stanowią one podstawę, dlaczego w ogóle zmiana została zainicjowana z punktu widzenia biznesu. Cele te mogą się odnosić oczywiście do różnych obszarów – do całej organizacji lub jej części.
- Wymagania interesariuszy (Stakeholder requirements) – są to wymagania stakeholderów, które muszą zostać spełnione, aby osiągnąć wymagania biznesowe. Będą stanowiły pomost pomiędzy wymaganiami biznesowymi, a wymaganiami rozwiązania. Muszą one wspierać wymagania biznesowe.
- Wymagania rozwiązania (Solution requirements) – to wymagania opisujące możliwości i cechy rozwiązania tak, aby zostały spełnione wymagania interesariuszy. W odróżnieniu od wymagań interesariuszy, dostarczają więcej szczegółów implementacyjnych dla rozwiązania, co umożliwia jego stworzenie.
Dzielą się one na:- Wymagania funkcjonalne (Functional Requirements) – opisujące możliwości, jakie musi mieć rozwiązanie: Jak będzie się zachowywać? Jakie procesy będzie realizować? Jakimi informacjami będzie zarządzać? Czyli, ogólnie rzecz biorąc: CO będzie to rozwiązanie umożliwiać?
- Wymagania niefunkcjonalne (Non – Functional Requirements) – te wymagania nie opisują, co będzie robił system, ale JAK będzie robił. Pod jakimi warunkami będzie działał efektywnie? Jakie standardy jakości będzie spełniał?
- Wymagania przejściowe (Transition Requirements) – to wymagania, które będą niezbędne, aby umożliwić przejście z jednego rozwiązania na inne. Mają charakter tymczasowy i, w odróżnieniu od pozostałych wymagań, nie będą już obowiązywać po implementacji rozwiązania.
Dobra, ale po co mi znać rodzaje wymagań?
Projekt realizujemy z jakiegoś powodu, prawda? Te powody powinniśmy zdefiniować jako cel biznesowy i ująć w wymagania biznesowe. Definiując wymagania interesariuszy (stakeholderów) musisz się upewnić, że wspierają one wymagania biznesowe.
Załóżmy, że prowadzisz firmę, która świadczy usługi call center dla dużych firm. Chcesz pozyskać w ciągu następnego roku 3 nowych klientów. Przeciętne call center, dla jednego klienta, to 20 osób. Nie masz w tej chwili takich możliwości lokalowych, aby zapewnić miejsce pracy dla 60 nowych osób. Z dostępnych opcji decydujesz się na rozbudowę swojej siedziby.
Wymaganie biznesowe:
zapewnić miejsce pracy dla 60 nowych osób, które będą pracowały w 3 nowych zespołach call center.
Wymagania stakeholderów:
Szef operacji: Zapewnić miejsce pracy dla 60 nowych pracowników zgodne ze standardami firmy dot. miejsca pracy pracowników call center.
Szef call center: Zapewnić 3 osobne pomieszczenia, na 20 osób każde tak, aby zespoły mogły pracować razem
Specjalista ds. BHP: zapewnić miejsca pracy dla 20 osób zgodne z polskim prawem.
Lider zespołu 1: każde stanowisko pracy musi mieć przestrzeń na 3 monitory na poziomie wzroku.
Lider zespołu 2: Każde biurko musi mieć marmurowy blat.
???
Marmurowy blat? No właśnie. Jest to wymaganie interesariusza. Można by to przyjąć do wiadomości i teoretycznie zrealizować. Ale czy to wymaganie wspiera realizację celu biznesowego? Nie. Chyba, że w standardach organizacji jest kupowanie marmurowych biurek dla pracowników call center. Gwarantuję Ci Jednak, że żadna firma nie ma takich standardów 🙂
Ten przykład jest oczywisty, ale rozumiesz o co mi chodzi? Wymagania stakeholderów muszą wspierać wymagania biznesowe. Jeżeli tego nie robią, należy je eliminować. Jeżeli tego nie będziesz robił, zakres projektu będzie rósł i rósł, a prawdopodobieństwo dowiezienia na czas będzie malało. I katastrofa gotowa. Dlatego wymagania to sedno pracy product owner’a.
Pozostałe wymagania mogłyby wyglądać tak:
Wymagania rozwiązania:
Funkcjonalne:
- Biurko musi mieć co najmniej 2 m szerokości i mieć dodatkową półkę, która pomieści 3 monitory 21,5”
Niefunkcjonalne:
- nowe pomieszczenia muszą spełniać standardy bezpieczeństwa opisane organizacji
- biurko musi spełniać standardy ISO XXX
Wymagania przejściowe:
- podłoga musi być zabezpieczona przed zabrudzeniem i uszkodzeniem na czas malowania ścian.
Każde wymaganie funkcjonalne lub niefunkcjonalne musi wspierać wymaganie stakeholderów, tak jak wymagania stakeholderów muszą wspierać wymagania biznesowe. Nie może być sytuacji, że masz wymaganie – sierotę. Takie, które nie wspiera wymagań biznesowych.
Wtedy klient traci czas i pieniądze na coś, co nie wspiera jego celu. Na pewno nie dlatego Cię zatrudnił 😉
