.png)
Dzisiejszy wpis czerpie inspirację z sytuacji projektowej, a mianowicie z niejasności dotyczących koncepcji cyklu życia wymagań. Istnieje dosyć poważne niezrozumienie tego zagadnienia – wiele osób myli zarządzanie cyklem życia z zarządzaniem wymaganiami, czyli tworzeniem repozytorium, nadawaniem atrybutów, akceptacją wymagań. Różnica między tymi pojęciami jest jednak dość znacząca.
Skorzystajmy z uznanych źródeł - "BABOK Guide" oraz IREB CPRE (certyfikowany specjalista inżynierii wymagań).
Analizując "BABOK Guide", można odnieść wrażenie, że cykl życia wymagań sprowadza się do śledzenia powiązań, utrzymywania wymagań w aktualnym stanie, priorytetyzacji, oceny zmian i akceptacji (KA Requirements Life Cycle Management). Ten dział opisuje kilka kluczowych praktyk związanych z zarządzaniem cyklem życia. Nie jest to jednak pełny cykl życia wymagań. Dlaczego? Ponieważ cykl życia ogólnie opisuje wszystkie etapy, przez które może przejść dany obiekt, od jego powstania do stanu terminalnego, czyli umownej śmierci.
Zgodnie z definicją w "BABOK Guide", cykl życia to seria zmian, które obiekt lub przedmiot przechodzi od początku do zakończenia. Zakończenia - zwróćmy na to uwagę.
Analizując "BABOK Guide", można wywnioskować, że cykl życia wymagań sprowadza się do stanów: zaproponowany, zaakceptowany, zweryfikowany, odłożony w czasie, anulowany lub zaimplementowany (KA Business Analysis Planning and Monitoring, task: 3.4 Plan Business Analysis Information Management).
Warto zauważyć, że nie jest to ani pełna lista możliwych stanów, ani pełny cykl życia, ponieważ brakuje stanu terminalnego. Stan "zaimplementowany" nie musi oznaczać zakończenia życia wymagań, ponieważ nawet zaimplementowane wymagania mogą być poddawane zmianom, mogą też być wycofane z działającego systemu, jeśli przykładowo utracą ważność. Nawet jeśli wymagania nie ulegają zmianom, w pewnym momencie (czasami bardzo odległej perspektywie czasowej) przestaną obowiązywać i zostaną zarchiwizowane, ponieważ cykl życia samego produktu dobiegnie końca – produkt zostanie wycofany z użycia, a wraz z nim wymagania, które stanowiły jego podstawę. Oczywiście, z perspektywy konkretnego projektu wytwarzania produktu, rzadko widzimy stany terminalne. Te stany zachodzą zwykle, gdy produkt zawierający określone zaimplementowane wymagania osiągnie swój stan “śmierci”.
BABOK Guide interpretuje pojęcie cyklu życia tak samo jak IREB (seria zmian, które obiekt lub przedmiot przechodzi od początku do zakończenia). Warto jednak zauważyć, że IREB dodatkowo wskazuje bardzo ważny element zarządzania cyklem życia, a mianowicie kontrola wersji. Wymagania ewoluują, zmieniają się, przechodzą z jednego etapu do drugiego. Zazwyczaj wiąże się to ze zmianami, zmianami atrybutów czy zmianami treści. Mechanizmem umożliwiającym monitorowanie tych zmian jest właśnie kontrola wersji.
Dlaczego znajomość pełnego cyklu życia ma takie znaczenie? Ponieważ w wielu przypadkach skupiamy się na pozyskaniu, udokumentowaniu i zaimplementowaniu wymagań. Innymi słowy, skupiamy się na obszarze początkowym cyklu życia. Często pomijamy, co dzieje się z wymaganiami po ich wdrożeniu w systemie i w czasie jego działania na produkcji. Koncentrujemy się na stworzeniu rozwiązania, ale niestety bardzo często zaniedbujemy kwestie związane z utrzymaniem i rozwojem.
Skutkiem tego może być to, że z punktu widzenia realizacji projektu wytwórczego, wymagania wydają się odpowiednio wyspecyfikowane i zarządzane za pomocą wystarczających mechanizmów. Przykładowo w projekcie możemy obsługiwać wymagania za pomocą backlogu i prostych historii użytkownika - z punktu widzenia potrzeb danego projektu to podejście może być wystarczające dla wytworzenia i wdrożenia systemu. Wystarcza do zrozumienia zakresu prac, stanowi wystarczającą podstawę komunikacji w zespole. Jednak z perspektywy cyklu życia produktu może to generować istotne negatywne konsekwencje.
Dlaczego? Ponieważ takie podejście do dokumentacji wymagań i tworzenia modelu informacyjnego systemu może być skuteczne z punktu widzenia realizacji projektowej, ale niekoniecznie w przypadku utrzymania już wdrożonego systemu.
Na przykład, jeśli jedynym źródłem wymagań jest backlog, to najprawdopodobniej zabraknie nam informacji o śledzeniu powiązań między wymaganiami. To oznacza, że wszelkie zmiany w już zaimplementowanych wymaganiach mogą być trudne do wprowadzenia. Nie będziemy mieli możliwości przeprowadzenia analizy wpływu zmian, co skutkuje ryzykiem destabilizacji systemu. Nie możemy też zakładać, że zespół utrzymaniowy ma wiedzę o architekturze systemu i powiązaniach, ponieważ zazwyczaj zespół utrzymaniowy to nie ci sami ludzie, którzy brali udział wytwarzaniu systemu. A nawet gdybyśmy założyli, że jest to ten sam zespół, to trudno oczekiwać, że ludzie, którzy dzisiaj mają wiedzę o budowie systemu, tę samą rzetelną i kompletną wiedzę będą mieli za jakiś czas, kiedy zajdzie potrzeba prac utrzymaniowych.
Śledzenie powiązań jest praktyką, na którą zarówno BABOK, jak i IREB kładą nacisk. To podstawowy mechanizm umożliwiający zarządzanie wymaganiami, zwłaszcza pod kątem analizy wpływu zmian.
Myślenie w sposób skoncentrowany na aktualnym projekcie, jego potrzebach, bieżących celach, jest z pewnością ważne. Ale niewystarczające.
Kluczowe jest myślenie perspektywiczne, z długofalowym horyzontem czasowym, obejmujące plan całego cyklu życia wymagań. Myślenie pod kątem przyszłego rozwoju. Zrozumienie i uznanie faktu, że samo wytworzenie systemu to tylko początek jego cyklu życia. Działanie systemu na produkcji bywa z reguły o wiele dłuższe niż projekt wytwórczy. Podejmowanie więc decyzji, które są wygodne z punktu widzenia projektu wytwórczego, ale będą miały negatywne konsekwencje dla możliwości sprawnego utrzymywania i rozwoju systemu, jest więc co najmniej odpowiedzialne.
Jednakże taki sposób myślenia, perspektywiczne i zorientowane na ułatwienie prac w przyszłości, jest możliwy tylko wtedy, gdy zrozumiemy istotę całego cyklu życia (zarówno poszczególnych wymagań, jak i całego produktu). Cykl życia to wszystkie etapy istnienia, łącznie ze stanem terminalnym, czyli umowną "śmiercią" wymagania czy systemu. Powinno to być przedmiotem naszego zainteresowania nawet w przypadku, gdy naszym zadaniem jest jedynie zaprojektowanie i wdrożenie systemu, a nie jego późniejsze utrzymanie. Może wydawać się, że utrzymanie to nie nasza troska – umowa z klientem dotyczy tylko i wyłącznie wytworzenia rozwiązania.
Ale prędzej czy później stanie się to troską naszego klienta. Z definicji nasza rola polega na dostarczaniu wartości – wartości rozumianej nie tylko jako produkt i wynikające z niego korzyści dla interesariuszy i biznesu. Wartością są też inne produkty pracy, umożliwiające dalszy sprawny rozwój systemu, oraz wypracowane procesy i mechanizmy.