Oltre le stime: costruire uno stack informativo per la gestione del rischio - Prima parte

Durante il talk Stop asking me how long it will take, a PyCon 2026 a Bologna, Ines Panker ha formulato un'osservazione che ci è rimasta addosso: forse, quando chiediamo una stima, non stiamo cercando soltanto di sapere quanto durerà un'attività. Stiamo cercando di ridurre il rischio di una decisione.

Una stima continua a essere utile. Permette di valutare un investimento, confrontare alternative, pianificare capacità e rendere esplicite le aspettative. Ma un numero, da solo, non ci dice quanto siano solide le informazioni su cui si basa, quali dipendenze possano modificarlo o quanto presto riusciremo a capire se il lavoro sta producendo valore.

Per questo non pensiamo che la risposta sia rinunciare alle stime. Pensiamo che sia necessario inserirle in uno stack informativo più ampio: assunzioni, livelli di confidenza, dipendenze, decisioni, dati storici e segnali raccolti durante il lavoro. A questo si aggiungono le logiche del team: confronto, responsabilità distribuita, review e capacità di far emergere presto ciò che ancora non sappiamo.

La gestione del rischio si sposta così dalla ricerca di un numero più preciso alla costruzione di un sistema capace di apprendere. Un sistema che usa le stime, ma non dipende soltanto da esse; che contiene l'incertezza e, nello stesso tempo, crea le condizioni per intercettare il valore.

È di questo che parliamo in questo articolo, con esempi, casi e soluzioni progressive tratti dalla pratica quotidiana di Nephila.

Ines racconta che la stima del software è spesso un esercizio di previsione poco affidabile: gli sviluppatori sono spinti a fornire numeri precisi, pur lavorando in contesti in cui requisiti e specifiche cambiano continuamente. Succede in team con decenni di pratiche alle spalle, e sappiamo bene che le stime tendono a essere ottimistiche, ma organizzazioni e clienti continuano a preferire numeri apparentemente precisi, anche se spesso si dimostrano sbagliati.

Questo perché il vero scopo delle stime non è ottenere precisione, ma ridurre l'incertezza percepita e comprendere i rischi del progetto.

Per questo motivo, ci fa capire Ines, sarebbe più utile spostare l'attenzione dalle stime a lungo termine, portandola verso logiche di gestione dei rischi, delle aspettative e dell'evoluzione dei requisiti, trattando il software come un'attività di discovery progressiva, piuttosto che come un processo perfettamente prevedibile, in un contesto ad alta variabilità.

Ecco i "trigger" emersi in questo talk, che riportano alla realtà quotidiana del nostro team alle prese con le stime, insieme alle nostre esperienze, pratiche e sperimentazioni.

È di questo che parliamo in questo articolo, con esempi, casi e soluzioni progressive tratti dalla pratica quotidiana di Nephila.

È stato interessante ritrovare, anche nella letteratura e nelle esperienze condivise, una dinamica che osserviamo spesso nei team tecnici: la difficoltà di stimare non deriva soltanto dalla complessità del lavoro, ma anche dai bias cognitivi. Alcuni tendono a sottostimare per eccesso di fiducia e semplificazione, altri a sovrastimare per prudenza. Inoltre, la percezione del rischio varia sensibilmente in funzione del ruolo ricoperto, influenzando il modo in cui vengono formulate le stime.

Nella nostra esperienza, abbiamo una prassi abbastanza rodata, facilmente impiegabile in team stabili e verticali, che consiste nel fare in modo che, dentro il team di progetto, ogni work item venga preso in carico o assegnato alla persona che, per competenze, esperienza e storico, è più indicata a farne analisi e stima. Un'altra persona del team viene poi associata al medesimo work item e riscontra/valida l'analisi e la relativa stima. Questo permette di includere capacità ed esperienza, ma di ridurre il rischio relativo ai bias cognitivi, perché bilancia l'analisi e la stima con un punto di vista diverso e minor rischio di condizionamenti. E si applica a ogni team member, senza distinzione di seniority, software architect e CTO compresi.

Ad esempio, in un progetto di continuità tecnologica su una piattaforma Django per la gestione di borse di studio e sussidi universitari per conto della pubblica amministrazione, un'architettura complessa ereditata da noi, che manuteniamo, evolviamo e continuiamo a rendere più solida in collaborazione con il team del cliente,  ogni work item viene assegnato o preso in carico per analisi e stima dalla persona, o da una delle persone, che ha maggiore conoscenza dell'ambito in cui quel work item insiste, per competenze specifiche e storico. L'analisi viene prodotta e documentata, e la stima viene assegnata in agile con il t-shirt sizing, fondamentale anche per la corretta assegnazione di capacity nei planning. Analisi e stime passano poi in revisione a un altro engineer individuato per affinità, che rilascerà feedback e commenti, nell'ottica di validare l'esito o di chiedere rivalutazioni o integrazioni. È possibile che analisi e stima vengano rifatte da zero, anche dal revisore? È piuttosto raro, ma il sistema lo consente, perché quello che conta è l'accuratezza dell'analisi e della stima, e l'apertura alla soluzione più adatta anche in ottica sistemica e architetturale complessiva.

Se il team è caratterizzato da conoscenze diffuse, e i team member non hanno competenze omogenee né per specialità né per seniority,  magari senza uno storico su cui fare benchmark, con conseguente amplificazione dei bias cognitivi, torna utile il Planning Poker, in cui ogni componente del team assegna in modo indipendente un valore alla stima, spesso usando la sequenza di Fibonacci, e poi si discutono soprattutto le valutazioni più distanti fino a raggiungere un consenso.

