"Jeżeli klient ma pozytywną historię kredytową oraz dochód powyżej progu, to przyznajemy limit, chyba że wniosek dotyczy kwoty wyższej niż standardowa, wtedy dodatkowo wymagamy zabezpieczenia, o ile klient nie jest klientem premium". Takie zdanie znalazłem kiedyś w dokumencie wymagań. Jedno zdanie, cztery warunki, trzy wyjątki. Deweloper zaimplementował je po swojemu, tester zrozumiał po swojemu, a biznes miał na myśli coś trzeciego.
Ten problem rozwiązuje się jednym narzędziem: tabelą decyzyjną. To jedna z tych technik, które w BABOK-u (technika "Decision Modelling") wyglądają niepozornie, a w praktyce ratują projekt.
Kiedy if-y opisane prozą przestają działać
Proza wytrzymuje dwa, może trzy warunki. "Jeśli klient jest nowy, daj 5% rabatu" - okej, to jeszcze działa. Ale logika biznesowa rzadko jest taka grzeczna.
Prawdziwe reguły mają kilka warunków wejściowych, wyjątki i przypadki brzegowe. Przy trzech warunkach typu tak/nie masz już 8 kombinacji. Przy czterech - 16. Spróbuj opisać 16 przypadków zdaniami podrzędnie złożonymi i policz, ile z nich zgubisz po drodze.
Objawy, że pora na tabelę:
- W wymaganiach pojawiają się zdania z więcej niż jednym "chyba że".
- Deweloper pyta "a co, jeśli klient ma historię, ale nie ma dochodu?", a odpowiedzi w dokumencie nie ma.
- Tester zgłasza buga, biznes mówi "przecież to oczywiste", a w specyfikacji tego przypadku po prostu nie ma.
Tabela decyzyjna zamienia prozę na macierz: każda kolumna (albo wiersz, zależnie od konwencji) to jedna reguła, którą widać w całości. Nie da się "zapomnieć" kombinacji, bo puste pole w tabeli krzyczy samo.
Budowa tabeli decyzyjnej: warunki, akcje, reguły
Tabela decyzyjna ma trzy części:
- Warunki - pytania, na które odpowiadasz na wejściu (np. "dochód netto >= 6000 zł?").
- Akcje - co system albo człowiek ma zrobić (np. "przyznaj automatycznie").
- Reguły - kolumny łączące konkretną kombinację odpowiedzi z konkretną akcją.
Zobaczmy to na scoringu wniosku kredytowego. Trzy warunki tak/nie, więc pełna tabela ma 2 x 2 x 2 = 8 reguł:
| Warunek | R1 | R2 | R3 | R4 | R5 | R6 | R7 | R8 |
|---|---|---|---|---|---|---|---|---|
| Dochód netto >= 6000 zł | T | T | T | T | N | N | N | N |
| Pozytywna historia w BIK | T | T | N | N | T | T | N | N |
| Umowa o pracę min. 6 mies. | T | N | T | N | T | N | T | N |
| Akcja | ||||||||
| Zgoda automatyczna | X | |||||||
| Analiza ręczna | X | X | X | |||||
| Odmowa | X | X | X | X |
Czytasz kolumnami: reguła R1 mówi "dochód jest, historia czysta, umowa stabilna - przyznaj automatycznie". R4: "dochód jest, ale ani historii, ani stabilnego zatrudnienia - odmowa".
Osiem przypadków, zero zdań podrzędnych, zero "chyba że". Biznes patrzy na kolumnę R5 (dochód poniżej progu, ale czysty BIK i stabilna umowa) i od razu decyduje: potwierdza analizę ręczną albo mówi "nie, to od razu odmowa". Rozmowa o regułach trwa minuty zamiast tygodni.
Tabelę można potem skompresować: jeśli przy negatywnej historii BIK i braku stabilnej umowy zawsze wychodzi odmowa, niezależnie od dochodu, to reguły R4 i R8 sklejasz w jedną z kreską ("-" = wartość nieistotna). Mniej kolumn, ta sama logika. Kompresuj dopiero PO zbudowaniu pełnej tabeli, nigdy przed - inaczej właśnie w kompresji zgubisz przypadek.
Kompletność i spójność: jak sprawdzić, że nie zgubiłeś reguły
Tu tabela decyzyjna bije prozę na głowę, bo poprawność da się policzyć.
Kompletność. Liczba reguł w pełnej tabeli to iloczyn liczby wartości każdego warunku. Trzy warunki tak/nie = 8 reguł. Warunek o trzech wartościach (segment klienta: standard / premium / VIP) i dwa tak/nie = 3 x 2 x 2 = 12. Twoja tabela ma mniej i to nie jest świadoma kompresja? Gdzieś jest dziura. W prozie tej dziury nie zobaczysz nigdy, w tabeli widzisz ją od razu.
Spójność. Dwie reguły są sprzeczne, gdy mają te same wartości warunków, ale różne akcje. W dokumentach łatanych przez kilka osób to norma: na stronie 4 ktoś dopisał wyjątek dla klientów premium, na stronie 11 ktoś inny dopisał inny. W tabeli sprzeczność to dwie identyczne kolumny warunków z różnymi X-ami. Widać gołym okiem.
Redundancja. Dwie reguły o tych samych warunkach i tej samej akcji to duplikat. Nie psuje logiki, ale zaciemnia tabelę.
Praktyczny rytuał z warsztatów z biznesem: buduję pełną tabelę ze wszystkimi kombinacjami, nawet "bezsensownymi", i przechodzę z interesariuszami kolumna po kolumnie z jednym pytaniem: "co system robi w TYM przypadku?". Najcenniejsze są odpowiedzi, przy których zapada cisza - to reguły, które w wersji prozą nigdy by nie powstały i wybuchłyby na produkcji.
DMN w pigułce: diagram wymagań decyzyjnych i hit policy
DMN (Decision Model and Notation) to standard OMG, tej samej organizacji, która stoi za BPMN i UML. Nie musisz znać całej specyfikacji. Do codziennej pracy analityka wystarczą dwa elementy.
Diagram wymagań decyzyjnych (DRD) pokazuje, z czego decyzja się składa i skąd bierze dane. Cztery klocki:
- Decyzja (prostokąt) - np. "Oceń wniosek kredytowy".
- Dane wejściowe (owal) - np. "Dane o dochodach", "Raport BIK".
- Model wiedzy biznesowej (prostokąt ze ściętymi rogami) - reużywalna logika, najczęściej właśnie tabela decyzyjna.
- Źródło wiedzy (element z falowaną krawędzią) - skąd reguły pochodzą: rekomendacja regulatora, polityka ryzyka, dział prawny.
DRD mówi, CO wpływa na decyzję; tabela decyzyjna - JAK dokładnie decydujemy. Duże decyzje rozbijasz na mniejsze: "Oceń wniosek" korzysta z pod-decyzji "Oceń zdolność" i "Oceń wiarygodność", każda ma własną tabelę. To ratuje przed tabelami-potworami na 200 reguł.
Hit policy mówi, co się dzieje, gdy do danych wejściowych pasuje więcej niż jedna reguła. Oznacza się ją literą w lewym górnym rogu tabeli:
- U (Unique) - reguły się nie nakładają, pasuje zawsze dokładnie jedna. Najbezpieczniejsza, bo wymusza spójność. Zaczynaj od niej.
- F (First) - pasować może kilka, wygrywa pierwsza od góry. Wygodna, ale kolejność wierszy staje się częścią logiki.
- A (Any) - może pasować kilka, ale wszystkie muszą dawać ten sam wynik.
- P (Priority) - wygrywa reguła o najwyższym priorytecie wyniku.
- C (Collect) - zbierasz wyniki wszystkich pasujących reguł, np. sumujesz rabaty.
Ta litera to skodyfikowana odpowiedź na pytanie, które i tak padnie od dewelopera: "a jak pasują dwie reguły naraz, to która wygrywa?". A jeśli obok DMN układasz sobie w głowie cały temat certyfikatów i standardów, porównanie rynkowych certyfikacji BA znajdziesz na analify.pl/certyfikacje.
Tabela decyzyjna a BPMN: gdzie decyzja mieszka w procesie
Częsty błąd: modelowanie logiki decyzyjnej bramkami w BPMN. Trzy warunki po kilka wartości i Twój diagram procesu zamienia się w choinkę bramek XOR, której nikt nie ogarnia.
Podział ról jest prosty. BPMN pokazuje kiedy decyzja zapada i co się dzieje potem. DMN pokazuje jak decyzja jest podejmowana. W procesie stawiasz jedno zadanie typu business rule task ("Oceń wniosek kredytowy"), a za nim jedną bramkę z wyjściami odpowiadającymi akcjom z tabeli: zgoda / analiza ręczna / odmowa. Cała macierz warunków żyje w tabeli DMN podpiętej pod to zadanie.
Efekt: diagram procesu zostaje czytelny, a logikę decyzji zmieniasz bez przerysowywania procesu. Biznes zmienił próg dochodu z 6000 na 7000 zł? Edytujesz jedną komórkę tabeli, proces nietknięty.
Jeśli dopiero układasz sobie warsztat BPMN, zacznij od artykułu o tym, jak narysować diagram procesu biznesowego, a potem wracaj tu po warstwę decyzyjną.
Z tabeli do testów: gotowe przypadki testowe niemal za darmo
To mój ulubiony argument w rozmowach z zespołami QA: dobra tabela decyzyjna to gotowy plan testów.
Każda reguła tabeli to jeden przypadek testowy. Kolumna R4 ze scoringu wyżej czyta się wprost jako scenariusz:
Dane: dochód 8500 zł, negatywna historia w BIK, umowa o dzieło od 2 miesięcy. Oczekiwany wynik: odmowa.
Osiem reguł = osiem przypadków testowych pokrywających całą logikę decyzji. Bez zgadywania, bez "przetestujmy jeszcze parę losowych kombinacji na wszelki wypadek". Do tego dorzucasz testy wartości brzegowych na warunkach liczbowych: dochód 5999, 6000 i 6001 zł, bo właśnie na progach implementacje sypią się najczęściej (klasyczny błąd: ">" zamiast ">=").
W jednym z projektów tabela zbudowana na etapie analizy wykryła sprzeczność w regułach przed pierwszą linijką kodu. Koszt: godzina warsztatu z biznesem. Ta sama sprzeczność na testach akceptacyjnych kosztowałaby sprint, a na produkcji - reklamacje klientów.
Umiejętność przekładania wymagań na testowalne reguły realnie widać w ogłoszeniach o pracę dla BA - popyt na konkretne umiejętności analityczne podglądniesz w barometrze rynku BA.
Szablon tabeli + trzy przykłady z różnych domen
Szablon do skopiowania. Wypełniasz pięć sekcji i masz artefakt gotowy do review:
| Sekcja | Co wpisujesz |
|---|---|
| Nazwa decyzji | Czasownik + obiekt, np. "Oceń wniosek kredytowy" |
| Hit policy | U, jeśli nie masz twardego powodu na inną |
| Warunki (wiersze górne) | Pytania z jednoznacznymi wartościami (T/N albo lista) |
| Akcje (wiersze dolne) | Konkretne działania, po jednym X na regułę (przy U) |
| Reguły (kolumny) | Pełny iloczyn kombinacji, kompresja dopiero na końcu |
Zanim wyślesz tabelę do kogokolwiek, przejdź checklistę review:
- Liczba reguł = iloczyn wartości warunków (albo opisana kompresja).
- Brak dwóch identycznych kolumn warunków z różnymi akcjami.
- Przy hit policy U - dokładnie jedna akcja na regułę.
- Granice liczbowe rozstrzygnięte (">=" czy ">").
- Każdą kolumnę zatwierdził właściciel biznesowy, nie "chyba tak będzie dobrze".
Przykład 1 - kredyt masz wyżej w sekcji o budowie tabeli.
Przykład 2 - rabaty w e-commerce (tabela z wpisami rozszerzonymi, czyli wartościami zamiast T/N):
| Wartość zamówienia | Klient w programie lojalnościowym | Rabat |
|---|---|---|
| < 200 zł | Nie | 0% |
| < 200 zł | Tak | 5% |
| 200-1000 zł | Nie | 5% |
| 200-1000 zł | Tak | 10% |
| > 1000 zł | Nie | 10% |
| > 1000 zł | Tak | 15% |
Sześć reguł, komplet kombinacji (3 przedziały x 2 statusy), zero nakładania się przedziałów. Zwróć uwagę na granice: czy 200 zł wpada do pierwszego przedziału, czy do drugiego? W tabeli musisz to rozstrzygnąć, w prozie "przy zamówieniach do 200 zł" nikt by tego pytania nawet nie zadał.
Przykład 3 - uprawnienia w systemie:
| Rola użytkownika | Konto zweryfikowane | Dostęp do raportów finansowych |
|---|---|---|
| Pracownik | Nie | Brak |
| Pracownik | Tak | Tylko odczyt |
| Menedżer | Nie | Brak |
| Menedżer | Tak | Odczyt i eksport |
| Administrator | Nie | Brak |
| Administrator | Tak | Pełny |
Konto niezweryfikowane zawsze daje "Brak", więc trzy reguły skompresujesz do jednej z "-" w kolumnie roli. Ale najpierw pełna tabela, potem kompresja.
Te trzy domeny celowo są różne, bo tabela decyzyjna nie jest techniką "bankową". Działa wszędzie tam, gdzie wynik zależy od kombinacji warunków: naliczanie prowizji, routing zgłoszeń w service desku, kwalifikacja leadów, walidacja formularzy. Jeśli dopiero rozważasz wejście w analizę biznesową, zajrzyj do ścieżek przebranżowienia na analityka - logiczne myślenie warunkami masz pewnie już teraz, tabela tylko nadaje mu formę.
Od czego zacząć
Weź jedną regułę biznesową z projektu, nad którym właśnie pracujesz - taką z co najmniej jednym "chyba że". Rozpisz warunki, policz kombinacje, zbuduj pełną tabelę i pokaż właścicielowi biznesowemu. Cisza przy którejś kolumnie oznacza, że znalazłeś dziurę w wymaganiach, zanim znalazła ją produkcja.
A jeśli chcesz przećwiczyć tabele decyzyjne, DMN i resztę warsztatu analityka na realistycznych zadaniach z feedbackiem, a nie tylko poczytać teorię, załóż darmowe konto na Analify i ucz się robiąc.