Inżynieria wymagań

Tekst
Przeczytaj fragment
Oznacz jako przeczytane
Jak czytać książkę po zakupie
Czcionka:Mniejsze АаWiększe Aa


Projekt okładki Hubert Zacharski

Ilustracja na okładkę Shutterstock/sumkinn

Wydawca Łukasz Łopuszański

Redaktor prowadzący Adam Kowalski

Redaktor Irena Puchalska

Koordynator produkcji Anna Bączkowska

Skład wersji elektronicznej na zlecenie Wydawnictwa Naukowego PWN Marcin Kapusta / konwersja.virtualo.pl

Zastrzeżonych nazw firm i produktów użyto w książce wyłącznie w celu identyfikacji.

Copyright © by Wydawnictwo Naukowe PWN SA

Warszawa 2018

eBook został przygotowany na podstawie wydania papierowego z 2018 r., (wyd. I)

Warszawa 2018

ISBN 978-83-01-20143-2

Wydawnictwo Naukowe PWN SA

02-460 Warszawa, ul. Gottlieba Daimlera 2

tel. 22 69 54 321, faks 22 69 54 288

infolinia 801 33 33 88

e-mail: pwn@pwn.com.pl, www.pwn.pl

Spis treści

Od redaktorów

Część I. Procesy i metody

1. Planowanie i monitorowanie analizy

1.1. Wstęp

1.2. Projekt

1.3. Problemy

1.4. Rozwiązanie

1.4.1. Zaplanowanie podejścia do przeprowadzenia analizy biznesowej

1.4.2. Zaplanowanie zaangażowania interesariuszy

1.4.3. Planowanie zarządzania analizą biznesową i planowanie zarządzania informacjami pozyskanymi w analizie biznesowej

1.4.4. Identyfikacja usprawnień w przebiegu analizy biznesowej

1.5. Podsumowanie

2. Od modelu do rozwiązania

2.1. Wstęp

2.2. Jak zapanować nad wymaganiami?

2.3. O porażkach w projektowaniu systemów

2.4. Propozycja

2.4.1. Narzędzia

2.4.2. Case study

2.4.3. Dawno, dawno temu, czyli jak to drzewiej bywało

2.4.4. Quo vadis World

2.4.5. Tworzymy system

2.4.6. Model rozwiązania systemowego

2.4.7. Struktura modelu wymagań

2.4.8. Przepis na powiązanie elementów zależnych w EA

2.4.9. Przypadki użycia

2.4.10. Śledzenie zależności

2.4.11. Nie wyobrażaj sobie, zobacz

2.4.12. Wykonaj z nami swój prototyp

2.5. THE END

3. Model modelowi nierówny, czyli łamanie schematów w postrzeganiu modelowania procesów biznesowych w projektach firmy

3.1. Wstęp

3.2. Opis przypadku

3.3. Problemy i wyzwania

3.4. Rozwiązanie problemu

3.4.1. Wizualizacja procesu

3.4.2. Model procesów podstawowych w notacji BPMN 2.0

3.4.3. Proces wytwarzania wymagań

3.4.4. Struktura zależności zagadnień i koncepcja zarządzania projektem

3.5. Rezultat

3.6. Wnioski, zalecenia i rekomendacje

4. Behaviour-Driven Development jako platforma komunikacji

4.1. Wprowadzenie i cel rozdziału

4.2. Domena jako fundament komunikacji

4.2.1. Kruszenie wiedzy domenowej własną głową

4.2.2. Wspólny cel i model domenowy

4.3. Język domenowy jako medium komunikacji

4.3.1. Na początku był słownik…

4.3.2. Parafraza jako narzędzie do budowania zrozumienia

4.3.3. Wpływ kultury pracy na komunikację

4.4. Komunikacja w rzeczywistym środowisku

4.4.1. Zmiany widzę – wszędzie zmiany!

4.4.2. Wyjdź zza biurka – analityk w terenie

4.5. Przeniesienie komunikacji na wyższy poziom

4.5.1. User Story jako format zapisu wymagań

