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.

Tabela 1.1. Dekompozycja celu analizy

Lp.

Cel

Istotność

Kolejność

1

Ustalenie wizji rozwiązania

wymagane

1

2

Ustalenie braków w obecnym rozwiązaniu

do ustalenia

nieznana

3

Dobór technologii

wymagane

2

4

Ustalenie zakresu

wymagane

2

…

…

…

…

24

Wewnętrzne zatwierdzenie dokumentu „Koncepcja i zakres projektu”

wymagane

14

25

Zatwierdzenie dokumentu „Koncepcja i zakres projektu” przez NIB

wymagane

15

Identyfikacja istotnych danych wejściowych

1. Zakres posiadanych informacji na temat wymagań dotyczących projektu:

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

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

2. Zakres posiadanych informacji dotyczących NIB i jego otoczenia biznesowego:

• znajomość rozwiązań obecnie wykorzystywanych przez NIB,

• znajomość domeny biznesowej projektu,

• przeprowadzona analiza interesariuszy.

3. Formalizm – sformalizowany sposób dokumentowania i zatwierdzania wymagań.

4. Ryzyka:

• niepewna realizacja dalszych etapów projektu (jeżeli realizacja projektu zostanie odłożona w czasie, ustalone wymagania się zdezaktualizują),

• niewystarczający czas do wykonania analizy (jeżeli czas konieczny do wykonania analizy okaże się dłuższy niż 1,5 miesiąca, nie zostanie dotrzymany termin przekazania informacji handlowej),

• niepewna reakcja klientów NIB na nowe rozwiązanie (jeżeli nie zostaną uwzględnione potrzeby adresatów rozwiązania, NIB nie osiągnie założonego celu biznesowego).

5. Kadra:

• analitycy: dostępność wykwalifikowanych analityków posiadających wiedzę ekspercką z obszaru biznesowego projektu,

• projektanci: dostępność wykwalifikowanych projektantów doświadczonych w realizowaniu projektów tej klasy.

6. Uwarunkowania geograficzne:

• lokalizacja interesariuszy: Wrocław,

• lokalizacja zespołu deweloperskiego: Gdynia,

• lokalizacja zespołu analitycznego: Gdynia,

• lokalizacja menedżera projektu: Toruń.

Plan analizy

Pierwsze podejście do planowania analizy zmierza do ustalenia ram czasowych dla zadań analitycznych, spójnych z pozostałymi działaniami koniecznymi do wykonania projektu. Na tym etapie zamierzonym wynikiem jest schematyczny zapis na kartce, flipcharcie lub tablicy sposobu rozłożenia w czasie realizacji celów pośrednich. W projekcie NIB do stworzenia szkicu planu zostały wykorzystane m.in. techniki:

• burza mózgów;

• oszacowania bazujące na doświadczeniach z pozostałych projektów, na przykład określenie standardowego dla określonego typu projektu czasu trwania procesu weryfikacji i akceptacji wewnętrznej wymagań wypracowanych na warsztatach.

Uczestnikami procesu tworzenia szkicu w projekcie NIB byli analitycy, projektanci, opiekun handlowy klienta i kierownik projektu. Z uwagi na małą czytelność oryginału i ogólną dostępność zdjęć dokumentujących wygląd umieszczonych na tablicy żółtych karteczek samoprzylepnych opis wyniku spotkania jest ograniczony do wypunktowania ustaleń ujętych w szkicu planu:

Aplikacja internetowa

2017-10-11 Ustalenie wizji

2017-10-26 Ustalenie zakresu projektu i dobór technologii

2017-11-09 Wewnętrzne zatwierdzenie dokumentu „Koncepcja i zakres projektu”

2017-11-10 Zatwierdzenie dokumentu „Koncepcja i zakres projektu” przez NIB

2017-11-22 Opracowanie szacunkowej wyceny

2017-11-29 Opracowanie oferty

2017-11-30 Złożenie oferty

W drugim podejściu są wyodrębniane konkretne zadania analityczne. Opis zadań obejmuje:

• określenie rodzaju działania,

