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

Ci eravamo lasciati, nel primo articolo,con l’analisi di casi reali dalla nostra pratica quotidiana, in cui raccontiamo come affrontiamo il classico scenario in cui una stima è più influenzata da un bias cognitivo e da una scarsa misurazione dei dati. Ma cosa succede quando dobbiamo gestire il punto di vista del committente, focalizzato su tempi e costi, e governare la complessità nei progetti di lunga durata? Scopriamolo insieme.

Un punto particolarmente interessante riguarda il rapporto con il committente. La richiesta è quasi sempre orientata a ottenere una previsione il più possibile precisa di tempi e costi. Tuttavia, la domanda più utile è spesso un'altra: quale risultato è possibile ottenere con il budget e il tempo disponibili? Il focus si sposta quindi dalla previsione del costo alla gestione del perimetro e delle priorità.

Quando la complessità cresce, il problema non è nel dettaglio, ma nell'idoneità del rischio calcolato. La cultura agile viene in supporto a un tipo di approccio non deterministico, perché parte dalla definizione di un perimetro e dalla gestione delle priorità in itinere. Ma cosa succede se il committente richiede comunque un approccio deterministico, in presenza di incognite importanti?

Una volta definito il perimetro di massima per dimensionare la classe di impegno, ad esempio, un progetto di almeno un anno, che impiega necessariamente almeno un team di 6 persone, abbiamo avuto esperienza di proporre una fase di discovery, con evidenza degli elementi di output da approfondire perché contenevano più incognite. Spostando l'analisi dei rischi in questa fase, una previsione più precisa dei tempi e dei costi si può affrontare, ma tutto il processo richiede un investimento iniziale da parte del cliente, che comunque non risolve il problema della certezza dei costi e dei tempi, anzi, in alcuni casi questo problema viene percepito come amplificato.

Applicare modelli agili, invece, richiede un rapporto di collaborazione e fiducia tra le parti, e che il committente sia parte attiva dell'evoluzione del progetto. Questo è l'ambito in cui il nostro team si muove con più naturalezza. Partiamo dalla metodologia, una expertise che abbiamo sviluppato iterativamente su noi stessi, in anni di cura e ricerca di best practice, per rendere i nostri workflow più efficienti e le nostre performance più efficaci. La condividiamo e la estendiamo adattandola all'ambiente e all'organizzazione del nostro committente, con un approccio inclusivo che faciliti la collaborazione e il comfort. Il committente ha pieno controllo del suo progetto, dell'evoluzione del perimetro e delle priorità, decide i costi e i tempi, ma non viene lasciato solo nel farlo.

Nel caso già citato del cliente editoriale scientifico, l'approccio metodologico è l'elemento fondante di una collaborazione pluriennale, e si compone di una base fissa più una variabile: è il cliente a decidere in ultima istanza, nell'ambito di una pianificazione condivisa, quanto impiegare della capacity tecnica del team assegnato al progetto.

In un altro caso, quello di una neobank che dal 2023 supportiamo con sviluppo full-stack (Django/Python, Tailwind) su un portale B2B2C integrato con servizi cloud Azure, il rischio risiedeva maggiormente nella convergenza dei diversi reparti interni al cliente su obiettivi e requisiti, e nelle dipendenze del nostro team da un certo numero di essi, che operano spesso in modo indipendente. Abbiamo optato per circoscrivere l'ambito di progetto identificando un team multidisciplinare di elevata seniority, un'allocazione fissa, e un workflow esplicito e dettagliato, che chiarisse sia le dinamiche di governance e controllo del rischio nei flussi operativi (dalla gestione delle priorità in roadmap, al governo delle dipendenze, alla gestione del backlog condiviso), sia le dinamiche di controllo del rischio in ambito tecnico, come l'impatto dei requisiti sulle soluzioni tecniche o i rework.

La riduzione dell'incertezza non passa necessariamente da stime sempre più accurate. Passa prima di tutto dalla capacità di scomporre il problema in unità sufficientemente piccole e comprensibili da poter essere stimate con un margine di errore accettabile. In questo contesto, l'iterazione diventa lo strumento principale per distinguere progressivamente ciò che è essenziale da ciò che è opzionale, riducendo il rischio complessivo del progetto.