4.5.2. Jednoznaczne i czytelne testy kodu źródłowego

4.5.3. Wykonywalna dokumentacja jako platforma komunikacji

4.6. Podsumowanie

Część II. Produkty prac

5. Dokumentacja analityczna

5.1. Dokumentacja byle jaka

5.1.1. Przedmiot

5.1.2. Problem

5.1.3. Rozwiązanie

5.1.4. Zastosowane techniki

5.1.5. Rezultaty

5.1.6. Wnioski, zalecenia, rekomendacje

5.2. Potrzebujemy tylko dokumentu

5.2.1. Przedmiot

5.2.2. Problem

5.2.3. Rozwiązanie

5.2.4. Rezultat

5.2.5. Wnioski, zalecenia, rekomendacje

5.3. Dużo dokumentacji, mało informacji

5.3.1. Przedmiot

 

5.3.2. Problem

5.3.3. Rozwiązanie

5.3.4. Rezultat

5.3.5. Wnioski, zalecenia, rekomendacje

5.4. Wnioski wniosków

6. Czy można było jeszcze coś zepsuć?

6.1. Przedmiot – charakterystyka projektu/sytuacji i problemu do rozwiązania

6.2. Stosowane definicje

6.3. Opis zlecenia, terminy realizacji i otoczenie projektu

6.3.1. Istniejąca aplikacja

6.3.2. Stan udokumentowania wymagań do obsługi urządzeń

6.3.3. Wiedza merytoryczna zespołu o zagadnieniu i wspieranych procesach u klienta

6.3.4. Zespół

6.3.5. Odpowiedzialności poszczególnych ról w zespole

6.3.6. Zamawiający

6.4. Przebieg procesu analizy i powstałe produkty w pierwszej fazie przed wstrzymaniem projektu

6.5. Problemy, przed którymi stanęliśmy

6.5.1. Przekonanie, że wszystko jest gotowe, wystarczy zaimplementować

6.5.2. Przeterminowane wymagania, brak właścicieli wymagań, zdefiniowanych interesariuszy

6.5.3. Skupiono się na szczegółach, pominięto główne założenia

6.5.4. Nie został rozpoznany proces biznesowy klienta

6.5.5. Duży zakres dostarczanych usług bez podziału na etapy realizacji. Trudność estymacji pozostałych prac

6.5.6. Pozostałe problemy

6.6. Rozwiązanie – podejścia, techniki i technologie, jakie wykorzystaliśmy w projekcie, by rozwiązać problem i zrealizować postawiony cel

6.6.1. Ankiety

6.6.2. Eksperci dziedzinowi, weryfikacja rozwiązań i kontakt z klientem

6.6.3. Lista wymagań

6.6.4. Pseudouporządkowana logika biznesowa aplikacji

6.6.5. Lista usług aplikacji

6.6.6. Podział na etapy i usługi dodatkowe

6.7. Rezultat

6.8. Wnioski, zalecenia i rekomendacje

Część III. Zespół i umiejętności miękkie

7. Janusze analityki. Czy warto być samotnym wilkiem w zespole?

7.1. Wprowadzenie

7.2. Samotny wilk

7.3. Zespół nadchodzi z odsieczą

7.4. Chaos: razem, ale osobno

7.5. Konsekwencje

8. Wprowadzanie Scruma – problemy i korzyści

8.1. Wstęp

8.2. O teorii autodeterminacji

8.3. Praca w Scrumie

8.3.1. Samoorganizacja zespołu – autonomia

8.3.2. Rozwiązanie

8.3.3. Sens pracy i trudność wykonywanych zadań

8.3.4. Rozwiązanie

8.3.5. Poczucie kompetencji – ciągły rozwój

8.3.6. Możliwość wpływania na produkt

8.3.7. Rozwiązanie

8.3.8. Relacje z innymi – potrzeba przynależności

8.3.9. Współpraca a rywalizujące Zosie samosie

8.3.10. Rozwiązanie

8.3.11. Rola relacji z użytkownikami

8.3.12. Rozwiązanie

8.4. Podsumowanie

