W zasadzie wiadomo, co robimy nie tak. Badaniem przyczyn porażek projektowych zajmują się organizacje uznane na całym świecie (m.in. Standish Group i jej słynny już Chaos Report), informując, że głównymi powodami problemów są m.in. niekompletne wymagania, niedostateczne zaangażowanie użytkowników, brak zasobów i wsparcia kierownictwa, nierealistyczne oczekiwania, niedoszacowane estymacje oraz problemy z planowaniem. Czynniki te nie zmieniają się niemalże od lat. Badania innych organizacji również wskazują na część z tych czynników jako wywierających największy negatywny wpływ na powodzenie realizowanych projektów.

Analizując statystyki i dostępną dokumentację, można wyciągnąć wniosek, że większość problemów występujących podczas realizacji skomplikowanych projektów jest związana z samym zarządzaniem projektem. Czynniki obciążone, zdawałoby się, najwyższym ryzykiem – technologiczne – to zaledwie niewielki odsetek przyczyn niepowodzeń projektów. Skąd taka rozbieżność? Dziedzina zarządzania projektem istnieje od wielu lat – nie jest ani nowa, ani nieusystematyzowana. Istnieje wiele wytycznych, praktyk, standardów opisujących reguły dobrego zarządzania projektem. Dlaczego więc od lat tak wiele problemów występujących podczas realizacji projektów IT wynika z faktu zarządzania nimi? Czyżby odpowiedź brzmiała: „ponieważ nie uczymy się na błędach”? Może przyczyny problemów są wciąż te same, ponieważ nigdy poważnie ich nie zbadaliśmy. Często widzimy tylko skutki i w panice próbujemy gasić pożar, kiedy już wybuchnie, nie zastanawiając się, czemu pożary występują tak często i co je powoduje. Może lepiej nie budować kolejnego domu ze słomy i papieru, zamiast dziwić się, że znowu  nie wytrzymał najmniejszej próby ognia? Podsumowując różne źródła i statystyki, można wskazać kilkanaście notorycznie powtarzających się czynników ryzyka.

Nie taka inżynieria wymagań straszna

Jednym z kluczowych obszarów zawsze wymienianym na szczycie listy czynników, które mogą wpływać na realizację naszych skomplikowanych produktów lub projektów, jest komunikacja, współpraca z klientem i dziedzina określana mianem inżynierii wymagań, która obejmuje wszystkie wymienione powyżej zagadnienia.

Pierwsze definicje opisują inżynierię wymagań jako proces określania, dokumentowania i zarządzania wymaganiami, jakie powinno spełniać produkt, oprogramowanie lub tworzony system [Sommerville]. Inżynieria wymagań zajmuje się wieloma zadaniami – od określania źródeł wymagań, przez analizę i specyfikację wymagań, przez zapewnienie i kontrolę jakości. Wymagania dotyczą nie tylko produktu informatycznego, ale i dowolnego innego produktu, dlatego też pełna definicja inżynierii wymagań powinna brzmieć – proces określania, dokumentowania i zarządzania wymaganiami na  rozwiązanie. 

W ramach inżynierii wymagań można wyróżnić specyficzne czynności. Niektóre z nich są integralną częścią procesów opracowywania wymagań, inne stanowią czynności pomocnicze dla procesów zarządzania wymaganiami.

Typowe czynności opracowywania wymagań to:

• identyfikacja wymagań,
• analiza i negocjacja wymagań,
• specyfikacja (dokumentacja) wymagań,
• walidacja i weryfikacja wymagań.

​​​

Typowe czynności zarządcze wykonywane w ramach inżynierii wymagań to:

• definiowanie i utrzymywanie możliwości śledzenia,
• zapewnienie jakości,
• zarządzanie konfiguracją i zmianami.

Czynności inżynierii wymagań są ściśle powiązane z innymi procesami wykonywanymi w ramach wytwarzania/utrzymania produktu. Inżynieria wymagań:

• może być postrzegana jako kontynuacja analizy biznesowej. Potrzeby i cele biznesowe ustalone w trakcie analizy biznesowej stanowią podstawę do opracowania wymagań przetwarzanych przez różne czynności inżynierii wymagań. Powstały w wyniku implementacji wymagań produkt jest przedmiotem kolejnej analizy biznesowej, ponieważ wdrożony, działający produkt może być źródłem kolejnych potrzeb biznesowych.
• dostarcza podstaw do planowania i organizacji projektu, ma więc bezpośredni wpływ na sposób zarządzania projektem. Ponadto same wymagania (projektowe) mogą narzucić metodę i narzędzia zarządzania projektem.
• stanowi jeden z najważniejszych fundamentów planu zapewnienia jakości w projekcie, ponieważ same wymagania mogą określać wymagany dla produktu minimalny poziom jakości (np. wymagania niezawodności czy bezpieczeństwa).
• dostarcza produktów służących opracowaniu projektu planowanego rozwiązania, jest wiec ściśle powiązana z projektowaniem oraz implementacją. Produkty inżynierii wymagań są też podstawą, a zarazem przedmiotem testów, mają więc również silne relacje z testowaniem.
• wnosi wkład do procesów zarządzania ryzykiem – inżynieria wymagań prowadzona adekwatnie do potrzeb danego projektu i okoliczności minimalizuje ryzyko projektowe, dostarczając wysokiej jakości materiału do dalszych prac projektowych; ponadto wymagania mogą wnosić pewne ryzyka, które należy uwzględnić w planie zarządzania ryzykiem.

