"żeby tak wszystko ze wszystkiego wynikało"

Problem dotyczy zarządzania zmianami w wymaganiach. Cytując rozmowę, oczekiwanie brzmi następująco Proszę Pana, chciałbym tu mieć takie narzędzie do zarządzania wymaganiami, w którym będę mógł sobie je definiować, żeby tak wszystko ze wszystkiego wynikało. Na przykład jak przyjdzie jakaś zmiana, to żebym od razu wiedział gdzie, co i jak, w której klasie należy zmienić. Rozumie Pan?

No, niby rozumiem...

Zarządzanie? Dobre sobie!
Weź pierwszą z brzegu mądrą książkę, która ma w tytule Requirements Management. 99% tekstu jest o (w kolejności ilości stron): dokumentowaniu, zbieraniu (ale raczej skąd? niż jak?) i analizie wymagań. I gdzieś tam pod koniec parę akapitów o tym, że change happens. A kluczową atrakcję wieczoru, czyli management zbywa się truizmem w stylu trzeba wdrożyć proces zarządzania zmianą.

Czyli co to jest to zarządzanie? Sądzę, że:

• składowanie wymagań
• dowiadywanie się jak nowe wymagania wpływają na istniejące
• wykrywanie konfliktów w wymaganiach
• dowiadywanie się jak zmiany (w skrócie: CR) wpływają na istniejące wymagania

Hipertraceability
Czy oczekiwanie wyrażone w początkowej historyjce ma sens. Jest w nim ukryta jakaś potrzeba, ale zastanawiam się czy ma sens. Można zaprzęgnąć EA albo coś droższego i wyklikać wszystkie możliwe powiązania tak, "żeby tak wszystko ze wszystkiego wynikało". A co w przypadku zmiany? Oprócz dowiedzenia się co z czym się wiąże, znów trzeba będzie poklikać. Sądzę, że utrzymywanie takiej macierzy powiązań to robota na kilka pełnych etatów. Wątpię, czy warta świeczki. Wątpię, czy jest nawet warta ogarka.

Gdzie leży problem z traceablility?
Duży system jest zazwyczaj podzielony na moduły, które są rozwijane przez osobne podzespoły, którym przewodzą dedykowani liderzy. Gdy przychodzi zmiana dotycząca jednego z modułów, może ona jakiś wpływ na inne. Jeśli dane lider na to wpadnie to świetnie. Jeśli nie, to sprawa wypłynie prędzej czy później.

Niszczące działanie zmiany nie jest wynikiem braku hiepertraceability, braku jedynie poprawnego narzędzia czy wynikiem braku kompetencji. To przede wszystkim problem organizacyjny i komunikacyjny. Liderzy nie wiedzą co się dzieje w inny modułach, analizują zmianę lokalnie bez odniesienia do całości (której nie znają) i nie komunikują się ze sobą wystarczająco.

Product Manager
Brakuje osoby (Product Manager), która będzie spinać system całość. Od razu pada pytania: czy od strony technicznej, czy biznesowej? Nie chodzi to, żeby przez Product Managera przechodziły wszystkie CR, a on będzie podejmował je analizował i podejmował decyzje. Nie może tak być, bo zaraz zrobi się z niego ktoś w stylu Solution Architect, w którym będzie powoli skupiała się kluczowa wiedza o systemie i który będzie wąskim gardłem procesu zarządzania zmianą. (a niech tam, to zatrudnimy mu asystentów i już, czemu nie? :) )

Product Manager jest raczej kimś kto dba o to by komunikacja pomiędzy liderami i zespołami przebiegała płynnie. Oczywiście będą trafiać do niego wszystkie CR, będzie posiadał dużą wiedzę biznesową i będzie doskonale znał produkt. Jego główny zadaniem będzie troszczenie się o produkt jako całość i pomaganie poszczególnym zespołom w komunikowaniu się z innymi i dogrywaniu wszelkich zmian.

Zauważmy, że nie jakaś konkretna osoba analizuje wymagania, wykrywa konflikty i wpływ nowych na istniejące. Rzeczy te wykrywane są w procesie komunikacji pomiędzy poszczególnymi zespołami i liderami.

Czy Product Manager będzie miał co robić? Jeżeli mówimy o produkcie, który ma wdrożenia dla poszczególnych klientów, to z pewnością tak. Odpowiedzialności Product Manager to:

• dbanie o rozwój produktu jako całości
• dbanie o loose coupling między produktem a wdrożeniami dla poszczególnych klientów :)
• przyjmowanie CR
• pomaganie liderom i zespołom w komunikowaniu się między sobą
• uzgadnianie i mediowanie w przypadku wprowadzania zmian w produkcie