• czas trwania czynności,

• szacunkową pracochłonność,

• cel wykonania działania,

• osoby odpowiedzialne za wykonanie zadania,

• określenie, czy czynność wymaga interakcji z interesariuszami,

• wynik wykonanego działania,

• określenie ryzyk związanych z działaniem.

Docelowa forma zapisu wyodrębnionych zadań jest uwarunkowana potrzebami wynikającymi z projektu i standardów przyjętych w firmie.

Forma zapisu planu analizy

Plan analizy jest narzędziem organizacji i koordynacji pracy analityków biznesowych i interesariuszy w ramach projektu. Przedstawiona postać definicji planu analizy nie wyczerpuje oczywiście wszystkich jego zastosowań. Z jednej strony plan analizy jest przygotowany w sposób umożliwiający:

• wkomponowanie go w plan obejmujący całokształt projektu,

• skoordynowanie wykonywanych zadań z czynnościami analitycznymi podejmowanymi w ramach równolegle prowadzonych projektów.

Z drugiej strony plan analizy jest podstawą do retrospektywnego spojrzenia na efektywność przeprowadzonych działań. Z wyżej wymienionych powodów przygotowywane plany składają się z dwóch warstw: syntetycznej i analitycznej.

Pierwsza warstwa – syntetyczna, przygotowywana w dedykowanej aplikacji do zarządzania projektami – zawiera syntetyczne informacje obejmujące:

• etap analizy będący agregatem grupy zadań analitycznych,

• czas trwania,

• kamienie milowe (realizacja celów pośrednich),

• przypisanie analityków do danego etapu wraz z określeniem ich zaangażowania w realizację,

• zależności między etapami analizy w danym projekcie i zależności międzyprojektowe.

Planowanie analizy w projektach o zbliżonym charakterze do projektu NIB ma charakter iteracyjny. Z punktu widzenia chociażby zabezpieczenia dostępności kluczowych dla projektu osób po stronie wykonawcy i NIB jest konieczne planowanie w długofalowej perspektywie. Na początku projektu precyzyjne wskazanie, jakie działania będą podejmowane za miesiąc lub za pół roku, nie zawsze jest możliwe. Rozwiązaniem jest budowa planów wielowariantowych, jednak z uwagi na brak dysponowania dostateczną wiedzą do identyfikacji wszystkich możliwych scenariuszy plan długofalowy jest traktowany jako akceptowalny, jeżeli dla każdego etapu, w chwili jego tworzenia, istnieje zarys wykonalnej koncepcji na jego przeprowadzenie. Podsumowując, w momencie tworzenia planu realność przeprowadzenia każdego etapu jest poddawana weryfikacji – jeżeli powiązany etap poprzedzający zakończył się sukcesem. W planowaniu z góry jest przyjmowane założenie, że planowanie jest czynnością, która jest kontynuowana w trakcie trwania projektu. Praca nad planem w trakcie trwania projektu zmierza do uszczegółowiania kolejnych etapów. Z kolei monitorowanie analizy zmierza m.in. do weryfikacji przyjętego planu, a wynikiem weryfikacji może być zmiana planu podyktowana koniecznością dostosowania do zmian w otoczeniu lub korekty popełnionych błędów.

Takie podejście oprócz:

• oszczędności czasu dzięki eliminacji spekulacji dotyczących niepewnej przyszłości,

• umożliwienia określania szczegółowych zadań wtedy, kiedy zespół dysponuje wystarczającymi danymi,

• usprawnienia reakcji zespołu na zmianę[9]

ma tę zaletę, że jeżeli w przyszłości, na podstawie wyniku monitorowania analizy, zostanie zmieniona czynność, na przykład z ankiety na grupę fokusową, to ramy czasowe w harmonogramie zostaną zachowane i aktualizacja harmonogramu na poziomie całego projektu nie będzie potrzebna. Zmiana harmonogramu projektu jest o tyle istotna, że często wiąże się z koniecznością zatwierdzenia zmiany w formie aneksu do umowy. Aneks do umowy może stanowić dodatkowy wysiłek organizacyjny, który w tym przypadku nie dawałby dodatkowej wartości.

