Rozpoznać teren

Aby projekt informatyczny zakończył się sukcesem, musimy przede wszystkim określić co jest jego celem oraz jakie elementy projektu są najbardziej istotne dla jego osiągnięcia. To właśnie kryje się pod określeniem "zarządzanie wymaganiami".

Aby projekt informatyczny zakończył się sukcesem, musimy przede wszystkim określić co jest jego celem oraz jakie elementy projektu są najbardziej istotne dla jego osiągnięcia. To właśnie kryje się pod określeniem "zarządzanie wymaganiami".

Najogólniej rzecz ujmując projekt (w tym projekt informatyczny) zakończy się sukcesem, jeśli zostanie zrealizowany w uzgodnionym zakresie, czasie i budżecie. Czasami okazuje się jednak, że mimo spełnienia wymienionych warunków efekt projektu nie satysfakcjonuje jego odbiorców czy użytkowników. Wiąże się to zazwyczaj z tym, że niewłaściwie zostały określone te cele projektu, które są najbardziej istotne dla jego efektów z punktu widzenia odbiorcy.

Dzieje się tak zazwyczaj dlatego, że projekt został niewłaściwie rozpoczęty. W nieprawidłowy sposób zostały rozpoznane cele projektu, źle został opisany jego zakres i rozwiązania, które ma dostarczyć. W przypadku projektu informatycznego możemy powiedzieć, że źle zostały przygotowane wymagania do projektu.

Według kwartalnych raportów "Chaos Chronicles", przygotowywanych przez amerykańską firmę analityczną i doradczą The Standish Group, trzecim w kolejności istotnym powodem porażek we wdrożeniu systemu informatycznego jest niewłaściwe, niekompletne zidentyfikowanie wymogów. Na czynnik ten wskazuje ok. 12% badanych. Następnym czynnikiem, wymienianym przez ok. 11% badanych, jest zmiana wymagań i specyfikacji projektu w trakcie jego realizacji. Jeśli dalej przyglądać się statystyce, to działania związane z określaniem, opisaniem, uzgadnianiem i wyjaśnianiem wymogów zajmują ok. 40% czasu realizacji całości projektu. Natomiast koszty późniejszych poprawek błędów są olbrzymie, mogą sięgnąć nawet 30% wartości projektu i w ostateczności stać się powodem przerwania realizacji systemu informatycznego.

Jak już napisałem, na efekt projektu ma wpływ sposób jego rozpoczęcia. O ile (jak powiedział pewien zapomniany polityk) "prawdziwego mężczyznę poznaje się po tym jak kończy, a nie jak zaczyna", to dobry projekt poznaje się jednak po tym jak się go rozpoczyna. Rozpoczęcie projektu to analiza faktycznych potrzeb, celu jego realizacji. W przypadku projektów informatycznych celem jest dostarczenie systemu informatycznego realizującego pożądane przez zlecającego funkcjonalności, działającego w określony sposób. Zbiór tych wszystkich potrzeb nazywamy ogólnie wymaganiami.

Sztuka zbierania

Co należy zrobić, aby etap pozyskiwania wymagań został uwieńczony sukcesem, by wykonana praca miała pozytywny wpływ na zakończenie projektu? Pomóc tutaj mogą pewne umiejętności i narzędzia, którymi trzeba posłużyć się na tym etapie projektu. Można podzielić je na dwie grupy: "miękkie" oraz "techniczne". O ile umiejętności techniczne (odpowiednie narzędzia czy metodologie zbierania wymagań) pomagają w pracy, o tyle niezbędne umiejętności "miękkie" powodują, że zebrane wymagania będą miały odpowiednią jakość.

"Miękkie" umiejętności i narzędzia służą do zapewnienia odpowiedniego zaangażowania osób biorących udział w zbieraniu wymagań. Pomagają zmotywować uczestników, wskazać im właściwe obszary działania, uzyskać odpowiedniej jakości efekty pracy. Konieczne jest z jednej strony odpowiednie ustawienie zakresu obowiązków i odpowiedzialności, z drugiej zadbanie o to, aby uczestnicy posiadali właściwą wiedzę o realizowanych zdaniach i konsekwencjach wprowadzanych rozwiązań. Osoby biorące udział w zbieraniu i opisywaniu wymagań powinny być właścicielami tych informacji. Muszą czuć sens wykonywania takiej pracy, muszą rozumieć informacje, które zbierają. Powinny mieć rzeczywisty wpływ na ich kształt oraz możliwość decydowania o zakresie prac, priorytetach. Nie mogą być "obdarowywani" wymaganiami, muszą sami je zgłaszać.

