Klient jest wejściem do swoich obiektów

Bez owijania: jedna pozycja kosztowa, której nie da się pominąć

Różnica, od której wszystko zależy: rodzic w drzewie kontra wpis w rejestrze

To jedno rozróżnienie tłumaczy, dlaczego Twój pomysł z 22:35 jest dobry, a mimo to nie robimy go przez drzewo.

Innymi słowy: propozycja B daje Ci obraz z 22:35 co do joty, tylko klient jest naklejką, a nie piętrem. Na ekranie wygląda to identycznie. W danych to dwa różne światy, a tylko jeden z nich da się dziś bezpiecznie zmieniać.

01Co powiedziałeś

Sześć zdań z nagrań. Każde z datą, godziną i jednym zdaniem o tym, co z niego wynika dla tej propozycji.

02Sześć znaczeń słowa "klient"

To jest powód, dla którego się pogubiłeś, i nie ma w tym Twojej winy. Słowo "klient" oznacza w Proofixie sześć różnych rzeczy naraz, a napis "Klienci" na pasku nawigacji znaczy co innego zależnie od tego, kto jest zalogowany. Tabela pochodzi z audytu, sekcja 2.

Umowa nazewnicza w tym dokumencie: "Twoja firma" to 2FSG, "Klient" to Benefit System albo Lidl, "Przedstawiciel klienta" to człowiek po ich stronie, "Obiekt" i "pod-obiekt" to miejsca. Nigdzie nie używam słowa "klient" w dwóch znaczeniach naraz.

03Dlaczego to drzewo wyszło dziwnie

Reguła, która porządkuje resztę

04Pięć rzeczy, które naprawiamy zawsze

Te pięć defektów naprawia każda z trzech propozycji. Są wspólną bazą, więc porównując A, B i C porównujesz to, co je różni, a nie to, co i tak trzeba zrobić.

Najważniejszy obrazek: dziś obok tego samego po zmianie

Po lewej Twoja dzisiejsza lista obiektów. Po prawej to, czym staje się wejście w propozycji B. Te same dane, ta sama firma, ten sam dzień.

Uwaga o cytatach z interfejsu: teksty z aplikacji przepisuję dosłownie, z jednym wyjątkiem. Kod używa w kilku miejscach długiej kreski, a w tym dokumencie obowiązuje zakaz tego znaku, więc w każdym takim miejscu stoi zwykły myślnik z odstępami. Nic poza tym nie jest zmienione.

To samo na telefonie: przed i po

D3: formularz mówi wprost, gdzie obiekt wyląduje

To jest naprawa tego, co zaskoczyło Cię o 22:32. Formularz nie zmienia zachowania aplikacji, tylko przestaje je ukrywać.

05Jak to wygląda

Sześć ekranów, każdy na webie i na telefonie. Ramki są przycięte na dole tak samo jak prawdziwy ekran: lista leci dalej, tylko jej nie widać.

Ekran 1: lista klientów z podglądem obiektów

Pełną listę widziałeś już w zestawieniu wyżej. Tu jest ta sama lista przewinięta niżej, do miejsca, w którym kończą się klienci i zaczyna to, co dziś robi największy bałagan.

Ekran 2: karta klienta jako miejsce pracy

To jest serce propozycji B. Najpierw stan dzisiejszy, żeby było widać, ile z tego już jest zbudowane.

Ekran 3: z karty klienta prosto do nowego obiektu

Naprawa D5 w działaniu. Klikasz "Dodaj obiekt" na karcie Benefit System i formularz otwiera się z już wybranym klientem.

Ekran 4: zakładka Obiekty zostaje jako widok "wszystko"

Klienci to jedno wejście, nie jedyne. Pracownik i menedżer częściej szukają obiektu niż firmy, więc lista obiektów zostaje, tylko wreszcie z treścią.

Ekran 5: zarządca, czyli rejestr klientów pusty

To odpowiedź na Twoje zdanie z 22:48 o patrzeniu z dwóch stron. Ekran nie pyta, kim jesteś. Sprawdza, czy masz klientów w rejestrze, i sam się dostosowuje.

Ekran 6: szukanie mówi, gdzie ta rzecz jest

Naprawa D4. Przy 12 obiektach to wygoda. Przy 312 to jedyny sposób pracy.

06Dwie persony obok siebie

To jest sprawdzian z Twojego zdania z 22:48. Ta sama aplikacja, ta sama wersja, dwa różne rodzaje firmy.

