La società in cui lavoro punta a un margine di errore massimo del 10%. Gli analisti non si fanno sfuggire la stima di più o meno del 10%.
Non so cosa pensare al riguardo, dal momento che non ho nulla a cui paragonarlo.
Quale potrebbe essere una buona base di riferimento per misurare se stiamo valutando troppo sbagliato, per più o meno? Quanto (in%) pensi sia okay da perdere?
A meno che non stiate valutando qualcosa di molto simile a quello che voi e i vostri colleghi avete fatto prima, il +/- 10% è ridicolmente ottimista. La tua gestione non ha molta esperienza con il software o non è a conoscenza dei Grandi limiti alla stima del software . Quel documento contiene alcuni materiale di supporto di accompagnamento e molti punditry può essere trovato.
Esaminiamo un sistema molto più semplice di un tipico progetto software: Rubik's Cube. Puoi risolvere qualsiasi posizione in 20 mosse , max. Ma dal momento che stai valutando, puoi guardare un determinato cubo solo per alcuni minuti prima di dare la soluzione. Puoi dare un buon preventivo? No, a volte la stima di un processo richiede più tempo rispetto al processo.
Un altro sistema semplice: Pinocchio. Un automa di legno, il suo nasello cresce quando pronuncia una bugia. Cosa succede quando Pinocchio è a riposo, e poi dice "Il mio naso sta crescendo"? Alcuni sistemi non sono suscettibili di previsione, sono indecidibili.
Questi due problemi sono integrati nella maggior parte dei sistemi software. Per questo motivo, non avrai mai stime vicine al +/- 10%.
Il mio consiglio è di fornire una stima strongmente imbottita, lavorare come uno schiavo per fare il progetto il più velocemente possibile, e quindi sembrare occupato fino a quando non si è entro il 10% sotto o sopra. A quel punto, annuncia un successo spettacolare.
Sarei molto titubante riguardo a qualsiasi tipo di "margine di errore target" perché dipende in realtà dal progetto. Se si sta tentando di stimare quanto tempo ci vorrà per installare, configurare e personalizzare un nuovo sistema CRM in cui nessuno è abbastanza sicuro di quali tipi di personalizzazioni saranno necessari e quale tipo di modifiche del processo aziendale saranno necessarie e la società non ha precedenti di grandi progetti simili, il margine di errore dovrebbe essere piuttosto ampio (ad esempio, si potrebbe supporre che occorreranno 18 mesi +/- 50% e quotazioni 9-27 mesi). Man mano che il progetto va avanti, le specifiche diventano più chiare, le decisioni vengono prese sui processi aziendali, i tuoi sviluppatori si sentono più a loro agio, ecc. Questi margini di errore dovrebbero essere più stringenti. Se stai cercando di stimare quanto tempo costruirà il 101 ° sito di e-commerce di base quando hai una buona storia dai primi 100, ti aspetteresti di essere in grado di dare una stima molto più accurata. La maggior parte dei progetti, tuttavia, cadrà da qualche parte nel mezzo.
Ora, se stai citando un singolo numero piuttosto che un intervallo, la risposta è probabilmente quella di iniziare a quotare l'intervallo in modo che la persona che sta facendo la stima possa specificare la precisione con cui si aspetta che la loro stima sia.
Una buona base di riferimento potrebbe essere basata su dati reali raccolti.
Il primo passo per farlo è registrare tutte le stime . Il secondo passaggio è che registra i risultati effettivi . Sii onesto, non essere tentato di "autoregolarsi" sul reale. Raccogli abbastanza di queste informazioni e disponi di alcuni dati a livello statistico sulla base delle tue stime. Nota, questo può variare in base a chi ha fatto la stima e chi è il lavoro. Solo in questo modo puoi ragionevolmente aspettarti di dare un "margine di errore" che è qualsiasi altra pura spazzatura.
Non si ferma neanche lì; l'analisi delle cause che impediscono la stima può aiutare a migliorare l'accuratezza delle stime future. Nota: rimangono ancora stime e, in quanto tali, sono solo stime .
Anche la stima non finisce dopo la prima stima; questo è qualcosa che può essere regolato man mano che il progetto progredisce man mano che aumenta la conoscenza, riducendo così il margine di errore possibile mentre procedete. Più si è aperti alla comunicazione, si discutono le sorprese precedenti: le persone sono state meno sorprese e hanno concesso più tempo per apportare modifiche alle aspettative del progetto o dei clienti.
In secondo luogo, forse un modo migliore di gestire il margine di errore è ' interni di confidenza ' piuttosto che meramente% margini di errore. Tu hai basato la data di consegna stimata su un intervallo di confidenza, piuttosto che una data singolare.
PERT è un esempio di un framework per gestire la stima basata sul ragionamento statistico. Ad esempio:
"Sulla base di ciò che conosco ora, abbiamo un livello di confidenza del 90% che possiamo offrire in 8 mesi: 95% di confidenza in 10 mesi, 99% di confidenza in 2 anni, ecc"
Nota qui: più fiduciosi ti vogliono, maggiore sarà la stima. A seconda della complessità (ovvero della precisione che potresti avere), potrebbe essere una piccola differenza tra l'80% e il 90%, o potrebbe essere enorme!
Infine - Buona fortuna;) Se risolvi il "margine di errore massimo" nella stima del software in base al quale puoi specificare qualcosa come "tutte le nostre stime saranno +/- 10%", assicurati di commissionare un film d'incassi per il resto di noi nel settore del software. Sto pensando a qualcosa come un incrocio tra Office Space e The Matrix: D
In realtà dipende molto dalle dimensioni e dalla complessità del progetto.
Se la stima del tuo progetto è di 1 settimana, il 10% è ragionevole. Significa +/- 1/2 giorno.
Se è 1 mese il 10% è traballante - dalla mia esperienza è impossibile prevedere ciò che scoprirai in 1 mese.
Più di un mese - tutte le scommesse sono perse :).
Questi sono per sviluppatore - quindi per una squadra di sviluppatori di 4 1 settimana == 1 mese.
Per un team di sviluppatori di 4, per lo più è utile creare un elenco di funzionalità che possono essere eseguite in 1 mese e includere una percentuale del 10% per quelle funzionalità. Quindi, ri-stimare per il prossimo mese.
Ho fatto delle supposizioni ingenue qui
Devi tenerne conto in .. ma questa è l'idea generale.
Ci sono molte variabili:
Quanto è lungo il progetto?
Come sarà gestito il progetto? Cascata? Agile? MISCHIA?
Assumerei dalla domanda Cascata. Se è così, ci si aspetta che si verifichino errori in una certa percentuale, data la richiesta di un margine.
Se la risposta è una metodologia Agile, specialmente qualcosa come SCRUM. Non importa davvero quale sia la percentuale di margine. Un margine di errore del 50% su uno Sprint di 2 settimane è di 1 settimana, in uno Sprint di 1 settimana è di 2,5 giorni, entrambi gli scenari estremamente peggiori. Questo perché la data di consegna viene ricostituita ogni Sprint e diventerà sempre più accurata nel tempo, anziché sempre meno.
Con Waterfall il 50% di margine di errore non è nemmeno sentito, ma per un progetto di 12 mesi che è di 6 mesi, e non viene scoperto / ammesso veramente è così male fino a 10 mesi nei 12 .
Quando ero solito dirigere i team di software, all'incirca attorno al confine Cretaceo / Terziario, in realtà abbiamo raggiunto quasi il 10% di sconto sulla stima. Era circa +/- 15% se la mia memoria molto dubbia serve. Ma questo era dovuto al fatto che stavamo valutando per le cose che avevamo già fatto : firmware di comunicazioni in tempo reale relativamente semplice che prendeva byte da A e li spostava a B usando un linguaggio che ci era familiare, in un ambiente in tempo reale progettato da noi, parlando con l'hardware progettato internamente da ragazzi a pochi uffici di distanza. Un sacco di leggere varianti sul tema precedente, per letteralmente anni .
Aspettarsi di raggiungere questo tipo di tasso di errore nella normale stima del progetto software è, francamente, ridicolo . Quando lo vedi apparentemente raggiunto, è perché entrambe le persone sono sopravvalutate e imbottite (facendo cose extra e progetti per animali domestici per consumare il budget), o sottovalutate e hanno lavorato come cani alla sera e nei weekend per recuperare tempo.
Probabilmente hai sentito la cosa del 300% giusto?
Lo uso davvero. Completamente basato su ciò che ho visto per anni. Quando sento un giorno o due, c'è una settimana o più per essere davvero fatto . E testato. In tutti gli ambienti. Documentazione aggiornata Test di usabilità testato. Test delle prestazioni. Carico testato. Un paio d'ore è davvero più come un giorno.
Penso che siamo davvero pessimi nella stima a causa di:
Quindi al più alto livello, con gli imprenditori che hanno bisogno di stime superiori al 300%, ciò che finiamo per fare è ottenere stime ragionevolmente buone, ma al prezzo di un livello più alto e più generale. "Avremo una funzione di modifica dell'utente" anche se la versione 1 significa solo per 1 gruppo di utenti per la modifica di 1 campo.
Quando si tratta di "Qual è il margine di errore accettabile quando si stima una durata del progetto?" trovo che questo approccio, usato in molti ambienti Agile, aiuti a cambiare la domanda a quale sia la minima funzionalità per ottenere una versione alpha o beta dal vivo e quindi eseguire iterazioni su di essa.
Leggi altre domande sui tag project-management estimation