Różne ekrany, jedna sprawa.
Wyobraź sobie warsztat: klient sprawdza zakres naprawy na telefonie, mechanik uzupełnia zlecenie, a biuro przygotowuje kosztorys przy komputerze. Każda osoba potrzebuje innego widoku, ale wszystkie pracują nad tą samą sprawą. To właśnie ustalamy, gdy projektujemy aplikację mobilną połączoną z panelem internetowym. Najpierw opisujemy drogę informacji i decyzji, później ekrany.
Telefon powinien prowadzić klienta do krótkiej czynności: przeczytania zmiany, wyboru terminu lub zatwierdzenia zakresu. Panel firmy może zawierać listę zleceń, filtrowanie i pracę wielu osób. Wspólny produkt pozwala ustalić jeden obieg, w którym dane przechodzą między tymi widokami. Zobacz potrzeby aplikacji dla warsztatu i wskaż, kto wykonuje każdy krok w Twojej firmie.
Skąd telefon i panel biorą informacje?
W takim projekcie planujemy wspólną obsługę danych na serwerze: zapis sprawy, zasady jej zmiany i odpowiedź dla każdego urządzenia. API to uzgodniony sposób, w jaki aplikacja prosi system o informacje lub przekazuje działanie. Na przykład telefon przesyła akceptację kosztorysu, a system sprawdza jej wersję i zwraca wynik. Panel biura odczytuje potem potwierdzony stan tej samej sprawy.
Ustalamy, które informacje odświeżają się po otwarciu ekranu, które po wykonaniu działania i czy potrzebne są dodatkowe aktualizacje podczas pracy. Wyświetlona wcześniej kopia może być już nieaktualna. Przy rezerwacji ostatniego miejsca system musi ponownie sprawdzić dostępność. Zdefiniowanie źródła danych, częstotliwości aktualizacji i reguł wspólnego zapisu jest częścią projektu, którą trzeba uwzględnić w zakresie.
Wspólne konto z dostępem do własnych spraw.
Klient może korzystać z tego samego konta w aplikacji na telefon i w portalu internetowym, jeśli zaplanujemy wspólną obsługę logowania. To pozwala wrócić do własnej historii na innym urządzeniu. Pracownik otrzymuje widok odpowiadający roli: na przykład obsługuje przydzielone zlecenia, podczas gdy kierownik zatwierdza zmianę zakresu. Uzgadniamy także wylogowanie, odzyskiwanie dostępu i zmianę urządzenia.
System powinien sprawdzać dostęp do konkretnej sprawy przy żądaniu z telefonu lub panelu. OWASP opisuje kontrolę uprawnień dla każdego żądania. W naszym przykładzie klient nie powinien otworzyć cudzego kosztorysu przez zmianę adresu. Takie sytuacje wpisujemy do testów odbioru razem ze zwykłym logowaniem i poprawnym wykonaniem zadania.
Połączenie z obecną stroną, sklepem lub systemem.
Możemy zacząć od narzędzia, które firma już ma, i sprawdzić jego dokumentację oraz dostępne operacje. Strona z opisem usług może kierować do aplikacji lub portalu. Sklep może udostępniać uzgodnione zamówienia, a kalendarz terminy. W każdym przypadku określamy, które dane odczytujemy, co zmieniamy i kto odpowiada za ich poprawność. Poradnik o integracjach wyjaśnia przygotowanie konkretnego połączenia.
Dostęp do API, limity, środowisko testowe i warunki dostawcy wpływają na możliwość wykonania. Połączenie przesyłające dane wymaga odpowiedniego uwierzytelniania i ochrony komunikacji; OWASP wskazuje HTTPS dla usług REST. Wycena obejmuje również obsługę błędów i późniejszych zmian po stronie dostawcy. Dopiero sprawdzony zakres pozwala planować automatyzację.
Od działania na telefonie do wyniku w panelu.
Rozpisujemy pełny przykład: klient otwiera aktualny kosztorys, akceptuje jego wersję, widzi potwierdzenie przyjęcia, a warsztat otrzymuje tę decyzję w karcie naprawy. Jeśli pracownik zmieni zakres przed akceptacją, telefon powinien pokazać nową wersję do sprawdzenia. Jeśli internet przerwie odpowiedź, klient dostaje czytelny stan oczekiwania i możliwość ustalenia wyniku wcześniejszej operacji.
Projektujemy sposób ponowienia bez drugiej akceptacji lub kolejnego zamówienia. Do tego potrzebne są wspólny identyfikator i uzgodnione reguły obsługi żądań. Powiadomienie może skierować użytkownika do sprawy, a jej aktualny stan powinien pozostać dostępny po wejściu na konto. Ważne decyzje opieramy na zapisanym wyniku systemu. Tak zamknięty przebieg można ocenić na telefonie i w panelu.
Co uzgadniamy przed wykonaniem i odbiorem?
Przygotowujemy listę ekranów dla klienta i pracowników, najważniejsze dane, role oraz jeden kompletny proces. Dopisujemy przypadki odbioru: ta sama sprawa na dwóch urządzeniach, zmiana danych w czasie pracy, utrata połączenia, ponowienie i brak uprawnienia. Ustalamy akceptowalny sposób odświeżania oraz komunikaty, dzięki którym użytkownik rozumie, czy jego działanie zostało przyjęte. To konkretna podstawa projektu i testów.
Wersje iOS i Android, panel, wspólne dane, integracje, hosting oraz utrzymanie otrzymują opisany zakres i wycenę. Można zacząć od portalu webowego i dołączyć aplikację mobilną, jeśli wspólny obieg został do tego przygotowany. Nasze branżowe podglądy pomagają omówić zadania. Opisz, co klient robi na telefonie i co firma robi dalej, a ustalimy potrzebne połączenia.
Jaką decyzję podjąć dalej?
Jeżeli dwie role mogą zmieniać tę samą sprawę, uwzględnij Jak opisać konflikt dwóch zmian tej samej sprawy?.
Przy rozbudowie zakresu o lokalizacje sprawdź Wiele oddziałów w jednej aplikacji: dane lokalne i wspólne.
Od decyzji do zakresu wykonania.
Zakres związany z tą decyzją opisujemy na stronie Aplikacje dla pracowników.
Praktyczny kontekst znajdziesz w opisie Transport i lokalne dostawy. To możliwy zakres dla branży, który dobieramy do konkretnej firmy.