Sedno: nikt nie wybiera trybu. Aplikacja czyta liczbę wpisów w rejestrze. Zero nowych przełączników, zero ustawień, których trzeba pilnować.

07Odpowiedź na pytanie z 19.08

"Szukam latwego sposobu, czy do kazdego obiektu trzeba wpisywac klienta czy co?"

08Co to kosztuje

Trzy warstwy. Pierwsza jest tania, bo listy, karty i drzewo już są. Druga to jedyne miejsce, gdzie ta propozycja naprawdę kosztuje. Trzecia jest osobna i nie musi się dziać teraz.

Warstwa 1: sam widok

Warstwa 2: dane i serwer

Warstwa 3: osobna fala

09Czego to NIE robi

Uczciwe granice. Każda z nich jest ograniczeniem dzisiejszej aplikacji, nie wyborem stylu.

1. Nie robi z klienta obiektu. Benefit System nadal nie ma adresu, punktu NFC, zlecenia ani godzin. Nie da się do niego wysłać pracownika. Decyzja z 06.08 stoi.
2. Nie pozwala przenosić obiektów w drzewie. Jeśli masz dziś obiekty pod korzeniem "Utrzymanie terenów zewnętrznych", propozycja B ich nie przestawi. To osobna fala z osobnym testem (audyt 8.2).
3. Nie zmienia tego, że klienta ustawia się tylko na obiekcie głównym. Pod-obiekt dziedziczy klienta z gałęzi i nie da się mu z formularza dać innego. Jedyny wyjątek to zaznaczarka na karcie klienta.
4. Nie łączy dwóch torów liczenia dostępu. Twoi ludzie widzą obiekty po drzewie, przedstawiciel klienta po naklejce klienta. To dwie różne matematyki i migracja z 07.08 wprost zabrania ich mieszania.
5. Nie naprawia tego, że kasowanie klienta odpina obiekty. Usunięcie klienta z rejestru zdejmuje naklejkę ze wszystkich jego obiektów. Same obiekty zostają, ale wpadają do "Bez klienta".
6. Nie daje filtru klienta w zleceniach, obecności i raportach. Zlecenie nie ma kolumny klienta. Dołożenie tam filtru to osobna pozycja, nieujęta w tej wycenie.
7. Nie opiera niczego na rodzaju usługi. To wolny tekst bez słownika. Jeśli go chcesz jako oś, to osobna wycena.
8. Nie naprawia zaznaczarki na karcie klienta. Ona nadal przełącza jeden wiersz naraz, mimo że podpowiedź obok mówi o dziedziczeniu przez korzeń gałęzi (audyt 9.8). Można to włączyć, bo komponent to potrafi, ale to osobna pozycja.
9. Nie zmienia tego, że menedżer widzi mniej niż Ty. Notka o zakresie zostaje. Po dołożeniu licznika serwerowego liczba obiektów będzie wspólna, ale sama lista nadal pokazuje to, do czego dana osoba ma dostęp.

10Co to odblokowuje

Jeden join, którym dociągamy nazwę klienta do listy obiektów, jest tym samym joinem, którego brakuje w kilku innych miejscach. Najciekawsze jest to: przedstawiciel klienta nie widzi dziś nigdzie nazwy klienta, którego reprezentuje. Marta z Benefit Systemu loguje się i widzi obiekty, ale nigdzie nie ma napisu "Benefit System". Dane fizycznie przychodzą do aplikacji (useMyClientUser pobiera cały wiersz), tylko nie są zadeklarowane w typie i nikt ich nie wyświetla (audyt 6.2). Ta propozycja domyka to przy okazji, bo raz zrobiona ścieżka "obiekt zna swojego klienta" działa we wszystkich panelach.

Dalej z tego samego wynika: filtr klienta w zleceniach, kafelek statystyk per klient na pulpicie, raport godzin per klient i zestawienie do faktury. Żadna z tych rzeczy nie jest w tej wycenie, ale każda z nich staje się po tej zmianie zwykłą robotą, a nie przebudową.

Osobno, jednym zdaniem: wątek z 19.08 o 15:17, że klient mógłby kiedyś kupić aplikację na swoje pozostałe obiekty, jest decyzją handlową do podjęcia później. Ta propozycja jej nie przesądza i niczego pod nią nie zamyka, bo klient jako wpis w rejestrze da się w przyszłości powiązać z osobnym najemcą, a klient jako korzeń drzewa już nie.