Un potenziale cliente manda un foglio di calcolo.

Centoquindici domande. Architettura, sicurezza, backup, crittografia, fornitori esterni, continuità del servizio, protezione dei dati.

Nessuno si stupisce. Non è il primo. Non sarà l'ultimo.

Eppure, al momento di aprire il file, ritorna sempre la stessa esitazione.

O si ricomincia tutto da capo: si riapre la documentazione, si frugano le configurazioni, si sollecita di nuovo il team tecnico.

Oppure si recupera il questionario del cliente precedente e si copia ciò che somiglia.

La prima strada sfinisce.

La seconda rassicura.

Entrambe fanno perdere ciò che l'azienda sa.

A ogni questionario si ricomincia

Il primo questionario di questo tipo che ho trattato in modo strutturato contava quarantatré domande.

Per rispondere è stato necessario mettere insieme sette fonti tecniche e fare un giro di domande e risposte con il team che gestiva il servizio. A questo si aggiungeva la stesura vera e propria:

• capire che cosa chiedeva davvero il potenziale cliente;
• ritrovare l'informazione;
• verificare che fosse ancora vera;
• decidere che cosa potevamo comunicare;
• rimettere la risposta nel formato richiesto.

Tra le tre e le sei ore di lavoro. Più persone coinvolte. Nessuna garanzia che il potenziale cliente diventasse cliente.

Non era una situazione eccezionale.

Ogni potenziale cliente manda il proprio documento. Una volta un foglio di calcolo, la volta dopo un Word, poi un PDF. I quadri di riferimento cambiano. Le numerazioni cambiano. Le formulazioni cambiano.

Ma gli argomenti, quelli, ritornano.

È questo che rende la situazione così frustrante: hai l'impressione di rispondere alla stessa domanda per la decima volta, e di doverla comunque ricostruire ogni volta.

Poi il documento parte.

E tutto il lavoro di ricerca resta chiuso nel file inviato.

Copiare sembra la soluzione ragionevole

Davanti a questa ripetizione, la reazione istintiva è ovvia.

Si conservano i vecchi questionari. Si cerca quello che somiglia di più. Si riprendono le risposte.

La stessa reazione esiste dentro l'azienda. Un team ha bisogno di una regola che appartiene a un altro team: i campi obbligatori di un modulo, una politica di backup, un limite contrattuale. Copia il passaggio nella propria documentazione, per averlo a portata di mano.

Sul momento funziona.

Si guadagna tempo. Si evita di disturbare sempre le stesse persone. Ci si appoggia a qualcosa che è già stato scritto, e spesso già convalidato.

Il problema è che il guadagno è immediato, mentre il costo arriva più tardi.

E arriva senza avvisare.

Una vecchia risposta somiglia a una conoscenza

In uno dei questionari ricevuti, una risposta era già compilata.

Indicava che la nostra certificazione ISO 9001 risaliva al 2017.

La frase sembrava perfettamente utilizzabile. Era precisa, già scritta, collocata di fronte alla domanda giusta.

La data corretta era il 2018.

Un anno di differenza. Niente di grave, all'apparenza.

Ma quell'errore mi ha fatto capire qualcosa di più importante.

Una vecchia risposta somiglia a una conoscenza. Ha la forma di un'affermazione. È scritta bene. Rassicura.

Eppure tace sull'essenziale:

• chi l'ha scritta;
• su che cosa poggia;
• in quale data era vera;
• se descrive ancora davvero il prodotto.

Una vecchia risposta può venire da un modello di documento, da un altro fornitore, da uno scambio di cui nessuno si ricorda più. Può essere stata giusta al momento dell'invio e sbagliata oggi.

E con l'IA questo rischio cresce.

Quando un'IA incontra in un documento una risposta già scritta, la riprende volentieri. Non ha alcun motivo di diffidarne. La frase è affermativa, ben collocata, coerente con la domanda.

L'IA, allora, non fa che accelerare la propagazione di un errore che nessuno ha visto.

La copia diverge senza rumore

Lo stesso meccanismo esiste tra team, ed è ancora più discreto.

Prendiamo una situazione molto ordinaria.

