Opublikowano 21 października 2026 · 4 min czytania
Opisałem cudzy system z rozsądku. Wszystko się zgadzało poza prawdą
Pisałem opis drogi dokumentu przez system biurowy — zapytanie, oferta, umowa, faktura — i doszedłem do miejsca, w którym proces pęka: duplikaty w kartotece klientów. Ten sam klient trzy razy, przy każdej kopii część historii.
Przyczynę napisałem od ręki, bo wydawała się oczywista: wyszukiwarka wymaga dokładnej nazwy, a przy kliencie czekającym w słuchawce szybciej jest założyć nową kartotekę niż znaleźć starą. Zdanie brzmiało dobrze. Każdy, kto pracował w biurze, kiwnąłby głową.
Było nieprawdziwe.
Co powiedziała weryfikacja
Pokazałem tekst osobie, która pracowała w tym systemie pięć lat. Odpowiedź obróciła akapit o 180 stopni.
Wyszukiwarka była dobra. Szukała po nazwie, po numerze klienta i po numerze rejestracyjnym pojazdu — po dowolnym fragmencie, z listą podpowiedzi w trakcie pisania. W biurze szukało się głównie po tablicy rejestracyjnej, bo to jedyna rzecz, którą klient stojący przy ladzie zawsze ma przy sobie.
Duble powstawały mimo to, bo pękało zupełnie inne miejsce: przy zakładaniu klienta program nie sprawdzał niczego. Dało się utworzyć dziesięć kartotek z identyczną nazwą i identycznym adresem. Różnił je wyłącznie kolejny numer klienta.
Widać to dopiero później, w wynikach wyszukiwania — dwie albo trzy pozycje nie do odróżnienia. Żeby rozstrzygnąć, która jest „ta właściwa", trzeba wejść w każdą i zobaczyć, przy której wiszą zlecenia i rachunki. Scalać nie było czym, więc użytkownicy wymyślili własne obejście: przy porzuconej kartotece dopisywano notatkę „nieaktywny, patrz numer klienta …".
Dwie funkcje, które nie mają ze sobą nic wspólnego
To jest sedno, a nie sama pomyłka.
„Dobrze się szuka" i „nie da się założyć dubla" to dwie osobne funkcje systemu. Nic ich nie łączy — ani kod, ani ekran, ani moment pracy. Pierwsza działa przy odczycie, druga przy zapisie. System może mieć jedną w komplecie, a drugiej nie mieć wcale.
Mój błędny opis sklejał je w jeden mechanizm, bo tak podpowiada zdrowy rozsądek: skoro są duble, to pewnie trudno było znaleźć oryginał. Rozumowanie jest sensowne i prowadzi w złe miejsce.
Przy odbiorze wdrożenia sprawdza się prawie zawsze tę pierwszą. Wpisuje się fragment nazwy, widzi się podpowiedzi, kiwa głową. Pytanie o drugą pada rzadko, a brzmi tak:
Co się stanie, gdy założę drugiego klienta o dokładnie tych samych danych?
Odpowiedzią bywa cisza i nowy rekord. Rok czyszczenia kartotek kosztuje wielokrotnie więcej niż jedno ostrzeżenie w chwili zapisu.
Dlaczego nie zorientowałem się sam
Bo w błędnej wersji nie było nic do zauważenia.
Proszę porównać oba zdania:
- Duble brały się z tego, że wyszukiwarka wymagała dokładnej nazwy, więc szybciej było założyć nowego klienta niż znaleźć starego.
- Duble brały się z tego, że przy zakładaniu klienta system nie sprawdzał, czy taki już istnieje.
Oba mają sensowny mechanizm. Oba kończą się tym samym skutkiem. Oba brzmią jak wspomnienie z biura, a nie jak teoria. Czytając, nie da się wskazać, które jest zmyślone — bo zmyślone nie zawiera błędu, zawiera prawdopodobieństwo.
Różnica jest jedna i widać ją dopiero, gdy zna się prawdziwą wersję: prawdziwa zawiera szczegół, którego czytelnik sam by nie wymyślił. Że system z dobrą wyszukiwarką po trzech różnych polach może nie mieć żadnej kontroli przy zapisie. Takich rzeczy się nie zgaduje, bo są nielogiczne — a systemy biurowe rosną latami i nie mają obowiązku być logiczne.
Czego NIE zrobiłem
Nie wróciłem do wyszukiwarki, żeby „i tak o niej wspomnieć". Kusiło, bo akapit był napisany, brzmiał nieźle i szkoda było go kasować — dałoby się go zostawić jako drugą, poboczną przyczynę.
To by było gorsze niż sam błąd. Zdanie „a przy tym wyszukiwarka bywała nieporęczna" jest dokładnie tą samą nieprawdą, tylko schowaną w tle, gdzie nikt jej nie zweryfikuje. Akapit poszedł do kosza w całości.
Nie dopisałem też do tekstu ostrzeżenia „opis może być niedokładny". Adnotacja o niepewności ma sens, gdy naprawdę nie da się sprawdzić. Tutaj dało się — wystarczyło zapytać. Ostrzeżenie byłoby tylko przeniesieniem kosztu weryfikacji na czytelnika, który ma na to gorsze narzędzia niż ja.
Wniosek, który biorę dalej
Dokumentacja procesu pisana „z rozsądku" nie zawiera widocznego błędu. Zawiera gładką nieprawdę. Nie ma w niej miejsca, które by zgrzytnęło — dlatego przechodzi każdą korektę, każde czytanie na głos i każde „brzmi sensownie".
Jedyne, co ją wykrywa, to ktoś, kto tam był. Nie recenzent, nie druga para oczu, nie model językowy — świadek. Odkąd to zobaczyłem, każdy akapit o cudzym systemie dzielę na dwie kategorie: to, co widziałem albo mam na to zapis, i to, co dopisałem, bo pasowało. Druga kategoria nie jest zła. Musi tylko wyjechać do weryfikacji, zanim ktokolwiek ją przeczyta jako fakt.
Nie mylić z sytuacją, w której pomiar się nie udał albo pochodził z innego dnia. Tu pomiaru nie było w ogóle — była prawdopodobna hipoteza postawiona w roli faktu. To najtrudniejszy przypadek do złapania, bo nie ma czego porównać z czym.

Patryk Piecyk
Warszawa · na etacie od 10.2026 · rozwój w stronę ERP/SAP i AI
Przez 7,5 roku pracowałem w niemieckiej firmie, pięć lat prowadząc jej biuro: zamówienia, faktury, reklamacje, ERP. Od czerwca 2026 buduję własne narzędzia do tej samej roboty — nie jestem programistą z wykształcenia, kod powstaje w parze z asystentem AI, a projekt, decyzje i testy są moje. Te notatki opisują, co się w tych systemach zepsuło i co z tego wyszło.
Masz pytanie do tego tekstu?
Napisz do mnie →