Aplikacja dla wypożyczalni samochodów zamiast arkusza

Wypożyczalnia samochodów terenowych prowadzona przez jedną osobę. Auta wracają z bezdroży, więc zużywają się inaczej niż flota miejska - a przy terenówce pozycji do pilnowania jest więcej niż w zwykłym samochodzie, bo dochodzi cały napęd na cztery koła.

To był pierwszy problem, jeszcze zanim ktokolwiek pomyślał o programie. Przekładnie, osie, hamulce, filtry i płyny mają po dwa terminy naraz: co tyle a tyle kilometrów albo co tyle a tyle miesięcy, zależnie od tego, co wypadnie wcześniej. W arkuszu oznacza to, że przy każdej pozycji ktoś musi ręcznie porównać dwie liczby z rzeczywistością.

Arkusz to wytrzymywał. Rozrósł się o kolejne zakładki, był uzupełniany na bieżąco i formalnie zawierał wszystko. Nie odpowiadał tylko na jedno pytanie: które auto mogę dziś wydać.

Od czego zaczęliśmy

Od arkusza, nie od ekranów. Przeszliśmy przez zakładkę po zakładce i przy każdej kolumnie pytaliśmy, po co jest i kiedy ostatnio się przydała. Część powstała kiedyś do jednej sytuacji i została na zawsze - te wypadły z zakresu, zanim cokolwiek zaczęliśmy budować.

Wyszły dwie rzeczy, których nie było w opisie zlecenia:

• Właściciel nie potrzebuje raportu o flocie. Potrzebuje jednej odpowiedzi: co wymaga działania teraz. Cała reszta może być schowana.
• Najgroźniejszy scenariusz to nie zapomniany serwis, tylko wydanie auta, przy którym coś jest już po terminie. Przy samochodzie, który jedzie w góry na tydzień, to nie jest kwestia porządku w papierach.

Druga obserwacja przesądziła o kształcie całej aplikacji.

Co zbudowaliśmy

Pulpit floty jest ekranem startowym. Każde auto ma na nim kartę ze stanem gotowości, przebiegiem i licznikiem pozycji krytycznych, ostrzeżeń oraz braków w danych. Jeden rzut oka wystarczy, żeby wiedzieć, czym można dziś wyjechać.

Karta pojedynczego auta to harmonogram pogrupowany po zespołach - napęd 4x4, hamulce, kabina, chłodzenie, elementy zużywalne. Każda pozycja niesie swój interwał i odliczanie w obie strony naraz: ile dni i ile kilometrów zostało do następnego terminu. Wpisanie nowego przebiegu przelicza całą listę od razu, bo przebieg jest jedyną rzeczą, którą trzeba wprowadzać ręcznie.

Obok harmonogramu karta auta trzyma jego dane, polisy i historię wykonanych serwisów wraz z kosztem. Ubezpieczenie ma swój termin dokładnie tak samo jak filtr kabinowy, więc leży w tym samym miejscu, a nie w osobnym folderze z przypomnieniem wpisanym do kalendarza. Odpowiedź na pytanie „kiedy to było robione ostatnio“ też przestała wymagać szukania w mailach.

Kluczowa decyzja: stan gotowości auta nie jest polem do wpisania, tylko wynikiem. Nikt nie zaznacza, że auto jest sprawne - program sam stawia je w stanie zablokowanym, gdy któraś pozycja przekroczy termin. Ostrzeżenie da się kliknąć i zapomnieć w pośpiechu, zwłaszcza gdy klient stoi przy biurku. Wyliczony status zdejmuje tę ocenę z człowieka i to jest cała różnica między arkuszem a systemem, bo arkusz niczego nie policzy sam.

Progi zamiast sztywnych reguł

Ostrożność jest ustawieniem, nie założeniem wpisanym w kod. Ostrzeżenie zapala się z zadanym wyprzedzeniem - osobno w dniach i osobno w kilometrach - a osobny próg mówi, ile pozycji w stanie ostrzeżenia auto może mieć, zanim przestanie być oznaczone jako gotowe i trafi do stanu serwisowego.

To była świadoma decyzja, żeby nie wracać do nas z każdą zmianą podejścia. Wypożyczalnia w sezonie i wypożyczalnia zimą to dwa różne poziomy ryzyka, a jedno i drugie ustawia się w tym samym oknie.

Dlaczego natywny macOS, a nie panel w przeglądarce

Firma jest jednoosobowa, a właściciel od lat pracuje na Macu. Panel webowy oznaczałby serwer do utrzymania, konto do logowania i zależność od łącza - trzy rzeczy więcej do pilnowania w firmie, która chciała mieć ich mniej.

Dane zostają lokalnie na jego komputerze, a cała baza to jeden plik, który kopiuje się na dysk zewnętrzny jak każdy inny dokument. Nic nie wychodzi na zewnątrz i nie ma bazy w chmurze, którą trzeba by chronić. Przy jednym użytkowniku i tej skali floty synchronizacja między urządzeniami rozwiązywałaby problem, którego ta firma nie ma.

Jak poszło wdrożenie

Pierwsza działająca wersja trafiła do klienta po tygodniu - z jego prawdziwymi autami i terminami przepisanymi z arkusza, nie z danymi testowymi. To był świadomy wybór: na wymyślonych rekordach nie widać, czy program odpowiada na pytania, które ktoś zadaje sobie w środę rano.

Drugi tydzień poszedł w całości na poprawki wynikające z pierwszych dni pracy na żywo. Po dwóch tygodniach arkusz przestał być otwierany.

Co się zmieniło po starcie

Najważniejsza zmiana nie da się zapisać liczbą: zniknęło pytanie „czy na pewno wszystko jest aktualne“. Wcześniej odpowiedź wymagała przejścia przez kilka zakładek, teraz widać ją od razu po uruchomieniu programu.

Uczciwie o pomiarze: to firma jednoosobowa, która nie prowadziła statystyk sprzed wdrożenia. Nie mamy więc porównania w rodzaju „wcześniej zajmowało to tyle, teraz tyle“. Liczby pod tym tekstem opisują stan po starcie, a nie oszczędność wyliczoną z danych klienta.

Nie wszystko przewidzieliśmy. Pierwsza wersja śledziła ten zestaw przeglądów, który dało się wyczytać z arkusza - a w praktyce okazało się, że właściciel pilnuje jeszcze kilku dodatkowych pozycji, których nigdzie nie zapisywał, bo trzymał je w głowie. Dołożyliśmy je już po starcie i to była największa zmiana zakresu w tym projekcie.

Wniosek na przyszłość jest banalny i kosztowny: arkusz klienta pokazuje to, co ktoś zapisał, a nie to, czego naprawdę pilnuje. Następnym razem pytamy o jedno i drugie.