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ą część z tych czynników za wywierające 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.

Budowa produktu a wymagania

W każdym projekcie, nie tylko IT, obowiązuje reguła: „im później błąd zostanie wykryty, tym więcej kosztuje jego naprawa”. W szczególny sposób dotyczy ona wymagań i ich jakości. Wymagania jako podstawa projektu rozwiązania są istotnym czynnikiem zapewnienia jakości. Wymagania precyzyjne, dokładne, kompletne i mierzalne – wyrażone po prostu językiem technicznym – minimalizują ryzyko błędów i usterek wynikających z błędnej interpretacji, niezrozumienia czy braków w wymaganiach. Wymagania wysokiej jakości powodują, że od samego początku – od etapu projektowania rozwiązania – korzystamy z prawidłowych wytycznych i unikamy podstawowych błędów. Z kolei wymagania słabej jakości znacząco zwiększają ryzyko niepowodzenia całego projektu, powodując między innymi opóźnienia (w pewnym momencie trzeba będzie naprawić błędy wynikające ze złej jakości wymagań, co opóźni prace projektowe). Wymagania niskiej jakości są też często przyczyną zupełnie zbędnych sporów z klientem, łatwych do uniknięcia przy zastosowaniu dobrych zasad inżynierii.

Innym problemem związanym z niskiej jakości wymaganiami jest kwestia zarządzania zmianami. Wymagania nieprecyzyjne lub niepełne prędzej czy później wzbudzą pytania i wątpliwości. Jeżeli wątpliwości te zostaną wyjaśnione na etapie analizy wymagań, szkoda nie będzie wielka – należy po prostu poprawić opis wymagań tak, by usunąć wątpliwe kwestie i sprecyzować wymaganie. Jeśli jednak problem wyniknie po zatwierdzeniu wymagań, na etapie projektowania, implementacji, czy – co gorsza – testów, rozwiązanie nie będzie już takie proste. Abstrahując od konieczności wykonania dodatkowych prac (kodowania, testowania itp. – czego można by uniknąć, znajdując i naprawiając błąd w wymaganiu na etapie dokumentacji), pojawia się problem samego wymagania i zmiany jego treści czy znaczenia. Zazwyczaj w momencie projektowania, czy implementacji, wymagania bądź już zaakceptowane przez klienta. Każda zmiana wymaga uzgodnienia z klientem, czasem długotrwałego i wywołującego pytania „dlaczego dopiero teraz zgłaszacie wątpliwości?”. Wydłuża to dodatkowo czas rozwiązania problemu. Ponadto zmiana wymagań po akceptacji to już nie „doprecyzowanie”, a często formalne żądanie zmiany wymagające dodatkowego czasu na obsługę i przetworzenie.

Większości wymienionych problemów można uniknąć, stosując proste mechanizmy zapewnienia jakości i kontroli jakości wymagań. Jednym z najbardziej znanych sposobów zapewniania jakości jest walidacja i weryfikacja (V&V; od ang. Validation & Verification). Weryfikacja polega na sprawdzeniu, czy produkt, który tworzymy, spełnia zatwierdzone wymagania; innymi słowy – „czy produkt jest tworzony prawidłowo?”. Walidacja z kolei odpowiada na pytanie: „czy tworzony produkt jest prawidłowy?”, czyli zgodny z oczekiwaniami i potrzebami interesariuszy. Zarówno walidacja, jak i weryfikacja mogą być wykonywane przy użyciu podobnych środków, takich jak różnego rodzaju przeglądy, listy kontrolne, prezentacje itp. Zasadnicza różnica między tymi procesami polega na ich celu – walidacja dąży do stwierdzenia, czy produkt będzie umożliwiał docelowej grupie odbiorców użycie zgodne z zamierzeniami i czy spełnia oczekiwania interesariuszy, podczas gdy weryfikacja ma na celu upewnienie się, że produkt jest realizowany zgodnie ze stwierdzonym zestawem wymagań.

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 powinien spełniać produkt, oprogramowanie lub tworzony system. Inżynieria wymagań zajmuje się wieloma zadaniami – od określania źródeł wymagań, przez analizę i specyfikację wymagań, przez zapewnienie i kontrolę jakości.