9. Outsourcing analizy. Jak się przygotować

9.1. Przedmiot – charakterystyka projektu i problemu do rozwiązania

9.2. Problemy, rozwiązanie i rezultat

9.2.1. Koordynacja zależności prac analitycznych

9.2.2. Komunikacja w zespole

9.2.3. Narzędzie CASE do modelowania

9.2.4. Wspólne szablony wymagań

9.2.5. Repozytorium. Gdzie przechowywać dokumenty?

9.2.6. Odbiór produktów analitycznych

9.3. Wnioski, zalecenia i rekomendacje

10. Coaching w analizie

10.1. Wstęp

10.1.1. Coach i coaching

10.2. Role w coachingu

10.2.1. Coach

10.2.2. Klient coachingu (inaczej: coachee)

10.2.3. Sponsor coachingu

10.3. Elementy coachingu

10.4. Model coachingowy

10.5. Przebieg procesu coachingowego

10.6. Umiejętności coachingowe

10.6.1. Aktywne słuchanie

10.6.2. Pytania sięgające sedna

10.6.3. Ćwiczenie

10.6.4. Bezpośrednia komunikacja

10.6.5. Ćwiczenie

10.6.6. Obecność

10.6.7. Ćwiczenie

10.6.8. Tak, i …

10.6.9. Ćwiczenie

10.7. Podejście coachingowe

Część IV. Ewolucja

11. Projektowanie nastawione na zmianę

11.1. Wstęp

11.2. Ewolucja systemów informatycznych

11.3. Inżynieria wymagań w kontekście ewolucji systemów

11.4. Inżynieria wymagań wspierająca ewolucję systemów

11.4.1. Model CoRE

11.4.2. Metody statystyczne

11.4.3. Przewidywanie przyszłości

11.4.4. Cztery podejścia do wymagań

11.4.5. Wymagania w systemach eksperckich

11.4.6. Podsumowanie metod

11.5. Projektowanie nastawione na zmianę

11.5.1. Wiedza domenowa

11.5.2. Modułowość rozwiązań

11.5.3. Uniwersalne interfejsy

11.5.4. Konfigurowalność

11.5.5. Myślenie o przyszłości

11.6. Podsumowanie

Bibliografia

Przypisy

O autorach

Od redaktorów

Inżynieria wymagań… tajemnicze pojęcie, które niemal każda pytana przez nas osoba interpretuje inaczej. Niektórzy uważają, że to zarządzanie wymaganiami. I mają rację. Inni – że inżynieria wymagań to to samo, co analiza biznesowa. W pewnym stopniu to też prawda. Jeszcze inni twierdzą, że inżynieria wymagań zasadniczo sprowadza się do opracowania projektu systemu czy innej formy produktu spełniającego postawiony cel biznesowy. To też prawda.

 

W odpowiedzi na pytanie, kim jest inżynier wymagań, często uzyskiwaliśmy takie informacje: „inżynier wymagań to analityk biznesowy”, „to analityk systemowy”, „to projektant systemu”, „to właściciel produktu”, „to ktoś, kto pozyskuje wymagania od klienta i je dokumentuje”, „to ktoś, kto opracowuje modele systemu”. I wszystkie były prawdziwe.

Czy to możliwe, że jedno pojęcie ma aż tyle prawidłowych interpretacji? Czym w takim razie jest inżynieria wymagań? I kim jest inżynier wymagań?

Niniejsza publikacja nie daje jednoznacznej i ścisłej odpowiedzi na te pytania. Autorzy, którzy uprzejmie zgodzili się opisać swoje doświadczenia i przemyślenia, dostarczają sporej dawki informacji o różnorodnych zadaniach, odpowiedzialnościach, metodach i stylach działania oraz cechach osobowościowych osób zajmujących się inżynierią wymagań. Inżynier wymagań prowadzi biznesowe ustalenia z interesariuszami, a wynikiem jego pracy jest koncepcja nowego procesu biznesowego; w innych sytuacjach inżynier wymagań tworzy modele kompleksowo opisujące projektowane rozwiązanie informatyczne. Z treści rozdziałów można wywnioskować, że inżynier wymagań to osoba, która uczestniczy czynnie lub biernie w wielu aspektach i etapach procesu wytwarzania, a zakres i forma tego udziału mocno zależą od kontekstu, możliwości biznesowych i technicznych oraz indywidualnych ustaleń. I tak jest w istocie.

