Chi fa il dirigente sa che esistono varie modalità per farsi una idea di tempistiche e costi di un progetto. Chi amministra progetti informatici, avrà più familiarità con la metodologia agile.
Ho conosciuto la metodologia agile in una precedente esperienza. In delle chiamate si creava una storia, ad esempio “l’utente vuole fare X perché vuole Y etc.” e si assegnavano dei punti a questa storia. Maggiori i punti, maggiore la difficoltà, maggiori i costi sia lato tempo che lato economico.
Così come nella matematica esistono le parentesi per spezzettare i problemi, nella metodologia agile si possono spezzare le storie per abbassare i punti. Un punto dibattuto della metodologia agile sta nel come convertire punti in ore-uomo e quanto farle costare al cliente.
PERT, detta anche stima a tre valori
Ti presenterò una diversa modalità, più statistica e “vecchia”, che, come puoi anticipare, ha i suoi svantaggi. Si potrebbe esagerare dicendo che si tratta di una modalità a prova di bomba, perché la modalità PERT veniva usata dal settore militare americano. Oggi usano tecniche più avanzate come il metodo Montecarlo, ma hanno progetti decisamente più complessi delle non grandi aziende, che leggeranno questo articolo. Questo articolo si rivolge a PMI, grosso modo come gli altri.
Questa tecnica parte in maniera piuttosto facile: si inizia stabilendo
a: il numero di giorni, ore, etc. reputato minore per il completamento di un progetto, attività
b: reputato il più possibile, verosimile
c: il massimo
Da cui si costruisce una specie di media M = a+4b+c/6
Sulle costanti della formula, 4 e 6, ci torniamo dopo perché ci si può giocare.
E ora viene la parte più difficile di questo metodo. Con quei numeri si può costruire una distribuzione in probabilità, che risulta un caso particolare di distribuzione beta, a sua volta un caso molto particolare di distribuzione normale.
Questo ci permette di poter calcolare, ad esempio al 95% di confidenza, entro quanto tempo completeremo il progetto o le attività, in funzione dei numeri decisi all’inizio. Aiuta dal punto di vista contrattuale e a non creare dissapori fra dirigente e squadra operativa, che spesso ha da ridire sulle tempistiche stimate.
Le costanti
Si può lavorare sulle costanti per fare stime più difensive, che pesano di più casi estremi e quindi stime con un intervallo più ampio. Questo ha particolarmente senso quando poche persone decidono quei 3 numeri di sopra, e quindi possono tenere a bada il loro pregiudizio inserendo questo fattore correttivo. Ma se hai una media e grande azienda ed ad un progetto quei numeri vengono decisi da più di 15 persone, fra dirigenti e dipendenti, il teorema centrale del limite ti viene in soccorso, perché ti semplifica il tipo di distribuzione risultante da questa interazione, producendo una stima meno distorta da possibili casi estremi.
Conclusioni
Per esperienza posso dire che il metodo agile risulta più pesante dal punto di vista della descrizione della storia, mentre quello PERT dal punto di vista numerico.
Esistono casi però dove entrambi i metodi falliscono non per la stima ma per come si parte. E non esistono metodi che tengono: serve esperienza. Alla data di scrittura dell’articolo ho registrato 2 casi su oltre 26 dove ho bucato la stima della tempistica.
Un caso aveva a che fare con una variazione in corso d’opera per i dati: avevo fatto l’analisi su X, li ho comunicati al cliente e si è accorto che voleva quei risultati su altro. Mi ha detto di ripetere la cosa sui dati Y, non prevista inizialmente.
In altro caso una libreria richiedeva una conoscenza molto approfondita della sua documentazione e gli errori di output non puntavano direttamente a quel suggerimento.
Vuoi provare a giocare con questo modo? Ho creare un foglio dedicato.
English 
Italian