Pianificare flussi digitali sicuri rivolti ai clienti

Che cos'è

Un flusso di lavoro rivolto ai clienti può estendersi su portale, servizio web, esperienza mobile, backend, API, provider di pagamento, processo di assistenza e team amministrativo. La pianificazione dovrebbe individuare ruoli utente e confini di accesso; autenticazione e recupero; moduli, file, messaggi, dashboard e stato; percorsi di pagamento, abbonamento, fattura, rimborso, disdetta e diritti di accesso; titolarità e conservazione dei dati; integrazioni con terze parti e responsabilità operative. Dovrebbe inoltre decidere se sia più appropriato il mobile o il web, se backend e API esistenti siano pronti e chi sarà responsabile di logging, assistenza, modifiche e passaggio di consegne. Revisione di sicurezza e sviluppo software possono essere perimetri separati.

Per Chi È

Questa guida aiuta i team che pianificano:

• Un portale per clienti o partner, un flusso di raccolta delle richieste, una dashboard, un percorso di pagamento, una transizione dal web al mobile o il lancio di un'applicazione
• Accessi basati sui ruoli, recupero, file, informazioni di stato, assistenza e responsabilità amministrative
• Una modifica di prodotto che coinvolge backend esistenti, API, provider terzi, stati di fatturazione o dati dei clienti
• Un confine più chiaro tra discovery, design, sviluppo, hardening, revisione e successiva responsabilità operativa

Cosa Aiuta A Chiarire

Le domande di pianificazione aiutano a far emergere:

• Se utenti, ruoli, regole di accesso, recupero dell'account, titolarità e conservazione dei dati sono compresi prima dell'avvio dello sviluppo
• Quali moduli, file, messaggi, dashboard, viste di stato, stati di pagamento e decisioni sui diritti di accesso attraversano i confini tra sistemi
• Se integrazioni, backend/API, sviluppo mobile, fase di lancio, logging, assistenza e responsabilità delle modifiche sono pronti per un passo successivo a perimetro definito
• Se il team ha bisogno di uno sprint per un portale, di una revisione dei pagamenti, di una transizione dal web al mobile, di una revisione della prontezza al lancio, dell'hardening del sito web o di una fase preliminare di discovery/blueprint

Cosa è incluso

• Una checklist per chi acquista che copre percorsi, ruoli, accessi, autenticazione, recupero, moduli, file, messaggi, dashboard, stato, pagamenti, abbonamenti, fatture, rimborsi, disdette, diritti di accesso, dati e integrazioni
• Spunti di pianificazione su responsabilità amministrative, prontezza di backend/API, mobile rispetto a web, fase di lancio, logging, assistenza, controllo delle modifiche e passaggio di consegne
• Un confronto su quando possono essere pertinenti Secure Client Portal Sprint, Subscription & Payment Infrastructure Security, Secure Web-to-Mobile Launch, App Launch Readiness e Website Performance & Security Hardening
• Un promemoria che flussi di lavoro, ruoli, integrazioni o responsabilità poco chiari possono richiedere attività di discovery o blueprint prima dello sviluppo

Cosa non è incluso

• Un impegno su sicurezza, idoneità regolamentare, approvazione dei pagamenti, prevenzione delle frodi, ricavi, approvazione negli store, successo del lancio, disponibilità del servizio, prestazioni o funzionamento senza interruzioni
• L'affermazione che uno sprint per un portale sia una piattaforma SaaS completa, che una revisione dei pagamenti sia una certificazione PCI o un'attività antifrode, o che lo sviluppo mobile renda automaticamente un prodotto pronto al lancio
• L'idea che l'hardening sostituisca la progettazione applicativa, i test di carico, la risposta agli incidenti o le operazioni continuative
• Il presupposto che sviluppo software, revisione di sicurezza, approvazione del provider e responsabilità continuativa costituiscano un unico perimetro automatico

Quando sceglierlo

Utilizzi questa guida prima che una modifica rivolta ai clienti diventi un elenco di funzionalità scollegate. È utile quando un team sta decidendo se sviluppare un portale, modificare gli accessi, introdurre abbonamenti, estendere un servizio web al mobile, preparare il lancio di un'applicazione o migliorare un sito web. Se il flusso di lavoro di base, le responsabilità, le integrazioni o i ruoli utente restano poco chiari, una discovery o un product blueprint sono di solito più preziosi di un'implementazione anticipata. Una revisione a perimetro definito può seguire quando una specifica questione di sicurezza o operativa è matura.

Il nostro approccio

Mappi il percorso prima di scegliere il metodo di realizzazione. Parta dall'utente, dal suo ruolo, dalla decisione di accesso, dai dati che fornisce o visualizza, dal sistema responsabile dello stato successivo e dal team responsabile quando qualcosa cambia. Segua gli stati di pagamento e dei diritti di accesso con la stessa cura delle schermate dell'interfaccia. Individui poi le dipendenze da provider e backend, le esigenze di assistenza e logging, i vincoli del mobile, la responsabilità del rilascio e i requisiti del passaggio di consegne. Ciò fa emergere se la decisione successiva riguarda la realizzazione di un portale, la logica di pagamento, il passaggio dal web al mobile, la prontezza al lancio, l'hardening del sito web o una discovery preliminare. Evita inoltre che un servizio a perimetro definito venga scambiato per una responsabilità illimitata di prodotto, operativa o di conformità. Una mappa scritta del flusso può inoltre registrare i percorsi normali ed eccezionali: un nuovo utente, un pagamento non riuscito, una disdetta, un account perso, un file mancante, un'interruzione di un fornitore o una richiesta di assistenza. Offre ai team di prodotto, operazioni, ingegneria e assistenza un punto condiviso per individuare le responsabilità prima che un cliente ne subisca le conseguenze. Questa chiarezza può ridurre la deriva del perimetro nelle successive attività di realizzazione. Man mano che la pianificazione procede, riveda la mappa ogni volta che cambiano un provider, un modello di pagamento, un ruolo, una regola di accesso, un'API, un canale di rilascio o un processo di assistenza. Un flusso che sembrava semplice in un diagramma può presentare eccezioni importanti in produzione. Registrare tali eccezioni rende più facile decidere se il perimetro successivo sia design, realizzazione, revisione, hardening, test o preparazione operativa. Aiuta inoltre chi acquista a richiedere ai fornitori le evidenze giuste prima di prendere una decisione. Infine, utilizzi la mappa per decidere cosa verrà misurato dopo la consegna e chi agirà in caso di rilievo, pagamento non riuscito, segnalazione dell'assistenza o richiesta di modifica. Un passaggio di consegne è più solido quando indica un responsabile, un momento di revisione e un confine concordato anziché limitarsi a elencare funzionalità.

Domande frequenti

Articoli correlati