Zarządzanie wymaganiami

Najczęściej pomijany etap w projektach. Moim zdaniem z dwóch powodów. Mało który sponsor projektu ma świadomość jakie ryzyka niesie brak wiedzy o otoczeniu projektu, bo jako sponsor już uwierzył w jego sukces (choroba znana jako emocjonalne podejście do własnych pomysłów). Drugi powód to fakt, że wielu interesariuszy projektu ma interes w tym, by te ryzyka nie zostały ujawnione. ten etap to pierwszy element, którego realizacja napotyka opory, a moim zdaniem powinien być wykonany nie raz przez zawarciem głównej umowy, gdyż może się okazać, że projekt jest z góry skazany na porażkę.

Z perspektywy każdego systemu (system to nie tylko oprogramowanie, to także system zarządzani jakością czy nowy system rabatowy) należy opracować model uwzględniający tych, którzy będę z niego bezpośrednio korzystali (aktorzy) oraz tych, którzy odczują skutki jego wdrożenia a mają wpływ na jego powstawanie. Taka analiza wpływu pozwoli ocenić ryzyka generowane przez każdego interesariusza i właściwie na nie zareagować. Jednym z produktów takiej analizy jest plan komunikacji. Mamy więc na tym etapie produkty:

• model otoczenia systemu (projektu),
• analiza ryzyka,
• plan komunikacji.

Etap drugi analiza i specyfikowanie wymagań

Ten etap jest największą częścią projektu analitycznego. Jak zebrać wymagania to tema rzeka. Ogólnie metody analizy i specyfikowania wymagań można podzielić na dwie grupy:

• metody formalne,
• metody nieformane.

Pierwsze opierają się na zastosowaniu sformalizowanych systemów pojęciowych i weryfikowalnym procesie analitycznym czyli po protu na stosowaniu określonych notacji (z reguły BMM i BPMN) oraz analizy systemowej.

Drugie bazują na spotkaniach, warsztatach, moderowanych sesjach. Ich główną cechą jest uznanie, że tak zebrane dane są wiarygodne: uznanie a priori, że zamawiający się nie myli i ma rację. Jakkolwiek to brzmi, nie jest to takie oczywiste. Wykazanie niesprzeczności tak zebranych wymagań jest wykonalne ale już ich spójność i kompletność jest nie do wykazania bo nie istnieje test kompletności „opowiadania”, skoro nie można wykazać (przetestować) kompletności to tym bardziej nie da się wykazać spójności.

Metody formalne bazują na analizie „od ogółu do szczegółu” organizacji i opracowaniu jej kompletnego modelu (na wymaganym dla danej analizy poziomie szczegółowości). Model taki staje się narzędziem testowania wymagań, np. mając modele wszystkich procesów biznesowych możemy sprawdzić, czy nie pominęliśmy jakichś istotnych działań, które wymagały by ujęcia w wymaganiach.

Bardzo ważna rzeczą jest jest podzielenie wymagań na biznesowe i funkcjonalne bo to nie to samo (czytaj Produkty w procesie analizy wymagań). Pani Raczko przywołała definicję Rona Ross’a, jednak chyba zbyt uprościła oryginał sprowadzając słowo „system” do „oprogramowanie”. Znany mi oryginał brzmi:

We define a business requirement as “something called for or demanded by a business model that a system model must support” We define a system model as follows a model that provides a design for an automatable system that is computationally competent. (źr. What’s the Difference Between Business Requirements and Functional Requirements?)

Rzecz w tym, że słowo „computational” oznacza „wyliczalność” w rozumieniu da się wyliczać automatycznie (raczej w sensie algorytmicznym). To nie koniecznie musi być komputer, mogą to być określone do wdrożenia procedury (przypomnę, że przedmiotem projektowania może być system zarządzania jakością lub system rabatowy sprzedaży). Warto zwrócić uwagę, że Ross nie użył słowa „requirement” (wymagania) w odniesieniu do systemu a „model”. Ross także słusznie zauważa, że wikipedia zrównuje pojęcie wymagać z wymaganiami funkcjonalnymi co jest i moim zdaniem błędem. Prawdopodobnie to uproszczenie w prezentacji zostało dokonane z uwagi na tematykę konferencji, uważam jednak, że jest groźne. Mam wszystkie książki Ross’a i wydaje mi się, że nie zrównuje on pojęcia system z oprogramowaniem.

Wymagania biznesowe w stosunku do wymagań „systemowych” cechuje inna bardzo ważna różnica: treść wymagań biznesowych MUSI być w 100% zrozumiała dla zamawiającego, napisana jego językiem. Model systemu, jako wymagania na system, może być (i z reguły jest) już „wiedzą tajemną” zrozumiałą tylko dla dostawcy systemu.

Zarządzanie zmianą wymagań

To kolejne niechciane dziecko w projektach. Jeżeli zgodzimy się, że zmiana wymagań jest „normą” to brak wiedzy (zapisów) o tych zmianach potrafi zabić projekt. Problem, który ja widzę w wielu projektach to: im łatwiej zgłosić i egzekwować zmianę w wymaganiach tym więcej tych zmian jest. Nie chodzi o to by tych zmian zakazywać, chodzi o to by były one za każdym razem przemyślane, a chodzi głownie o wpływ zmian na termin i budżet projektu.

