Praca offline w terenie — kiedy jest wymogiem, a kiedy wymówką

„Nasi ludzie pracują tam, gdzie nie ma zasięgu” pada w rozmowie o wdrożeniu prawie zawsze. Czasem jest to precyzyjny opis rzeczywistości. Czasem zdanie, które ktoś usłyszał od brygadzisty, powtórzył dalej i nikt go nigdy nie sprawdził.

Różnica jest kosztowna: pełna praca bez sieci to jedna z nielicznych pozycji, które potrafią przesunąć start wdrożenia o kwartał.

Wymóg czy wymówka#

W firmach, z którymi rozmawiamy, to samo zdanie pełni dwie zupełnie różne funkcje.

Bywa opisem faktów. Ekipy schodzące do piwnic i kotłowni, montaż w halach o konstrukcji stalowej, praca na terenach, gdzie sieć kończy się kilometr przed bramą. Przewidywalnie i codziennie.

Bywa sposobem na zamknięcie tematu. Jeżeli w systemie nie da się pracować bez sieci, a sieci „nigdy nie ma”, to nie da się też wymagać raportu na koniec dnia. Zdanie bywa wtedy szczere i nieprawdziwe jednocześnie.

Trzecia sytuacja jest najczęstsza: zasięg jest, tylko słaby, a aplikacja radzi sobie z nim gorzej niż z jego całkowitym brakiem. Ładuje się trzydzieści sekund, gubi wpisany formularz, każe zaczynać od nowa. Rozwiązaniem nie jest wtedy tryb offline, tylko poprawne zachowanie przy złym łączu.

Jak zmierzyć, czy naprawdę tracicie zasięg#

Nie potrzeba do tego oprogramowania. Potrzeba dwóch tygodni i jednej tabelki.

Proś o notatkę, nie o opinię. Cztery kolumny: data, miejsce, ile minut trwało, co wtedy chcieli zrobić. Pytanie „czy macie problemy z zasięgiem” da odpowiedź „ciągle”. Notatka da liczbę.

Ostatnia kolumna jest najważniejsza. Nie liczy się to, ile razy padła sieć, tylko ile razy padła, gdy ktoś czegoś od systemu potrzebował. Brak zasięgu w drodze nie kosztuje nic.

Rozdziel odczyt od zapisu. „Chciałem sprawdzić adres” i „chciałem zamknąć zlecenie” to dwa różne problemy o dwóch bardzo różnych cenach.

Licz czas trwania, nie zdarzenia. Trzy minuty w windzie i cztery godziny w hali produkcyjnej to nie jest ta sama pozycja.

Załóżmy, że przy dwunastu ekipach wyszło kilkanaście zdarzeń miesięcznie, w większości krótkich i w większości dotyczących odczytu — to nie jest materiał na pełny offline. Jeżeli natomiast trzy z tych ekip spędzają po pół dnia poza siecią i akurat one wypełniają najwięcej raportów, odpowiedź jest inna i dotyczy tych trzech ekip, nie całej firmy.

Poziom pierwszy: odczyt z pamięci podręcznej#

Aplikacja trzyma na urządzeniu to, co ostatnio pobrała, i pokazuje to, gdy sieci nie ma. Zlecenia na dziś, adresy, historia obiektu, zdjęcia z poprzedniej wizyty.

Pokrywa to większość zdarzeń z twojej tabeli, bo w terenie dużo częściej potrzebna jest informacja niż możliwość jej wprowadzenia. To także najtańszy z trzech poziomów: dane tylko do odczytu nie tworzą konfliktów, więc jedyną decyzją jest to, co pobierać z wyprzedzeniem.

Jedno trzeba zrobić dobrze: pokazać datę ostatniej aktualizacji. Stare dane wyświetlone jako aktualne są gorsze niż komunikat o braku połączenia. Monter, który pojechał pod adres zmieniony wczoraj, drugi raz temu ekranowi nie zaufa.

Poziom drugi: kolejkowanie zapisów#

Wypełniony formularz, zdjęcie i zmiana statusu nie idą prosto na serwer. Lądują w kolejce na urządzeniu i wychodzą, gdy sieć wróci.

