Praca analityka to nie tylko pozyskiwanie, dokumentowanie i zarządzanie wymaganiami. W wielu organizacjach innym ważnym zadaniem analityka jest wsparcie organizacji procesu CM (ang. Change Management) oraz nadzór i kontrola szybkiej realizacji zmian w wytwarzanym systemie. Terminem zmiana określa się każdą modyfikację projektu aplikacji dokonaną po zatwierdzeniu projektu – dokumentacji analitycznej i technicznej, prototypów, etc. Zmiany mogą być wnoszone:

• w trakcie implementacji – jeśli pojawi się konieczność modyfikacji zatwierdzonego projektu ze względu na zmianę wymagań klienta; wykryte w specyfikacji wymagań błędy, trudności implementacji dotychczasowego rozwiązania (np. ograniczenia techniczne);
• w trakcie testów – zmiany mogą wynikać z konieczności poprawy błędów logicznych, biznesowych itp. wykrytych podczas testowania. Często podczas testowania wychodzą na jaw błędy wynikające z nieprzewidzenia pewnych czynności, które operator systemu może wykonać. Brak specyfikacji odpowiedzi systemu na takie „nieprzewidziane” czynności z reguły oznacza błąd aplikacji;
• w trakcie testów użyteczności lub akceptacyjnych – zmiany wynikające głównie z modyfikacji lub wprowadzania nowych wymagań klienta, np. dostosowania wymagań związanych z użytecznością aplikacji do rzeczywistych potrzeb użytkowników, zmiany przepływu pewnych procesów biznesowych, tak aby mapowały rzeczywiste czynności wykonywane przez użytkowników (ta ostatnia sytuacja ma miejsce szczególnie wtedy, gdy użytkownicy końcowi nie są zaangażowani w projektowanie systemu, a widzą go po raz pierwszy dopiero np. podczas testów akceptacyjnych. Często okazuje się wówczas, że projekt wymaga pewnej optymalizacji lub nie odpowiada rzeczywistemu procesowi wykonywanemu przez pracowników danej organizacji, mających docelowo korzystać z budowanego systemu);
• podczas działania na produkcji – jeśli pojawią się zewnętrzne zmiany wymagań (np. przepisy prawne, bankowe), lub wewnętrzne (np. klient żąda dodatkowych funkcji).

Nieprawidłowości (błędy, niespójności, luki, etc.) w specyfikacji wymagań może znaleźć i zgłosić praktycznie każdy udziałowiec projektu – od analityka, autora specyfikacji, poprzez klienta, programistów, aż po użytkowników końcowych wykonujących lub wspierających testy akceptacyjne lub testy użyteczności.

Zmiana dokonywana na życzenie klienta jest przedmiotem osobnej wyceny o ile stanowi wyraźną modyfikację zapisów wymagań w dokumentacji projektowej lub jest nowym wymaganiem. Należy pamiętać o tym, iż bardzo często klient zgłasza „ukryte” żądanie zmiany – tzn. w formie zgłoszenia błędu – co zdarza się, gdy dokumentacja projektowa nie jest wystarczająco szczegółowa i kompletna. Sytuacja taka może prowadzić do konieczności implementacji wielu zmian (nawet dość złożonych) w ramach określonego na początku projektu budżetu. Aby zminimalizować ryzyko pojawiania się takich zmian, należy upewnić się, iż wymagania klienta, spisane na początku analizy biznesowej i w trakcie jej trwania są udokumentowane spójnie, szczegółowo, przejrzyście i jednoznacznie. Klient powinien oficjalnie zweryfikować i zatwierdzić określone produkty analizy przed rozpoczęciem prac implementacyjnych.

Jeżeli w danym projekcie nie ma wydzielonej roli menedżera zmian, analityk pełni rolę osoby przyjmującej zgłoszenia zmian, analizującej ich pracochłonność, ryzyko i wpływ na istniejący system, oraz planującej prace implementacyjne. Zarządzanie zmianami wymaga prowadzenia rejestru zmian (ang. Change Log), w którym zapisywane są wszystkie żądania zmian (pochodzące od wszystkich uprawnionych do zgłaszania propozycji zmian osób – tzn. tester może nie móc samodzielnie zgłaszać żądania zmiany, ale kierownik testów po otrzymaniu propozycji od owego testera i wstępnej analizie jej zasadności - tak), wraz z decyzjami odnośnie ich realizacji, planami implementacji, etc. Należy pamiętać, iż rejestr zmian obejmuje jedynie zmiany, których zgłoszenia zostały oficjalnie przekazane kierownictwu projektu za pomocą odpowiedniej, określonej ustaleniami z klientem, dokumentacji żądania zmiany (może to być zarówno dokument żądania zmiany, jak i polecenie w systemie JIRA). W rezultacie, jeśli żądania zmian przyjmowane są za pośrednictwem określonego formularza, zmiana zgłoszona w postaci e-maila nie powinna zostać włączona do rejestru.

