Planowanie bezpiecznych cyfrowych procesów dla klientów

Co to jest

Proces skierowany do klientów może obejmować portal, usługę internetową, doświadczenie mobilne, backend, API, dostawcę płatności, proces wsparcia i zespół administracyjny. Planowanie powinno określić role użytkowników i granice dostępu; uwierzytelnianie i odzyskiwanie konta; formularze, pliki, wiadomości, pulpity i statusy; ścieżki płatności, subskrypcji, faktur, zwrotów, anulowań i uprawnień; własność i przechowywanie danych; integracje ze stronami trzecimi oraz odpowiedzialność operacyjną. Powinno też rozstrzygnąć, czy właściwa jest wersja mobilna czy webowa, czy istniejący backend i API są gotowe oraz kto będzie odpowiadać za logowanie, wsparcie, zmiany i przekazanie. Przegląd bezpieczeństwa i dostarczanie oprogramowania mogą stanowić odrębne zakresy.

Dla kogo

Ten przewodnik pomaga zespołom planującym:

• Portal dla klientów lub partnerów, proces przyjmowania zgłoszeń, pulpit, ścieżkę płatności, przejście z web na mobile lub uruchomienie aplikacji
• Dostęp zależny od ról, odzyskiwanie konta, pliki, informacje o statusie, wsparcie i obowiązki administracyjne
• Zmianę produktu obejmującą istniejące backendy, API, dostawców zewnętrznych, stany rozliczeń lub dane klientów
• Jaśniejszą granicę między discovery, projektowaniem, dostarczaniem, utwardzaniem, przeglądem i późniejszą odpowiedzialnością operacyjną

Co pomaga wyjaśnić

Pytania planistyczne pomagają ujawnić:

• Czy użytkownicy, role, reguły dostępu, odzyskiwanie konta, własność danych i ich przechowywanie są zrozumiałe przed rozpoczęciem dostarczania
• Które formularze, pliki, wiadomości, pulpity, widoki statusu, stany płatności i decyzje o uprawnieniach przekraczają granice systemów
• Czy integracje, backend/API, dostarczanie wersji mobilnej, etap uruchomienia, logowanie, wsparcie i odpowiedzialność za zmiany są gotowe na kolejny krok w określonym zakresie
• Czy zespół potrzebuje sprintu portalu, przeglądu płatności, przejścia z web na mobile, przeglądu gotowości do uruchomienia, utwardzania strony, czy wcześniejszych prac discovery/blueprint

Co jest zawarte

• Lista kontrolna dla kupującego obejmująca ścieżki, role, dostęp, uwierzytelnianie, odzyskiwanie konta, formularze, pliki, wiadomości, pulpity, statusy, płatności, subskrypcje, faktury, zwroty, anulowania, uprawnienia, dane i integracje
• Pytania planistyczne dotyczące odpowiedzialności administracyjnej, gotowości backendu/API, wyboru między wersją mobilną a webową, etapu uruchomienia, logowania, wsparcia, kontroli zmian i przekazania
• Porównanie sytuacji, w których istotne mogą być Secure Client Portal Sprint, Subscription & Payment Infrastructure Security, Secure Web-to-Mobile Launch, App Launch Readiness oraz Website Performance & Security Hardening
• Przypomnienie, że niejasne procesy, role, integracje lub odpowiedzialność mogą wymagać prac discovery lub blueprint przed dostarczaniem

Co nie jest uwzględnione

• Obietnica bezpieczeństwa, zgodności z wymogami regulacyjnymi, akceptacji płatności, zapobiegania nadużyciom, przychodów, akceptacji w sklepie, udanego uruchomienia, dostępności, wydajności lub nieprzerwanego działania
• Twierdzenie, że sprint portalu jest pełną platformą SaaS, że przegląd płatności jest certyfikacją PCI lub działaniem przeciw nadużyciom, ani że dostarczenie wersji mobilnej automatycznie przygotowuje produkt do uruchomienia
• Sugestia, że utwardzanie zastępuje projekt aplikacji, testy obciążeniowe, reagowanie na incydenty lub ciągłe operacje
• Założenie, że dostarczanie oprogramowania, przegląd bezpieczeństwa, zgoda dostawcy i bieżąca odpowiedzialność stanowią jeden automatyczny zakres

Kiedy to wybrać

Z tego przewodnika warto skorzystać, zanim zmiana skierowana do klientów stanie się listą niepowiązanych funkcji. Jest przydatny, gdy zespół decyduje, czy zbudować portal, zmienić dostęp, wprowadzić subskrypcje, rozszerzyć usługę internetową na urządzenia mobilne, przygotować uruchomienie aplikacji lub usprawnić stronę. Jeśli podstawowy proces, odpowiedzialność, integracje lub role użytkowników pozostają niejasne, prace discovery lub blueprint produktu są zwykle cenniejsze niż wczesne wdrożenie. Przegląd w określonym zakresie może nastąpić później, gdy konkretne pytanie dotyczące bezpieczeństwa lub operacji będzie gotowe.

Nasze podejście

Należy zmapować ścieżkę przed wyborem metody dostarczania. Warto zacząć od użytkownika, jego roli, decyzji o dostępie, danych, które przekazuje lub widzi, systemu odpowiadającego za kolejny stan oraz zespołu odpowiedzialnego, gdy coś się zmienia. Stany płatności i uprawnień należy śledzić równie starannie jak ekrany interfejsu. Następnie trzeba wskazać zależności od dostawców i backendu, potrzeby wsparcia i logowania, ograniczenia wersji mobilnej, odpowiedzialność za wydania i wymagania dotyczące przekazania. Pokazuje to, czy kolejna decyzja dotyczy dostarczenia portalu, logiki płatności, prac nad przejściem z web na mobile, gotowości do uruchomienia, utwardzania strony czy wcześniejszego discovery. Zapobiega też pomyleniu usługi w określonym zakresie z nieograniczoną odpowiedzialnością produktową, operacyjną lub za zgodność. Pisemna mapa procesu może również zapisać ścieżki standardowe i wyjątkowe: nowego użytkownika, nieudaną płatność, anulowanie, utracone konto, brakujący plik, awarię dostawcy lub zgłoszenie do wsparcia. Daje zespołom produktu, operacji, inżynierii i wsparcia wspólne miejsce do ustalenia odpowiedzialności, zanim problem dotknie klienta. Taka jasność może ograniczyć rozrastanie się zakresu w późniejszych pracach. W miarę rozwoju planowania należy wracać do mapy za każdym razem, gdy zmienia się dostawca, model płatności, rola, reguła dostępu, API, kanał wydawniczy lub proces wsparcia. Proces, który na diagramie wyglądał prosto, na produkcji może mieć istotne wyjątki. Zapisanie tych wyjątków ułatwia decyzję, czy kolejnym zakresem jest projektowanie, dostarczanie, przegląd, utwardzanie, testy czy przygotowanie operacyjne. Pomaga też kupującemu poprosić dostawców o właściwe dowody przed podjęciem decyzji. Wreszcie mapę warto wykorzystać do ustalenia, co będzie mierzone po dostarczeniu i kto zareaguje na ustalenie, nieudaną płatność, sygnał ze wsparcia lub prośbę o zmianę. Przekazanie jest solidniejsze, gdy wskazuje właściciela, punkt przeglądu i uzgodnioną granicę, zamiast jedynie wymieniać funkcje.

Często zadawane pytania

Artykuły pokrewne