Niezmiernie trudno jest podać zwięzłą definicję inżyniera wymagań – jest to bowiem rola o na tyle szerokich i zależnych od kontekstu zadaniach i odpowiedzialnościach, że chyba każda definicja okaże się niepełna. W tej książce nie podejmujemy zatem próby szczegółowego i wyczerpującego zdefiniowania tej roli. W celu przejrzystości wprowadzimy pewne niezbędne podłoże teoretyczne, jak również przedstawimy naszą interpretację inżyniera wymagań, jednak niuanse i szczegółowe opisy obszaru działania inżynierów wymagań w różnych kontekstach pozostawiamy współautorom oraz wyobraźni Czytelników.

A więc drogi Czytelniku, zacznijmy od podstawowej sprawy. Kim jest dla nas inżynier wymagań? Oto nasza interpretacja:

Inżynier wymagań – rola w projekcie odpowiedzialna za pozyskanie konkretnych potrzeb i oczekiwań interesariuszy, ich analizę i interpretację oraz zaprojektowanie koncepcji rozwiązania spełniającego postawione cele biznesowe przy uwzględnieniu kontekstu biznesowego i technologicznego.

Część I Procesy i metody

Dyskusji o inżynierii wymagań nie sposób rozpocząć bez omówienia procesu oraz wspierających go technik, metod i narzędzi.

Gwoli krótkiego przypomnienia – inżynierię wymagań można zdefiniować jako proces pozyskiwania, analizy, dokumentowania i zarządzania wymaganiami właściwy do określonego rozwiązania. Rozwiązaniem takim jest dowolny produkt czy usługa umożliwiające spełnienie postawionych przez daną inicjatywą celów biznesowych oraz spełnienie potrzeb kluczowych interesariuszy.

W ramach samej inżynierii wymagań można wyróżnić kilka specyficznych obszarów, wśród których znajdują się:

• identyfikacja wymagań,

• analiza i negocjacja wymagań,

• specyfikacja (dokumentacja) wymagań,

• walidacja i weryfikacja wymagań.

Powyższe czynności można zakwalifikować do grupy tak zwanych procesów opracowywania wymagań (ang. requirements development)[1]. W realiach projektowych niezbędny kontekst i ciągłość tych procesów zapewniają czynności zarządzania wymaganiami (ang. requirements management)[2], które obejmują m.in.:

• definiowanie i utrzymywanie możliwości śledzenia,

• zapewnienie jakości,

• zarządzanie konfiguracją i zmianami.

Wymienione wyżej czynności tworzą swoiste ramy dla planowania, wdrożenia i monitorowania czynności inżynierii wymagań.

Niniejsza część książki wprowadzi Czytelnika w temat wdrażania i praktycznego zastosowania tych procesów i czynności – zaczyna się od rozdziału o planowaniu i monitorowaniu analizy Agnieszki Kugler, która na postawie doświadczeń w rzeczywistym projekcie przedstawi sposób wykorzystania dobrych praktyk i potencjału zespołu w celu zwiększenia skuteczności procesu analizy.

W kolejnych rozdziałach podejmiemy temat modelowania. Poznamy go z dwóch pespektyw. W pierwszej Hanna Banaszkiewicz i Katarzyna Gottfried przybliżą koncepcję modelu jako sposobu przedstawienia działalności organizacji. Autorki przedstawią całościowy proces analizy wybranego tematu, rozpoczynając od definicji problemu biznesowego, przechodząc przez szczegółową analizę biznesową i modelowanie procesów biznesowych, kończąc na wnioskach z wykonanej analizy – w szczególności identyfikacji usprawnień i zmian wymaganych do zwiększenia skuteczności i jakości omawianego procesu.