Un team di prodotto lavora sulla qualità dei rapporti di intervento. Si appoggia a una regola che appartiene a un altro team: l'elenco delle informazioni obbligatorie alla chiusura di un intervento. L'ha letta, l'ha ripresa nei propri documenti, va avanti.

Sei settimane dopo, il lavoro va in revisione.

Qualcuno nota uno scostamento.

Nel frattempo la regola è cambiata. L'altro team ha fatto evolvere il prodotto. Era legittimo. Era perfino previsto.

Ma nessuno l'ha segnalato.

Nessuno ha mentito. Nessuno ha commesso un errore grossolano. La regola ha semplicemente continuato a vivere là dove era nata, mentre la sua copia restava ferma altrove.

È questo che rende il problema così difficile da individuare: una copia che diverge non fa alcun rumore. Resta pulita, ben formulata, credibile. Ha solo smesso di essere vera.

Davanti a questo, ci sono due modi di sbagliare, e sono simmetrici.

Rimandare all'originale evita la copia. Si consulta la regola là dove vive. Ma se niente segnala che è cambiata, si continua ad appoggiarsi a ciò che si è letto sei settimane prima.

Copiare rende autonomi. La copia non dipende più dall'altro team. Ma se niente dice da dove viene, un anno dopo ci si ritrova con una nota giusta, o sbagliata, di cui nessuno sa su che cosa poggi.

Ciascuna delle due scelte comporta quindi un obbligo:

• un riferimento richiede di sapere quando la sua fonte cambia;
• una copia richiede di dire da dove viene, a quando risale e che cosa è stato riformulato nel passaggio.

Il problema non è copiare o fare riferimento.

Il problema è farlo senza scrivere ciò che ogni scelta richiede.

Conservare i fatti, non i documenti

Per i questionari, alla fine ho cambiato punto di partenza.

Non volevo più costruire una biblioteca di risposte da copiare.

Volevo costruire una memoria di ciò che sapevamo davvero rispondere.

Tutto è cominciato con una decisione semplice: ordinare per argomento, non per cliente.

Una domanda chiamata «14.6.l» da un potenziale cliente e una domanda chiamata «CL-072» da un altro riguardavano la stessa cosa: i backup. Ordinate per file cliente, restavano estranee l'una all'altra. Ordinate per argomento, si ritrovavano.

La domanda non era più: «che cosa abbiamo risposto a quel cliente?»

Diventava: «che cosa sappiamo rispondere sui backup?»

E per ogni argomento conservavamo un fatto verificato, accompagnato da ciò che permette di fidarsene:

• la sua origine: una documentazione ufficiale, una configurazione verificata, un test, la conferma del team competente;
• la data in cui è stato convalidato;
• i limiti di ciò che possiamo dichiarare.

Il questionario del cliente conservava il suo valore. Mostrava che cosa il mercato voleva sapere, con le sue parole e le sue priorità.

Ma non provava più niente.

La domanda veniva dal cliente. La prova veniva da noi.

Abbiamo anche separato due cose che i vecchi questionari mescolavano: ciò che serve a verificare una risposta e ciò che può essere inviato. Il dettaglio di una configurazione può essere indispensabile al revisore interno senza avere posto in un documento trasmesso a un potenziale cliente.

La formulazione destinata al cliente veniva preparata a parte.

Le prove e le riserve restavano accanto, per chi doveva convalidare.

Lasciare la conoscenza a chi ne è responsabile

Lo stesso principio vale tra team.

Una regola ha un proprietario. È il team che la fa evolvere, che sa perché esiste e che ne risponde.

Il primo modo di usarla è consultarla là dove vive, invece di tenerne una versione personale. Ci si appoggia a essa senza pretendere di possederla.

A volte non basta. Serve fissare la versione esatta su cui poggia una decisione. La si vuole riformulare per un uso particolare. Si vuole che resti disponibile anche se il team d'origine si riorganizza.

In questo caso, la si può copiare.

Ma la copia deve conservare il suo passato: da dove viene, a quale data, e che cosa è stato modificato.

La differenza tra i due sta meno nella scelta che nella responsabilità:

• quando consulto, la conoscenza continua ad appartenere all'altro team;
• quando copio, una versione autonoma passa sotto la mia gestione, e divento responsabile del suo uso.

Resta una tentazione che tutti conoscono.

