.png)
Zapraszam do lektury kolejnej części cyklu publikacji mających na celu omówienie głównych punktów w programie certyfikacji IREB oraz wspierających przygotowanie do egzaminu certyfikacyjnego IREB CPRE. W tej części publikacji wkraczamy w obszar opracowywania wymagań.
Obszar opracowywania wymagań w ujęciu IREB skupia się wokół pozyskiwania i analizy informacji oraz negocjowania ostatecznej treści wymagań. Podstawowym celem pozyskiwania informacji jest zdobycie danych na temat wymagań, oczekiwań, potrzeb wraz z informacjami dodatkowymi, takimi jak ograniczenia i założenia dotyczące możliwości planowanego rozwiązania. Z kolei celem analizy informacji jest zrozumienie, identyfikacja powiązań, zależności oraz ujawnienie informacji na pierwszy rzut oka niewidocznych. Szczególną praktyką w obszarze opracowywania wymagań jest negocjowanie wymagań. Negocjowanie wymagań polega na uzgodnieniu treści, zakresu, formy wymagań w przypadku pojawienia się niespójności lub wyraźnych sprzeczności. Negocjowanie wymagań to w dużej mierze obsługa konfliktów wymagań.
Źródła wymagań
Rozpocznijmy od tematu pozyskiwania wymagań. Zanim rozpoczniemy faktyczne pozyskiwanie wymagań, należy określić źródła informacji. Jak już wiemy, podstawowym źródłem wymagań jest kontekst systemu. W kontekście są interesariusze, dokumenty biznesowe, regulacje, systemy, z którymi nasz system będzie się integrował. Jest to podstawowe źródło wymagań dlatego też jakiekolwiek wysiłki związane z pozyskiwaniem wymagań powinniśmy rozpocząć od zrozumienia kontekstu.
W wielu przypadkach najbardziej kluczowym źródłem wymagań są interesariusze, których szczególnym przykładem mogą być klienci, sponsorzy projektu, właściciele biznesowi, tzw. reprezentanci biznesu, i oczywiście użytkownicy końcowi. Dość specyficznym rodzajem interesariusza jest konkurencja. Oczywiście fakt zidentyfikowania konkurencji jako interesariusza nie oznacza wcale, że zaplanujemy wywiady z konkurencją dotyczące planowanych cech naszego systemu; może to jednak oznaczać, że działania konkurencji będą w pewnym sensie źródłem naszych wymagań.
W zależności od danej sytuacji różni interesariusze mogą mieć różne znaczenie. Dlatego dla sukcesu pozyskiwania wymagań i ogólnie dla sukcesu projektu ważne jest odpowiednie zarządzanie oczekiwaniami interesariuszy. Pierwszym krokiem do tego jest identyfikacja interesariuszy, czyli określenie, kto w przypadku naszego projektu będzie interesariuszem. Jest tu wiele technik pomocniczych, jak na przykład technika cebuli Aleksandra czy prosta technika klasyfikacji interesariuszy na interesariuszy wewnętrznych i zewnętrznych. Po określeniu, kim są interesariusze naszego projektu, powinniśmy przystąpić do ich analizy. Analiza interesariuszy może obejmować różne aspekty, przykładowo może skupiać się na zrozumieniu ich poziomu decyzyjności, czy określeniu poziomu zainteresowania wynikami projektu. Często stosowaną techniką jest tutaj tak zwana macierz wpływu i zainteresowania. Warto uwzględnić też inne atrybuty, jak na przykład dostępność interesariuszy i ich lokalizację, oczekiwania czy preferencje komunikacyjne. Znacząco ułatwi nam to później planowanie komunikacji z interesariuszami czy ogólnie planowanie zaangażowania w nasze prace. Bardzo ważnym atrybutem dotyczącym interesariuszy jest ich obszar ekspertyzy czy też zainteresowania. Ta informacja pomoże nam zrozumieć, kto jest właściwym źródłem informacji na interesujący nas temat.
Znając już interesariuszy, możemy przystąpić do określenia ich potrzeb, oczekiwań, obaw, zastrzeżeń. Warto tutaj zwrócić uwagę na to, że naszą rolą jest też rozwianie tych obaw, wyjaśnienie potencjalnych wątpliwości co do zasadności budowy systemu, co do potencjalnych konsekwencji realizacji projektu na danego interesariusza. Pamiętajmy o tym, że zależy nam, aby interesariusze byli naszymi sojusznikami, ponieważ to głównie od nich i od rzetelności udzielonych przez nich informacji może zależeć sukces naszego przedsięwzięcia.
Kolejnym źródłem wymagań mogą być dokumenty. Przykładowo, dokumenty opisujące proces biznesowy, który ma być wspierany naszym rozwiązaniem, mogą być znakomitym źródłem wymagań. Takie dokumenty opisują bardzo często to, jak w chwili obecnej realizowany jest proces – dają nam więc gotowe informacje o tak zwanej sytuacji obecnej (AS IS). Tego typu informacja może stanowić materiał wyjściowy do przykładowo wywiadu z interesariuszami na temat pożądanych usprawnień i ulepszeń w procesie. Innym rodzajem dokumentu, który może służyć jako informacja wejściowa do procesu pozyskiwania wymagań, może być na przykład procedura realizacji jakiegoś zadania, regulamin świadczenia usług, formularz reklamacji czy inny rodzaj dokumentacji biznesowej powiązanej z systemem, nad którym pracujemy. Szczególnym rodzajem dokumentacji stanowiącej źródło wymagań są regulacje, ustawy, rozporządzenia, standardy branżowe. W przypadku wielu projektów jest to podstawowe źródło wymagań (dla przykładu projekty mające na celu dostarczenie rozwiązań dla branży motoryzacyjnej w wielu przypadkach bazują niemalże wyłącznie wymaganiach opisanych w standardach branżowych).
Kolejnym dosyć typowym źródłem wymagań są systemy. Mogą to być systemy już istniejące w organizacji klienta, systemy, z którymi się integrujemy i które mogą być źródłem wymagań dotyczących, na przykład, danych wymienianych między naszym systemem a systemami “zewnętrznymi”. Innym rodzajem systemu, który może być źródłem informacji, są podobne dostępne na rynku rozwiązania czy też systemy konkurencyjne. Dosyć często analiza takich rozwiązań może być swego rodzaju inspiracją do identyfikowania wymagań dla naszego rozwiązania.
Znamy już źródła wymagań. Zastanówmy się teraz, jak wymagania pozyskiwać. Istnieje szereg technik pozyskiwania wymagań, i skuteczność zależy od kontekstu, przykładowo od dostępności interesariuszy, rodzaju informacji, które chcemy pozyskać, oraz od ograniczeń, jak na przykład ograniczenia budżetowe czy czasowe.
Model Kano
Warto zwrócić uwagę, że w zależności od tego, jakie informacje chcemy uzyskać, dobieramy inne narzędzia i techniki. W tym miejscu warto wspomnieć o tzw. modelu Kano, czyli modelu satysfakcji klienta. Zgodnie z modelem Kano, każdy produkt lub usługa składa się z szeregu cech, które różnym sposobem wpływają na satysfakcję klienta. W uproszczonym wariancie tego modelu, wyróżniamy trzy typy cech, zwane czynnikami:
Czynniki podstawowe: Cechy będące sednem produktu, uznawane za oczywiste i stanowiące podstawę danego produktu. Na przykład, dla produktu "długopis", podstawową cechą jest to, że można za jego pomocą pisać.
Czynniki wydajności: Cechy zwiększające satysfakcję klienta, ułatwiające użytkowanie produktu lub usługi, pozwalające na dłuższe korzystanie z produktu i ogólnie budujące pozytywne doświadczenia użytkownika. Dla przykładu, w przypadku długopisu, czynnikiem wydajności może być dobra ergonomia, czyli dopasowanie długopisu do dłoni użytkownika.
Czynniki entuzjazmu: Cechy powodujące zachwyt u odbiorcy, czyli takie właściwości produktu, które przekraczają oczekiwania klienta, Powodują tak zwany efekt wow. bardzo często Klient nie zdaje sobie sprawy że takie cechy są możliwe do zrealizowania i czuję się bardzo pozytywnie zaskoczony odkrywając te cechy w naszym produkcie. Dla naszego przykładu długopisu, czynnikiem entuzjazmu mogłoby być możliwość zmiany grubości pisma.
Odnosząc model Kano do systemów, w szczególności informatycznych, możemy przyjąć, że czynniki podstawowe to wymagania obligatoryjne, czyli te, które określamy jako "Must Have" używając metody MoSCoW. Bez tych wymagań, produkt nie jest produktem. Na przykład, dla systemu typu kalendarz online, czynnikiem podstawowym może być możliwość przeglądania kalendarza.
Czynniki wydajności to wymagania, które możemy oznaczyć jako "Should Have" lub "Could Have". Są to wymagania równie pożądane, ponieważ dzięki nim budujemy satysfakcję klienta. Nasz produkt będzie używany z większym komfortem i generował pozytywne doświadczenia użytkownika. W przypadku naszego systemu kalendarza, czynnikiem wydajności może być na przykład funkcjonalność oznaczania poszczególnych typów wydarzeń różnymi kolorami. Dzięki temu użytkownik będzie mógł łatwo rozróżniać różne wydarzenia na kalendarzu.
Ostatni rodzaj czynników, czyli czynniki entuzjazmu, to wymagania, które najprawdopodobniej musimy przewidzieć sami. Klient/użytkownik nam o nich nie powie - ponieważ dotyczyć one potrzeb ukrytych, których odbiorca nie być świadomy. Prawidłowe pozyskanie i implementacja tych czynników nie jest zadaniem trywialnym. Wymaga dogłębnego poznania biznesu, potrzeb klienta, a zwłaszcza ukrytych potrzeb. Należy przy tym zwrócić uwagę na to, że nieprawidłowa identyfikacja czynników entuzjazmu może generować efekt odwrotny do oczekiwanego – czyli zamiast efektu Wow uzyskamy efekt “ta funkcja jest mi kompletnie niepotrzebna”. Zamiast zachwytu uzyskamy więc frustrację – a nie jest to oczywiście coś na czym nam zależy.
Model Kano jest istotny z jeszcze jednego powodu - zakłada swego rodzaju “inflację”. To, co jest dziś czynnikiem entuzjazmu, z upływem czasu może stać się czynnikiem wydajności, a nawet czynnikiem podstawowym. Warto więc na bieżąco śledzić technologie czy trendy rynkowe, by wiedzieć o tym, jakie właściwości / cechy produktów aktualnie zwiększają satysfakcję interesariuszy, a co jest już swego rodzaju standardem oczekiwań.
Jak wykorzystać model Kano w pozyskiwaniu wymagań? Wiemy już, że w modelu tym wyróżniamy trzy podstawowe rodzaje cech, wiemy, jak te cechy mapują się na atrybuty wymagań. Znając założenia modelu Kano, możemy więc stwierdzić, że w pewnym sensie kluczowe dla nas będzie pozyskanie wymagań dotyczących czynników podstawowych, ponieważ, jak już wspomnieliśmy, to one stanowią istotę systemu, to one są wymaganiami obligatoryjnymi. Wymagania wydajności dotyczą wymagań ułatwiających użytkownikom pracę, zwiększające satysfakcję – więc te cechy również musimy pozyskać. Dlaczego? Dlatego, że żyjemy w erze technologii. Naszym interesariuszom najprawdopodobniej nie wystarczy już dostarczenie po prostu systemu, będą mieli swoje oczekiwania co do wydajności tegoż systemu, jego użyteczności, czy po prostu przyjemności z użytkowania danego rozwiązania. Jeśli chcemy więc się wyróżnić na rynku, nasze rozwiązania powinny nie tylko dostarczać pożądane funkcjonalności czy inne cechy, powinny też wspierać użytkowników w sprawnej, przyjemnej (w miarę możliwości oczywiście) realizacji zadań.
Wracając do zastosowania modelu Kano w pozyskiwaniu wymagań - pamiętajmy o tym, że wymagania związane z czynnikami entuzjazmu mogą, co prawda, budować przewagę konkurencyjną, lojalność klienta, jego zadowolenie, czy wręcz zachwyt, jednak nie są to korzyści uzyskiwane za darmo. Czynniki entuzjazmu dotyczą ukrytych potrzeb klienta. Klient danych cech funkcjonalności nie zamawiał, nie płaci za nie i ich nie oczekuje. Do pewnego stopnia możemy więc proponować tego typu usprawniacze klientowi, pamiętajmy jednak o typowych ograniczeniach projektowych, jak na przykład budżet i czas. Nieco inna sytuacja jest w przypadku projektowania systemów dedykowanych na szeroki rynek, w takim przypadku dostarczenie czynników, które generują efekt "wow" i mile zaskakują klienta, jest częścią budowania przewagi konkurencyjnej. W przypadku tego rodzaju projektów z reguły mamy budżet przewidziany na rozwój swego rodzaju innowacyjnych cech.
Techniki pozyskiwania wymagań
Przejdźmy teraz do technik pozyskiwania wymagań. Program IREB CPRE wymienia cały szereg różnych technik. Techniki te są sklasyfikowane jako techniki gromadzenia informacji oraz techniki projektowania i generowania pomysłów, czyli techniki w pewnym sensie "kreatywne".
Podstawowym celem technik klasyfikowanych jako techniki gromadzenia jest pozyskanie informacji z różnych źródeł, czy tym źródłem są interesariusze, dokumenty czy też określone systemy. Te techniki służą głównie do pozyskiwania wymagań związanych z czynnikami podstawowymi i czynnikami wydajności. Dość sporadycznie możemy uzyskać też informacje o potencjalnych czynnikach entuzjazmu. Z kolei techniki projektowania i generowania pomysłów są swego rodzaju wyzwalaczami innowacyjnych koncepcji. Mogą więc być dobrą metodą na pozyskiwanie wymagań stanowiących czynniki entuzjazmu.
W grupie technik gromadzenia informacji wyróżniamy:
Techniki zadawania pytań - szczególnym przypadkiem technik zadawania pytań są techniki wywiadu i kwestionariuszy.
Techniki współpracy - szczególnym przypadkiem technik współpracy są warsztaty czy pozyskiwanie wymagań oparte na tłumie.
Techniki obserwacji – tu przykładem może być technika obserwacji polowej oraz praktykowanie.
Techniki oparte na artefaktach - przykładem technik opartych na artefaktach jest Rea użycie wymagań z innych projektów czy tak zwana archeologia systemu.
Techniki zadawania pytań, jak sama nazwa wskazuje, polegają na zadawaniu określonych pytań celem uzyskania odpowiedzi. Można te pytania zadawać w formie wywiadu z interesariuszem lub w gronie interesariuszy, można też zadawać je w postaci przygotowanego kwestionariusza.
Techniki współpracy polegają na pracy zespołowej – innymi słowy, pozyskiwanie wymagań to praca grupowa. Bardzo popularną techniką wspierającą pozyskiwanie wymagań w taki sposób jest technika warsztatu, czyli specyficznego spotkania, które ma swój określony cel, angażuje określonych interesariuszy i ma na celu osiągnięcie zdefiniowanych rezultatów. Innym ciekawym rodzajem techniki współpracy jest inżynieria wymagań oparta na tłumie. W tym podejściu źródłem wymagań jest nasz umowny tłum, czyli pewna społeczność. Taką społecznością może być na przykład społeczność użytkowników, którzy za pomocą dedykowanej platformy mogą zgłaszać sugestie dotyczące systemu, który projektujemy.
Techniki obserwacji polegają na obserwowaniu użytkowników wykonujących pewien proces, pewne zadanie. Siłą tych technik jest możliwość zrozumienia, jak pewna czynność jest realizowana przez rzeczywistych operatorów w rzeczywistych warunkach operacyjnych. Mamy więc możliwość pozyskać wymagania dotyczące czynników podstawowych, czyli czynników, które mogłyby być stosunkowo łatwo pominięte, na przykład w czasie wywiadu. Obserwacja minimalizuje te ryzyko, ponieważ widzimy rzeczywisty proces i mamy możliwość zaobserwowania na czym polega istota tego procesu. Szczególnym typem technik obserwacji jest technika praktykowania, polegająca nie tyle na biernym obserwowaniu danego procesu, co na wykonywaniu tego procesu. Nazwa techniki pochodzi od pojęcia praktykowanie, inaczej terminowanie, czyli nauka zawodu od tak zwanego mistrza. W przypadku inżynierii wymagań mistrzem jest interesariusz, który uczy studenta-inżyniera wymagań, jak realizować określony proces. Jest to bardzo skuteczna technika pozwalająca zrozumieć funkcjonowanie danego procesu. Dodatkowo pozwala wychwycić też potencjalne usprawnienia i ulepszenia.
Techniki oparte na artefaktach bazują na wykorzystaniu określonych produktów pracy jako źródeł wymagań. Przykładem zastosowania takich technik może być archeologia systemu, czyli wydobywanie wymagań na podstawie analizy dokumentacji istniejącego systemu bądź też na podstawie analizy samego systemu. Często przybierają one postać tak zwanego spisu z natury. Z kolei technika polegająca na użyciu wymagań to technika stosowana często w przypadku firm, które mają gotowy produkt, który jest customizowany, dostosowywany na potrzeby konkretnych klientów. W tym przypadku nie tworzymy wymagań od zera, a raczej używamy istniejących wymagań i odpowiednio je modyfikujemy.
Z kolei techniki projektowania i generowania pomysłów możemy podzielić na:
Techniki projektowania – w szczególnym przykładem techniki projektowania jest prototypowanie.
Techniki generowania pomysłów - przykładowo burza mózgów przy technika analogii.
Techniki projektowania, jak sama nazwa wskazuje, polegają na projektowaniu rozwiązań. Jednym z celów takich technik może być możliwość pozyskiwania wymagań na podstawie analizy pewnej koncepcji projektowej. Jest to dość częste rozwiązanie w przypadku interesariuszy, którzy mają problemy z wyrażeniem swoich potrzeb i oczekiwań. Zdarza się, że interesariusze nie są w stanie wyobrazić sobie abstrakcyjnych wymagań, ale są natomiast w stanie odnieść się do czegoś fizycznego, do konkretnego projektu. Przedstawienie projektu, przykładowo prototypu, pomoże im zrozumieć ich oczekiwania i przekazać nam odpowiednie wskazówki.
Bardzo często wyniki projektowania pozwalają też ujawnić wymagania na pierwszy rzut oka ukryte, zwłaszcza wymagania dotyczące czynników entuzjazmu, jak na przykład użyteczność systemu.
W przypadku technik generowania pomysłów, głównym celem jest opracowanie idei, koncepcji, które w idealnej sytuacji dają potencjał innowacyjnego rozwiązania danego problemu biznesowego. Dobrym przykładem techniki generowania pomysłów jest bardzo popularna technika burzy mózgów. Technika tak polega na tym, że dla zadanego tematu, problemu, zagadnienia organizujemy sesję burzy mózgów, podczas której uczestnicy zachęceni są do generowania pomysłów na rozwiązanie danego problemu. Pomysły te nie są w żaden sposób oceniane podczas sesji, ponieważ istotą burzy mózgów jest umożliwienie wsparcia kreatywności w środowisku pozbawionym ograniczeń. Oznacza to, że uczestnicy burzy mózgów zachęcani są do zgłaszania pomysłów- wszystkich, jakie tylko przyjdą im do głowy. Nawet pomysłów pozornie szalonych czy niewykonalnych. Ważne jest to, aby te pomysły były zgłaszane, ponieważ nawet absurdalny pomysł może spowodować pojawienie się kolejnej kapitalnej koncepcji.
Z kolei technika analogii polega w uproszczeniu na tym, że dla zadanego problemu poszukujemy analogii, czyli sposobu rozwiązania podobnego problemu. Tych analogii możemy poszukiwać w całkowicie innych niż IT obszarach.
Podstawą skuteczności technik kreatywnych jest odpowiedni dobór ludzi. Bardzo dobrze sprawdzają się zespoły złożone z ludzi o różnych doświadczeniach, różnych kompetencjach i różnych punktach widzenia. Ważne jest też, żeby zapewnić odpowiednie środowisko pracy, ponieważ kreatywności nie da się sztucznie wymusić.
Typy pozyskiwanej informacji
Podczas pozyskiwania wymagań pamiętajmy o jednym: pozyskujemy nie tylko informacje dotyczące funkcji, ale również inne rodzaje wymagań. Pozyskiwanie funkcji jest stosunkowo łatwe, natomiast pozyskiwanie wymagań jakościowych może sprawiać problem. Po pierwsze, bardzo często są to wymagania dość oczywiste dla interesariuszy, i z tego powodu nie traktują ich jako wymagania. Na przykład, jeżeli klient zleca nam budowę sklepu internetowego, dla klienta najprawdopodobniej szybkość działania systemu czy niezawodność funkcjonowania są cechami oczywistymi, więc o tym nie powie. Powinniśmy więc we właściwy sposób zaadresować takie ryzyko i przewidzieć w naszych procesach pozyskiwania wymagań również pozyskiwanie informacji o cechach jakościowych. Bardzo dobrą pomocą może tu być na przykład odniesienie do modelu jakościowego, wspomnianego już wcześniej, takiego jak SQuaRE.
Kolejnym problemem związanym z pozyskiwaniem wymagań jakościowych może być kwestia ich mierzalności. Samo pozyskanie wymagań w formie "system ma być użyteczny" czy "wydajny" nie wystarczy. Musimy mieć metrykę, czyli informacje o tym, czego tak naprawdę oczekujemy, jak dane wymaganie ma być zaimplementowane i do jakiego poziomu jakości dążymy.
Tu pojawia się problem, ponieważ bardzo często inżynier wymagań nie ma kompetencji technicznych i nie jest w stanie przewidzieć, jakie informacje mogą być istotne w odniesieniu do konkretnego wymagania. Pamiętajmy jednak, że nie jesteśmy w projekcie sami – na pewno mamy w zespole architekta bądź dewelopera, którzy mogą pomóc nam w pozyskiwaniu bardziej technicznych informacji.
W kolejnej części cyklu omówimy analizę i negocjowanie wymagań.
Comentarios