Stime in programmazione

Tutti gli sviluppatori devono fare i conti sulle stime, e quando parlo di stime non sto parlando solamente di quanto ci si impiega a realizzare una determinata funzionalità. La stima è anche all’interno del dettaglio del software: quanto impiegherà questa funzionalità fatta in questo modo a elaborare x righe di dati ?, Quanto impiegherà l’interfaccia a ricevere feedback dal server se lo stesso deve passare x dati in questo modo ?.

Le stime sono presenti sempre nella progettazione di un software e servono a prevedere “stimando” l’impatto di tutte le cose. Del resto ogni volta che stiamo realizzando un software stiamo creando qualcosa di ancora parzialmente sconosciuto. 

Le stime sono importanti, ma è anche la metrica che usiamo a essere nel contesto. Parlando per esempio con un cliente di quanto tempo ci vorrà per realizzare il software da lui commissionato, è differente dire circa 60 giorni o circa 2 mesi. Sembra strano ma l’uso di una unità di misura rispetto ad un’altra viene percepita in maniera differente dal cliente, nonostante stiamo dando lo stesso valore. Se la nostra stima si basa sui mesi, tutto sembrerà più approssimativo e lascia l’interlocutore pensare che ci possano essere molti più giorni di errore rispetto al dire la stessa stima in giorni.

Un’altra cosa importante da considerare è il modello di paragone. Difficilmente quando noi facciamo delle stime non paragoniamo ciò che stiamo stimando con qualcosa di già conosciuto e che si avvicina. Anche se ci sembra di “stimare” qualcosa di mai fatto, non è così. Il nostro cervello calcola una stima basandosi su modelli già memorizzati e su quelli si basa per calcolare il valore. E’ ovvio che più modelli sono stati memorizzati nella nostra esperienza e più potranno aiutarci a dare una stima, ma questo è vero solo nella velocità in cui rispondiamo, non nella precisione. 

Noi esseri umani tendiamo a sottostimare il lavoro che qualcosa deve fare, questo perché il cervello cerca sempre la soluzione più rapida e sintetica al problema e non si pone di analizzare approfonditamente le cose. Ecco perché le stime sono “stime” e non valori esatti. 

Come il nostro cervello tende a sottostimare il risultato, anche il nostro cliente tende a valutare e stimare ciò che gli diamo come informazione. Questo crea un problema di comprensione della stima e di misunderstand.

Nella mia esperienza reale però mi sono sempre scontrato con il fatto che i clienti vogliono avere delle stime precise su tempi e costi del loro progetto ed è vano cercare di convincerli del fatto che una stima è una stima e che il suo livello di precisione può variare anche di molto su progetti medio/lunghi. Anche noi se fossimo clienti vogliamo avere queste due informazioni che riteniamo vitali per qualsiasi cosa acquistiamo.

Quindi che fare ?

Quello che possiamo fare è di tenere traccia nel tempo della nostra affidabilità alla stima, capire quanto scarto di errore abbiamo dato alle attività e cercare di usare sempre una stima che vada con un margine di errore pessimistico del 80% della peggiore stima mai fatta, applicando quindi il principio di pareto sulla stima. Se la mia stima peggiore è quindi del 50% in più di tempo, al cliente potrò dare una stima almeno del 40% in più per il progetto ancora da realizzare. Non è sicuramente un modo preciso di stimare, ma rende il cliente meno impaziente e ci aiuta a migliorare il rapporto cliente-fornitore.