W drugim rozdziale dotyczącym modelowania Ewa Rek oraz Jarosław Szewczuk opowiedzą o tym, w jaki sposób łączyć techniki modelowana z innymi koncepcjami w celu stworzenia skutecznej formy komunikacji z interesariuszami. Dzięki tym dwóm perspektywom Czytelnik nie tylko pozna zalety i korzyści z modelowania wymagań i rozwiązań za pomocą notacji zrozumiałych dla wszystkich interesariuszy. Dowie się również, jak wykorzystać modele do porozumiewania się i wyjaśniania trudnych koncepcji oraz nauczy się budować własne metody komunikacji bazujące na doświadczeniach Autorów.

Na zakończenie tej części książki Kamila Gawrońska przybliży temat BDD – podejścia wykorzystującego określone produkty prac w celu usprawnienia komunikacji w przedsięwzięciu. Ten rozdział obejmuje zagadnienia z pogranicza procesów, technik i narzędzi. Autorka przekrojowo omawia temat, wprowadzając Czytelnika zarówno w obszar komunikacji w pracach związanych z inżynierią wymagań, jak i konkretnych technik wspierających ten obszar. Temat ten zapewne spodoba się Czytelnikom, którym bliskie są zwinne metody wytwarzania oprogramowania, ponieważ BDD jest jedną z technik Agile, ponadto z racji swojej względnej prostoty i podłoża biznesowego – zdobywającą coraz większą popularność.

1. Planowanie i monitorowanie analizy Agnieszka Kugler

1.1. Wstęp

Miarą sukcesu analityka biznesowego w organizacji jest jego skuteczność. W jaki sposób ją osiągnąć? Przede wszystkim proponuję przyjąć, że skuteczna analiza sprowadza się do wykonywania „właściwych zadań”[3] oraz założyć, że przeprowadzenie analizy to realizacja skończonej liczby zadań. Nie każde wykonane zadanie stanowi jednak postęp w analizie. Celem jest uzyskanie planu składającego się z zadań dopasowanych do potrzeb projektu. Zagadnienie to należy do wymagających ze względu na brak uniwersalnej metody doboru zadań do realizacji w ramach prowadzonej analizy. Wspomniany brak uniwersalnej metody nie oznacza, że procesu nie można wesprzeć, stosując sprawdzone praktyki.

Rozdział zawiera opis wykorzystania dobrych praktyk dotyczących planowania i monitorowania analizy w realizowanym przez zespół projekcie budowy nowej platformy do realizacji inwestycji kapitałowych. Starania zespołu nie zmierzały w kierunku proceduralnego ujęcia planowania i monitorowania analizy biznesowej. Tym samym nie proponuję gotowego i sprawdzonego schematu działania. Moim zamiarem jest przedstawienie, w jaki sposób dobre praktyki i interakcja zespołu realizującego projekt zwiększają prawdopodobieństwo zakończenia analizy z sukcesem.

Rozdział bazuje na rzeczywistym projekcie, ponieważ jednak jego realizacja jest objęta zobowiązaniem do zachowania poufności i poszanowania tajemnicy handlowej, prezentowane są jedynie wybrane informacje oraz zanonimizowane dane, nienaruszające dobra klienta i członków zespołu realizacyjnego.

1.2. Projekt

Firma Nord International Broker (NIB), świadcząca usługi dla giełdowych inwestorów indywidualnych, wyraziła zainteresowanie budową nowego rozwiązania (aplikacji internetowej i mobilnej) będącego platformą do realizacji inwestycji kapitałowych, które miałoby zastąpić obecne rozwiązania. Zakres informacji przekazanych we wrześniu 2017 r. obejmował:

• dokument zdefiniowany przez NIB jako „próba opisania planowanego rozwiązania”,

• termin przekazania informacji handlowej z szacunkową wyceną – listopad 2017 r.

21 września 2017 r. opiekun handlowy klienta przekazał informację o potrzebie uruchomienia analizy dotyczącej opisanego wyżej projektu.

1.3. Problemy