Ja także widzę tu dużą różnicę. Z moich obserwacji wynika, że projekty, w których zastosowano zwinne metody zarządzania nimi, bardzo często tracą kontrolę nad zakresem projektu. Po pierwsze dlatego, że wprowadzanie zmian bez ich dokumentowania i świadomego przeprojektowywania systemu, prowadzi do niekontrolowanego przyrostu pracy. Po drugie projekty zwinne cechuje to, że nie mają opisanego zakresu projektu a jedynie wizje produktu jaki ma powstać, w efekcie jedynym elementem projektu jakim zarządza kierownik projektu jest praktycznie tylko budżet gdyż zakres jako taki nie istnieje a harmonogram to tylko na bieżąco definiowane etapy.



Uogólniając nieco: w metodach klasycznych istnieje sztywna granica pomiędzy fazą analizy i specyfikowania wymagań a fazą ich implementacji. W metodach zwinnych mamy pętlę zgłaszania zmian (i nowych wymagań), która z reguły nie jest dokumentowana.

Czy to powoduje, że w metodach klasycznych odcinamy sobie możliwość zastosowania nowych pomysłów? Absolutnie nie, nowe pomysły są materiałem na nowy projekt. Zgłaszane zmiany są analizowane i albo są akceptowane bo mają mały lub żaden wpływ na budżet i harmonogram, albo są odkładane na etap „eksploatacji i rozwoju” w cyklu życia produktu (nowy cel projektu i nowy projekt). Pani Raczko stwierdziła, że jej doświadczenie wskazuje, że projekty prowadzone metodą klasyczną są z reguły szybciej kończone, ale dotyczy to raczej większych projektów. Moje doświadczenia są analogiczne. Granicą którą kiedyś obliczałem, po przekroczeniu której warto zrezygnować z metod zwinnych, jest budżet przekraczający 100 tys. zł. Jak widać nie są to aż tak wielkie projekty. Jednak dla każdej firmy utrata 100 tys. zł (nieudany projekt) stanowi bardzo odczuwalny wydatek.

Jak wygląda taka zmiana?



Kluczowe korzyści to kompletna dokumentacja projektu, jest ona nie tylko pomocna po jego zakończeniu, ale także w trakcie jego trwania, gdyż stanowi narzędzie kontroli budżetu. Bardzo złym miernikiem postępu projektu jest deklarowanie zużywanych zasobów (roboczogodziny lub dni), w zwinnych metodach to w zasadzie jest to jedyny miernik. Jeżeli zaś dysponujemy dokumentacją każdej zmiany, jest ona znacznie bardziej wiarygodnym miernikiem postępu projektu, gdyż zarządzamy projektem zadaniowo a nie zasobowo. W metodach zwinnych nie da się wykonać analizy wpływu zmiany na cały projekt, bo nie istnieje dokumentacja całego systemu (jego model), on dopiero powstaje w trakcie trwania projektu. Tak więc w zasadzie nie istnieje pojęcie analizy ryzyka zgłaszanej zmiany w metodach zwinnych. W metodzie klasycznej, mamy udokumentowany, każdy etap projektu co, poza ewentualnymi sporami o zakres, pozwala panować nad spójnością i niesprzecznościa zgłaszanych zmian wymagań, gdyż specyfikacja – jako całość – przez cały czas trwania projektu (a nie tylko na początku) ma być kompletna, spójna i niesprzeczna.

Na koniec narzędzia

W tej kwestii jedno jest pewne: jeżeli już uznamy, że wymaganiami zarządzamy, to robienie tego narzędziami biurowymi (edytor tekstu, arkusz kalkulacyjny, proste oprogramowanie do diagramów typu Visio) strasznie podniesie pracochłonność projektu (czytaj o sabotażu dokumentacyjnym). Klienci, którzy uważają, że wolno użyć tylko narzędzi, których sami na co dzień używają, sami sobie robią krzywdę, bo zgłaszanie zmian nie polega na modyfikacji cudzych dokumentów projektowych, a na tworzeniu własnych (czytaj o zgłaszaniu zmian).

Biorąc pod uwagę fakt, że wymagań w średnim nawet projekcie jest co najmniej kilkadziesiąt, utrzymanie ich spójności i analiza wpływu każdej zmiany na cały projekt staje się benedyktyńską pracą, najczęściej szybko zarzucaną właśnie z powodu pracochłonności (a nie braku jej sensu). Dlatego w zasadzie brak narzędzia CASE do zarządzania wymaganiami (są z reguły częścią narzędzi do analizy i modelowania) w zasadzie w moich oczach dyskwalifikuje usługodawcę.

Z powyższego płynie także kolejny wniosek: autor specyfikacji wymagań, powinien kontynuować projekt jako osoba zarządzająca wymaganiami, i bardzo dobrze jest jeżeli pracuje po stronie Zamawiającego, gdyż stanowi naturalny mechanizm kontroli pracy dostawcy np. oprogramowania. Zamawiający nie ma innej możliwości realnego, merytorycznego nadzoru nad dostawcą, to Zamawiający powinien zarządzać wymaganiami bo to w końcu jego wymagania!



Źródło: www.it-consulting.pl
Autor: Jarosław Żeliński