Nie popełniaj tych błędów przy zbieraniu wymagańigormroz16 stycznia 2023
Każdego roku powstają tysiące nowych produktów, z czego o większości nigdy nie słyszymy, bo okazują się porażką. Listy przyczyn projektowych fuckupów bywają długie, ale niemal na każdej przewijają się problemy związane ze zbieraniem i zarządzaniem wymaganiami. Wydawałoby się, że przecież nie powinno być z tym problemu. Klient (wewnętrzny albo zewnętrzny) przychodzi i mówi, co chce, a zespół to realizuje. Co w tym trudnego? Okazuje się, że całkiem sporo.
Czy zdarzyło się Wam, że w trakcie projektu nagle, jak z kapelusza, wyskoczyło nowe wymaganie, o którym nikt wcześniej nie wspominał? A może w gąszczu potrzeb interesariuszy gdzieś umknęło Wam to jedno, malutkie zdanko, a na końcu okazało się, że bez tego ani rusz? Tym, którym się to nie przytrafiło szczerze zazdroszczę, bo w mojej karierze w roli analityka biznesowego przytrafiło się wiele błędów związanych z wymaganiami. W tym artykule chciałbym się z Wami podzielić moją historią i pokazać, jakie kroki zaradcze wprowadziłem, aby uniknąć podobnych sytuacji w przyszłości.
Wyjaśnijmy sobie jednak na początek, czym jest to wymaganie? Cytując za Moniką Perendyk, wymaganie to:
Warunek lub zdolność potrzebna interesariuszowi do rozwiązania problemu lub osiągnięcia celu.
Warunek lub zdolność, które musi spełniać lub posiadać system lub komponent systemu, spełnienie warunków umowy, normy, specyfikacji lub innych formalnie narzuconych dokumentów.
Udokumentowane przedstawienie stanu lub zdolności jak w punkcie 1 lub 2.
Definicja pochodzi ze standardu IEEE Std. 610.12-1990 (ten został zastąpiony przez standard IEEE/ISO/IEC 24765-2017).
Sam stosuję taką definicję, że wymaganie to coś, co w planowanym rozwiązaniu musi się znaleźć, aby cel mógł być spełniony. Natomiast jeżeli chodzi o wyżej przytoczoną definicję, to wymagania z jakimi mam styczność odnoszą się do tego drugiego punktu, czyli systemu, jaki mamy zbudować.
Zbieranie wymagań nie jest ani łatwe, ani proste. Poznanie wszystkich potrzeb, dotarcie do wszystkich zainteresowanych, którzy mogą wnieść coś do projektu lub mogą wpłynąć na realizację zadań bywa skomplikowane. Kolejną rzeczą, jaką trzeba wziąć pod uwagę to zarządzanie zebranymi wymaganiami.
Jak zarządzać wymaganiami?
Dobrze wiecie, że nie da się spełnić wszystkich życzeń od razu, dlatego też potrzebujemy tym dobrze zarządzać. Tutaj kolejny raz z pomocą przychodzi literatura. W analizie biznesowej wyróżnia się trzy główne kategorie wymagań:
Wymagania biznesowe – odnoszą się do powodów, dlaczego owa inicjatywa została podjęta. Mogą one dotyczyć całej organizacji, obszaru biznesowego, czy też tej konkretnej inicjatywy[2]
Wymagania interesariuszy – opisują potrzeby interesariuszy, które muszą zostać zaspokojone, aby osiągnąć wymagania biznesowe[2]
Wymagania rozwiązania – opisują możliwości i cechy rozwiązania spełniającego wymagania interesariuszy. Zapewniają odpowiedni poziom szczegółowości, aby umożliwić opracowanie i wdrożenie rozwiązania[2]. Tutaj też bardzo często pojawiają się podgrupy:
wymagania funkcjonalne – jest to wymaganie dotyczące wyniku zachowania systemu, który powinien zostać dostarczony przez funkcję systemu[3], oraz
wymagania niefunkcjonalne – wymaganie, które dotyczy jakości tworzonego oprogramowania, które nie zostało określone przez wymagania funkcjonalne[3].
Wyróżniamy dodatkowo czwartą kategorię, w której znajdują się tzw. wymagania przejściowe. To takie wymagania, których potrzebujemy w momencie tworzenia jakiegoś rozwiązania, ale nie są naszymi docelowymi wymaganiami. Jak podaje „BABOK Guide vol.3”, wymagania przejściowe dotyczą takich tematów jak konwersja danych, szkolenia i ciągłość biznesowa.
Dlaczego tak istotna jest znajomość tych kategorii? Ponieważ, jak mogliście zobaczyć, jedne wymagania wynikają z drugich. Zbieranie wymagań powinniśmy zaczynać od punktu pierwszego, czyli od wymagań biznesowych. Następnie przechodzimy do wymagań interesariuszy, a na koniec wydobywamy wymagania dotyczące rozwiązania. Tak to powinno działać. A jak jest w rzeczywistości?
6 najczęstszych błędów popełnianych w projektach przy zbieraniu wymagań
Błąd nr 1: z kwiatka na kwiatek
W rzeczywistości bywa różnie z płynnością wydobywania wymagań. Z pewnością nie raz doświadczyliście sytuacji, gdy w trakcie ważnej dyskusji rozmowa skręca w obszary, gdzie nasz rozmówca zaczyna opowiadać o aspektach, w których czuje się bezpiecznie, ale niekoniecznie o tym, co istotne w danej chwili. Pracując ponad 8 lat jako fizjoterapeuta, wiem, jak moi rozmówcy potrafią poprowadzić rozmowę tak, aby opowiadać o tym, co ich najbardziej interesuje lub uważają za istotne, przy czym dla mnie niewiele wnosi w danym momencie. Podobna sytuacja ma miejsce w trakcie spotkania projektowego. Rozpoczynamy dyskusję otwierającym pytaniem, np. dotyczącym głównych celów danej inicjatywy i w pewnym momencie zbaczamy na inny temat lub rozmawiamy o szczegółach rozwiązania, nie znając jeszcze wszystkich założeń biznesowych. Dlatego też tak istotne jest trzymanie się tej hierarchii kategorii.
Oczywiście nie chodzi też o to, aby odpytywać naszego rozmówcę punkt po punkcie, bo może być to bardzo męczące dla wszystkich. Powinniśmy zostawić przestrzeń na różne wątki i dygresje. Jednak należy pamiętać, jaki przyświęca nam cel danego spotkania i powinniśmy wrócić do właściwego tematu. Pamiętajmy, że mamy do zrealizowania zadanie – ukończyć projekt. Być może zespół czeka na ważne informacje, które masz zdobyć i im dostarczyć lub są jakieś pytania pozostające bez odpowiedzi albo decyzje dotyczące rozwiązania, które muszą zostać podjęte, a nasz rozmówca zaczyna opowiadać o innym, nowym wymaganiu lub pomyśle na nową funkcjonalność. Dlatego też istotne jest, aby do każdej sesji zbierania wymagań odpowiednio się przygotować.
Tutaj z pomocą może przyjść uprzednio przygotowana lista pytań poruszająca kwestie, które chcemy poruszyć. Można też wykorzystać pewne wzorce, jak np. lista rzeczy, o które należy zapytać przed rozpoczęciem projektu lub dokumentacja projektowa, w której również mamy zawarte stałe elementy istotne z naszego punktu widzenia. Taką sesję można oprzeć na rozmowie odnośnie przebiegu procesu, kolejnych kroków, jakie ma przejść użytkownik. Niezależnie co wybierzecie, należy się tego trzymać, tak aby uzyskać ważne dla Was informacje.
Inna sprawa, że Wasz rozmówca może mieć zupełnie inny pomysł na to spotkanie i pomimo dobrego przygotowania z Waszej strony on będzie mówił o innych sprawach, bo przyjechał Was poznać, tak trochę prywatnie, a rozmowa o projekcie jest dla niego drugorzędna. W takiej sytuacji warto płynąć z prądem.
Błąd nr 2: przechodzimy od razu do sedna
Jak widzicie, przebieg spotkania może mieć różne scenariusze. Wasi rozmówcy mogą meandrować po różnych obszarach, które nie do końca odpowiadają Waszym planom. Inna sytuacja ma miejsce, gdy nasz rozmówca przechodzi bezpośrednio do szczegółów rozwiązania, jakie chciałby otrzymać. Zaczynamy rozmową od razu od rodzajów przycisków, jakie mają znaleźć się w aplikacji lub jakie kroki ma wykonać użytkownik na danym etapie, pomijając wyższe kategorie wymagań, jakimi są wymagania biznesowe oraz interesariuszy. Dla lepszego zobrazowania tego, jak to wygląda opiszę sytuację z projektu w jakim uczestniczyłem.
W trakcie współpracy z klientem z branży logistycznej dostaliśmy zlecenie na dostarczenie nowej funkcjonalności dotyczącej śledzenia przesyłek. Taka funkcjonalność to oczywiście podstawa w tej branży. Warto jednak dodać, że produkt klienta był przeznaczony dla dostawców przemysłowych, więc w grę wchodziły różne środki transportu – drogowy, kolejowy, morski i lotniczy. Klient dosyć mgliście przedstawił nam, skąd taka potrzeba biznesowa, ale dosyć szybko zaczął zarysowywać, jak ta nowa funkcjonalność powinna działać, jakie są jej główne założenia. Idea była taka, że fajnie by było, jakby przesyłkę można było śledzić podobnie do działania Flightradar – klikamy sobie na mapie na przesyłkę i znamy jej trasę oraz termin dostawy. W trakcie rozmowy wyszło, że klient miał już przygotowane nawet wstępne zarysy ekranów, jak również był umówiony na rozmowę z designerem, aby zacząć tworzyć poszczególne ekrany. Oczywiście pozwoliliśmy klientowi opowiedzieć o tej potrzebie, ale w pewnym momencie zadaliśmy pytania dotyczące wymagań biznesowych oraz interesariuszy – Kto będzie tego używał? Dlaczego to jest tak ważne, aby to stworzyć? Co się stanie, jeżeli tego nie zbudujemy? Po tych pytaniach klient zaczął się zastanawiać nad sensem budowania tej nowej funkcjonalności, a koniec końców porzucił ten pomysł.
Jak można zauważyć na powyższym przykładzie, pominięcie jednej lub kilku kategorii wymagań może spowodować pewien chaos w projekcie. Możemy narazić klienta lub naszą organizację na „spalenie” budżetu, czasu i zasobów na rzeczy, których tak de facto nikt na końcu nie będzie używał. Dlatego tak istotne jest pilnowanie hierarchii wymagań. Oczywiście nie chodzi o to, aby zawsze zaczynać od wymagań biznesowych i następnie schodzić w dół, odpytując naszego zleceniodawcę punkt po punkcie. Pamiętaj, że warto być elastycznym w trakcie rozmowy, ale trzeba pamiętać, aby zapytać o brakujące klocki.
Jak prowadzić taką rozmowę, gdy nasz rozmówca zaczyna od szczegółu? W tej kwestii polecam zajrzeć do książki Michała Bartyzela “Oprogramowanie szyte na miarę”, gdzie autor opisuje różnego rodzaju techniki prowadzenia konwersacji, aby zebrać ważne dla nas informacje.
Poznaj podstawy zarządzania projektami, bez bullshitu
Jak widać, zdobywanie wymagań może być skomplikowane. Niemniej jednak można się tego nauczyć. Dobrą praktyką jest przygotowanie listy pytań. Inną sprawą jest wykonanie pracy przed samym rozpoczęciem zbierania wymagań.
Według dobrych praktyk przedstawionych w „BABOK Guide vol.3”, zanim przejdziemy do zbierania wymagań mamy jeszcze szereg innych czynności do wykonania. Jedną z nich jest analiza interesariuszy.
Jak już wspomniałem na wstępie, czasem dochodzi do sytuacji, gdy znienacka pojawiają się wymagania istotne dla przebiegu naszego projektu. Bardzo często jest to spowodowane niedostateczną analizą interesariuszy. Pominięcie osoby lub grupy osób, jakie mogą wpływać na nasz projekt może skończyć się dużym zamieszaniem i dostarczeniem wadliwego produktu.
Osobiście, na początku swojej przygody z inżynierią wymagań pominąłem, tak bardzo istotną grupą, jaką są programiści. Tak, tak, właśnie. Uznałem, że przecież dostaną zadanie dobrze opisane, więc nic tylko pisać kod. Za co oczywiście przepraszam moje koleżanki i kolegów. Dosyć szybko okazało się, że popełniłem kolosalny błąd. Przecież mają oni bardzo realny wpływ na projekt. To od tej grupy otrzymamy informacje, jakie są ograniczenia technologiczne proponowanego rozwiązania. Powiedzą nam również, jak bardzo jest to złożony problem i zdecydowanie podpowiedzą, co można zrobić inaczej, szybciej i taniej.
Niemniej jednak bywa i tak, że mamy zrobioną analizę interesariuszy, ale problem znajduje się w zarządzaniu nimi, a szczególnie w komunikacji. Podam przypadek z ostatniego mojego projektu.
Dołączyłem do niego, gdy na ukończeniu był już jeden z ważniejszych nowych modułów, który lada dzień miał ujrzeć światło dzienne. Ciężko mi ocenić, jak przebiegały prace odnośnie zbierania wymagań dotyczących tego modułu. Niemniej jednak po wypuszczeniu pierwszej wersji – na szczęście na użytek wewnętrzny – otrzymaliśmy bardzo dużo informacji zwrotnych dotyczących jakości tego modułu, a także funkcji, jakich w nim brakuje. Co się okazało? Po rozpoczęciu analizy wyszło, że w wewnątrz organizacji są osoby, które mają wiedzę na temat tego, jakie procesy powinien ten moduł obsługiwać, aby był konkurencyjny wobec innych rozwiązań. Efekt końcowy mamy taki, że albo dostarczymy klientom komercyjnym najprostszą wersję, albo opóźnimy mocno wydanie i przerobimy już istniejące rozwiązanie. Jak można zauważyć, są to trudne sytuacje, które wpływają na produkt i pieniądze klienta, a można było ich uniknąć.
Błąd nr 4:User Story to nie wymaganie
Inna, dosyć często spotykana sprawa to spisanie wymagań w formie User Story.
W świecie zwinnego tworzenia oprogramowania ta forma zapisu jest dobrze znana. Bardzo często zdarza się, że efektem końcowym sesji zbierania wymagań, najczęściej w formie warsztatów, jest tzw. User Story Map, czyli lista historyjek użytkownika ułożona wedle większych części – epików i być może jeszcze podzielona na kolejne wersje wydania.
Tak czy inaczej, jest takie wrażenie, że mamy już wszystko zrobione i wszystko wiemy. Niestety, trzeba pamiętać o tym, że historyjka użytkownika (User Story) to nie jest wymaganie! To jest tylko wstęp do dyskusji na temat tego, jak to powinno działać. To w trakcie dyskusji nad ogólnym założeniem zadania wychodzi, jakie wymagania kryją się w tej historyjce użytkownika. Nagle okazuje się, że zwykły opis User Story związany z rejestracją nowego użytkownika, taki jak ten: „Jako nowy klient, chcę się zarejestrować do serwisu, aby móc zbierać punkty lojalnościowe”, może skrywać wiele wymagań odnośnie polityki haseł, podania danych takich jak telefon, adres albo podanie wieku użytkownika, czy nawet zgód, jakie trzeba zaznaczyć.
Koniec końców może się okazać, że tych wymagań jest tak dużo, że warto wtedy podzielić zadanie na mniejsze kawałki. Należy więc zapamiętać, że User Story to nie jedno wymaganie, a wyłącznie wstęp do nich.
Błąd nr 5: brak uzasadnienia biznesowego
Jeżeli jesteśmy już w temacie opisywania historyjek użytkownika, to trzeba również wspomnieć o jednym z częstszych błędów, jakie ma miejsce. Jest to powiązane z tematem, który już wcześniej poruszyliśmy, czyli pomijaniem kategorii wymagań. Z moich obserwacji wynika, że historyjki użytkownika opisywane są z pominięciem bardzo istotnej części. Wedle literatury, historyjka użytkownika, powinna składać się z:
aktora, który wykonują tę akcję,
akcji, jaką ma do wykonania aktor,
efektu wykonanej akcji.
Niestety bardzo często zapominamy o ostatnim elemencie – uzasadnieniu biznesowym. Wiemy, jaki aktor i co ma do wykonania, ale pomijamy informację, dlaczego to jest istotne z punktu widzenia tego aktora. Jest to o tyle istotne, że może dać nam odpowiedź, czy taka historyjka użytkownika ma sens i czy jest konieczna na tym etapie realizacji projektu. Może się okazać, że czytając tę wartość biznesową, prowadzący projekt uznają, że na tym etapie nie jest to istotne i może poczekać na późniejszy termin realizacji. Osobiście, od pewnego czasu do opisu zadania do realizacji wprowadziłem punkt potrzeba biznesowa (ang. business needs).
W ostatnim moim projekcie klient miał bardzo fajny proces analizowania rozwoju swojego produktu. Każdy mógł zgłosić pomysł na nową funkcjonalność. Wystarczyło użyć pewnej formatki, opisać problem lub potrzebę. Następnie było to oceniane przez inne osoby w firmie i wyceniano takie zadania na podstawie pewnej formuły. Na tej podstawie zapadała decyzja na ile jest to istotne z punktu widzenia biznesu. Jednak w całym tym procesie najtrudniejszy moment był na samym początku. Opis problemu lub potrzeby, jaką zgłaszali interesariusze bardzo często nie zawierał uzasadnienia biznesowego. Ludzie pisali, co ich boli albo co by chcieli dostać w produkcie, ale nie było słowa, jak to wpłynie na cały biznes. Postanowiłem, że wprowadzę jednozdaniowy opis potrzeby biznesowej wynikający z umieszczonego opisu. Było to jedno z trudniejszych zadań, ponieważ trzeba było odkryć, co tak naprawdę ta nowa funkcjonalność ma wnieść do naszego produktu. Jedno zdanie, a naprawdę wiele zmienia.
Błąd nr 6: zapominamy o wymaganiach pozafunkcjonalnych
Ostatnim na mojej liście błędów, jakie popełniamy w trakcie zbierania wymagań jest: pominięcie wymagań poza lub, jak niektórzy mówią, niefunkcjonalnych. Tak, tak. Każdemu się pewnie zdarzyło zapomnieć zapytać o właściwości projektowanego rozwiązania. Oczywiście nie chodzi tu o odpowiedzi typu: „chcę mieć szybki system” albo „ma być funkcjonalny”. Musimy dokładnie określić, co to znaczy szybki i funkcjonalny. Dla każdego z nas te słowa mogą oznaczać zupełnie co innego. Dlatego tak istotne jest doprecyzowanie tego.
Istnieje 8 głównych kategorii wymagań pozafunkcjonalnych[4].
Ostatnimi czasy na szczyt tej listy wysunęła się tzw. dostępność. Jest to szczególnie istotne w dzisiejszych czasach, gdy projektujemy rozwiązania informatyczne. Należy pamiętać o różnych grupach społecznych, które mierzą się z pewnymi ograniczeniami.
Innymi elementami tych wymagań są wydajność, kompatybilność, utrzymalność. W tej grupie mogą się pojawić wymagania dotyczące lokalizacji przetrzymywania danych, jeżeli mówimy o rozwiązaniach chmurowych. Niektórzy klienci wymagają, aby ich dane były przetrzymywane na terenie Unii Europejskiej i nigdzie indziej.
Kolejnym punktem, który może umknąć naszej uwadze to responsywność naszego rozwiązania. Mieliśmy ostatnio w firmie, w której obecnie pracuję taką sytuację, że w trakcie trwania projektu klient stwierdził, że jednak te ekrany, które już powstały mają posiadać możliwość korzystania z nich także na urządzeniach mobilnych (o czym wcześniej nie było mowy). Nierzadko się zdarza, że w kontrakcie, jaki podpisujemy z odbiorcą naszej pracy znajduje się punkt o dostępności usługi, czyli przez jaki czas, procentowo, system ma być dostępny dla użytkowników końcowych. Tak więc warto pamiętać o wymaganiach niefunkcjonalnych.
Zbieranie i zarządzanie wymaganiami w projektach – podsumowanie
Zbieranie wymagań nie jest łatwym procesem. To też nigdy nie jest skończony proces. Zdarzają się sytuację, gdy konkurencja wypuści na rynek podobne rozwiązanie i musimy reagować na te zmiany. Może też się zdarzyć, że zmienią się nam przepisy regulacyjne i będziemy musieli dostosować nasz produkt do tych zmian. W trakcie zbierania wymagań możemy natrafić na osoby nam przychylne do planowanego nowego rozwiązania i chętnie dzielić się z nami informacjami, ale możemy też mieć interesariusza negatywnie nastawionego do tych zmian i będzie ukrywał przed nami cenne informacje. Jeżeli prowadzimy wywiad lub warsztat, musimy liczyć się z tym, że dyskusja skręci nam w nie tę stronę, jaką oczekiwaliśmy. Niemniej jednak dobre przygotowanie do etapu zbierania wymagań, dobra analiza interesariuszy, trzymanie się hierarchii wymagań może nam ułatwić zbieranie wymagań. Mam nadzieję, że po przeczytaniu tego artykułu uniknięcie błędów, jakie sam popełniłem w swojej jeszcze krótkiej karierze, a projekty, jakie realizujecie będą kończyć się sukcesem.
Autor tekstu: