Standaryzacja inżynierii wymagań – czy ma sens?

Pewnie znasz taką sytuację. Jesteś w obcym mieście i zgłodniałeś / zgłodniałaś. Wybór pada na pizzę. Wchodzisz do pobliskiej pizzerii i zamawiasz. Wiesz czego się spodziewać. Cienki placek wypiekany w piecu na miejscu, o w przybliżeniu znanej wielkości, pokryty dodatkami. Jeśli wiadome jest jaki to rodzaj pizzy, np. neapolitańska lub rzymska, to Twoje oczekiwania są jeszcze bardziej precyzyjne. Pozostaje wybrać dodatki (zwykle tu też nie ma zaskoczenia) lub nazwę pizzy, która często też jest mocno uniwersalna i to wszystko. Jeśli nie masz wyjątkowego pecha co do miejsca, w którym się znalazłaś / znalazłeś to po chwili otrzymasz zamawiany produkt, w miarę zgodny z Waszymi oczekiwaniami.

Opisana wyżej sytuacja to przykład standaryzacji. Zarówno zamawiający jak i dostawca posługują się ustaloną i ustandaryzowaną terminologią („pizza”, „pizza neapolitańska”, „Margherita”, „ Marinara” etc.). Dodatkowo istnieją pewne standardy rynkowe dotyczące produktu, a zatem precyzujące oczekiwania zamawiającego i zobowiązania dostawcy. Czy podobnie nie powinno być w przypadku analizy biznesowej / inżynierii wymagań? 😊

Gdy studiowałem informatykę, a było to już wiele lat temu, często słyszałem, że branża IT, w tym inżynieria wymagań to dziedziny relatywnie nowe, innowacyjne, niedojrzałe, skomplikowane, a przez to trudne do ustandaryzowania. Skoro od tego czasu minęło już sporo lat, to może czas najwyższy by analiza biznesowa i inżynieria wymagań jednak nieco „dojrzały” i uległy standaryzacji? Zapewne zwiększyłoby to efektywność branży oraz odsetek udanych projektów IT. Jak zatem się do tego zabrać?

Standardowa terminologia

Jak właściwie każda specjalistyczna dziedzina, tak samo analiza biznesowa i inżynieria wymagań posługują się pewnym dziedzinowym słownictwem. Problem z tym, że nie zawsze jego rozumienie jest uniwersalne. Przykładem może być termin „wymagania biznesowe” definiowany często jako „ogólne, wysokopoziomowe wymagania definiujące cele i potrzeby organizacji”. Jednak dla niektórych termin ten oznacza wszystkie „nietechniczne” wymagania, a zatem wszystko co zgłaszają lub czego potrzebują „nietechniczni” interesariusze niezależnie od poziomu szczegółowości czy też kontekstu. I tu znowu dochodzimy do problemu, bo słowo „interesariusz” też bywa różnie rozumiane. Ileż to razy byłem świadkiem ożywionych dyskusji u których podstawy było zwyczajnie inne zrozumienie stosowanych terminów…

Co można z tym zrobić? Moim zdaniem ratunkiem może być oparcie się na standardach branżowych. Zwykle definiują one pojęcia w bardzo zbliżony sposób, a dodatkowe wskazanie którym standardem się posługujemy, jeszcze bardziej precyzuje i uściśla zrozumienie poszczególnych słów i zwrotów.

Szablony dokumentacji

Szablony, a więc predefiniowane, uzgodnione, a często standardowe struktury mogą być aplikowane na różnych poziomach. Standard IREB wymienia szablony wyrażeń służące do definiowania pojedynczych wymagań, szablony formularzy oraz szablony całych dokumentów. Po co nam one? Po to by ustalić z góry czego oczekiwać, a z drugiej strony co dostarczyć. Precyzując z interesariuszami (szczególnie klientami) jakie szablony będą użyte, ustalamy wzajemne oczekiwania, a tym samym zakres pracy do wykonania. Co więcej stosując szablony oszczędzamy sobie wysiłku związanego z każdorazową analizą w jaki sposób należy przygotować dokumentację. Zwyczajnie mamy to ustalone i od razu możemy przystąpić do działania. Jest to przydatne, zwłaszcza gdy działamy w większym zespole i konieczna jest synchronizacja pracy. Stosując szablony zyskujemy zatem łatwiejsze sprecyzowanie zakresu pracy, a w konsekwencji większą precyzję estymacji wysiłku oraz redukcję wysiłku związanego z planowaniem i synchronizacją działań.

Warto również wskazań inną korzyść, o której często się zapomina. Wiele wymagań nadaje się do ponownego użycia. Nie zawsze należy „wynajdywać koło na nowo”, a efektywne jest właśnie użycie ponownie wymagań z innych projektów lub z ogólnej „biblioteki standardowych wymagań” istniejącej w niektórych organizacjach. Oczywiście stosowanie szablonów o wiele to ułatwia.

Standardowe notacje

Wymagania są często dokumentowane przy użyciu modeli. Te z kolei mogą być tworzone w oparciu o standardowe notacje, np. BPMN, UML czy SysML. Czy warto ich używać? Moim zdaniem zdecydowanie tak. Mają one swoje specyfikacje, a zatem sprecyzowaną składnie i semantykę. Dzięki temu istnieje jednoznaczny sposób ich interpretacji. Nawet jeśli ktoś ich w pełni nie zna lub nie rozumie któregoś elementu, ma gdzie szukać informacji. Istnieje przecież wspomniana specyfikacja, a poza tym książki, kursy czy nawet filmy na YouTube (niestety różnej jakości).

