Wdrożenie narzędzia do zarządzania wymaganiami

Wdrożenie narzędzi, które mają docelowo wspierać i usprawniać procesy wytwarzania oprogramowania są zawsze wyzwaniem konsumującym dużo czasu i środków finansowych. Aby rozwiązanie były w pełni stosowane w organizacji, należy pamiętać że podstawą jest zawsze wypracowany proces inżynierii wymagań, który jest zaakceptowany i uzgodniony wewnątrz organizacji. W innym wypadku wdrożenie narzędzi mija się z celem, gdyż będzie ono bez użyteczne. Wysokiej klasy rozwiązania dedykowane przychodzą od dostawców już w pewnej konfiguracji, którą zawsze można stosować do swoich potrzeb. Wymaga to jednak od organizacji wysokiego poziomu dojrzałości wewnętrznej w obszarze IT oraz świadomości rynku. Jest to jednak sytuacja w procesach nastawionych na niski koszt produkcji bardzo rzadko spotykana, bo firmy nie chcą inwestować w ich zdaniem zbędne narzędzi czy procesy, a skupić się na produkcie. Zorientowanie na korzyści z perspektywy celów krótkoterminowych może oczywiście przynieść wartość na dynamicznym rynku szybko zmieniających się potrzeb. Brak planowania długoterminowego rozwoju produktów i procesów ich produkcji mści się zawsze. Lektura wcześniejszych rozdziałów pokazuje jak skomplikowane są procesy związane z wymaganiami, a ich pełne pokrycie w wielu wypadkach nie będzie możliwe bez dobrze dobranego zestawu narzędzi W tym celu liczne firmy doradcze pomagają wdrażać zarówno procesy inżynierii wymagań, a także narzędzia je wspierające. Nie są to projekty łatwe i wymagają od zespołu realizacji doświadczenia zarówno pod optymalizacji procesów i znajomości narzędzi, które będą wdrażane. Aby oddać poziom skomplikowania i długość takiego projektu poniżej przedstawiono etapy wdrożenia.

Krok 1 – Zebranie informacji o aktualnym procesie i wymaganiach klienta

Wdrożenie narzędzia do zarządzania wymaganiami nie jest procesem prostym ani szybkim, jednak może być projektem, który doprowadzi do sporych oszczędności w organizacji. Pierwszym krokiem wdrażania zarówno procesów Inżynierii Wymagań, jak i narzędzi, jest zebranie wymagań i oczekiwań klienta co do samego procesu lub jego usprawnień. Pierwszym pytaniem zadanym przez firmę wdrażającą rozwiązanie będzie sytuacja obecna i stosowane w organizacji metodyki oraz standardy, które muszą być spełniane np. z powodu uwarunkowań prawnych lub domeny biznesowej, w której porusza się organizacja. Jako że definicja zarządzania wymaganiami jest często rozmyta, należy na wczesnym etapie uzgodnić z klientem jego oczekiwania i ograniczenia związane z realizacją projektu. Informacje najczęściej są zbierane w formie warsztatu, w którym uczestniczą reprezentanci grup dotkniętych przez proces Inżynierii Wymagań oraz przedstawiciele biznesu. Efektem prac jest dokument „Plan Zarządzania Wymaganiami”, który opisuje formalną komunikacje w obszarze wymagań, w zespole oraz zasady współpracy z dostawcami zewnętrznymi. Dokument specyfikuje, w jaki sposób opisujemy, przetrzymujemy, zmieniamy wymagania oraz jakie dokumenty na ich podstawie opracowujemy. Plan powinien opisywać proces pracy z wymaganiami w całym cyklu życia i rozwoju aplikacji lub systemu. W przypadku powoływania się w planie na metodyki, należy zapewnić, że ich praktyki są faktycznie stosowane w organizacji w sposób poprawny i zalecany.

Krok 2 – Wybór narzędzia automatyzującego proces

Po stworzeniu procesu odpowiednio skrojonego na potrzeby organizacji i uwzględniającego wszystkie jej potrzeby i realia dziedziny, w której się porusza, następuje proces doboru odpowiedniego narzędzia. Wybór powinien zostać wcześniej poprzedzony odpowiednią analizą rynku w celu znalezienia rozwiązania najlepiej pasującego do opisanego wcześniej procesu Inżynierii Wymagań, ale także uwzględniającego jego przyszłe zmiany. Podczas analizy musimy uwzględnić wszystkie czynniki mające wpływ na wdrożenie i używanie narzędzia jak: szkolenia, koszt licencji, koszt wdrożenia, integracja rozwiązania z obecnym portfolio narzędzi w organizacji (wszystkie czynniki zostały omówione w dalszej części książki). Zły wybór generuje wysoki koszty na etapie wdrożenia, utrzymania i nie prowadzi do oczekiwanych efektów w postaci oszczędności.

