Il labirinto infinito delle segnalazioni senza risposta

Esistono organizzazioni dove segnalare un malfunzionamento è un’esperienza kafkiana che fa sembrare semplice ottenere un permesso edilizio. Mandi una email. Ricevi un autoresponder che promette risposta entro 24 ore. Passano tre giorni. Richiami. Ti dicono che non hanno traccia della tua richiesta. Rispedisci l’email. Ti chiedono di compilare un modulo web. Compili il modulo. Ti arriva un numero di pratica. Quel numero non esiste nel loro database quando lo citi telefonicamente. Benvenuti nell’inferno dell’assistenza tecnica gestita con i piedi.

La nebbia della vaghezza comunicativa

Il vero nemico dell’assistenza efficace non sono i sistemi complessi o i bug esoterici. È l’incapacità cronica di descrivere cosa sta realmente accadendo. Chiedere a qualcuno di spiegare precisamente un problema tecnico è come chiedere a un bambino di tre anni di descrivere un incubo: sai che c’è qualcosa che non va, ma potresti dover scavare attraverso strati di informazioni contraddittorie prima di capire cosa.

“Questa cosa qui non va” è la descrizione standard. Quale cosa? Dove esattamente? In che circostanze? Quale errore appare? Queste domande vengono percepite come pedanteria inutile invece che come tentativi legittimi di comprendere il problema. L’aspettativa implicita è che tu debba possedere capacità telepatiche per accedere direttamente alla loro esperienza sensoriale e capire cosa intendano.

Ancora più frustrante è il fenomeno della memoria selettiva applicato ai malfunzionamenti. Un sistema che si blocca “costantemente” spesso significa che si è bloccato una volta sei settimane fa durante una presentazione importante. Quella singola occorrenza viene amplificata retrospettivamente fino a diventare un’epidemia cronica. Nel frattempo, le migliaia di interazioni perfettamente funzionanti vengono dimenticate completamente, come se non fossero mai esistite.

La mitologia della riproducibilità istantanea

Per molti utenti, l’informatica funziona come un interruttore della luce: o è acceso o è spento, senza vie di mezzo. Il concetto che un comportamento anomalo possa dipendere da condizioni specifiche, sequenze particolari di azioni, timing preciso o stato del sistema è completamente alieno.

“Stavo facendo esattamente quello che faccio sempre” è l’affermazione ricorrente. Ma quando chiedi di mostrare passo-passo, emergono dozzine di variazioni piccole ma critiche. Hanno usato un browser diverso. Erano connessi da una rete differente. Avevano aperto finestre in ordine diverso. Avevano premuto pulsanti con tempistiche variate. Ogni dettaglio che sembrava irrilevante si rivela potenzialmente decisivo, ma nessuno lo aveva menzionato perché “non poteva essere importante”.

Poi c’è il classico problema che svanisce miracolosamente quando provi a investigarlo approfonditamente. L’utente urla che tutto è collassato, impossibile lavorare, emergenza assoluta. Inizi a fare domande diagnostiche. “Aspetta… ora sembra andare. Che strano!” E così il mistero rimane irrisolto fino alla prossima manifestazione spontanea.

L’anarchia dei canali multipli

In assenza di sistemi centralizzati, le richieste arrivano da ogni direzione immaginabile. Email personali degli sviluppatori. Messaggi istantanei. Telefonate dirette. Note scritte su foglietti lasciati sulle scrivanie. In un caso particolarmente surreale, qualcuno aveva persino usato i social media personali di un programmatore per segnalare un bug critico.

Il risultato è perdita totale di tracciabilità. Chi sta lavorando su cosa? Quali problemi sono stati già affrontati? Quali richieste sono duplicate? Impossibile saperlo quando le informazioni sono sparse in quindici sistemi differenti senza alcuna sincronizzazione. Le caselle email condivise diventano cimiteri digitali dove le richieste vanno a morire lentamente, sepolte sotto valanghe di conversazioni incrociate.

Questo caos multicanale genera anche il fenomeno delle segnalazioni duplicate da angolazioni diverse. Lo stesso problema viene riportato via email, poi telefonicamente, poi tramite messaggio, creando l’illusione di tre emergenze separate quando in realtà è una sola questione descritta in modi vagamente diversi.

Il collasso della gerarchia delle urgenze

Quando tutto diventa priorità massima, nulla lo è realmente. Ma spiegarlo a chi gestisce l’assistenza con logiche politiche invece che tecniche è impossibile. I clienti che urlano più forte ottengono attenzione immediata, indipendentemente dalla gravità oggettiva dei loro problemi. Nel frattempo, malfunzionamenti seri che colpiscono utenti più educati languiscono ignorati per settimane.

A volte la priorità viene assegnata automaticamente in base al valore del contratto commerciale. Un cliente importante che segnala una preferenza estetica minore ottiene classificazione critica. Centinaia di utenti che perdono dati effettivi vengono etichettati come media priorità perché pagano meno. La logica economica a breve termine massacra quella tecnica e operativa.

Ancora peggio sono le organizzazioni dove non esiste proprio un criterio di prioritizzazione. Tutto viene affrontato nell’ordine casuale in cui capita, come se problemi che bloccano produzione e richieste di funzionalità cosmetiche avessero lo stesso peso. È democrazia portata all’assurdo: tutti i problemi sono uguali, quindi nessuno riceve l’attenzione che meriterebbe.

Il buco nero della comunicazione assente

Aprire una segnalazione e ricevere zero feedback per settimane è un’esperienza comune in organizzazioni disfunzionali. Nessun aggiornamento sullo stato. Nessuna stima temporale. Nessuna indicazione se qualcuno sta effettivamente guardando il problema. Solo silenzio cosmico che fa dubitare se la richiesta sia mai arrivata a destinazione.

Gli utenti attraversano fasi psicologiche prevedibili durante questa attesa. Prima la fiducia ingenua che riceveranno risposta presto. Poi l’irritazione crescente man mano che i giorni passano. Quindi tentativi ripetuti di sollecitare tramite canali alternativi. Infine la rassegnazione amara e la decisione di cercare soluzioni alternative o cambiare fornitore completamente.

Dal lato tecnico, la situazione è altrettanto frustrante. Ticket che rimangono aperti per mesi diventano leggende metropolitane, tramandati da un team all’altro come maledizioni antiche. Nessuno ricorda più esattamente cosa richiedessero. Nessuno osa chiuderli per paura di conseguenze impreviste. Diventano artefatti archeologici che nessuno sa come gestire.

L’incompetenza dello smistamento

Assegnare richieste alle persone sbagliate è un’arte perfezionata in molte organizzazioni. Sistemi automatici che usano keyword matching primitivo mandano problemi completamente sconnessi a specialisti perplessi. “La parola ‘lento’ è nel testo? Mandalo al team database!” Non importa che il contesto parli di consegne postali o apprendimento umano.

In altri casi, lo smistamento viene lasciato completamente agli utenti finali, che ovviamente non hanno idea di come sia organizzato internamente il team tecnico. Scelgono la persona con cui hanno miglior rapporto personale, indipendentemente dalla competenza specifica necessaria. Il risultato sono sviluppatori sommersi da richieste fuori dal loro ambito che devono costantemente ridirezionare, perdendo tempo prezioso.

La mancanza di triage professionale crea anche accumuli diseguali. Alcuni specialisti sono sovraccarichi mentre altri sono sottoutilizzati, semplicemente perché le richieste vengono distribuite seguendo logiche casuali invece che competenze effettive.

La conoscenza che evapora continuamente

Problemi identici vengono risolti ripetutamente perché nessuno documenta le soluzioni. Ogni volta è come affrontare una sfida nuova, anche se esattamente lo stesso malfunzionamento è stato sistemato sei volte nei dodici mesi precedenti. L’assenza di memoria organizzativa trasforma ogni debug in archeologia.

Le knowledge base aziendali, quando esistono, sono deserti informativi. Pagine create anni prima e mai aggiornate. Procedure che fanno riferimento a versioni software scomparse da tempo. FAQ che rispondono a domande che nessuno pone, ignorando quelle quotidiane. È come avere una biblioteca dove tutti i libri parlano di argomenti irrilevanti scritti in lingue morte.

Questo vuoto documentale crea dipendenza totale dalla memoria volatile dei singoli individui. Quando persone chiave lasciano l’azienda, portano via con sé anni di soluzioni accumulate. I nuovi arrivati devono reinventare la ruota costantemente, riscoprendo fix che erano stati trovati e dimenticati numerose volte.

L’addestramento inesistente

Buttare persone nell’assistenza senza preparazione è strategia popolare. “Ecco il sistema, questi sono i problemi aperti, arrangiati.” Zero formazione sui prodotti supportati. Zero spiegazione dei processi interni. Zero guida su come interagire efficacemente con utenti frustrati.

Il team risultante risponde a ogni domanda complessa con “ti richiamo” seguito da ricerche frenetiche su internet o suppliche disperate ai colleghi più esperti. Gli utenti percepiscono immediatamente questa incompetenza e perdono fiducia nell’organizzazione intera, non solo nell’individuo specifico.

Ancora più problematico è assumere persone completamente inadatte al ruolo. L’assistenza richiede capacità analitiche, pazienza nel decifrare richieste vaghe, empatia nell’interazione con persone non tecniche. Invece spesso finiscono in questo ruolo persone che trattano ogni contatto come se parlassero con idioti, usando script predefiniti indipendentemente dal problema reale.

Chiusure premature e metriche fasulle

Quando l’obiettivo diventa chiudere numeri di ticket invece che risolvere problemi veri, la qualità crolla verticalmente. “Dobbiamo processare venti segnalazioni al giorno” diventa il mantra, indipendentemente se quelle chiusure rappresentino soluzioni effettive o solo modi creativi di rimuovere problemi dalle statistiche attive.

Ticket vengono marcati come risolti basandosi su test superficiali che non verificano davvero la correzione. “Sembra funzionare ora” diventa una giustificazione sufficiente, senza considerare se il fix regge sotto carico, con dati diversi, in condizioni variate. Prevedibilmente, molte di queste “soluzioni” esplodono poco dopo, generando riaperture che vanificano il lavoro apparente.

La pressione sui numeri crea anche incentivi perversi. Meglio chiudere dieci problemi semplici che affrontare uno complesso che richiederebbe giorni. I malfunzionamenti difficili rimangono eternamente aperti mentre quelli banali vengono processati velocemente per far sembrare il team produttivo.

Costruire sistemi che funzionano davvero

Le organizzazioni mature trattano l’assistenza come asset strategico, non come costo necessario. Implementano piattaforme centralizzate dove ogni richiesta viene tracciata dall’apertura alla chiusura. Stabiliscono criteri oggettivi di prioritizzazione basati su impatto reale invece che politica. Mantengono comunicazione costante con chi segnala, anche quando non ci sono ancora soluzioni.

Investono pesantemente in documentazione accurata e aggiornata. Analizzano pattern nelle segnalazioni per identificare problemi sistemici da correggere alla radice. Formano continuamente il personale sia tecnicamente che sulle soft skill necessarie. Misurano qualità delle risoluzioni, non solo quantità.

In queste aziende, il karma tecnologico funziona positivamente. Trattano bene chi chiede aiuto oggi, sapendo che domani potrebbero essere loro a dover aprire richieste disperate. E quando capita, trovano dall’altra parte persone competenti, empatiche, determinate a risolvere invece che a scaricare responsabilità.

Questo articolo è tratto da “Non funziona niente! – I progetti IT in crisi”, il primo libro della collana Nothing Works! — una tragicommedia aziendale per chi ha visto troppi Gantt chart trasformarsi in fiction.

Scopri la collana completa, gli altri libri e le prossime uscite su nothingworks.it

Vuoi il libro subito? Compralo su Amazon

Potrebbe interessarti anche

• Sistemista IT in una PMI: mansioni e competenze
• DIRETTORE ACQUISTI
• Perché documentare gli interventi IT potenzia la posizione del Sistemista?
• BACK OFFICE MANAGER
• Da sistemista IT a IT Manager: un, possibile, percorso di carriera nell’ambito manifatturiero
• SOC MANAGER 
• I problemi quotidiani di un Sistemista IT e come risolverli
• SISTEMISTA
• Quanto guadagna un Sistemista a Torino?
• SISTEMISTA IT