Warto więc rozważyć zasadność podziału analizy na podetapy w pierwszej warstwie – planowaniu na poziomie syntetycznym. W mojej ocenie nie zawsze jest to konieczne. Odwołując się do projektu NIB, podział na podetapy był pomocny w szacowaniu pracochłonności analizy. Dodatkowo pozwalał na rozróżnienie okresów o różnym poziomie zaangażowania analityków i z tych powodów został wykorzystany. Na rysunku 1.1 przedstawiono fragment pierwszej warstwy planu dla projektu NIB.

Druga warstwa – przygotowywana w arkuszu kalkulacyjnym – zawiera analityczny podział etapów analizy na zadania. Zakres informacji obejmuje:

• określenie rodzaju działania,

• czas trwania czynności,

• szacunkową pracochłonność,

• cel wykonania działania,

• osoby odpowiedzialne za wykonanie zadania,

• określenie, czy czynność wymaga interakcji z interesariuszami,

• wynik wykonanego działania.

Projektowanie szczegółowych czynności analitycznych jest pracą, w której inicjatywa leży po stronie analityków zaangażowanych w realizację projektu. Odpowiadając za pracę całego zespołu, można poczynić obserwację, że prawdopodobieństwo sukcesu zależy w dużej mierze od tego, jaki wpływ na podejście do analizy mieli analitycy odpowiedzialni za jej przeprowadzenie.

Zasadnicze zagadnienie dotyczy doboru odpowiedniego poziomu szczegółowości zadań. Za granicę dekompozycji jest przyjmowany poziom umożliwiający realne monitorowanie bez szkody dla samego procesu analizy. W zespole zostało wypracowane podejście, w którym w projektach o znanej charakterystyce, czyli takich, w których na zasadzie adaptacji znajdują zastosowanie wcześniejsze podejścia do prowadzenia analizy, poziom zadań jest bardziej ogólny niż w projektach prekursorskich, w których zadania są rozpisywane bardziej szczegółowo. Wynika to z faktu, że ryzyko błędu jest większe w projektach, dla których podejście do analizy jest ustalane w sposób twórczy. Zamiast wymieniania dostępnych powszechnie zaleceń dotyczących czynników, które należy wziąć pod uwagę przy ustalaniach ziarnistości zadań, punkt odniesienia stanowi zaprezentowany w tabeli 1.2 fragment pierwszej wersji planu wraz z komentarzem stworzonym na poziomie poszczególnych zadań analitycznych. Zadania w nim ujęte dotyczą etapu przygotowania warsztatów inicjujących dla aplikacji internetowej, realizowanego w celu określenia wizji.

W projekcie NIB wizja rozwiązania, będąca pierwszym celem do realizacji, miała się dopiero ukonstytuować, dlatego przyjęto założenie, że najlepszą techniką do wykorzystania w tym zakresie będą warsztaty. Zadania przewidziane w ramach przygotowań do warsztatów zostały dostosowane do możliwości, które wynikały m.in. z zaprezentowanych poniżej czynników:

• znane było z poprzednich projektów wysokie zaangażowanie i bardzo dobre przygotowanie interesariuszy – na tej podstawie można było w przygotowaniu do warsztatów założyć zadania realizowane we współpracy z NIB;

Rysunek 1.1. Plan analizy na poziomie syntetycznym

Tabela 1.2. Plan analizy – wersja szczegółowa

• w projekt byli zaangażowani analitycy i projektanci z dużym doświadczeniem i wiedzą biznesową; ich zadania mogły przewidywać pozyskiwanie wiedzy potrzebnej do opracowania nowych propozycji, które miały być wzięte pod uwagę w opracowaniu wizji;

• rozproszenie geograficzne uczestników analizy (Wrocław, Gdynia, Toruń) powodowało konieczność dostosowania zadań do możliwej do wykorzystania formy komunikacji;

• narzucony rygor czasowy spowodował ograniczenie stopnia udokumentowania prac analitycznych do niezbędnego minimum.