Zadania te wymagają od członków projektu posiadania zarówno specyficznych umiejętności merytorycznych, jak i doskonałych umiejętności miękkich, ponieważ praca inżyniera wymagań polega w dużej mierze na kontaktach z ludźmi. Osoba je wykonująca powinna posiadać nie tylko wiedzę i doświadczenie, ale i pewne predyspozycje.

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.

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.

Powszechnie używane narzędzia wspierające prowadzenie projektu nie potrafią wymieniać informacji między sobą, co prowadzi do powielania funkcjonalności i konieczności żmudnego i narażonego na błędy przenoszenia danych między nimi. Wybór narzędzi dokonywany jest zwykle pod kątem zaspokojenia potrzeb każdego zespołu z osobna, co z czasem całkowicie blokuje rozwój strategii departamentu odpowiedzialnego za rozwój IT. Oczywistym wnioskiem jest konieczność dążenia do konsolidacji dyscyplin w ramach projektu na poziomie integracji repozytoriów danych i ujednolicenia narzędzi, przy jednoczesnej eliminacji powielania ich podstawowych funkcji.

Zgodnie z tą koncepcją, efektywne narzędzia wspierające pracę zespołów projektowych powinny obsługiwać cały zintegrowany cykl produkcyjny (ang. Application Lifecycle Management – skrót ALM). ALM ma za zadanie zintegrować najważniejsze dyscypliny projektowe, jak zarządzanie wymaganiami, zarządzanie zmianami i konfiguracjami oraz zarządzanie procesami zapewnienia jakości. Dla osiągnięcia jak najlepszych efektów, narzędzia ALM powinny wspierać się na solidnych fundamentach, które zapewnią możliwość pomiaru efektywności procesów wytwarzania oraz współpracy między wszystkimi uczestnikami projektu.

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.

IBM Engineering DOORS Next 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. Udokumentowane w ten sposób wymagania można następnie łączyć w scenopisy i scenariusze, w odniesieniu do których osoby zainteresowane projektem będą zgłaszać dodatkowe lub zmodyfikowane wymagania.

IBM DOORS Next, obok IBM Workflow Management™ i IBM Test Management, należy do zasadniczych elementów rozwiązania IBM Engineering. Integracja między produktami do zespołowego zarządzania cyklem życia aplikacji umożliwia powiązanie wymagań ze scenariuszami testów i zadaniami programistycznymi. Takie powiązanie ułatwia uczestnikom projektu odkrywanie zmian, interpretację ich wpływu i utrzymanie poprawności oraz aktualności danych o projekcie. IBM Engineering DOORS Next jest zbudowany na platformie technicznej IBM Jazz™, której rozszerzalna architektura wspomaga sprawne zarządzanie wszystkimi etapami projekt.

IBM DOORS Next jako produkt ukierunkowany na pracę zespołową 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 oprogramowania 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ł innowacyjności i usprawnień, które mogą być wdrożone w organizacji.

Czynniki istotne przy doborze odpowiednich narzędzi

Wybór i wdrożenie dowolnych narzędzi wsparcia procesów wytwarzania oprogramowania należy poprzedzić dokładną analizą. Dotyczy to zarówno narzędzi komercyjnych, jak i darmowych, których wdrożenie i utrzymanie może być bardzo kosztowne mimo pomijalnego kosztu licencji. Proces wyboru odpowiedniego narzędzia powinien być osobnym przedsięwzięciem, a nie, jak zazwyczaj, fragmentem przedsięwzięć już realizowanych w organizacji. Pozwoli to dobrać narzędzie dla całej organizacji skutecznie, a nie w pośpiechu, tylko i wyłącznie do potrzeb obecnie realizowanego projektu. Ma to szczególne znaczenie w przypadku wyboru narzędzi komercyjnych, których koszt przekracza budżet większości przedsięwzięć. Wybór narzędzia jest zawsze determinowany przez cenę, rodzaj dostępu do danych, wspierane metodyki, sposób przechowywania wymagań oraz wsparcie potrzeb organizacji. Aby analiza została zrealizowana w sposób pełny, należy wziąć pod uwagę istotne czynniki, które mogą mieć znaczący wpływ na ewentualne wdrożenie utrzymanie narzędzia. Można do nich zaliczyć:

