Skrzynka Spółdzielni

#DEV LOG: Wpis #01 — Od briefu klienta do projektu systemu

Data: 7 czerwca 2026 Status: Faza projektowania zakończona — budowa startuje w przyszłym tygodniu

#Skąd się to wzięło

Klient zgłosił się do nas z konkretnym problemem operacyjnym: workflow konserwacyjny spółdzielni mieszkaniowej był całkowicie nieustrukturyzowany. Zlecenia napływały nieformalnymi kanałami — telefony, wiadomości, przekaz ustny — i nie było żadnego wiarygodnego sposobu na śledzenie, kto jest za co odpowiedzialny, jaki jest stan każdego zlecenia ani ile zajmuje jego realizacja.

Brief klienta sprowadzał się do tego:

„Potrzebujemy miejsca, gdzie można rejestrować zgłoszenia konserwacyjne, przydzielać je odpowiednim osobom i pozwolić każdemu zobaczyć co się dzieje — z różnymi poziomami dostępu w zależności od roli."

Prosty brief. Naprawdę trudny do dobrego zaprojektowania.

#Co zaprojektowaliśmy razem

Przez ostatni tydzień iterowaliśmy na briefie, żeby przekształcić go w konkretny projekt systemu. Oto co ustaliliśmy.

#Trzy role

System zbudowany jest wokół trzech odrębnych grup użytkowników o bardzo różnych potrzebach:

Właściwy model dostępu od samego początku oszczędza później ogromnego bólu — jedna baza kodu, trzy skoncentrowane interfejsy.

#Cykl życia zlecenia

Każde zlecenie przechodzi przez zdefiniowany cykl:

1. Zarejestrowane — zapisane z: kto zgłosił, data, opis, miejsce realizacji, odpowiedzialny
2. Przydzielone — technik kieruje je do odpowiedniego konserwatora
3. Potwierdzone — pracownik potwierdza odczytanie (widoczne dla innych)
4. W trakcie — pracownik aktualizuje status z komentarzem w miarę postępu prac
5. Zamknięte — oznaczone jako zrealizowane lub udokumentowane jako zablokowane z podaniem przyczyny

Stan zablokowania jest równie ważny jak stan zakończenia. Jeśli zlecenie nie może być wykonane, system rejestruje dlaczego — te dane są równie przydatne operacyjnie jak informacja o realizacji.

#Wieloplatformowy zasięg

Ekipy terenowe nie siedzą przy biurkach. Od pierwszego dnia system celuje w:

• Aplikacja webowa Next.js — responsywna na urządzenia mobilne
• PWA — obsługa offline dla słabego zasięgu w terenie
• Aplikacja desktopowa Electron — dla koordynatorów i kierowników biurowych
• Aplikacja React Native — natywne powiadomienia push i SMS jako fallback (Faza 2)

#Dlaczego Human-in-the-Loop od pierwszego dnia

Zamiast budować automatyzację AI i mieć nadzieję, że jest wystarczająco niezawodna, stosujemy model Human-in-the-Loop (HITL) dla pierwszej fazy:

[ Zgłoszenie ] ──► [ Normalizacja ] ──► [ Widok staging ] ──► [ Człowiek przydziela i zatwierdza ] ──► [ Aktywne ]

Nic nie przechodzi do statusu aktywnego bez ludzkiego zatwierdzenia. To sprawia, że system jest w 100% niezawodny od pierwszego dnia użytkowania, a jednocześnie zbieramy realne dane operacyjne potrzebne do tego, by jakakolwiek przyszła automatyzacja była rzeczywiście godna zaufania.

#Statystyki dla kierownictwa

Kierownicy mają widok tylko do odczytu z najważniejszymi metrykami:

• Czas od rejestracji do realizacji dla każdego zlecenia
• Średni czas realizacji w podziale na typy zleceń
• Liczba zleceń aktualnie w toku

#Co dalej

Faza projektowania jest zakończona. Mamy jasny projekt systemu, uzgodniony model ról i wieloplatformową architekturę, która nie będzie wymagała przepisania gdy wzrośnie obciążenie.

Pierwsza budowa MVP startuje w poniedziałek lub wtorek przyszłego tygodnia.

Pierwsza działająca wersja obejmie podstawowy cykl: rejestracja zlecenia, przydzielanie, aktualizacje statusu i widoki zależne od roli — wystarczająco dużo, żeby klient mógł od pierwszego dnia przepuszczać przez system prawdziwą pracę.

Następny wpis: pierwsza budowa w toku, wczesne decyzje UI i niespodzianki, które pojawiły się gdy prawdziwy kod trafił na prawdziwe wymagania.