Plan analizy jest wypracowywany wewnątrz zespołu realizacyjnego w konsultacji z interesariuszami w celu zapewnienia, że nie będzie kolidował z działaniami pozostałych stron. Zespół realizacyjny jest również angażowany w systematyczną weryfikację i aktualizację planu.

Proces planowania podejścia do analizy uwzględnia elementy związane z zarządzaniem ryzykiem. Zagadnienie zarządzania ryzykiem jest tematem, który mógłby być przedmiotem odrębnego artykułu. W tym obszarze projekt NIB podążał zgodnie z wypracowanym i sprawdzonym standardem. Do zapewnienia odpowiedniej jakości procesu zarządzania ryzykiem zostały wykorzystane:

• metodyka zarządzania ryzykiem obowiązująca w firmie,

• plany zarządzania ryzykiem wypracowane w zrealizowanych projektach.

Na podstawie wypracowanego podejścia do analizy jest przygotowywany plan zaangażowania interesariuszy.

1.4.2. Zaplanowanie zaangażowania interesariuszy

Zaplanowanie zaangażowania interesariuszy służy przede wszystkim do zapewnienia dostępności wszystkich osób kluczowych do pozyskiwania wymagań. Interesariusze w projekcie NIB stanowili grupy różne pod względem zainteresowania i decyzyjności. Formy komunikacji z każdą grupą były ustalane odrębnie. Z praktyki wynika, że już na etapie planu analizy należy dbać o racjonalny wymiar obciążenia interesariuszy i w miarę możliwości faworyzować preferowane przez klienta formy i częstość kontaktu. Takie postępowanie minimalizuje ryzyko absencji strategicznych osób, które może ujemnie wpłynąć na jakość analizy.

W projekcie NIB przy planowaniu zaangażowania interesariuszy zostały wykorzystane wykonana wcześniej analiza interesariuszy i plan analizy, w którym jawnie wskazano konieczność współpracy z NIB. Przekazany interesariuszom plan zaangażowania prezentował informacje podane w tabeli 1.3. Szacowany okres trwania analizy miał trwać 1,5 miesiąca.

Plan zaangażowania interesariuszy jest przygotowywany indywidualnie dla każdego projektu. Należy mieć na uwadze, że w procesie planowania i monitorowania duży wpływ na sprawność przeprowadzania analizy biznesowej mają elementy, które nie wymagają wypracowania za każdym razem odrębnego rozwiązania. Należą do nich działania, co do których, z prawdopodobieństwem graniczącym z pewnością, można określić jednolity schemat, składający się z precyzyjnych zaleceń i standardów. Należy oczywiście założyć, że każdy przyjęty schemat będzie poddawany systematycznej ocenie: czy przystaje do potrzeb projektu i czy rzeczywiście jest najlepszym z możliwych sposobem realizacji przedmiotowego celu. Obszarem szczególnie podatnym na standaryzację jest planowanie zarządzania analizą biznesową i planowanie zarządzania informacjami pozyskanymi w analizie biznesowej.

Przypisy

[1] REQB, REQB CPRE Foundation Level syllabus 2014, http://www.reqb.eu/

[2] Ibidem.

[3] Peter F. Drucker, The Essential Drucker, Harpercollins 2001, s. 17.

[4] Ken Schwaber, Mike Beedle, Agile Software Development with Scrum, Upper Saddle River, Prentice Hall, 2002, ISBN 0-13-067634-9. Ogunnaike Babatunde A., Harmon Ray W., Process Dynamics. Modeling and Control, Oxford University Press, 1994.

[5] International Institute of Business Analysis, https://www.iiba.org/babok-guide.aspx (dostęp: 27.12.2016).

[6] Ibidem, s. 21.

[7] Mike Cohn, Agile Estimating and Planning, Pearson Education, 2006, s. 12.

[8] International Institute of Business Analysis, A Guide to the Business Analysis Body of Knowledge, Toronto 2015, s. 27.

[9] Mike Cohn, Succeeding With Agile Software Development Using Scrum, Pearson Education, 2010, s. 287.