Technik kończy długi dzień u klienta, wraca do biura i jeszcze czeka na niego papierologia. Co robił? Dla którego klienta? Ile godzin?
Potem ktoś inny potrzebuje tych informacji w systemie do zarządzania projektami. Więc tę samą pracę zapisuje się drugi raz.
W Sensem, hiszpańskiej firmie produkującej drzwi, tak wyglądała codzienność. Rano technicy zgłaszali, czym będą się zajmować, i ruszali w teren. Osiem do dziesięciu godzin później wracali do biura i próbowali przypomnieć sobie dzień na tyle dokładnie, żeby wypełnić kartę pracy.
Pascual Brines tak opisał ten proces, w tłumaczeniu z hiszpańskiego:
"Wcześniej zapisywaliśmy wszystko ręcznie na papierze... To był formularz, którego używaliśmy do rejestrowania codziennej pracy każdego pracownika."
Godziny to była tylko część problemu. Szczegóły zlecenia uciekały z pamięci, zanim ktoś zdążył je zapisać. Notatki, które mogły pomóc kierownikowi zaplanować kolejne zlecenie albo zrozumieć opóźnienie, nigdy nie trafiały do biura.
Nie było tego w wymaganiach biznesowych, ale nie dawało mi spokoju jedno pytanie: "Jak usprawnić im pracę, nie dokładając ludziom roboty?"
Notatki. Dać ludziom możliwość zapisania, co się wydarzyło, kiedy jeszcze mieli to świeżo w głowie. Przy okazji wpisywania godzin, które i tak musieli raportować. Kierownicy dostają potrzebne szczegóły, a technicy nie muszą odtwarzać całego dnia z pamięci. W tę stronę chciałem pójść.
Miałem jeden kontakt i dziesięć osób, dla których budowałem
Zająłem się projektem, pracując w Neotic, mniej więcej w styczniu 2025 roku. Pomagaliśmy hiszpańskim firmom cyfryzować codzienną pracę. W tym czasie program Kit Digital oferował dotacje z funduszy unijnych na wdrażanie narzędzi cyfrowych w małych firmach, również jednoosobowych.
Moim kontaktem był Pascual Brines, Product Manager i właściciel Sensem. Wyjaśniał potrzeby firmy, przekazywał uwagi zespołu i podejmował ze mną decyzje. Wszystko omawialiśmy po hiszpańsku. Aplikacja też miała być po hiszpańsku.
Budowałem dla około dziesięciu osób: siedmiu techników i trzech kierowników projektów. Większość techników była starsza, po czterdziestce, pięćdziesiątce lub więcej, i nie radziła sobie szczególnie dobrze z technologią. Potrzebowali zapisać swoją pracę i wrócić do swoich spraw.
Chciałem, żeby aplikacja była idiotoodporna. Nie ma nic sexy w tłumaczeniu każdemu technikowi nowego programu tylko po to, żeby mógł wpisać godziny. To dodatkowa robota dla niego i dla osoby, która musi wszystko wyjaśniać.
Oprogramowanie powinno być proste dla użytkownika i nadal robić to, czego potrzebuje firma. Otwierasz, wiesz, co zrobić, robisz, zamykasz. Jeśli ktoś potrzebowałby instruktażu za każdym razem, gdy chce wpisać godziny, to ja nie wykonałem swojej pracy.
Ustaliłem wymagania, zaproponowałem rozwiązanie, rozpisałem specyfikację, zaprojektowałem ekrany i zbudowałem aplikację. Pascual miał jedną osobę, do której mógł zadzwonić w sprawie projektu. Ja miałem jedną osobę, która znała firmę i mogła dać mi odpowiedzi.
Wymagania były konkretne:
- Technicy mogli przypisywać godziny do właściwego klienta i projektu oraz dodawać notatki.
- Kierownicy widzieli wpisy bez zbierania i przepisywania kart pracy.
- Kierownicy sami zarządzali statusami projektów i kontami pracowników.
- Raporty pokazywały, na co idzie czas, i pomagały rozdzielać pracę.
- Codzienna obsługa musiała być prosta na telefonie.
Od tego ostatniego punktu zależało, czy cała reszta w ogóle będzie miała znaczenie.
Wystarczyła prosta aplikacja
Technicznie był to prosty CRUD. Dodaj rekord, odczytaj, zmień, usuń. Coś, co spokojnie można zbudować na projekt dyplomowy. Klienci, projekty, ludzie, wpisy czasu i raporty.
Trudniejsza część polegała na zrozumieniu, jak to wszystko ma się zmieścić w czyimś dniu pracy. Bubble pozwalało zbudować ekrany i logikę działania, a hosting był w pakiecie.
Mogłem więc poświęcić więcej czasu temu, jak ludzie będą z aplikacji korzystać. Osobna baza danych, hosting i proces wdrażania oznaczałyby dodatkową pracę, która w niczym nie pomagałaby technikowi wpisać godzin.
Koszt abonamentu był dla klienta akceptowalny. Neotic też inwestowało wtedy w low-code i szkoliło ludzi z realizacji projektów w takich narzędziach. Potrzeby klienta pasowały do naszego sposobu pracy.
Szczerze, Bubble mnie zaskoczyło. Nie spodziewałem się, że narzędzie low-code pozwoli mi zrobić aż tyle. Budowanie w nim było przyjemnością. Poradniki też były naprawdę przydatne. Jeśli zaczynasz z Bubble, przerób je. Oszczędzisz sobie sporo zgadywania.
Dla kogoś, kto żyje kodem, a ostatnio także niepokojącą liczbą plików Markdown, to była miła odmiana. Można było bez pisania kodu stworzyć coś, czego prawdziwa firma będzie używać codziennie. Całkiem fajna sprawa.
Nie wszystko szło gładko. Rozwijane menu w panelu zarządzania wymagało obejścia na telefonach. Najwyraźniej nawet mała aplikacja wewnętrzna musi mieć swojego bossa do pokonania.
Wpisanie pracy zajmowało około 45 sekund
Kierownicy tworzyli klientów i projekty. Technik otwierał aplikację, wybierał klienta i projekt, wpisywał godziny, dodawał notatki i zapisywał wpis.
Zajmowało to około 45 sekund.
Każdy miał swoje konto. Kierownicy mogli dodawać pracowników, dezaktywować konta i nadawać uprawnienia do zarządzania. Klienci nie potrzebowali dostępu. To było narzędzie dla ludzi wykonujących i organizujących pracę.
Technicy zapisywali, co zrobili. Na tej podstawie kierownicy decydowali o kolejnych krokach i ustawiali status projektu: nierozpoczęty, w toku, zakończony lub anulowany.
Zmieniła się też obsługa telefonów od klientów. Wcześniej pytanie o postęp mogło oznaczać, że najpierw trzeba zadzwonić do technika. Teraz kierownik otwierał panel i mógł odpowiedzieć na podstawie wpisów i statusu projektu.
Raporty obejmowały godziny i liczbę projektów na klienta, średni i medianowy czas poświęcony projektom, ich przebieg w czasie, wartość klientów i obciążenie techników. Kierownicy widzieli, na co idą godziny i gdzie warto inaczej rozdzielić pracę.
Po pięciu dniach przestali sięgać po papier
Całość zajęła około sześciu tygodni, razem z wymaganiami, budowaniem, zbieraniem uwag i dostarczeniem aplikacji.
Po drodze było sporo rozmów i poprawek. Zmieniałem ekrany i logikę na podstawie uwag od Pascuala, a raporty dopasowywałem do tego, co kierownicy potrzebowali zobaczyć. Kiedy zespół zaczął korzystać z aplikacji, podstawowy proces był już gotowy. Zostały głównie drobne poprawki interfejsu.
Przez pierwszy tydzień roboczy technicy używali aplikacji i nadal wypełniali papierowe karty pracy. Mieli czas się przyzwyczaić i sprawdzić, czy nowy sposób działa.
Po pięciu dniach zrezygnowali z papieru.
Z tego jestem najbardziej dumny. Nigdy nie rozmawiałem bezpośrednio z technikami. Wszystko przechodziło przez Pascuala. Musiałem zrozumieć ich dzień i zaprojektować pracę z aplikacją dla osób, które niespecjalnie miały ochotę uczyć się nowego programu.
A to oni zdecydowali, że po tygodniu mogą odłożyć papier. Razem z kierownikami chcieli dalej używać tego, co zbudowałem.
To było jedno z tych rzadkich wdrożeń, w których wszystko układa się tak, jak liczyłeś. Kilka drobnych poprawek, głównie w interfejsie, i zespół po prostu pracował. Po całym tym myśleniu, budowaniu i ustalaniu szczegółów, cholera, to było świetne uczucie.
Mogli odłożyć narzędzia i wrócić do domu
Klient oszacował, że nowy proces oszczędza każdemu technikowi około 15 minut dziennie. To był jego szacunek oparty na obserwacji, a nie badanie ze stoperem.
Przy siedmiu technikach i 21 dniach roboczych w miesiącu daje to około 37 godzin. Bez doliczania czasu, który kierownicy oszczędzali na zbieraniu kartek, przepisywaniu danych i dopytywaniu o postępy.
Piętnaście minut brzmi niepozornie, dopóki to ty nie siedzisz nad kartą pracy po długim dniu. Odzyskanie tego kawałka dnia ma znaczenie.
Zamiast całego rytuału na koniec dnia wystarczyło zostawić narzędzia w biurze i iść do domu. Czasem nie trzeba było wracać do biura w ogóle. Nie czekała tam żadna karta pracy do wypełnienia.
Wiem, że aplikacja służyła do codziennej pracy przez co najmniej osiem miesięcy, kiedy jeszcze zajmowałem się projektem. Byliśmy dostępni w razie potrzeby wsparcia, ale klient nie prosił w tym czasie o kolejne funkcje.
Jest w tym coś bardzo satysfakcjonującego. Mnie dobrze się ją budowało. Im dobrze się jej używało. Po kilku drobnych poprawkach nikt nie potrzebował, żebym dalej tłumaczył, jak działa.
Papier dostał pięciodniowe tournée pożegnalne. Potem wszyscy wrócili do swojej roboty :)