Ten sam raport, ten sam dzień, trzy różne liczby zamówień. Nikt nie popełnił błędu w kodzie. Po prostu każdy dział rozumiał słowo „zamówienie" inaczej: dla sprzedaży zamówieniem był potwierdzony koszyk, dla magazynu dopiero wydanie z półki, dla finansów wystawiona faktura. Na warsztatach nikt tego nie wyłapał, bo wszyscy używali tego samego słowa i wszyscy kiwali głowami.
Miałem taki projekt. To jest jedna z tych rzeczy, które nie wychodzą w dokumencie ani w code review. Wychodzą na produkcji, kiedy ktoś porówna dwa raporty i zapyta, który kłamie.
W tym tekście pokazuję, jak zbudować słownik pojęć projektu, żeby ta rozmowa odbyła się na starcie, a nie po wdrożeniu. Bez narzędzi za tysiące złotych i bez trzytygodniowego audytu terminologii.
Dlaczego niejednoznaczne pojęcia są droższe niż złe wymagania
Źle napisane wymaganie widać. Ktoś je czyta, marszczy brwi, pyta „co to właściwie znaczy" i wymaganie idzie do poprawki. To normalny koszt pracy z wymaganiami.
Niejednoznaczne pojęcie nie ma takiego mechanizmu obronnego. Ono wygląda na zrozumiane. Analityk pisze „system wysyła powiadomienie do aktywnego klienta", biznes czyta, kiwa głową, deweloper implementuje. Każdy z nich podstawił pod „aktywnego klienta" swoją definicję i każdy jest przekonany, że wszyscy mówią o tym samym. Konflikt ujawnia się dopiero na danych, zwykle po wdrożeniu, kiedy zmiana definicji oznacza już przeliczenie historii, poprawkę raportów i rozmowę o tym, kto to zatwierdził.
Dlatego to jest problem z gatunku „tanio na starcie, drogo na końcu". Godzina na warsztacie kontra tydzień na produkcji.
BABOK Guide wymienia słownik pojęć wśród technik analizy biznesowej. W praktyce jest to jedna z najrzadziej stosowanych technik z całego zestawu, bo wygląda na papierologię. Ronald G. Ross w „Business Knowledge Blueprints" stawia sprawę ostrzej: jeden termin w skali organizacji powinien znaczyć dokładnie jedną rzecz, inaczej żadna komunikacja biznesowa nie jest jednoznaczna. Ta książka wypłynęła zresztą w dyskusji na naszym forum, gdy jeden z uczestników opisywał dokładnie ten sam ból.
Słowa-pułapki: jak je rozpoznać w pięć minut
Nie potrzebujesz słownika na trzysta haseł. Potrzebujesz go na te kilkanaście słów, które wyglądają na oczywiste.
Pułapka ma trzy znaki rozpoznawcze:
- Wszyscy jej używają bez zająknięcia. Im bardziej naturalne słowo, tym mniejsza szansa, że ktoś dopyta o definicję.
- Ma wersję potoczną i wersję systemową. „Klient" w rozmowie to człowiek. „Klient" w bazie to rekord, który może być duplikatem, firmą albo osobą kontaktową.
- Da się ją policzyć. Jeśli słowo trafia do raportu, metryki albo warunku w regule biznesowej, jego definicja ma konsekwencje liczbowe.
Klasyka gatunku, którą spotkasz niemal w każdym projekcie: aktywny, zamówienie, status, zakończony, użytkownik, klient, produkt, dostępny, anulowany, nowy. Do tego dochodzą słowa specyficzne dla branży - w ubezpieczeniach „szkoda", w logistyce „przesyłka", w edukacji „kurs".
Szybki test na warsztacie, który zajmuje trzy minuty: poproś dwie osoby z różnych działów, żeby niezależnie napisały na karteczce definicję jednego słowa. Potem porównajcie. Jeśli definicje się różnią, właśnie znalazłeś pierwszy wpis do słownika i zrobiłeś to bez kłótni, bo problem pokazał się sam.
Jak wygląda wpis, który realnie coś rozstrzyga
Definicja jednym zdaniem to za mało. Wpis, który działa, ma pięć elementów:
1. Termin. Dokładnie w tej formie, w jakiej pada w rozmowach biznesowych, nie w formie technicznej z bazy.
2. Definicja. Jedno zdanie, w języku biznesu, sformułowane tak, żeby dało się na jego podstawie rozstrzygnąć przypadek graniczny. „Aktywny klient to klient, który złożył co najmniej jedno opłacone zamówienie w ciągu ostatnich 12 miesięcy" jest definicją. „Aktywny klient to klient, który z nami współpracuje" nie jest.
3. Właściciel definicji. Imiennie, po stronie biznesu. To nie jest formalność. Kiedy za pół roku ktoś zechce zmienić okno z 12 na 6 miesięcy, musi być jasne, kto ma prawo tę zmianę zatwierdzić. Analityk pilnuje procesu, ale definicji nie wymyśla przy biurku.
4. Przypadki graniczne. Dwa, trzy zdania odpowiadające na pytania, które i tak padną. Czy klient z zamówieniem opłaconym i zwróconym jest aktywny? Czy liczy się data złożenia czy data płatności? Tu mieszka prawdziwa wartość wpisu.
5. Zakazane synonimy. Lista słów, których w dokumentacji nie używamy zamiennie: „użytkownik" to nie „klient", „anulowany" to nie „zwrócony". Ten punkt najczęściej wypada ze słowników i najszybciej się mści.
Nie dokładaj kolumn na zapas. Widziałem szablony słowników z dziesięcioma polami, w tym „poziom istotności" i „data przeglądu". Wypełniło się je raz i nigdy do nich nie wrócono. Pięć pól da się utrzymać przez cały projekt.
Tak wygląda komplet na jednym terminie:
| Pole | Treść |
|---|---|
| Termin | Aktywny klient |
| Definicja | Klient, który w ciągu ostatnich 12 miesięcy złożył co najmniej jedno zamówienie opłacone i niezwrócone. |
| Właściciel | Dyrektor sprzedaży |
| Przypadki graniczne | Liczy się data płatności, nie data złożenia. Zamówienie zwrócone w całości nie liczy się wcale. Zwrot częściowy liczy się. Klient zablokowany zachowuje status do końca okna 12 miesięcy. |
| Zakazane synonimy | „użytkownik" (to konto w systemie), „kontrahent" (to podmiot w księgowości) |
Zwróć uwagę na proporcje. Definicja ma jedno zdanie, a przypadki graniczne cztery - i tak ma być, bo to one rozstrzygają spory, gdy Ty będziesz już na innym projekcie.
Kto to prowadzi, gdy analityków jest kilku
W małym projekcie sprawa jest prosta: prowadzi jeden analityk. Schody zaczynają się w dużym wdrożeniu, gdzie kilka osób pracuje na osobnych modułach i każdy siedzi na swojej działce. Dokładnie takie pytanie padło w dyskusji na naszym forum: co zrobić, gdy modułów jest wiele, analityków paru, a słownika jeszcze nie ma.
Sprawdza się model dwóch poziomów:
Poziom projektu - terminy wspólne. Kilkanaście słów, które przechodzą przez wszystkie moduły: klient, zamówienie, status, użytkownik. Prowadzi je jedna osoba, definicja jest jedna dla całego projektu, zmiana wymaga uzgodnienia. To jest twarda część.
Poziom modułu - terminy lokalne. Słowa, które żyją tylko w jednym obszarze: „limit kredytowy" w module finansowym, „slot dostawy" w logistyce. Prowadzi analityk modułu, nikt mu w to nie wchodzi.
Reguła rozstrzygająca konflikty jest jedna: jeśli ten sam termin ma dwie różne definicje w dwóch modułach, to albo definicja idzie na poziom projektu i zostaje ujednolicona, albo jedno z pojęć dostaje inną nazwę. Trzeciej możliwości nie ma, bo trzecia możliwość to właśnie te trzy różne liczby w raporcie.
I najważniejsze przy starcie od zera: nie czekajcie na komplet. Zacznijcie od pięciu terminów, tych najbardziej spornych. Słownik, który powstaje w miarę pracy, przeżyje. Słownik jako osobny projekt umrze na etapie planowania.
Gdzie to trzymać, żeby ktoś do tego zaglądał
Miejsce ma mniejsze znaczenie niż widoczność, ale nie jest obojętne. Trzy warunki: jedno miejsce, dostęp dla wszystkich bez proszenia o uprawnienia, link wklejany do każdej specyfikacji.
W praktyce najczęściej ląduje to na wiki zespołu. Confluence pojawia się w 15 z 310 aktywnych ogłoszeń dla analityków na naszym job boardzie, a Jira w 21 (odczyt z 11 sierpnia 2026, aktualne liczby są na barometrze rynku pracy BA). To narzędzia, które i tak masz pod ręką. Zwykła tabela na stronie wiki wystarczy na cały projekt.
Czego unikać: słownika w załączniku do maila, słownika w arkuszu na czyimś dysku, słownika w rozdziale 2 dokumentu, który ma 80 stron. Wszystkie trzy formy mają jedną wspólną cechę - istnieją, ale nikt do nich nie zagląda.
Osobna sprawa: definicje pojęć branżowych i metodycznych, tych spoza Twojego projektu. Tu nie ma sensu pisać własnych wersji. Do tego mamy słownik pojęć analizy biznesowej - 259 haseł, od interesariusza po traceability. Twój słownik projektowy ma zawierać wyłącznie to, co jest specyficzne dla Twojej domeny i Twoich danych.
Kiedy zacząć i jak to wpleść w warsztaty
Pierwszy wpis powstaje na pierwszym warsztacie, nie po nim. Prowadzisz spotkanie, ktoś rzuca słowo, które brzmi podejrzanie oczywiście, zatrzymujesz się na trzydzieści sekund i pytasz: „zanim pójdziemy dalej - co dokładnie znaczy u was aktywny klient". Zapisujesz odpowiedź przy wszystkich. Jeśli padną dwie odpowiedzi, masz materiał na najciekawszą część warsztatu.
Ta mikropraktyka wpina się w każdą technikę zbierania wymagań: wywiad, warsztat, obserwację. Jeśli chcesz odświeżyć cały zestaw, opisałem go w tekście o technikach elicytacji wymagań, a samo prowadzenie spotkania w poradniku o facylitacji warsztatu wymagań.
Rytm utrzymania jest prosty i nie wymaga procesu: nowy termin dopisujesz w dniu, w którym się pojawił, a raz na sprint przeglądasz wpisy dodane od ostatniego razu. Pięć minut.
Czego słownik nie załatwi
Nie zastąpi modelu danych. Definicja „aktywnego klienta" mówi, co ma być policzone, ale nie mówi, z których tabel i po jakich kluczach - to robota dla modelu danych i ERD.
Nie zastąpi kryteriów akceptacji. Słownik pilnuje znaczenia słów, kryteria pilnują sprawdzalności wymagania. Jedno bez drugiego zostawia lukę, o której piszę w tekście o pisaniu kryteriów akceptacji.
Nie zastąpi specyfikacji. Jest jej częścią, zwykle jednym rozdziałem, i tak trafia do specyfikacji wymagań SRS.
I nie rozwiąże konfliktu interesów. Jeśli dwa działy walczą o definicję, bo od niej zależy ich premia, to nie jest spór terminologiczny i nie rozstrzygniesz go tabelką. Słownik wtedy robi jedno, ale robi to dobrze: pokazuje konflikt na papierze, zamiast pozwalać mu się rozpuścić w miłej rozmowie.
Zacznij od jednego słowa
Nie potrzebujesz zgody zarządu ani nowego narzędzia. Na najbliższym spotkaniu z biznesem wybierz jedno słowo, które pada najczęściej, i zapytaj o definicję. Zapisz odpowiedź, dopisz właściciela i jeden przypadek graniczny. Masz słownik projektu.
Reszta to powtarzanie tego ruchu przez kolejne tygodnie.
Jeśli chcesz przećwiczyć to na realnych artefaktach, a nie na slajdach - na Analify prowadzimy ścieżkę od wymagań przez modelowanie po specyfikację, z materiałami i zadaniami sprawdzanymi przez praktyków. Pierwszą lekcję każdego kursu otwierasz na darmowym koncie. Załóż darmowe konto i zacznij od tego, co rozjeżdża Ci wymagania w bieżącym projekcie.
Najczęstsze pytania
Czym słownik pojęć projektu różni się od słownika branżowego?
Słownik branżowy tłumaczy terminy metodyczne, te same w każdej firmie. Słownik projektu rozstrzyga znaczenie słów w Twojej domenie i na Twoich danych, czyli mówi, kogo dokładnie ta firma nazywa aktywnym klientem. Pierwszy możesz wziąć gotowy, drugiego nikt za Ciebie nie napisze.
Ile terminów powinien mieć słownik projektu?
Kilkanaście, nie kilkaset. Kryterium doboru jest ostrzejsze niż przeczucie, że słowo bywa mylące: bierzesz termin do słownika wtedy, gdy trafia do raportu, metryki albo warunku w regule biznesowej, czyli gdy jego definicja zmienia liczby. Reszta terminologii spokojnie zostaje w tekście dokumentów.
Kto powinien być właścicielem definicji w słowniku projektu?
Osoba z biznesu wskazana z imienia i nazwiska, nie dział i nie analityk. Analityk prowadzi słownik i pilnuje procesu, ale samej definicji nie ustala, bo od niej zależą liczby, z których ktoś jest rozliczany. Właściciel przydaje się głównie później: gdy ktoś zechce zmienić definicję, musi być jasne, kto ma prawo to zatwierdzić.
Jak zacząć słownik, gdy projekt już trwa?
Nie od kompletu, tylko od pięciu najbardziej spornych terminów. Na najbliższym spotkaniu poproś dwie osoby z różnych działów o niezależne zapisanie definicji jednego słowa i porównajcie wyniki. Jeśli definicje się różnią, masz pierwszy wpis i dowód, że słownik jest potrzebny, bez przekonywania kogokolwiek.