Język, za pomocą którego wymogi te będą spisywane, nie może być technicznym czy biznesowym żargonem, zrozumiałym tylko dla niektórych osób uczestniczących w projekcie. Musi w sposób jasny i jednoznaczny opisywać, co ma być efektem projektu, co ma realizować system informatyczny, jakie funkcjonalności ma udostępniać. Trzeba podkreślić stwierdzenie, że wymogi mają opisywać czego chce użytkownik, a nie jak. Rozmowy o nowych rozwiązaniach informatycznych nierzadko zaczynają się od stwierdzenia ze strony zleceniodawcy, że "chciałbym mieć aplikację napisaną w Visual Basicu, w której będę mógł..." (tu następuje lista życzeń). Przyjęcie zlecenia sformułowanego w taki sposób jest najprostszym sposobem doprowadzenia projektu do klęski.

Nowy proces wraz z nowym systemem

W trakcie budowania wymagań do nowego systemu trzeba też uświadomić przyszłym użytkownikom, że wprowadzone rozwiązanie zmieni sposób ich pracy. Paweł Szulc i Robert Ganiowski w jednym z numerów CXO bardzo celnie opisali, jaki wpływ mają rozwiązania informatyczne na sposób prowadzenia biznesu: "System informatyczny musi być elementem procesów biznesowych zamawiającego, jednak wewnętrzna organizacja tych procesów powinna być inna od tej sprzed wdrożenia systemu informatycznego. Jeżeli zinformatyzujemy kroki aktualnego procesu, uzyskamy niewielkie korzyści wynikające z ich automatyzacji, a koszty inwestycji mogą się nie zwrócić. Dzięki zastosowaniu nowoczesnych technologii informatycznych pewne dotychczas wykonywane akcje mogą być całkowicie wyeliminowane lub zastąpione mniejszą liczbą ekwiwalentnych. Wiedząc, co może zaoferować informatyka (to wiedzą informatycy) i mając w pamięci wartości, jakie firma zamawiająca usługę IT chce dostarczać swoim klientom (to wie zamawiający), można stworzyć zupełnie nowy proces. Ale zadania tego żadna ze stron kontraktu nie zrealizuje samodzielnie". Jak z tego wynika, bardzo ważne jest zapewnienie właściwej współpracy obu stron (informatyki i biznesu) już od początku projektu. Od fazy budowania wymagań trzeba przyglądać się, w jaki sposób SI może zmienić sposób prowadzenia biznesu i jak wpłynie na jego przyszły kształt.

Zbierając wymagania do systemu informatycznego trzeba zastanowić się też nad tym, czy nowe rozwiązanie nie pogłębi istniejących problemów. Jak słusznie zauważył George Sifri, konsultant zajmujący się zarządzaniem projektami: "Automatyzacja procesu, który nie jest efektywny i przenoszenie tej nieefektywności na system informatyczny spowoduje, że proces stanie się jeszcze bardziej nieefektywny".

Nie przesadzić

Ważnymi punktami tworzenia listy wymagań dla budowanego rozwiązania informatycznego jest zamknięcie listy wymogów oraz jej spriorytetyzowanie. Aby mogło się to odbyć bez kłótni i pretensji między np. przedstawicielami różnych wydziałów, których dotknie realizacja systemu, przed rozpoczęciem zbierania wymagań należy uzgodnić, jakie potrzeby organizacji będzie zaspokajał system, a jakich (przynajmniej w pierwszej wersji) nie obejmie oraz jakie obszary i funkcjonalności znajdą się w jego zakresie, a które zostaną pominięte. Często zdarza się, że pod pozorem realizacji systemu informatycznego dla konkretnego celu "przemycane" są wymogi spoza danego obszaru. Niby nie ma w tym nic złego ("jak już coś robimy..."), ale powoduje to potencjalnie nieograniczone zwiększenie listy zadań do wykonania. Wspomniany dokument (lista wymagań) pozwala jasno wskazać, czym projekt będzie się zajmował, a czym nie. Jeśli tego nie zrobimy, możemy nigdy nie zakończyć projektu, gdyż zawsze znajdą się jakieś mniejsze czy większe potrzeby, które zleceniodawcy będą chcieli zaspokoić w ramach realizacji systemu.