Spotkałem się nieraz z argumentami przeciwników stosowania standardowych notacji i zamiast nich używania „czegoś własnego”. Dotyczyły one przeważnie rzekomego skomplikowania i potrzeby stosowania „prostych diagramów”. Faktem jest, że notacje jak BPMN czy UML mają dość skomplikują składnię i semantykę. Ich specyfikacje liczą po kilkaset stron. Nikt jednak nie zmusza nas do stosowania ich w pełnej złożoności. Tak jak w przypadku każdego innego sposobu komunikacji, możemy stosować tylko niektóre najprostsze elementy i bazowe struktury, tworząc mało zaawansowane, ale przystępne i łatwo zrozumiałe diagramy. Próg wejścia do tworzenia diagramów przy użyciu wymienionych notacji jest zatem dość niski.

Pamiętajmy również o tym, że „własne” notacje powinny być przynajmniej minimalnie udokumentowane. W przypadku braku dokumentacji, nie ma żadnej gwarancji, że odbiorcy diagramu zrozumieją go zgodnie z intencjami autora. Warto zatem dodać chociażby najprostszą „legendę” wyjaśniającą zrozumienie poszczególnych elementów użytych na diagramie. A jeśli musimy samodzielnie tworzyć i utrzymywać dokumentację własnej notacji, to zawsze oznacza to dodatkową, moim zdaniem zbędą pracę do wykonania.

Procesy, procedury i techniki

W wielu organizacjach, z którymi miałem przyjemność współpracować istotne były procedury oraz standardy dotyczące sposobu działania i zastosowania poszczególnych technik. Dzięki ich zdefiniowaniu i stosowaniu jasne było w jaki sposób należy przygotować ofertę oraz wycenę. Jasne było jak wygląda proces opracowywania, ustalania i akceptowania dokumentacji. Jasne było też miedzy innymi to kogo angażować do projektów, jak zarządzać odpowiedzialnością oraz co robić w sytuacjach spornych. Zdefiniowanie standardów działania wymaga przeanalizowania potencjalnych problemów i optymalnych sposobów działania z wyprzedzeniem i „na chłodno” gdy jest na to czas i nie działamy pod presją lub wpływem emocji. Ich stosowanie wnosi sporą poprawę efektywności dzięki eliminacji niepotrzebnych i dublujących się działań lub działań o znikomej celowości.

Standaryzacja a innowacyjność

Często podnoszonym argumentem przeciw standaryzacji jest ten mówiący o tym, że zmniejsza ona innowacyjność. I rzeczywiście, działanie według ściśle zdefiniowanych i niezmiennych ram może ją redukować. Warto temu jednak przeciwdziałać. Jak to robić? Przede wszystkim istotne jest, aby interesariusze w tym szczególnie osoby odpowiedzialne za realizację poszczególnych działań dobrze rozumiały wprowadzone standardy, ich sens, oraz wynikające z nich korzyści. Po drugie standard zawsze musi ewoluować i podlegać modyfikacjom na podstawie nowych pomysłów i doświadczeń.

Ważne jest, aby standardy nie były „wyrytymi w kamieniu”, sztywnymi zasadami nie podlegającymi dyskusji, ale przeciwnie były czymś zawsze otwartym, podlegającym stałym, kontrolowanym zmianom wynikający z tzw. lessons learned. Warto na bieżąco zbierać o nich opinie i planować cykliczne aktualizacje. Pamiętajmy o tym, że nie podlegający zmianom, niezrozumiały dla interesariuszy standard przestaje być efektywnym i użytecznym narzędziem. Staje się dziwnym, obcym i utrudniającym życie „dogmatem”.

Standaryzacja a AI

W obecnych czasach trudno nie wspomnieć nawet słowem o kontekście sztucznej inteligencji. Zgodnie z zasadą, która w nieco bardziej eleganckiej formie brzmi „quality in, quality out”, zasilając narzędzia oparte na AI danymi wysokiej jakości można spodziewać się również wyższej jakości wyników. Zasadnym wydaje się zatem, że ustrukturyzowana i ustandaryzowana dokumentacja może stanowić odpowiedni materiał do wykorzystania w kontekście narzędzi AI.

Moje rekomendacje

• Pamiętaj, że wiele nieporozumień i sporów wynika z odmiennego zrozumienia terminologii – staraj się standaryzować w Twojej organizacji terminologię dotyczącą inżynierii wymagań.
• Stosuj szablony dokumentacji – pozwalają one łatwiej zarządzać oczekiwaniami interesariuszy, a także planować i estymować pracę do wykonania.
• Stosuj standardowe, udokumentowane notacje do tworzenia modeli – dzięki temu uzyskasz bardziej jednoznaczne, powszechnie zrozumiałe diagramy, bez konieczności ponoszenia dodatkowych nakładów na dokumentowanie „własnych notacji”.
• Definiuj procesy i procedury – dzięki temu łatwiej skoordynować pracę i uniknąć marnotrawstwa związanego z niepotrzebnymi lub dublującymi się aktywnościami.
• Dbaj o zrozumienie standardów – pamiętaj, że ich efektywne wykorzystanie jest uwarunkowane ich poprawnym zrozumieniem.
• Bądź otwarty na zmiany – standardy powinny „obowiązywać”, ale jednocześnie podlegać ciągłym zmianom, tak by odpowiadały aktualnym potrzebom i wnioskom z doświadczeń.
• Poznaj standardy branżowe – pamiętaj, że nie musisz wymyślać wszystkiego od podstaw, standardy opracowywane i popularyzowane przez IREB oraz IIBA są bardzo dobrym punktem wyjścia.

Radek Grębski

Analityk biznesowy, Product Owner, trener