Po co komu analiza – czyli o wartości jaką wnosi analityk biznesowy do realizowanych projektów.

Powodzenie projektów IT

Badanie międzynarodowej organizacji Standish Group¹⁾ dowodzi, że zaledwie 31% projektów IT kończy się sukcesem. Z kolei 19% to projekty, których wdrożenie zostało przerwane, czyli zakończyło się porażką. Wśród najważniejszych powodów nieudanych i kwestionowanych projektów wdrożeniowych najczęściej wymienia się brak zaangażowania użytkownika i wsparcia kierownictwa oraz niekompletne i zmieniające się wymagania (łącznie ok. 44% udziału w przyczynach). Kluczem do lepszego zrozumienia kryteriów decydujących o powodzeniu, lub niepowodzeniu projektów IT, wydają się być połączone obszary biznesu i wymagań, czyli to czym zwyczajowo zajmuje się analiza biznesowa. Właśnie dla osób zainteresowanych tematyką analizy oraz rolą analityka biznesowego w projektach IT dedykowany jest niniejszy artykuł.

Projekt przerwany – projekt anulowany ze względu na brak możliwości dostarczenia oczekiwanych funkcjonalności w zakładanym czasie lub budżecie.

Projekt kwestionowany – projekt zrealizowany do końca, ale z przekroczonym budżetem lub terminem, jak również nie oferujący wszystkich pierwotnie zakładanych funkcjonalności.

Projekt skuteczny – projekt zakończony w założonym terminie i budżecie, realizujący wszystkie funkcjonalności zdefiniowane w pierwotnych wymaganiach.

Analiza biznesowa vs. analityk biznesowy

Według definicji BABOK²⁾ analiza biznesowa to praktyka umożliwiania zmian w przedsiębiorstwie poprzez definiowanie potrzeb i rekomendowanie rozwiązań, które przynoszą wartość interesariuszom. Analiza biznesowa umożliwia przedsiębiorstwu sformułowanie potrzeb i uzasadnienie zmian oraz zaprojektowanie i opisanie rozwiązań, które mogą zapewnić wartość.

Z kolei analityk biznesowy, również zgodnie z definicją BABOK²⁾, to każda osoba wykonująca zadania z zakresu analizy biznesowej, bez względu na zajmowane stanowisko czy rolę w organizacji. Analitycy biznesowi są odpowiedzialni za odkrywanie, syntezę i analizę informacji z różnych źródeł w przedsiębiorstwie, w tym narzędzi, procesów, dokumentacji i interesariuszy. Analityk biznesowy jest odpowiedzialny za pozyskiwanie rzeczywistych potrzeb interesariuszy, co często wiąże się z badaniem i wyjaśnianiem ich wyrażonych pragnień, w celu określenia podstawowych problemów i przyczyn.

Skracając i łącząc powyższe definicje możemy stwierdzić, że rolą analityka biznesowego jest pozyskiwanie wymagań w procesie analizy biznesowej, w zakresie potrzeb oraz oczekiwań klienta co do planowanych rozwiązań oraz odpowiednie ich dokumentowanie, modelowanie i zarządzanie nimi. Wyraźny akcent na wymagania jest uzasadniony tym bardziej, że to właśnie ten obszar był jedną z głównych przyczyn wcześniej wspomnianych niepowodzeń projektów IT. Czym dokładnie są wymagania, jak je identyfikować oraz w jaki sposób dokumentować?

Czym są wymagania?

Z pomocą przychodzą najczęściej przytaczane w literaturze branżowej definicje oraz standardy:

1. Definicja wg. Standardu IEEE³⁾: „Warunek lub umiejętność potrzebna użytkownikowi, by rozwiązać problem, bądź osiągnąć cel.”
2. Definicja wg. I. Sommerville, P. Sawyer⁴⁾: „Wymagania stanowią specyfikację tego, co powinno zostać zaimplementowane. Opisują jak powinien zachować się system, albo określają jego właściwości lub atrybuty. Mogą nakładać ograniczenia na proces tworzenia systemu.”
3. Definicja wg. BABOK²⁾: „Wymaganie jest użyteczną reprezentacją potrzeby. Wymagania koncentrują się na zrozumieniu, jaki rodzaj wartości może być dostarczony, jeśli wymaganie zostanie spełnione.”

Są to dość ogólne definicje, dlatego często stosuje się podział wymagań, umożliwiający bardziej szczegółowy opis skupiający się na obszarze, którego wymaganie dotyczy. Stowarzyszenie IIBA²⁾ wyróżnia następujące rodzaje wymagań wraz z opisem ich zakresu:

1. Wymagania biznesowe – deklaracje celów, zadań i wyników, które opisują dlaczego zainicjowano zmianę. Mogą dotyczyć całego przedsiębiorstwa, obszaru biznesowego lub określonej inicjatywy.
2. Wymagania interesariuszy – opis potrzeb interesariuszy, które muszą być osiągnięte, aby spełnić wymagania biznesowe. Mogą służyć jako pomost między wymaganiami biznesowymi a wymaganiami dotyczącymi rozwiązań.
3. Wymagania dotyczące rozwiązań – opis możliwości i cech rozwiązań, które spełniają wymagania interesariuszy. Zapewniają odpowiedni poziom szczegółowości, aby umożliwić rozwój i wdrożenie rozwiązania. Wymagania dotyczące rozwiązania można podzielić na dwie podkategorie:
4. wymagania funkcjonalne – opis możliwości, jakie musi mieć rozwiązanie w zakresie zachowania i informacji, którymi rozwiązanie będzie zarządzać,
5. wymagania niefunkcjonalne (lub wymagania dotyczące jakości) – nie odnoszą się bezpośrednio do zachowania funkcjonalności rozwiązania, ale raczej opisują warunki, w których rozwiązanie musi pozostać skuteczne lub cechy, które rozwiązanie musi mieć.
6. Wymagania dotyczące przejścia – opis możliwości, jakie musi mieć rozwiązanie oraz warunki, które rozwiązanie musi spełnić, aby ułatwić przejście ze stanu obecnego do stanu przyszłego, ale które nie są potrzebne po zakończeniu zmiany. Różnią się one od innych typów wymagań, ponieważ mają charakter tymczasowy. Wymagania dotyczące przejścia dotyczą takich tematów, jak konwersja danych, szkolenia i ciągłość biznesowa.

Specyfikacja Wymagań Oprogramowania

Zwyczajowo wymagania dokumentuje się w Specyfikacji Wymagań Oprogramowania (z ang. „SRS” – Software Requirements Specification). Dokument SRS jest obowiązującym w branży standardem (np. ISO, IEC, IEEE), dlatego też będziemy posługiwać się tym właśnie terminem, jak również przytoczonym wcześniej polskim tłumaczeniem (Specyfikacja Wymagań Oprogramowania).

„SRS określa funkcjonalności oraz możliwości, które musi realizować system oprogramowania, a także definiuje charakterystyki oraz ograniczenia, które system powinien uwzględniać. SRS w wystarczającym stopniu powinien opisywać zachowania systemu w różnych warunkach, jak i pożądane charakterystyki systemu, takie jak wydajność, bezpieczeństwo i użyteczność.” ⁶⁾

Tworząc dokument SRS dobrze jest korzystać w gotowych szablonów, które zostały zdefiniowane w ramach powszechnie obowiązujących standardów (takich jak np. IEEE 830). Pozwala to unikać błędów, zwłaszcza osobom początkującym w temacie analizy. Warto mieć na uwadze, że w projektach realizowanych w oparciu o metodyki zwinne, dokument SRS może przyjmować inną strukturę i formę, niż w tych tradycyjnych. Przykładowo podczas pozyskiwania wymagań w wielu projektach zwinnych, powszechnie wykorzystywane są tzw. „user story” (opowieści użytkownika), gromadzone w dynamicznym rejestrze wymagań, który podlega ciągłej zmianie i aktualizacji.

Niezależnie od wybranego modelu projektowego (np. tradycyjny lub zwinny), należy mieć na uwadze, że proces tworzenia specyfikacji przebiega niejako równolegle do procesu analizy wymagań. Dopiero skończona specyfikacja stanowi sformalizowanie wyników analizy (z tego względu może być traktowana jako podstawa kontraktu pomiędzy zamawiającym a dostawcą rozwiązania).  Sam cykl zarządzania wymaganiami może wyglądać jak na załączonej grafice, gdzie wymagania są źródłem dla propozycji rozwiązania (design), a te z kolei mogą być podstawą do definiowania kolejnych wymagań. Nadrzędnym celem procesu specyfikacji wymagań jest opracowanie dokumentu SRS w stopniu szczegółowości adekwatnym do celów i statusu projektu.

Koszty zmian na różnych etapach projektu

Dlaczego właściwe pozyskiwanie, dokumentowanie i zarządzanie wymaganiami przez analityka jest takie ważne? Czy nie można uprościć tego procesu i od razu przejść do proponowania rozwiązań oraz ich implementacji? Jak wynika z wielu opracowań, nakłady pracy poniesione podczas analizy zwracają się w olbrzymim stopniu na kolejnych etapach projektu. Co więcej, im później wykryty zostanie błąd lub brak istotnego wymagania, tym kosztowniejsza jest zmiana. Wracamy tym samy do początkowej tezy artykułu, gdzie o powodzeniu lub sukcesie projektu IT decydują min. wymagania (uzgodnione, potwierdzone i kompletne).

„Praktyka pokazuje, że czas i środki poświęcone na analizę wymagań (obejmuje ona także projekt logiki biznesowej), istotnie skracają proces implementacji (która zawiera projektowanie szczegółów architektury implementacji). Głównym źródłem oszczędności jest wypracowany na początku i przetestowany model logiczny systemu dzięki czemu praktycznie unikamy pętli odkrywania nowych wymagań.” ⁵⁾