Intencja klienta była oczywista. Zamierzeniem NIB-u było osiągnięcie w założonym czasie określonego wzrostu przychodów, a kluczem miało być podniesienie jakości usług świadczonych przez NIB. Natomiast pytanie, na które należało dopiero odpowiedzieć, brzmiało: jak ma wyglądać rozwiązanie, który pozwoli ten cel osiągnąć?

Dokonując porównania różnych projektów, można dostrzec, że typowymi trudnościami, z którymi przychodzi zmierzyć się przy planowaniu podejścia do analizy, są szerokie i zmienne zakresy projektów oraz działanie w narzuconym rygorze czasowym. Nie są to oczywiście problemy, które występują w każdym projekcie. Jeżeli jednak planowanie dotyczy projektu złożonego, unikalnego i podatnego na zmianę, wskazane jest wykorzystanie podejścia empirycznego[4]. W takim przypadku planowanie analizy opiera się na regularnym i odpowiednio częstym sprawdzaniu założonego przebiegu analizy w celu zapewnienia iteracyjnego rozwijania planu, jak również odpowiednio szybkiej korekty podejmowanych działań.

1.4. Rozwiązanie

Prezentacja zastosowanego w omawianym projekcie podejścia do planowania i monitorowania analizy byłaby niepełna, gdyby ograniczyć ją do przedstawienia przyjętego planu. Obszar planowania analizy jest nieustannie poddawany usprawnieniom. Innymi słowy, przyjęty plan reprezentuje to, co wedle bieżącego stanu wiedzy jest najlepszym rozwiązaniem. Relacjonując przebieg procesu po jego zakończeniu, zwykle wiadomo, co można było zrobić inaczej. Stwierdzenie, że nie istnieje plan analizy, którego nie można by zrobić lepiej, motywuje do gromadzenia zaleceń do wykorzystania w przyszłości. Z tego powodu planowanie analizy jest wykonywane indywidualnie dla każdego projektu, z zachowaniem wypracowanych standardów. Standardy są oparte na dobrych praktykach i wiedzy wynikających z dotychczasowych doświadczeń. Dobre praktyki, do których odnosi się treść rozdziału, to przede wszystkim zasób wiedzy, jakim jest Guide to the Business Analysis Body of Knowledge® (BABOK® Guide v3)[5] zawierający zbiór praktyk analitycznych rekomendowanych przez International Institute of Business Analysis (IIBA). W tym kontekście artykuł można potraktować jako ocenę możliwości zastosowania i adaptacji zaleceń IIBA w przykładowym procesie analizy.

Podstawowym wynikiem planowania i monitorowania analizy biznesowej jest organizacja i koordynacja pracy analityków biznesowych i interesariuszy. Korzyściami, które wynikają z dobrze przeprowadzonego planowania i monitorowania, są precyzyjne oszacowania pracochłonności i terminów niezbędnych do budżetów i prognoz, budowanie zaangażowania członków zespołu projektowego i interesariuszy oraz spójne działanie zespołów realizacyjnych. Do osiągnięcia założonych efektów wymagane jest podjęcie działań na kilku płaszczyznach:

• zaplanowanie podejścia do przeprowadzenia analizy biznesowej, które sprowadza się do dobrania właściwej metody; wynikiem tej czynności jest plan podejścia do analizy (w dalszej części rozdziału dla planu podejścia do analizy będzie stosowane również określenie „plan analizy”);

• zaplanowanie zaangażowania interesariuszy, które jest narzędziem służącym do budowania i utrzymania efektywnych relacji z interesariuszami;

• zaplanowanie zarządzania analizą biznesową porządkujące sferę procedowania decyzji, zmian, akceptacji, nadawania priorytetów itp.;

• zaplanowanie zarządzania informacjami pozyskanymi w analizie biznesowej zmierzające do ustalenia sposobu organizacji przechowywania i dostępu do informacji gromadzonych w toku analizy;

• identyfikacja usprawnień w przebiegu analizy biznesowej, która polega na ocenie wykonanej pracy i wprowadzaniu ewentualnych korekt bądź ulepszeń[6].