Struktura rejestru zmian może różnić się w zależności od projektu i potrzeb. Rejestr prowadzony jest często w postaci arkusza Excel z następującymi informacjami:

• identyfikator zmiany,
• nazwa (krótki opis),
• autor (zgłaszający propozycję zmiany),
• odpowiedzialny za realizację zmiany,
• czasochłonność (np. w MD),
• ryzyko związane z realizacją zmiany,
• status zgłoszenia zmiany.

Status żądania zmiany powinien jednoznacznie określać stan realizacji zmiany. Przykładowe statusy żądania zmiany oraz ich opis przedstawiono poniżej:

• Nowa – żądanie zmiany wpłynęło do analizy, nie zostało jeszcze zaakceptowane.
• Analiza – zgłoszenie zmiany jest w trakcie analizy ryzyka, wpływu itp.
• Zaakceptowana – żądanie zmiany zostało przeanalizowane pod kątem pracochłonności i ryzyka, dostępności zasobów oraz kosztu zmiany. Podjęto decyzję o implementacji zmiany.
• Odrzucona - żądanie zmiany zostało przeanalizowane pod kątem pracochłonności i ryzyka, dostępności zasobów oraz kosztu zmiany. Podjęto decyzję o odrzuceniu i zamknięciu zmiany.
• W realizacji – zmiana jest w trakcie implementacji. Została przypisana do programisty, który określa przybliżony termin dostarczenia zmiany do systemu na produkcji.
• W testach systemowych – zmiana jest zaimplementowana, przetestowana przez programistę, który ją realizował i zainstalowana w środowisku testów systemowych (wewnętrznych).
• W testach UAT – zmiana została pozytywnie zweryfikowana w testach systemowych, zostaje zainstalowana w środowisku UAT celem ostatecznej weryfikacji przez klienta.
• Zamknięta – zmiana zaimplementowana, zweryfikowana z wynikiem pozytywnym i zamknięta.

Po realizacji (implementacji kodu), zmiana musi być poddana weryfikacji, czyli musi zostać przetestowana. Jeśli zmiana została zgłoszona w testach angażujących zespół klienta, lub już po instalacji systemu na produkcji, weryfikacja powinna zostać wykonana najpierw wewnętrznie przez zespół testerów dostawcy, a dopiero po pozytywnym wyniku, wdrożona do systemu, na którym pracuje klient.

Zmiany, których weryfikacja dała wynik negatywny na danym etapie, pozostają w tym samym statusie do momentu poprawy (np. zmiana przetestowana na etapie „w testach systemowych” i zweryfikowana jako niezgodna ze specyfikacją, pozostaje w statusie „w testach systemowych” dopóki nie zostanie dostarczona poprawka). Nieprawidłowości w implementacji zmian zgłaszane są jako błędy.

Wszystkie zmiany (wynikające ze zmian wymagań, korekty błędów analizy, etc.) wymagają szybkiej reakcji oraz sprawnego wprowadzania modyfikacji do systemu i wiążą się zwykle z dużym ryzykiem (np. naruszenia spójności lub stabilności aplikacji, pojawienia się błędów regresji).

W ujęciu ogólnym analityk jest odpowiedzialny za:

• szkolenie personelu klienta z zakresu systemu oraz procedur (zgłaszania żądań zmian, zgłaszania błędów itp.). W określonych przypadkach analityk może też być proszony o przygotowanie i wykonanie szkoleń oraz lekcji pokazowych dla zespołu testerów, np. w przypadku, gdy testerzy nie należą do personelu dostawcy;
• stworzenie podręczników użytkownika opisujących w wystarczającym stopniu obecną funkcjonalność systemu (celem ułatwienia pracownikom klienta zrozumienia funkcjonowania systemu i ewentualnej identyfikacji żądań zmian, czyli zmian do zaakceptowanej i opisanej w podręczniku czy specyfikacji funkcjonalności);
• zbieranie, analizę i szacowanie zgłoszeń żądań zmian;
• informowanie klienta oraz pracowników dostawcy o wpływie i ryzyku proponowanych zmian celem dalszej dyskusji i uzgodnienia działań, które będą przedsięwzięte (implementacja zmiany, bądź odrzucenie np. z powodu niskiej krytyczności a dużego ryzyka);
• przygotowanie planów implementacji i wdrożenia zmian (wspólnie z zespołem projektowym - developerskim);
• nadzór nad poprawnością zaimplementowanych zmian oraz wsparcie wdrożenia zmienionej wersji systemu i w dalszej kolejności testów.

Autor: Karolina Zmitrowicz