Ad esempio, per uno dei maggiori produttori al mondo di vernici, abbiamo sviluppato parte dell'interfaccia client/point of sale di un sistema di color matching per la consultazione, personalizzazione e dispensazione delle formule colore, con scambio dati verso un server remoto. Avevamo un team sufficientemente numeroso, con competenze prevalentemente frontend e full-stack: l'uso del planning poker sui singoli task è stato importante per guidare il team, aiutandolo a superare lo scoglio della paura della "stima errata", e per costruire una consapevolezza condivisa, estesa anche a competenze non tecniche (PM, account manager, team leader). Il rischio è stato contenuto anche e soprattutto grazie alla "parcellizzazione" dei task portati in planning, che ne ha ridotto per quanto possibile la complessità tecnica. L'ambito di rischio si definiva quindi in prevalenza intorno ai bias cognitivi, che con la logica pluralista che contraddistingue il metodo, e la potenza della statistica, ha permesso di ridurre il gap di confidenza, portando a concentrarsi sull'argomentazione analitica per raggiungere il consenso nel caso delle stime più distanziate. Man mano è stato poi costruito uno storico, un sistema di reference stories misurabili che progressivamente fungessero da benchmark e migliorassero la capacità di previsione del team.

Molte organizzazioni investono tempo nella produzione di stime, ma raramente chiudono il ciclo confrontandole con il tempo effettivamente impiegato. Spesso manca una raccolta sistematica dei dati di consuntivo, rendendo impossibile migliorare progressivamente la capacità di previsione del team.

Nella cultura agile, i dati di consuntivo non servono a giudicare gli errori del passato, ma ad adattare il piano di lavoro, con un approccio che supera i vecchi bilanci rigidi per misurare il valore reale creato e tiene conto della variabilità delle condizioni in itinere. È un approccio che abbiamo adottato in modo piuttosto fedele, portando nelle retrospettive la discussione su cosa fosse andato storto, privilegiando quindi il contesto alla condivisione sistematica del tempo effettivamente impiegato a consuntivo.

Siamo, d'altra parte, un'organizzazione in cui l'impiego del tempo, risorsa primaria, è un dato fortemente analizzato, in un'ottica data driven, per comprendere come l'intero sistema si muove e poterlo orientare. La capacity delle nostre persone è distribuita su più progetti contemporaneamente che seguiamo per i nostri clienti, oltre che su applicazioni e prodotti digitali a uso interno (parzialmente rilasciati), su sviluppo di metodologie e pratiche, e include un grant significativo assegnato alle attività di ricerca, formazione e community.

Mappare l'impiego del tempo serve un'esigenza prima di tutto analitica e di progettazione complessiva: permette di armonizzare gli obiettivi di un portfolio di attività di diversa natura, che coinvolgono tutti contemporaneamente, regolando le priorità su sprint interni settimanali. È importante, ad esempio, per equilibrare il carico individuale con attenzione a che un engineer non sia impiegato su più di 2 o 3 progetti nello stesso sprint, perché questo porterebbe a disperdere la concentrazione, incidendo sulla qualità del lavoro e sul benessere della persona.

Inoltre, tutte le attività, anche quelle non specificamente finalizzate allo sviluppo di prodotti digitali, sono identificate tramite user stories e gestite tramite Taiga, una piattaforma di project management Django-based. Tutti i work item generati su Taiga entrano nel feed di un sistema di time-tracking personalizzato, sempre Django-based, per essere popolati con il dato di impiego da parte di ognuno.

Questo sistema di raccolta dati a consuntivo, in quanto basato su applicativi progettati e sviluppati da noi, ci permette di estenderne l'impiego anche ai progetti dei nostri clienti, quando gestiti secondo un approccio di ingegneria collaborativa, e che utilizzano un framework di project management del cliente. Tramite API, il framework del cliente alimenta il nostro sistema di time-tracking, senza bisogno di tracciare parallelamente il tempo impiegato: utilissimo nei casi in cui il lavoro di sviluppo debba essere rendicontato, perché riduce il tempo di consuntivazione, mantiene il livello di dettaglio e annulla il rischio di errore dovuto a processi manuali di trascrizione.

Con un cliente che pubblica diverse riviste scientifiche — una collaborazione pluriennale e un ambiente stimolante in cui condividiamo conoscenza tecnica su Django, design architetturale, product management e approcci metodologici, ruotando attorno all'estensione di Janeway, una piattaforma open source per la pubblicazione online di articoli scientifici, con contributo attivo anche al progetto open-source — siamo andati oltre. Qui siamo in un contesto di integrazione di team, con ruoli distribuiti tra noi e loro, e sviluppatori da ambo le parti. Un nostro software architect conduce i planning e mantiene la responsabilità tecnica dell'area sviluppo, guidando la produzione delle stime con il t-shirt sizing. Il framework di project management del cliente, GitLab, è collegato tramite API con il nostro sistema di time-tracking, e le misurazioni dei dati a consuntivo rilevati sulle persone che forniamo al team integrato alimentano, sui singoli work item, un set di informazioni che servono anche a migliorare progressivamente la capacità di previsione del team integrato.

***

Questa è la prima parte dell’articolo Oltre le stime: costruire uno stack informativo per la gestione del rischio, pensato in due uscite. La seconda parte uscirà il 24 Settembre e chiuderà la riflessione con altri due casi centrati su: il punto di vista del committente, focalizzato su tempi e costi, e la gestione delle stime con progetti complessi e scalabili. 

***

Abbiamo scritto questo articolo con il supporto dell'AI. Se vuoi saperne di più su come usiamo questi strumenti per la scrittura, ecco la spiegazione.

Immagine di copertina: 
Foto di Ximena Balderas su Unsplash