Krok 3 – Implementacja rozwiązania

Każde narzędzie dostarczane jest przez producenta w pewnej domyślnej konfiguracji, którą otrzymujemy zaraz po instalacji samego produktu. Rolą firmy realizującej projekt wdrożeniowy jest dostosowanie wdrażanego produktu do realnych potrzeb organizacji i wcześniej zdefiniowanego planu zarządzania wymaganiami, tak aby narzędzie wspierało wypracowane rozwiązanie najlepiej, jak tylko pozwala na to jego funkcjonalność. Konfiguracja narzędzia powinna obejmować dostosowanie typów wymagań, atrybutów, używanych szablonów dokumentów, miar oraz metryk oraz ról i uprawnień dla samych użytkowników. W ramach procesu wdrożeniowego powinny zostać wypracowane oraz zaimplementowane w organizacji procedury użycia narzędzia przez klienta a osoby w niech uczestniczące odpowiednie przeszkolone. Proces edukacji powinien być dostosowany do wypracowanego procesu, a nie powinien się tylko skupiać na funkcjonalnościach narzędzia, które nie muszą być wszystkie istotne z perspektywy klienta końcowego.

Krok 4 – Projekt pilotażowy

Po poprawnej implementacji narzędzia następuje etap uzyskania odpowiedzi na pytanie, czy wypracowane rozwiązanie procesowe wraz z narzędziami faktycznie rozwiązuje obecne wyzwania i czy jesteśmy jest w stanie w pełni wdrożyć je w organizacji. Weryfikacja powinna się odbyć w ramach projektu pilotażowego, który powinien być rzeczywistym projektem, aby odpowiednio zmotywować jego uczestników do pracy i nadać przedsięwzięciu odpowiedni bieg. Brak odpowiedniej motywacji osób może doprowadzić do potraktowania zadania jako drugoplanowego, co jednocześnie doprowadzi do braku realnej oceny rozwiązania i jego ewentualnych wad wymagających poprawienia. Projekt powinien także być krótkim o niskim priorytecie, aby szybko zweryfikować wypracowane rozwiązanie i aby jego ewentualne negatywne skutki nie miały wpływu na operacyjne działanie organizacji. Jeżeli projekt będzie się przeciągał w czasie, to możemy długo czekać na podsumowanie projektu i oceny wprowadzonych usprawnień. Przeprowadzony projekt powinien zostać poddany dogłębnej analizę pod kątem wartości i wyzwań, które wniósł do organizacji. Osoby odpowiedzialne za realizację tego przedsięwzięcia powinny w dalszej części projektu pełnić rolę ekspertów dziedzinowych i propagować wiedzę oraz świadomość w temacie danej dziedziny w organizacji. Pełnią oni rolę tzw. ekspertów dziedzinowych (ang. Subject-Matter Expert) oraz mentorów w kolejnych projektach dla innych członków organizacji w celu szerzenia wiedzy i odpowiedniego stosowania wypracowanych praktyk.

Krok 5 – Propagacja rozwiązania na inne projekty

Po zakończeniu wcześniejszych etapów, kolejnym krokiem w procesie wdrożenia narzędzia jest propagacja rozwiązania na inne projekty w organizacji. Wcześniej wypracowane i zweryfikowane elementy procesowe są wdrażane w rzeczywistym ekosystemie projektowym. Na tym etapie powinniśmy zaplanować wsparcie projektu wdrożeniowego przez osoby realizujące wdrażanie narzędzi i pełniące rolę mentorów dziedzinowych z zakresu wypracowanego procesu. Częstą praktyką jest szkolenie docelowych uczestników procesu i użytkowników narzędzia w temacie wypracowanego procesu i jego wsparcia przez wybrane narzędzie do zarządzania wymaganiami. Popularne są w tym obszarze szkolenia ukierunkowane typowo na narzędzia lub na określone techniki specyfikowania wymagań jak np. pisanie przypadków użycia.

Czynniki mające znaczenie przy doborze odpowiednich narzędzi

