Contenuti
- Il problema può rimanere nascosto
- Undici giorni senza che nessuno lo sapesse
- A volte deve chiamare un cliente
- Anche una rete può essere scoperta per caso
- E a volte se ne accorge qualcuno dall’esterno
- Il problema non è che qualcuno se ne sia accorto
- Come avrebbe dovuto funzionare
- “Funziona” non dovrebbe significare soltanto “non vedo errori”
- La casualità non è un controllo
- La domanda da porsi
Quando finalmente si scopre un problema in un sito, la prima reazione è spesso di sollievo.
“Meno male che ce ne siamo accorti.”
Ed è certamente meglio conoscere un problema che non conoscerlo.
Ma c’è una domanda successiva che vale la pena porsi:
Come ce ne siamo accorti?
Se la risposta è:
“Per caso.”
la notizia non è così buona.
Perché significa che il sistema non aveva un modo affidabile per dirci che qualcosa non stava funzionando.
Il problema può rimanere nascosto
Un sito può continuare a essere online mentre una parte del sistema non funziona.
Un webhook può smettere di completare il proprio lavoro.
Un’e-mail può non essere più inviata.
Un percorso di rete può essere configurato in modo errato.
Una parte degli utenti può non riuscire a raggiungere il servizio.
Il problema esiste.
Ma se nessun controllo lo intercetta, il sistema può continuare a comportarsi apparentemente come sempre.
Finché qualcuno non se ne accorge.
Undici giorni senza che nessuno lo sapesse
In una casistica reale, un webhook aveva smesso di completare correttamente il processo previsto.
I lead continuavano ad arrivare.
Il sistema continuava a ricevere dati.
Ma l’azione successiva non veniva eseguita.
Il problema è rimasto presente per undici giorni.
Non è stato scoperto da un controllo.
È emerso indirettamente, osservando che i risultati commerciali non erano coerenti con il numero di lead generati.
Il problema esisteva da giorni.
La scoperta è arrivata soltanto perché qualcosa, alla fine, ha fatto nascere un sospetto.
A volte deve chiamare un cliente
Lo stesso schema può presentarsi con la posta.
Il sito raccoglie una richiesta.
La notifica dovrebbe arrivare all’azienda.
Ma qualcosa nel percorso della posta si interrompe.
Il sito può continuare a funzionare.
Il modulo può continuare a raccogliere richieste.
Nessun errore evidente compare all’utente.
Poi un cliente telefona.
“Avete ricevuto la mia richiesta?”
Ed è in quel momento che si scopre che il processo non funzionava.
Anche qui il problema non è soltanto la posta che non arriva.
È il fatto che nessuno aveva scoperto che non arrivava.
Anche una rete può essere scoperta per caso
Durante un trasloco può succedere qualcosa di apparentemente semplice.
Il lavoro fisico è terminato.
Le apparecchiature sono state spostate.
I sistemi vengono riaccesi.
Ma un problema di routing impedisce a una parte della rete di funzionare correttamente.
Il problema non viene rilevato da una procedura di verifica.
Viene scoperto quando qualcuno prova a utilizzare ciò che dovrebbe essere già operativo.
Il trasloco è finito. La rete no.
Anche in questo caso il problema non è soltanto l’errore tecnico.
È l’assenza di un controllo capace di verificarlo prima che qualcuno lo incontri.
E a volte se ne accorge qualcuno dall’esterno
Un provider può applicare una regola di protezione che impedisce ad alcuni utenti di raggiungere il sito.
Dal punto di vista dell’infrastruttura può non esserci alcun errore.
Ma per gli utenti interessati il servizio non è raggiungibile.
Come si scopre?
Può essere sufficiente una telefonata.
“Il sito non mi funziona.”
Ancora una volta, il primo segnale non arriva da una procedura interna.
Arriva da chi si trova dall’altra parte del processo.
Il problema non è che qualcuno se ne sia accorto
È importante fare una distinzione.
Non c’è nulla di sbagliato nel fatto che una persona segnali un problema.
Le segnalazioni degli utenti sono preziose.
Un cliente può accorgersi di un comportamento che nessun controllo automatico avrebbe individuato.
Il problema nasce quando la segnalazione casuale rappresenta l’unico meccanismo disponibile per scoprire che qualcosa non funziona.
Se un cliente deve telefonare per farci sapere che il processo di contatto è interrotto, abbiamo scoperto il problema.
Ma lo abbiamo scoperto tardi.
Come avrebbe dovuto funzionare
Una procedura operativa non dovrebbe limitarsi a descrivere cosa fare quando qualcuno segnala un problema.
Dovrebbe prevedere, quando necessario, anche come verificare che il processo stia funzionando prima che qualcuno debba segnalarlo.
Dopo un trasloco, per esempio, non basta sapere che le apparecchiature sono state spostate.
Bisogna verificare ciò che deve funzionare.
Dopo una modifica a un’integrazione non basta verificare che il sistema si avvii.
Bisogna verificare che il processo arrivi alla destinazione prevista.
Dopo un cambiamento alle comunicazioni non basta controllare che il sito sia online.
Bisogna verificare che le informazioni continuino ad arrivare dove devono.
La procedura deve quindi arrivare fino al risultato operativo atteso.
“Funziona” non dovrebbe significare soltanto “non vedo errori”
Questo è uno dei motivi per cui le procedure operative sono importanti.
Senza una procedura, la verifica rischia di dipendere dall’esperienza della persona che esegue il lavoro.
Si guarda il sito.
Si prova una pagina.
Si controlla che il server risponda.
E si conclude:
“Sembra tutto a posto.”
Ma “sembra” non è una verifica.
Una procedura definisce invece che cosa deve essere controllato e quale risultato ci si aspetta.
Questo permette di ripetere il controllo anche quando cambia la persona che lo esegue.
La casualità non è un controllo
Se scopriamo un problema per caso, possiamo essere soddisfatti di averlo finalmente trovato.
Ma non possiamo considerare la casualità una strategia di controllo.
Perché la prossima volta potremmo non essere fortunati.
Il cliente potrebbe non chiamare.
Il commerciale potrebbe non accorgersi del calo.
Nessuno potrebbe provare quella particolare funzione.
Il problema potrebbe quindi rimanere nascosto ancora più a lungo.
E nel frattempo continuare a produrre danni.
La domanda da porsi
Quando scopriamo un problema, quindi, non dovremmo fermarci alla domanda:
“Come lo risolviamo?”
Possiamo aggiungerne un’altra:
“Perché abbiamo dovuto aspettare che qualcuno se ne accorgesse?”
Se la risposta è “per caso”, forse non abbiamo ancora finito il lavoro.
Perché abbiamo risolto il problema che abbiamo trovato.
Ma non necessariamente quello che ha permesso al problema di rimanere nascosto.
Se l’unico modo con cui scopri un problema è il caso, allora hai ancora un problema di Continuità Operativa.
