Jednym z najważniejszych, a zarazem najtrudniejszych zadań analityka biznesowego i systemowego jest walka z barierami komunikacyjnymi. Co ciekawe, walka ta często rozgrywa się na poziomie pojedynczych słów. Czasem pozornie niewinne wyrażenie potrafi wywołać lawinę nieporozumień między biznesem, analitykiem, testerem a deweloperem.
Weźmy na tapet popularny zwrot: „w szczególności”.
Dwuznaczność, która rodzi błędy
Jako analitycy chętnie sięgamy po to sformułowanie, gdy chcemy wypunktować najbardziej krytyczne przypadki, nad którymi biznes powinien się pochylić. Rozważmy przykład:
„Bank blokuje kanały zdalne”
Dla biznesu brzmi to ogólnikowo i może wydawać się abstrakcyjne. Aby to zobrazować, dopisujemy doprecyzowanie:
„Bank blokuje kanały zdalne, a w szczególności uniemożliwia realizację wypłat i płatności”.
W naszym zamyśle podkreślamy w ten sposób szczególny przypadek o najwyższym priorytecie. Czerpiemy tutaj z tradycji języka prawniczego, w którym zwrot „w szczególności” oznacza zazwyczaj katalog otwarty (exempli gratia). Sygnalizuje on: „podaję kluczowe przykłady, ale mogą istnieć inne, niewymienione sytuacje”.
I tu pojawia się pułapka.
Jak zwrot widzi Developer i Tester?
Podczas gdy dla analityka i biznesu jest to zbiór otwarty, dla inżyniera oprogramowania (dewelopera lub testera) to samo sformułowanie może stać się katalogiem zamkniętym.
Istnieje realne ryzyko, że techniczna część zespołu podejdzie do tego zapisu literalnie: skupi się wyłącznie na zablokowaniu wypłat i płatności, całkowicie ignorując pozostałe kanały zdalne i scenariusze brzegowe. W efekcie powstaje luka w systemie, która na etapie testów akceptacyjnych lub (co gorsza) na produkcji, okazuje się poważnym błędem implementacyjnym.
Gdzie absolutnie NIE WOLNO używać zwrotu „w szczególności”?
Bezwzględnie unikaj tego sformułowania we wszelkiej dokumentacji operacyjnej, projektowej i technicznej, gdzie kluczowa jest precyzja logiczna:
- W Rejestrach Wymagań (SRS) oraz opisach User Stories – wymagania muszą być jednoznaczne, a nie uznaniowe.
- W Kryteriach Akceptacji (Acceptance Criteria) – tam zamiast „w szczególności” muszą pojawić się konkretne, wyliczone punktowo warunki (1, 2, 3…) tworzące jasny, zamknięty i mierzalny zakres (Definition of Done).
- W Specyfikacjach API i kontraktach integracyjnych – niejednoznaczność w strukturach danych lub obsłudze błędów bezpośrednio prowadzi do awarii systemowych.
Gdzie jego użycie jest w pełni naturalne?
Zwrot ten odnajduje swoje w pełni legalne i pożyteczne miejsce w dokumentach wysokopoziomowych, strategicznych i narracyjnych, gdzie operuje się na ogólnej wizji:
- W politykach wewnętrznych i procedurach (Compliance) – gdzie opisujesz ogólne zasady i chcesz zilustrować skalę wpływu na biznes za pomocą otwartego zbioru przykładów.
- W dokumentach koncepcyjnych i wizjach projektu – na etapie wstępnych warsztatów z interesariuszami, zanim jeszcze powstaną twarde wymagania systemowe i architektura rozwiązań.
Podsumowanie
Precyzja języka analityka to lustro, w którym przegląda się jakość przyszłego systemu. Zanim następnym razem użyjesz w specyfikacji zwrotu „w szczególności”, zadaj sobie pytanie: czy intencją jest otwarcie katalogu przykładów, czy precyzyjne domknięcie zakresu? W świecie IT częściej potrzebujemy tego drugiego.
Notatka jest częścią cyfrowego ogrodu. Będzie ewoluować wraz z kolejnymi refleksjami na temat warsztatu analitycznego, modelowania pojęciowego i architektury korporacyjnej.