Wsparcie dla inżynierii wymagań dzięki platformie IBM Engineering

Podstawą opracowania procesu prowadzenia projektów dopasowanego do organizacji są odpowiednio dobrane dobre praktyki, metody zarządzania oraz efektywne narzędzia wspierające. Ich wybór dla wielu organizacji stanowi wyzwanie i poważny problem. Analizując środowiska, w których obecnie prowadzone są projekty, możemy stwierdzić, że zespoły analityków, programistów i testerów zwykle nie komunikują się ze sobą w sposób efektywny, co negatywnie wpływa na wydajność pracy, koszty i jakość finalnego produktu.

Jednym z przykładów takich narzędzi jest platforma IBM Engineering, która pozwala na organizację procesu wytwarzania produktów, systemów i oprogramowania od etapu pozyskania potrzeb biznesowych po przeprowadzenie testów, a następną weryfikacje i walidację samego rozwiązania. Jednym z produktów w ramach platformy IBM jest produkt IBM Engineering DOORS Next, który implementuje standardy związane z inżynierią wymagań, a dzięki temu zapewnia Lepsze wyniki realizacji projektów dzięki optymalizacji definicji wymagań i zarządzania nimi. IBM Engineering DOORS Next może pomóc zespołowi projektowemu w powiązaniu wymagań z informacjami zapisanymi w centralnym repozytorium lub w portalu zarządzania projektem. Korzystając z rozwiązania IBM, można dokumentować i kojarzyć informacje zapisane w różnych formatach i współużytkować je w grupie wielu użytkowników oraz między różnymi projektami. Oprogramowanie oferuje funkcje wyszukiwania i filtrowania, które ułatwiają poruszanie się po obszernych zasobach informacji opisujących wymagania.

Rozwiązania tego typu może pomóc zespołom w zarządzaniu informacjami przechowywanymi centralnie lub dostępnymi w portalu projektu, a jednocześnie zapewnia widoczność niezbędnych informacji dla zaangażowanych w projekt osób spoza podstawowego zespołu. Oferuje interfejs WWW służący do formułowania, opisywania, omawiania i recenzowania wymagań. Rozwiązanie IBM umożliwia pisanie sformatowanych dokumentów tekstowych, tworzenia diagramów procesów biznesowych, opracowywanie przypadków użycia i szkiców interfejsu użytkownika. 

IBM DOORS Next integruje zespoły i kojarzy oczekiwania biznesowe osób zainteresowanych projektem z funkcjami dokumentacyjnymi i umożliwiającymi śledzenie pochodzenia wymagań. W wielu przypadkach eliminuje konieczność wielokrotnego wykonywania tych samych prac, ponieważ sprzyja wcześniejszemu prawidłowemu sformułowaniu wymagań.

Wybór narzędzia niespełniającego wymagań lub niedopasowanego do infrastruktury organizacji z powodów organizacyjnych, procesowych lub kulturowych zawsze niesie ze sobą ryzyko. W celu jego uniknięcia lub przynajmniej minimalizacji, należy przeprowadzić wnikliwą analizę produktów dostępnych na rynku pod kątem starannie wybranych kryteriów porównania. Zły wybór w tym obszarze zawsze generuje koszta i nie ma znaczenia, czy wybierzemy narzędzia komercyjne czy narzędzia darmowe open source.

Rezultatem źle podjętych decyzji są najczęściej:

• Poniesione wysokie koszty narzędzia, które nie spełnia wymagań klienta.
• Zakup drogiego narzędzia na jeden projekt zmniejszy jego budżet, takie zakupy należy planować na departament.
• Wysoki koszt szkolenia w przypadku narzędzi, które nie mają zapewnionego wsparcia - koszt integracji narzędzia z innymi produktami używanymi w organizacji. 
• Koszty rozszerzania narzędzia o brakującą funkcjonalność w przypadku narzędzi typu Open Source.

Podejmowanie w tym obszarze pochopnych decyzji może mieć długoterminowy wpływ na usprawnianie procesów rozwoju oprogramownia i zarządzania projektami w organizacji. Często można zaobserwować, jak  firma uzależnia się od oprogramowania jednego dostawcy, co może w przyszłości skutkować związaniem się z jedną konkretną technologią. Ogranicza to potencjał inowacyjności i usprawnień, które mogą być wdrożone w organizacji.

Seria webinarów od IBM

IBM organizuje serię webinarów na temat zarządzania w przemyśle i inżynierii wymagań. Szczegóły na ich temat dostępne są tutaj.