Drugą ważną rzeczą jest priorytetyzacja wymagań. Każda lista wymogów powinna być tak zbudowana, aby najwyższy priorytet otrzymały te funkcjonalności, które są niezbędne z punktu widzenia procesu, który będzie wspomagany przez budowany system, bez których proces nie będzie mógł być realizowany. Pozostałe funkcjonalności można podzielić na dwie grupy: takie, które znacząco podniosą wydajność całości procesu lub usprawnią zarządzanie nim oraz takie, które usprawniać będą realizację poszczególnych obszarów, podprocesów. O ile pierwszą grupę wymagań po prostu trzeba zrealizować, o tyle o realizacji pozostałych można pomyśleć w dalszej kolejności, np. w kolejnej generacji systemów. Takie podejście pozwoli racjonalnie rozłożyć koszty realizacji systemu oraz skrócić czas, w jakim będziemy mogli otrzymać narzędzie wspierające organizację.

Niewłaściwe rozpoznawanie potrzeb, dla zaspokojenia których ma być realizowany system informatyczny, jest niestety częstym zjawiskiem. Osoby biorące udział w projekcie z ramienia organizacji zlecającej jego wykonanie często nie są w stanie samodzielnie zidentyfikować, co tak naprawdę ma dać planowany system i jakie problemy organizacji ma rozwiązać. Powodem tego może być to, że osoby budujące wymagania nie posiadają odpowiednich umiejętności analitycznych, nie potrafią np. odróżnić przyczyny wystąpienia problemu od jego obserwowalnego rezultatu. "Najpoważniejszym wynikiem złego procesu pozyskiwania wymagań jest to, że twórcy oprogramowania rozwiązują nieprawidłowy problem. Jest to gwarancją niepowodzenia projektu" - pisze Radosław Adamus w książce "Wprowadzenie do zasad pozyskiwania wymagań". Dlatego ważna jest tutaj rola analityka biznesowego, który pomoże rozpoznać, jakie wymogi powinny być wyartykułowane przy budowaniu systemu, aby efektywnie rozwiązał faktyczne problemy organizacji.

Kwestia kompetencji i wyobraźni

Jest bardzo istotne, aby kompetencje w konstruowaniu wymagań do systemu były zarówno po stronie zleceniodawcy, jak i po stronie wykonawcy. Jeśli nawet zleceniodawca jest w stanie przygotować wymogi w sposób właściwy, w pełni kompletny i profesjonalny, a po stronie wykonawcy natknie się na osobę niekompetentną, efekty tego mogą być dla projektu katastrofalne. Jeśli zleceniobiorca nie zrozumie przedstawionych mu wymogów, jeśli nie będzie potrafił wspólnie ze zleceniodawcą rozpoznać najważniejszych z nich i do nich dostosować planu pracy, to znacząco zmaleją szanse na zakończenie projektu sukcesem.

Termin "zarządzanie wymaganiami" okazuje się bardzo egzotyczny w polskich warunkach. O ile znaczenie właściwego zarządzania wymaganiami biznesowymi jest powszechnie doceniane w wielu firmach w Stanach Zjednoczonych, Europie Zachodniej czy Azji, o tyle w Polsce temat ten jest niestety niedoceniany. O stosunku prowadzących projekty do zarządzania ich zakresem (czyli de facto wymaganiami) mówi chociażby wynik ankiety realizowanej na stronach polskiej sekcji Project Management Institute, gdzie tylko 8% głosujących wskazało, że obszar ten jest interesujący w kontekście wiedzy o zarządzaniu projektami.

Co gorsza, temat ten jest zupełnie nieobecny na wielu szkoleniach związanych z prowadzeniem projektów informatycznych. Mówi się o tym, że trzeba zbierać wymogi biznesowe i w jaki sposób to robić, natomiast nie przekazuje się wiedzy, jak należy właściwie zarządzać wymogami. Analizujący koszty wykonania systemu informatycznego szukają oszczędności po stronie dostawców sprzętu czy oprogramowania. Rzadko kiedy dbają o to, aby jasno, ściśle określić zakres prac niezbędnych do wykonania, aby zrobić to, co jest naprawdę potrzebne, co będzie rzeczywiście wspierać prowadzoną działalność. Tutaj kryją się prawdziwe źródła kosztów oraz możliwości oszczędności. Od tej fazy zależy całościowy efekt finansowy projektu. I taki jest prawdziwy sens właściwie realizowanego zarządzania wymaganiami.


TOP 200