Capita spesso di leggere la documentazione di un altro team. Si individua un errore. Si sa cosa correggere. Ci vorrebbero trenta secondi.

Meglio proporre la correzione che farla.

Chi individua un errore non decide la collocazione definitiva della conoscenza. È il team che ne è responsabile a giudicare se la correzione descrive davvero il suo perimetro, o soltanto il caso particolare di chi la propone.

È questo che impedisce a un risultato locale di diventare, in silenzio, una verità generale.

Una lacuna visibile vale più di una frase plausibile

Ordinare i fatti per argomento ha avuto un effetto che non mi aspettavo.

Ha fatto emergere le lacune.

Quando un'informazione mancava, non era più possibile nasconderla dietro una vecchia formulazione. L'argomento c'era, la domanda pure, ma nessun fatto verificato permetteva di rispondere.

La lacuna diventava visibile.

E una lacuna visibile può diventare un'azione.

Invece di riempire la casella con una frase rassicurante, si prepara una domanda precisa per il team interessato. Si indica quali righe del questionario quella risposta permetterà di completare. Si sa a chi porla, e perché.

È probabilmente il cambiamento più importante.

Una frase plausibile nasconde un rischio.

Una lacuna esplicita lo trasforma in lavoro identificabile.

Il quarto questionario

Il quarto questionario contava centoquindici domande. Quasi il triplo del primo.

Questa volta non partivamo più da un insieme di file sparsi. Gli argomenti ricorrenti erano noti, e per ciascuno sapevamo dove si trovavano i fatti verificati.

Novantasei risposte complete sono state prodotte direttamente, senza nuova raccolta.

Il resto del documento era classificato:

• risposte solide, da verificare un'ultima volta;
• risposte incerte;
• alcune domande impossibili da trattare con le informazioni disponibili.

I punti ancora aperti avevano cambiato natura. Non cercavamo più a caso chi sapesse che cosa. Restavano decisioni commerciali, come la durata di un impegno, e alcune conferme tecniche puntuali.

Il lavoro rimasto era visibile, attribuibile e circoscritto.

Nella mia esperienza, la preparazione di un questionario è passata da tre-sei ore a circa dieci minuti per produrre l'80-90% del documento.

Questo numero può ingannare.

Non vuol dire che l'80-90% delle risposte sia certo e pronto a impegnare l'azienda. Vuol dire che il documento è in larga parte preparato: le risposte note sono al loro posto, le loro fonti sono state ritrovate, i punti fragili sono segnalati, le informazioni mancanti sono diventate richieste precise.

La revisione umana resta indispensabile.

Ma finalmente si concentra nel punto giusto. Il revisore non passa più il suo tempo a frugare vecchi file e a sollecitare ancora una volta le stesse persone. Verifica gli impegni, decide che cosa si può dire e si concentra su ciò che è nuovo o incerto.

Ciò che l'azienda conserva

Ripartire da zero e copiare sembrano due atteggiamenti opposti.

Uno spreca il lavoro passato. L'altro lo riusa senza verificarlo.

In realtà poggiano sulla stessa confusione: prendere il documento per la conoscenza.

Il documento è fatto per un cliente, un momento, un formato. È necessario. Ma non è il posto in cui un'azienda dovrebbe conservare ciò che sa.

Ciò che sa sta in fatti che conservano la loro origine, la loro data e i loro limiti, consultati là dove vivono o copiati dicendo da dove vengono.

Il primo questionario aveva richiesto un'indagine.

I successivi hanno approfittato di tutto ciò che quell'indagine aveva insegnato. Un errore di data è diventato una regola di prudenza. Una conferma ottenuta da un team è diventata un fatto riutilizzabile. Una domanda senza risposta è diventata una lacuna nota invece di una dimenticanza.

Il potenziale cliente riceve sempre il suo documento.

L'azienda, dal canto suo, conserva finalmente ciò che ha imparato preparandolo.

---

Nota sugli esempi

Gli esempi di questo articolo si basano su più di trent'anni di pratica nell'informatica e nella gestione di team, e su numerosi scambi con colleghi. Li ho modificati, generalizzati o ricomposti: nessuno descrive un cliente, un prodotto o un'organizzazione reali, né riflette i dati o le posizioni del mio datore di lavoro. Le opinioni espresse sono esclusivamente mie.