il debito di conoscenza
Serie in cinque parti su memoria organizzativa, conoscenza tacita e rischio nei progetti informatici. Parte 3 di 5. Nelle puntate precedenti abbiamo visto la distinzione fra memoria formale e informale di un’organizzazione, l’ingiustizia epistemica nei sistemi informativi, e le tre patologie che nascono quando la memoria informale si perde. Da qui in avanti, un nuovo concetto per nominare il costo di questa perdita.
Un’organizzazione può possedere quantità sterminate di dati e non sapere più come funziona. Può avere una base dati di gestione delle configurazioni aggiornata, migliaia di pagine nella base di conoscenza, ogni attività registrata in un sistema di ticketing, procedure certificate e cruscotti abbastanza luminosi da rischiarare una sala riunioni. Può presentare a un comitato di indirizzo una pianificazione rispettata, un diagramma di avanzamento rassicurante e ogni indicatore colorato di verde.
Poi una persona si assenta, un’anomalia attraversa due sistemi, un fornitore termina il contratto, una dipendenza rimane senza proprietario. Improvvisamente nessuno sa più perché una determinata configurazione non debba essere modificata, quale eccezione tenga in piedi il processo, che cosa significhi davvero una nota scritta anni prima in un ticket ormai chiuso.
Il repository come mausoleo
Come è possibile un simile scarto fra l’apparenza e la sostanza? Perché la conoscenza viene spesso trattata come un inventario: qualcosa che può essere estratto dalle persone, ripulito, classificato e depositato in un sistema. Una volta compilato il documento, chiuso il ticket, aggiornato il repository, si presume che il sapere sia stato trasferito.
Un ticket ricorda quasi sempre che cosa è stato fatto, ma raramente consente di ricordare perché, fra dieci alternative plausibili, ne sia stata scelta proprio una: registra la decisione e perde il paesaggio mentale nel quale quella decisione aveva senso. Un repository può contenere tutto e non spiegare più nulla. In quel momento cessa di essere una memoria e diventa un mausoleo, un luogo ordinato, consultabile, dove manca il significato, non l’informazione.
La metis del tecnico
Il capannone era pieno del ronzio ordinario delle apparecchiature accese, quando a Pratica di Mare uno specialista si chinò su un vecchio ricevitore radar di bordo installato sugli Atlantic BR1150. Le verifiche di continuità non mostravano anomalie, ma l’apparato si rifiutava di funzionare.
Il tecnico non accese subito l’oscilloscopio. Prese un cacciavite isolato, appoggiò l’orecchio alla griglia dell’altoparlante e sfiorò il piedino di un transistor nello stadio d’ingresso. Attese un «toc». «Il finale spinge. Il problema è nella miscelazione dei segnali», disse.
Aveva interrogato il circuito introducendo deliberatamente un rumore e ne aveva interpretato la risposta con il proprio corpo. In quel gesto convivevano elettronica, memoria acustica, esperienza operativa e una quantità incalcolabile di tentativi precedenti. Nessun manuale avrebbe potuto descrivere tutte le variazioni di quel suono, la pressione della mano, il tempo dell’attesa, il ragionamento che collegava una vibrazione dell’altoparlante a uno stadio preciso del ricevitore.
I greci chiamavano metis questa intelligenza capace di adattarsi alla resistenza del reale. Nei sistemi informatici si incontra ogni giorno, anche se spesso non viene riconosciuta come tale. È la sistemista che identifica un malfunzionamento dalla cadenza insolita dei messaggi di registro prima che scatti una soglia. È l’operatore del servizio di assistenza che collega tre segnalazioni apparentemente indipendenti. È il responsabile di progetto che comprende, dal modo in cui viene formulata una stima, che il gruppo non ha ancora individuato la dipendenza destinata a travolgere la pianificazione.
Niente di magico, in tutto questo: è conoscenza compressa dall’esperienza.
Michael Peters e Tina Besley, se non sbaglio, hanno usato l’espressione culture della conoscenza per descrivere, negli studi sull’educazione e sul capitalismo della conoscenza, gli ambienti in cui il sapere si forma e circola attraverso pratiche condivise, tramandate spesso per generazioni, tanto nelle forme rappresentabili quanto in quelle che sfuggono a ogni rappresentazione.
Applico qui quel concetto ai progetti informatici per analogia, ben sapendo che i due autori non avevano in mente un reparto IT quando lo hanno proposto: aiuta comunque a descrivere qualcosa che nessun inventario documentale riesce a catturare. La conoscenza organizzativa si comporta come una pratica esercitata da una comunità, più che come un oggetto posseduto dall’organizzazione.
Esiste nel linguaggio condiviso, nelle domande che un gruppo ha imparato a porre, nei segnali che considera significativi, nelle gerarchie informali della competenza e persino nelle deviazioni dalla procedura. Spesso il processo ufficiale funziona soltanto perché qualcuno conosce il modo corretto di aggirarne le imperfezioni.
Il debito di conoscenza
Quando queste competenze non vengono riconosciute, un progetto comincia ad accumulare quello che propongo di chiamare debito di conoscenza. L’espressione ricorda da vicino il debito tecnico, coniato, mi pare, da Ward Cunningham nei primi anni Novanta per descrivere le scorciatoie di codice che si pagano più avanti, con gli interessi. Le somiglia però solo nel nome: circola più nella pratica dello sviluppo software che nei testi accademici, e qui provo a prenderla in prestito e a metterla a fuoco, non a presentarla come un concetto già consolidato in letteratura.
Il debito tecnico risiede nel codice: soluzioni provvisorie, componenti obsolete, duplicazioni e fragilità destinate a rendere più costosa ogni modifica futura. Il debito di conoscenza risiede invece nella distanza fra ciò che l’organizzazione crede di sapere e ciò che soltanto alcune persone sanno realmente fare.
Si accumula quando una decisione architetturale viene registrata senza conservarne le motivazioni; quando lo sviluppo e l’esercizio si incontrano soltanto al momento del passaggio in produzione; quando un consulente lascia il progetto portando con sé la storia delle eccezioni; quando una retrospettiva viene rinviata per recuperare un ritardo; quando un incidente viene chiuso dopo avere ripristinato il servizio, senza ricostruire le condizioni che lo hanno reso possibile.
Ogni passaggio di consegne comprime la conoscenza. Se non è progettato con cura, applica una compressione con perdita: il documento arriva a destinazione, il significato no.
Il debito si accumula in silenzio. Non compare nel conto economico, non produce immediatamente uno scostamento dalla pianificazione, raramente trova posto nel registro dei rischi. Continua però a maturare interessi, e il conto salato viene presentato quando la persona indispensabile non è più disponibile, quando il sistema entra in una condizione mai prevista, quando una modifica apparentemente innocua innesca una dipendenza dimenticata.
Nella prossima puntata: due casi in cui questo debito è arrivato a scadenza, con conseguenze molto diverse per portata ma identiche per struttura, il Mars Climate Orbiter della NASA e il crollo in 45 minuti di Knight Capital.
© Calogero Bonasia. Tutti i diritti riservati. Questa pagina costituisce la versione di riferimento dell’articolo. Le citazioni e gli altri usi previsti dalla legge sono consentiti con l’indicazione del titolo, dell’autore e della fonte. Al di fuori di questi casi, la riproduzione, la pubblicazione, la distribuzione, la traduzione, l’adattamento o qualsiasi altro riutilizzo del testo, anche privo di finalità commerciali, richiedono la preventiva autorizzazione scritta dell’autore.