Każde z wymienionych działań było obecne w projekcie NIB. Poniżej został zaprezentowany sposób realizacji wybranych elementów z zakresu planowania i monitorowania analizy.

1.4.1. Zaplanowanie podejścia do przeprowadzenia analizy biznesowej

Uogólniając, zaplanowanie podejścia do przeprowadzenia analizy biznesowej sprowadza się do dekompozycji pracy zespołu do poziomu poszczególnych zadań. Jednym z podstawowych powodów, dla którego plan analizy może się zakończyć niepowodzeniem, jest koncentracja na czynnościach do wykonania[7], a nie na założonych wynikach analizy. Wyodrębniane zadania muszą zatem być działaniami celowymi i zakładać osiągnięcie określonego rezultatu – dającego się zidentyfikować wyniku pracy, równoznacznego z postępem analizy, na przykład określenie wizji rozwiązania, identyfikacja celu biznesowego klienta.

Przystępując do dekompozycji, za punkt startu przyjmuje się ustalenie poziomu posiadanej wiedzy dotyczącej potrzeb. W przypadku omawianego projektu, korzystając z informacji przekazanych przez NIB, był ustalany poziom wiedzy dotyczącej potrzeby NIB polegającej na zbudowaniu nowej platformy dla inwestorów indywidualnych. Na podstawie zebranych informacji w pierwszej kolejności ustala się cel analizy.

Cel analizy

Przyjętą praktyką przy tego typu projektach jest wypracowywanie celu analizy w zespole obejmującym opiekuna handlowego klienta, menedżera projektu, liderów zespołów deweloperskiego i analitycznego. Skład takiego zespołu może się zmieniać, jeżeli tylko wiedza, doświadczenie i kompetencje analityka lub projektanta stanowią efektywne wsparcie.

Wyrażenie zainteresowania przez NIB budową nowego rozwiązania na ówczesnym etapie oznaczało przede wszystkim przystąpienie przez NIB do szacowania budżetu projektu. Informacje na temat planów co do dalszej realizacji projektu były zarysowane przez NIB w sposób, który uniemożliwiał przyjęcie któregokolwiek wariantu za pewny. Z tego powodu za cel analizy zostało przyjęte ustalenie w terminie do końca 15 listopada 2017 r. koncepcji i zakresu projektu w stopniu wystarczającym do szacunkowej wyceny budżetu projektu. Osiągnięcie celu wiązało się z pozyskaniem przydatnych informacji, niezależnie od podejścia (kaskadowego bądź zwinnego), które miało zostać zastosowane do realizacji przedsięwzięcia w przyszłości. Jednocześnie obrany cel minimalizował narażenie zespołu projektowego na ryzyko wykonania szczegółowej analizy, która do czasu podjęcia decyzji o realizacji projektu się zdezaktualizuje.

Kolejnym krokiem do wykonania była klasyfikacja analizy, w celu doboru podejścia do analizy.

Klasyfikacja analizy

Podejście do analizy określa sposób organizacji i sterowania procesem analizy. W zakresie organizacji i sterowania procesów można wyróżnić dwa podstawowe podejścia:

• predykcyjne – adresowane do ustabilizowanych, powtarzalnych i nieskomplikowanych procesów;

• adaptacyjne – adresowane do zmiennych, unikalnych i złożonych procesów.

Kryteria pozwalające na wybór jednego z podejść – predykcyjnego lub adaptacyjnego – jednoznacznie wskazują, że większość projektów będących udziałem zespołu wymaga podejścia będącego wypadkową tych obu podejść. Reprezentatywną ilustrację opisanej sytuacji stanowi projekt NIB. Odwołując się do najbardziej spopularyzowanych kryteriów podziału[8], projekt NIB pod względem:

• sposobu definiowania rozwiązania z uwagi na:

– niejasną i wrażliwą na zmiany wizję predestynował do iteracyjnego budowania finalnego rozwiązania;

