Specyfikacja systemu ewidencji dla sieci lombardów

Zadanie

Zastawy w sieci rejestruje się w PawnExpert: program jest potrzebny do sprawozdawczości wobec regulatora i pozostaje głównym. Resztę ewidencji każdy oddział prowadzi w Excelu: kasę, skup metali, sprzedaż, losy przedmiotów, których klient nie wykupił. Podsumowanie sieci właściciel zbiera telefonami do pracowników. Gdzie trafił niewykupiony przedmiot, nie widać od razu, a ręczna ewidencja zostawia miejsce na błędy i nadużycia: rozbieżności w kasie, zaniżoną wagę przy skupie.

Analiza

Przed projektowaniem przeanalizowano eksporty PawnExpert i arkusze Excel oddziałów: jakie pola są, gdzie dane się rozjeżdżają, czego brakuje do podsumowania. Od razu wyszło główne ograniczenie: PawnExpert nie ma API, więc nowy system może tylko czytać jego eksport. Zasad, których nie ma w danych, starczyło na dziewięć pytań do właściciela, między innymi o limit pożyczki względem wyceny, premie pracowników i przedziały cen skupu.

Specyfikacja

Specyfikację napisano według standardu ANSS. System uzupełnia PawnExpert: bot Telegram wysyła właścicielowi podsumowanie sieci o 9:00, alerty o terminach i przyciski, którymi decyduje o losie niewykupionego przedmiotu; aplikacja webowa daje pracownikom na telefonie kasę, skup, ewidencję przedmiotów i zmiany. Granice są zapisane: PawnExpert nie jest zastępowany, archiwum z Excela nie jest przenoszone.

Pięć niezmienników chroni to, po co właścicielowi ten system. Bez zdjęcia przedmiot nie jest przyjmowany. Jednej umowy nie da się wprowadzić dwa razy. Operacji się nie usuwa, tylko oznacza, kto i dlaczego. Kierunek niewykupionego przedmiotu wybiera tylko właściciel. Cena skupu za gram spoza przedziału czeka na jego zgodę. Każde wymaganie ma kryteria odbioru.

Przegląd przed kodem

Przed rozwojem agent Claude Code przeczytał specyfikację z jedną zasadą: więcej niż trzy problemy, kodu nie ma. Agent się zatrzymał i zgłosił około 15 uwag, cztery blokujące: brak prawdziwego pliku PawnExpert do parsowania, brak tabel w schemacie bazy, choć relacje już na nie wskazują, brak wzoru oczekiwanego salda kasy, brak opisu, co robić z zastawem, który zniknął z eksportu. W kodzie każda z nich oznaczałaby przeróbkę. Zanonimizowana specyfikacja i odpowiedź agenta są opublikowane jako przykład w repozytorium ANSS.

Wynik

Gotowe są analiza danych, specyfikacja z przeglądem agenta, prototyp ekranu pracownika i oferta etapowa. Właściciel odłożył wdrożenie. Systemu nie zbudowano, pomiarów nie ma.

Co z tego przydaje się dziś

Gdy ewidencja opiera się na programie bez API, analiza zaczyna się od pytania, jakie dane da się z niego wyciągnąć i w jakiej formie. Niezmienniki ustalają, na co system nie może pozwolić w żadnych warunkach. Przegląd specyfikacji agentem przed kodem wyłapuje błędy, póki ich poprawka kosztuje jedną linijkę tekstu.