• Proces wdrażany w organizacji – narzędzie powinno udzielać wsparcia procesowi istniejącemu w organizacji. Większość narzędzi komercyjnych dostarcza szablony metodyk lub pozwala na dostosowanie struktury procesów do potrzeb organizacji, która będzie je wdrażać. Brak wsparcia dla procesów utrudni wykorzystanie możliwości narzędzia w pełni, a wręcz może uniemożliwić jego użycie.

• Potencjalne zmiany w procesie w przyszłości – jeżeli proces będzie w przyszłości zmieniany, należy upewnić się, że wybrane narzędzie będzie nadal w stanie go wspierać.

• Koszt oprogramowania – jest to jeden z najistotniejszych czynników z perspektywy inwestycji w narzędzia. Przy wyborze oprogramowania koszt licencji stanowi zazwyczaj połowę inwestycji, ponadto należy pamiętać o uwzględnieniu usług wdrożeniowych czy szkoleniowych. Kalkulując całkowitą wartość projektu, należy uwzględnić:

• koszty licencji,
• koszty wdrożenia oprogramowania,
• koszty szkoleń (lokalnych lub zagranicznych),
• koszty utrzymania oprogramowania (odnowienia licencji).

• Skala użycia narzędzia – czyli kwestia, czy narzędzie będzie używane w jednym projekcie, czy też w całej organizacji. Większe wykorzystanie oprogramowania wpływa na optymalizację zwrotu z inwestycji w skali całej organizacji. Użycie rozwiązań komercyjnych w jednym projekcie może być niemożliwe ze względu na koszt zakupu licencji, usług wdrożenia i szkoleń.

Zagadnienia związane z integracją narzędzia z innymi obszarami (zarządzania projektem, procesem testowym, zmianami) – przy różnorodności dostawców narzędzi kwestia integracji staje się skomplikowana, co może skutkować utratą możliwości integracji danych z całego procesu, w tym możliwości śledzenia. Aby uporać się z tym problemem, należy wybierać narzędzia, które są zgodne z już posiadanymi rozwiązaniami, lub ukierunkować strategię organizacji na wybór jednego dostawcy całej platformy narzędzi do zarządzania procesem tworzenia oprogramowania.

Możliwości wdrożenia i wsparcia – istnieje wielu dostawców narzędzi wspierających procesy inżynierii wymagań, jednak nie wszyscy działają na polskim rynku. Przy wyborze technologii istotne jest, aby narzędzia, na które się decydujemy, miały lokalne wsparcie techniczne w obszarze wdrażania oraz merytoryczne w zakresie prowadzenia szkoleń. Zlekceważenie tego zalecenia może generować wysokie koszty usług związanych ze wsparciem oprogramowania.

Przyszłościowe plany rozwoju produktu (ang. roadmap) – podczas zakupu narzędzi należy pamiętać o sprawdzeniu dalszych planów ich rozwoju w perspektywie co najmniej trzech lat. W przeciwnym razie może nas spotkać niemiła niespodzianka, jeśli dostawca zaprzestanie wspierania narzędzia, co w połączeniu z brakiem ścieżki migracji do innego rozwiązania może okazać się znacznym problemem w utrzymaniu spójności i efektywności procesu inżynierii wymagań. Kwestia rozwoju narzędzi w mniejszym stopniu dotyczy rozwiązań Open Source, gdyż w ich przypadku użytkownik może je z założenia rozbudować w dowolnym momencie, ingerując w kod.

Zakres użycia narzędzia – w przypadku wielu przedsięwzięć wybrane narzędzia mogą być stosowane zarówno przez klienta, jak i dostawcę rozwiązania. Użycie tych samych narzędzi przez obie strony najczęściej służy usprawnieniu komunikacji i współpracy. Przed dokonaniem zakupu narzędzia należy sprawdzić, czy licencja producenta pozwala na taki sposób jego współdzielenia. Część dostawców wymaga, by klient i dostawca współpracujący w takim modelu posiadali osobne licencje. W sytuacji optymalnej dostawca lub klient może na czas realizacji projektu korzystać z licencji należącej do drugiej strony.

https://www.ibm.com/pl-pl/products/requirements-management-doors-next

https://jazz.net/products

http://smarterprocess.pl/