– uwarunkowania organizacyjne wewnątrz NIB – oczekiwania dotyczące zachowania w niezmiennej postaci zakresu, budżetu i harmonogramu – predysponował do zastosowania podejścia predykcyjnego;

• formalizmu – miał wysokie wymagania dotyczące szczegółowości i zakresu dokumentacji.

Z wymienionych powodów, w praktyce klasyfikacja analizy rzadko jednoznacznie wskazuje na wariant predykcyjny bądź adaptacyjny. Sprawdzonym rozwiązaniem jest traktowanie podejścia do analizy jako strategii podporządkowanej celowi analizy. Wyodrębnianie zadań, które będą celowymi działaniami nakierowanymi na osiągnięcie określonego rezultatu, rozpoczyna się od dekompozycji celu analizy na cele pośrednie.

Dekompozycja celu analizy

Dekompozycja celu analizy na cele pośrednie jest wykonywana w gronie analityków, którzy mogą być zaangażowani w realizację projektu – w konsultacji z opiekunem handlowym klienta, menedżerem projektu i zespołem deweloperskim. Na tym etapie zabiega się o suwerenność analityków. Analityk posiada wiedzę z zakresu prowadzenia analizy biznesowej. Jednocześnie spoczywa na nim odpowiedzialność za analizę i z tego powodu musi mieć realny wpływ na sposób jej prowadzenia. Nie oznacza to oczywiście, że analitycy nie powinni konsultować i weryfikować swoich ustaleń z pozostałymi członkami zespołu.

Punktem wyjścia do dekompozycji celu analizy jest ustalenie brakujących informacji potrzebnych do osiągnięcia obranego celu analizy oraz okoliczności, które mają wpływ na proces pozyskiwania wymagań. Cele pośrednie są analizowane pod względem istotności; wstępnie ustalana jest również kolejność realizacji. Poniżej zostały przedstawione wybrane cele pośrednie zidentyfikowane w projekcie NIB.

Cel 1. Uzupełnienie wiedzy w zakresie celu biznesowego zmiany i wizji rozwiązania.

Istotność: Uzupełnienie jest wymagane do przeprowadzenia analizy.

Kolejność: Cel realizowany w pierwszej kolejności.

Cel 2. Uzupełnienie wiedzy dotyczącej zakresu, w jakim obecne rozwiązanie nie spełnia wymagań NIB.

Istotność: Do ustalenia.

Kolejność: Do ustalenia.

Komentarz: Jeżeli NIB zależy na wypracowaniu zupełnie nowej jakości w swoim rozwiązaniu, to identyfikacja braków w obecnych aplikacjach będzie miała charakter wtórny, tzn. będzie polegała na porównaniu nowej wizji ze stanem obecnym. Byłoby to więc zagadnienie do ewentualnego przeanalizowania na dalszym etapie projektu. Jeżeli z kolei NIB traktuje wyodrębnione elementy obecnego rozwiązania jako wymagający zachowania standard obsługi swoich klientów, to należy zadbać o pozyskanie wiedzy z tego obszaru.

Cel 3. Dobranie technologii do budowy rozwiązania.

Istotność: Dobranie technologii jest wymagane do przeprowadzenia i zakończenia analizy.

Kolejność: Cel realizowany po ustaleniu wizji projektu.

W praktyce tak opisowy zapis nie znajduje zastosowania, wystarczy krótka tabelka (tab. 1.1).

Znajomość istotności i kolejności celów pośrednich jest równoznaczna z posiadaniem szkicu planu. Podstawową zaletą bazowania na przedstawionym szkicu jest przede wszystkim ukierunkowanie planowania w stronę doboru środków adekwatnych do założonego celu. Innymi słowy, narzucenie sobie takiej dyscypliny w planowaniu powoduje zminimalizowanie ryzyka wykonywania zbędnych i bezcelowych czynności. Przed rozwinięciem szkicu do postaci prawdziwego planu jest wykonywana inwentaryzacja informacji, które powinny być uwzględnione w planowaniu. Poniżej został zaprezentowany zakres wybranych informacji szczególnie istotnych z punktu widzenia planowania podejścia do analizy w projekcie NIB.