Ponieważ istnieją różne metodyki tworzenia oprogramowania, nie ma jednego podejścia w zakresie procesu opracowywania wymagań. Możliwe jest natomiast zróżnicowanie nakładów pracy, poniesionych na specyfikowanie wymagań w zależności od wybranej metodyki projektowej (np. tradycyjna lub zwinna).

Projekty realizowane tradycyjnie, iteracyjnie oraz zwinnie

Przyjrzyjmy się możliwym strukturom procesu opracowywania wymagań, ze względu na wybraną metodykę projektową. W projektach tradycyjnych, zwanych również kaskadowymi (tzw. „waterfall”), większość nakładów pracy związanych z opracowaniem wymagań przypada na sam początek procesu. W projektach realizowanych iteracyjnie (np. RUP – Rational Unified Process), praca nad wymaganiami realizowana będzie w każdej iteracji, z największym udziałem w fazie początkowej. Z kolei w projektach zwinnych różnica ta zaciera się niemal całkowicie, a proces zbierania wymagań jest równomiernie rozłożony na każdą fazę (np. na każdy sprint).

Obecnie coraz częściej przyjmuje się, że duże projekty realizowane kaskadowo to już przeszłość. Wynikać może to przede wszystkim z szybko zmieniającego się otoczenia biznesowego. Mało która firma może pozwolić sobie, np. na roczną implementację rozwiązania, podczas której wiele założeń, co do samego projektu może ulec zmianie. Niepewność będąca charakterystyką ostatnich lat, wymusza coraz częstsze stosowanie metodyk projektowych, które zapewniają odpowiednią elastyczność w swoim podejściu. Wynika stąd rosnąca popularność metodyk zwinnych, takich jak np. Scrum oraz jego liczne wariacje zaimplementowane na wewnętrzne potrzeby różnych organizacji i przedsiębiorstw. Jak zauważa Jarosław Żeliński, nawet duże projekty warto dzielić na mniejsze:

„W znakomitej większości przypadków rok budżetowy to zbyt krótko na duży monolit. W efekcie pytanie nie brzmi czy dzielić, ale jak dzielić zakres projektu. Przypominam, że wymagania to warunki a te się zmieniają, więc w świetle tego (co) napisano, nie mamy możliwości spisania specyfikacji wymagań na duże projekty. Co nam pozostaje? Skupić się na strategii i uznać, że to jednak cykl życia systemu jest kluczem, a nie jego – niemożliwa do opracowania – dokładna specyfikacja.” ⁷⁾

Wniosek wydaje się oczywisty, projekty powinny być zarządzane i realizowane możliwie zwinnie (lub dzielone na mniejsze), gdyż otoczenie biznesowe również ulega ciągłym i nieraz szybki przemianom. Adaptacyjne podejście daje organizacji narzędzia do elastycznej i odpowiedniej reakcji na zmiany zachodzące w otoczeniu biznesowym.

Wnioski

Dość często przyjmuje się, że analiza leży w gestii dostawcy rozwiązania (tu głównie w znaczeniu systemu informatycznego). Jak jednak wynika z wcześniejszych rozważań, odpowiedzialność za właściwą specyfikację wymagań powinna spoczywać na stronie bezpośrednio zainteresowanej, czyli zamawiającym. Wynika to przede wszystkim z tego, że rzetelna analiza nie zawsze leży w interesie samego dostawcy, gdyż często ogranicza zakres oraz koszty projektu. W tym właśnie miejscu wkracza analityk biznesowy. Nie każda organizacja ma zasoby oraz wiedzę, aby samodzielnie i skutecznie przeprowadzić proces analizy biznesowej, dla planowanego przedsięwzięcia. Na szczęście na rynku działają wyspecjalizowane podmioty, wspierające organizacje w tym procesie i mogące pochwalić się nieraz znacznym portfolio zrealizowanych projektów. Analityk biznesowy może pomóc decydentom (interesariuszom) oraz organizacjom w podjęciu właściwych decyzji, w myśl maksymy: „zrozum, zanim zaproponujesz rozwiązanie” ⁸⁾.

1. Standish Group – „CHAOS 2020: Beyond Infinity Overview”
2. International Institute of Business Analysis – „A Guide to the Business Analysis Body of Knowledge”
3. Standard IEEE 610-1990 – „IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries”
4. I. Sommerville, P. Sawyer – „Requirements Engineering – A Good Practice Guide”
5. Jarosław Żeliński – „Raport Jama Sofware? O wymaganiach”
6. K. Wiegers, J. Beatty – „Specyfikacja oprogramowania – Inżynieria wymagań”
7. Jarosław Żeliński – „Na co zwrócić uwagę przygotowując się do wyboru systemu w 2021?”
8. Jarosław Żeliński – „Analiza Biznesowa – Praktyczne modelowanie organizacji”