Przy wyborze dowolnych narzędzi dla wsparcia procesów wytwarzania oprogramowania, należy wykonać dokładną analizę poprzedzającą wdrożenie. Dotyczy to zarówno narzędzi komercyjnych, jak i darmowych, gdzie koszt licencji jest możliwy do pominięcia, jednak wdrożenie i utrzymanie może być bardzo kosztowne. Proces wyboru odpowiedniego narzędzia powinien być osobnym projektem w organizacji, a nie jak zazwyczaj fragmentem już realizowanych projektów. Pozwoli to skutecznie dobrać narzędzie dla całej organizacji, a nie w pośpiechu tylko i wyłączeni do potrzeb aktualnie realizowanego projektu. Ma to szczególne znaczenie przy narzędziach komercyjnych, których koszt skutecznie przekracza budżet większości z projektów. Wybór narzędzia zawsze jest zdeterminowany przez cenę, rodzaj dostępu do danych, wspierane metodyki, sposób przechowywania wymagań oraz wsparcie dla potrzeb organizacji. Aby analiza była zrealizowana w sposób pełny należy odpowiedzieć sobie na pytania, które mogą mieć znaczący wpływ na ewentualne wdrożenie utrzymanie narzędzia.

Do najbardziej kluczowych czynników, które powinny być brane pod uwagę przy wyborze narzędzi można zaliczyć:

  • Proces wdrożony w organizacji – narzędzie powinno być w stanie wspierać proces istniejący w organizacji. Większość narzędzi komercyjnych dostarcza szablonów metodyk lub pozwala na dostosowanie struktury procesów do potrzeb organizacji, która będzie je wdrażać. Brak wsparcia dla procesów uniemożliwi wykorzystanie w pełni możliwości narzędzia, a wręcz może uniemożliwiać jego użycie.
  • Zmiany w procesie w przymości – jeżeli proces będzie zmieniany w przyszłości, należy upewnić się, że wybrane narzędzie będzie w stanie nadal go wspierać.
  • Koszt oprogramowania – jest to jeden z najbardziej kluczowych czynników brany pod uwagę z perspektywy inwestycji w narzędzia. Przy wyborze oprogramowania koszt licencji stanowi zazwyczaj połowę całej inwestycji, należy ponadto pamiętać o uwzględnieniu elementów, takich jak usługi wdrożeniowe czy szkoleniowe. Kalkulując całkowitą wartość projektu należy uwzględnić:
    • Koszty licencji
    • Koszty wdrożenia oprogramowania
    • Koszty szkoleń (lokalne lub zagranicą)
    • Koszty utrzymania oprogramowania (odnowienia licencji)
  • Skala użycia narzędzia – czyli kwestia tego, czy narzędzie będzie używane w jednym projekcie, czy też w całej organizacji. Większa utylizacja oprogramowania wpływa na optymalizację zwrotu z inwestycji w skali całej organizacji. W przypadku komercyjnych rozwiązań użycie ich 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ądzanie projektem, procesem testowym, zmianami) – przy różnorodności dostawców narzędzi, kwestia integracji staje się skomplikowana, w rezultacie czego można utracić możliwość integracji danych z całego procesu, w tym możliwość śledzenia. Aby sprostać temu wyzwaniu, zalecane jest wybieranie narzędzi integrujących się z aktualnie posiadanymi rozwiązaniami lub ukierunkowanie strategii organizacji na jednego dostawcę 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 wszystkie działają na polskim rynku. Przy wyborze technologii istotne jest, aby wybrane narzędzia miały lokalne wsparcie techniczne w obszarze wdrażania oraz merytoryczne w zakresie prowadzenia szkoleń. W przeciwnym wypadku może to generować wysokie koszty usług związanych z wsparciem oprogramowania.
  • Przyszłościowe plany rozwoju produktu (ang. roadmap) – przy zakupie narzędzi należy pamiętać o sprawdzeniu dalszych planów jego rozwoju z perspektywy minimum 3 lat. W przeciwnym wypadku może nas spotkać niemiła niespodzianka w postaci zaprzestania wsparcia narzędzia przez jego dostawcę, co w połączeniu braku ś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 tym przypadku w założeniu użytkownik może je w dowolnym momencie rozbudować 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 ma na celu usprawnienie komunikacji i współpracy. Przed dokonaniem zakupu należy sprawdzić, czy licencja producenta pozwala na taką formę jej współdzielenia. Część dostawców w takim modelu współpracy wymaga, by klient i dostawca posiadali własne licencje. W optymalnej sytuacji dostawca lub klient może używać licencji w posiadaniu drugiej strony na czas realizacji projektu.