che cosa deve governare un responsabile di progetto
Il flusso nascosto dietro la velocità locale
Un caso meno catastrofico dei due naufragi narrati nella puntata precedente, ma simile nella sostanza, riguarda un progetto di digitalizzazione dei servizi al cittadino presso un ente della pubblica amministrazione italiana. I team di sviluppo, che seguivano il metodo Scrum, completavano gli sprint con regolarità, riducevano il backlog e mantenevano una velocità costante. Nonostante ciò, il tempo necessario per chiudere una singola pratica del cittadino rimaneva invariato per mesi.
Una mappatura dell’intero processo, anziché concentrarsi solo sulla produttività dei singoli gruppi, ha rivelato una verità sorprendente: la pratica trascorreva circa l’ottanta per cento del suo tempo in attesa, bloccata tra un ufficio e l’altro. Questo tempo perso era dovuto a diversi fattori, come una firma in ritardo, un parere tecnico in attesa, una responsabilità trascurata o una richiesta che nessuno aveva l’incarico esplicito di sollecitare.
Il backlog non mentiva. Rispondeva, semplicemente, alla domanda sbagliata: fotografava la velocità locale dei singoli gruppi, mentre il tempo che il servizio impiegava per attraversare l’intero organismo restava invisibile a ogni cruscotto. Le unità operative erano state spinte al massimo del rendimento, lasciando che il sistema nel suo insieme si incagliasse nelle code fra un passaggio e l’altro. Un po’ come potenziare tutti i motori di una nave, senza accorgersi che il timone è bloccato.
Quando lo sviluppo di nuove funzionalità venne sospeso, e l’attenzione si spostò sulle dipendenze, sul lavoro in corso, sui tempi di attesa nei passaggi fra le strutture coinvolte, la capacità complessiva del sistema raddoppiò. A parità di persone impiegate.
Che cosa deve governare un responsabile di progetto
Il compito di un responsabile di progetto non si esaurisce nel governare ambito, tempi, costi e qualità: quella è soltanto la superficie visibile del lavoro. Il compito vero consiste nel preservare la continuità della comprensione, mentre il lavoro attraversa specializzazioni, fornitori, strumenti e livelli gerarchici diversi, come un messaggio che deve arrivare integro dopo essere passato di mano in mano.
Una matrice RACI può stabilire chi sia responsabile di un’attività, senza garantire che quella persona comprenda il sistema sul quale deve decidere. Una Definition of Done può dichiarare completata una funzionalità, senza dimostrare che il gruppo di Operations sappia diagnosticarla alle tre del mattino.
Un manuale operativo può descrivere una sequenza di operazioni, senza trasferire la capacità di riconoscere il caso in cui quella sequenza non debba essere applicata. Un indicatore può segnalare che il progetto procede secondo la pianificazione di riferimento, senza misurare quanta comprensione si sia persa lungo il cammino.
Per questo il debito di conoscenza meriterebbe un posto esplicito nella governance progettuale, un vero oggetto di controllo, più che l’ennesimo documento da archiviare e dimenticare. Occorre osservare quante decisioni critiche siano prive di motivazione documentata; quante dipendenze restino affidate a relazioni informali; quanti incidenti possano essere risolti da una sola persona; quanto tempo serva a un nuovo componente del gruppo per diventare autonomo; quante attività vengano riaperte perché il passaggio di consegne ha trasferito il risultato, ma non il contesto.
Occorre coinvolgere le Operations nelle revisioni di progettazione, affiancare le persone nelle funzioni critiche, praticare revisioni incrociate, conservare le decisioni architetturali con le loro motivazioni, trattare le retrospettive come attività di produzione della conoscenza, garantire che chi solleva un’anomalia rimanga coinvolto fino alla sua chiusura.
La documentazione rimane indispensabile: è una mappa preziosa del territorio, finché nessuno la scambia per un sostituto del cammino. Una mappa perfetta non insegna mai a muoversi in una palude.
Mi pare di ricordare, a questo proposito, un contributo pubblicato nella biblioteca online del Project Management Institute, dedicato proprio alle tecniche di trasferimento della conoscenza fra progetti: sosteneva una tesi coerente con quanto detto finora, cioè che negli ambienti organizzati per progetti gli strumenti informatici non sostituiscono le reti sociali attraverso le quali il sapere viene davvero trasferito. Resta comunque un problema strutturale: spesso i gruppi di lavoro vengono sciolti proprio quando hanno finalmente raggiunto l’efficienza.
Intelligenza artificiale e culture della conoscenza
L’intelligenza artificiale generativa amplifica questa contraddizione. Si possono fornire a un sistema milioni di documenti e ottenere risposte rapide su procedure, contratti, requisiti e incidenti passati. Tuttavia, se il patrimonio documentale si limita a descrivere il processo ufficiale e ignora il lavoro effettivo, il sistema genererà una rappresentazione coerente di un’organizzazione inesistente, un ritratto verosimile di un corpo inanimato. In sostanza, automatizzerà la finzione ufficiale.
L’intelligenza artificiale non annulla le culture della conoscenza, ma le integra. Se la cultura organizzativa incoraggia la compilazione e scoraggia il dissenso, il sistema apprenderà a generare documenti impeccabili e decisioni prive di discernimento. Al contrario, se l’organizzazione valorizza la rilevazione delle anomalie, conserva le motivazioni alla base delle decisioni e promuove il confronto tra competenze, la tecnologia può amplificare una capacità già presente. Pertanto, la qualità di uno strumento cognitivo dipende anche dalla qualità epistemica dell’organizzazione che lo alimenta.
Ascoltare il «toc»
L’obiettivo è costruire organizzazioni capaci di riconoscere chi possiede la conoscenza, di farla circolare, di ascoltarla anche quando contraddice il cruscotto, più che sistemi che pretendano di sapere al posto delle persone.
Un database non potrà mai sentire un guasto come lo sente un tecnico con un cacciavite in mano. Non ha un corpo, una storia, una comunità, né la memoria dei rumori precedenti. Una buona governance può però garantire che, quando qualcuno sente quel «toc», disponga del tempo, dell’autorità e del canale necessari per fermare la macchina.
Un’organizzazione ben gestita commette errori come tutte le altre, ma si distingue per la capacità di individuare segnali deboli che attraversano le interfacce e arrivano ai vertici, prima di degenerare in perdite, incidenti o missioni fallite. Si può archiviare tutto il rumore del mondo, ma la conoscenza inizia quando qualcuno riconosce l’unico suono fuori posto.
© 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.