Lavorando spesso su progetti aperti e scalabili, con molte evolutive su cicli di vita pluriennali, siamo abituati a governare la complessità partendo da analisi robuste e da una solida architettura del software: è per questo che utilizziamo una tecnologia come Django, un framework maturo e stabile, particolarmente adatto a questo tipo di progetti, che ci permette di continuare a costruire senza correre il rischio di buttare tutto per rifare, anche dopo diversi anni. Su questa base, la riduzione del rischio di stima passa necessariamente da una scomposizione dei work item in unità sufficientemente piccole e gestibili.

Recentemente abbiamo sperimentato un workflow di stima in ambito tecnico, supportato dall'uso di un LLM, per un set di 36 change request richieste da un cliente internazionale, su uno tra i tanti strumenti di workflow interno che abbiamo sviluppato per loro, una piattaforma per l’autorizzazione delle trasferte dei propri dipendenti distribuiti in tutto il mondo.

Nel caso specifico, Juliana Nicacio, backend developer del team che ha lavorato su questo progetto, è partita dal t-shirt sizing in uso comune nell'ambito delle stime tecniche, con successivo step di validazione interna, ma ha evoluto e documentato il processo di analisi adottando criteri precisi. Per ogni item, l'analisi parte dal codice, non dalla descrizione della change request: in questo modo vengono chiaramente distinti i bugfix dalle nuove regole di business da introdurre. Contestualmente, organizza gli item per aree funzionali condivise, raccogliendo le domande aperte per gruppo. Separa nettamente gli item pronti da quelli bloccati da domande al cliente. Affronta poi la complessità distinguendo, ad esempio, tra funzionalità da sviluppare da zero e funzionalità che possono utilizzare pattern e meccanismi analoghi, oppure scomponendo e motivando le stime più grandi in parti (ore di codice, ore di test) o stimando come add-on quando una risposta del cliente potrebbe aggiungere scope. Segnala anche il raggio d'azione di una modifica, che implica un maggiore o minore rischio di impatto su altre funzionalità.

In sintesi, il metodo separa sistematicamente ciò che è verificabile dalle ipotesi da confermare con il cliente, tiene le stime ancorate a una scala fissa, e scompone ogni stima in codice/test/verifica manuale per renderla tracciabile e giustificabile, invece che un numero a sensazione. Ne esce un documento di analisi a più dimensioni, che il cliente può utilizzare per definire priorità e prendere decisioni in piena autonomia rispetto ai propri obiettivi, modificandole nel tempo e senza dover ripetere, a ogni iterazione, la domanda "quanto costa questa funzionalità?".

Se c'è un filo che lega queste quattro esperienze, è che nessuna di esse prova a risolvere il problema della stima rendendola più precisa. Ognuna prova a renderla più informata: da chi la produce e chi la valida, da cosa viene misurato dopo, da come viene posta la domanda al cliente, da quanto piccola e tracciabile è l'unità che si prova a stimare.

È questo, in fondo, lo stack informativo di cui parliamo nel titolo: non un numero più affidabile, ma un insieme di pratiche come revisione tra pari, planning poker, time-tracking data driven, discovery mirata, scomposizione sistematica, che lavorano insieme per contenere l'incertezza invece di fingere di eliminarla. Le stime restano uno strumento imperfetto, e continueranno a esserlo. Ma diventano uno strumento affidabile nella misura in cui smettiamo di chiedere loro di predire il futuro, e iniziamo a chiedere loro di aiutarci a governarlo, un'iterazione alla volta.

Restiamo convinti che ci sia ancora molto da imparare, e continueremo a condividere quello che scopriamo lungo il percorso.

***

Questa è la seconda e ultima parte dell'articolo Oltre le stime: costruire uno stack informativo per la gestione del rischio. Se hai perso la prima parte, trovi qui il primo articolo.

***

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.