Odpowiada na sytuację, która zdarza się najczęściej: nie „cały dzień bez sieci”, tylko „padło w momencie wysyłki”. Formularz wypełniany przez pięć minut nie może zniknąć dlatego, że ktoś wszedł do windy.

Większa część kosztu leży tu po stronie interfejsu, nie synchronizacji. Kolejka, której nie widać, jest gorsza niż jej brak, bo człowiek nie wie, czy wysłał, więc wysyła drugi raz.

Trzy rzeczy muszą być widoczne bez szukania: ile pozycji czeka, kiedy ostatnio coś przeszło i co zrobić z pozycją, która nie przechodzi. Trzecia jest pomijana najczęściej i to ona generuje telefony do koordynatora.

Poziom trzeci: pełna praca rozłączna#

Cały dzień bez sieci. Człowiek tworzy nowe rekordy, edytuje istniejące, sięga po dane, których nie zdążył pobrać przed wyjazdem, a wieczorem wszystko synchronizuje się w obie strony.

To nie jest poziom drugi, tylko dłuższy: to inna architektura, w której urządzenie przestaje być ekranem do systemu i staje się jego kopią. Trzeba wtedy rozstrzygnąć trzy rzeczy.

Co leży na urządzeniu. Dane firmy w telefonie, który da się zgubić i zostawić w samochodzie — decyzja o zakresie kopii i o utracie sprzętu.

Kto nadaje identyfikatory. Dwie ekipy tworzą offline nowe zgłoszenie. Numer musi powstać na urządzeniu i nie może się powtórzyć po synchronizacji.

Jak rozstrzygane są konflikty. Sekcja poniżej.

Koszt liczy się w miesiącach, nie tygodniach, i nie kończy się przy odbiorze: każda funkcja dołożona później też musi działać rozłącznie. To podatek nałożony na całe wdrożenie, a nie jednorazowa pozycja w wycenie.

Dlatego pełny offline warto traktować jak decyzję o architekturze, nie jak funkcję z listy życzeń. Jeżeli tabela z dwóch tygodni go nie uzasadnia, jest to kwartał opóźnienia kupiony za problem, którego nie macie.

Konflikty, czyli rachunek płatny po wdrożeniu#

Konflikt to sytuacja, w której ta sama rzecz została zmieniona w dwóch miejscach, zanim się spotkały. Ktoś musi zdecydować, która wersja przetrwa.

Najprostsza reguła — wygrywa zapis, który dotarł później — jest jednocześnie najgorsza, bo działa po cichu. Konflikt na polu tekstowym bywa zauważalny, konflikt na liczbie nigdy. Godziny pracy, zużyte materiały, ilość na protokole odbioru — po synchronizacji wszystko wygląda równie wiarygodnie, niezależnie od tego, która wersja wygrała.

Konfliktów lepiej unikać, niż je rozstrzygać: dopisywanie zamiast nadpisywania, osobny wpis każdej osoby zamiast jednego wspólnego pola, status zmieniany przez jedną rolę, nie przez trzy. To decyzje o kształcie danych i zapadają na początku, nie przy synchronizacji.

Osobna sprawa, jeżeli w systemie działa agent wykonujący akcje po zatwierdzeniu przez człowieka. Zgoda wydana offline dotyczy stanu sprzed kilku godzin, więc akcje z kolejki są raczej propozycjami do ponownego spojrzenia niż poleceniami czekającymi na wysyłkę.

Podsumowanie#

Zacznij od poziomu pierwszego: jest tani i pokrywa większość tego, co naprawdę się zdarza. Dołóż drugi, bo chroni pracę, którą ktoś już wykonał. Trzeci wybierz dopiero wtedy, gdy masz na to dane z pomiaru, i zawęź go do ekip, których faktycznie dotyczy.

Najczęstszy błąd nie polega na wybraniu złego poziomu, tylko na przyjęciu wymagania bez sprawdzenia. Dwa tygodnie notatek kosztują mniej niż jedno spotkanie o zakresie i zwykle zmieniają jego wynik.

Pozostałe warunki, które muszą być spełnione, żeby ekipa w ogóle otworzyła aplikację, opisujemy w przewodniku zarządzanie zespołem w terenie.