Definisci il deliverable prima di stimare le ore
Non puoi produrre una stima difendibile per un termine vago come sito web, campagna, integrazione o redesign. Prima descrivi il risultato osservabile: pagine, stati, formati, integrazioni, dispositivi, contenuti forniti, processo di approvazione e criteri di accettazione.
Scrivi una breve definizione di fatto per ogni deliverable. Se due persone ragionevoli potrebbero non essere d’accordo sul fatto che il lavoro sia completato, l’ambito non è ancora abbastanza specifico da stimare. Chiarirlo adesso costa meno che discuterne quando il budget è già finito.
- Cosa verrà consegnato e in quale formato
- Cosa deve fornire il cliente e entro quando
- Quali dispositivi, browser o piattaforme devono essere supportati
- Quanti concetti, varianti e cicli di revisione sono inclusi
- Cosa è esplicitamente escluso dalla stima
Suddividi il lavoro in blocchi abbastanza piccoli da poter essere messi in discussione
Dividi il deliverable in attività che in genere richiedono da una a otto ore. Un’attività chiamata sviluppare l’applicazione per 60 ore nasconde troppe ipotesi. Autenticazione, stati account, validazione moduli, layout responsive, analytics e deploy possono essere stimati e verificati separatamente.
Separa il lavoro ripetibile da quello incerto. Una pagina costruita con una libreria di componenti esistente non ha lo stesso rischio di un’integrazione di terze parti non documentata. Unirli in un solo numero fa finanziare l’ignoto dal lavoro conosciuto.
Usa stime a tre punti per le attività incerte
Per un’attività con incertezza significativa, annota una durata ottimistica, una più probabile e una pessimistica. Una stima ponderata pratica è: ore attese = (ottimistica + 4 × più probabile + pessimistica) ÷ 6.
Supponiamo che un’integrazione possa richiedere 4 ore se documentazione e accessi sono corretti, 8 ore nel caso più probabile e 20 ore se l’API crea problemi. La stima ponderata è 9,3 ore. La formula non elimina l’incertezza; impedisce che il caso ottimistico diventi silenziosamente il piano ufficiale.
Se lo scenario pessimistico farebbe saltare il progetto, non nasconderlo dentro una percentuale. Offri una fase di discovery a pagamento, una fase a ore o un punto decisionale prima di impegnarti su un totale fisso.
Conta il lavoro nascosto e le dipendenze del cliente
Il tempo di produzione è solo una parte della consegna. Discovery, riunioni, aggiornamenti, preparazione file, revisione feedback, test, controlli di accessibilità, handover e deploy consumano capacità. Se sono necessari al progetto, devono essere inclusi nella stima.
Le dipendenze devono avere un responsabile e una scadenza. Attendere accessi o contenuti può non generare ore fatturabili, ma può spostare la data di consegna e provocare costosi cambi di contesto. Definisci cosa succede quando un input arriva in ritardo invece di fingere che il calendario sia immune alla realtà.
- Discovery, ricerca e chiarimento dei requisiti
- Project management e comunicazione consolidata con il cliente
- Preparazione contenuti, migrazione o pulizia dati
- Quality assurance, accessibilità e test su dispositivi
- Revisioni incluse, deploy e handover
- Costi diretti e specialisti esterni
Esempio pratico: piccolo aggiornamento di un sito
Il refresh di un sito di cinque pagine richiede 4 ore per discovery e struttura, 10 per design, 22 per implementazione, 8 per inserimento contenuti e controlli qualità, 5 per comunicazione e handover e 5 per il ciclo di revisione incluso. Il lavoro definito totalizza 54 ore.
Un’integrazione CRM resta incerta. La stima a tre punti è 4, 8 e 20 ore, che produce 9,3 ore attese. Aggiungi un piccolo margine del 20% a prezzo fisso solo a quella attività incerta: 1,9 ore. Il totale di pianificazione è circa 65 ore, non 54 e non un 70 casuale.
Internamente conserva la stima per attività. Nella proposta al cliente presenta deliverable, ipotesi, revisioni incluse, prezzo e calendario. Le ore sono la prova alla base della tua decisione; non devono trasformarsi in un verbale allegato a ogni preventivo.
Trasforma ogni progetto concluso in dati per stimare meglio
Registra il tempo reale usando le stesse categorie della stima. Dopo la consegna annota da dove nasce la differenza: requisiti poco chiari, ritardo del cliente, sorpresa tecnica, rilavorazione o semplicemente una stima troppo ottimistica.
Dopo diversi progetti, sostituisci i buffer generici con intervalli basati sui tuoi dati. Potresti scoprire che l’implementazione è prevedibile mentre preparazione contenuti e approvazioni non lo sono. È informazione operativa utile e molto più preziosa che chiedere a internet quanto dovrebbe durare un sito web.
- Confronta ore stimate e reali per attività, non solo sul totale progetto
- Annota la causa di ogni scostamento significativo
- Aggiorna i template riutilizzabili dopo la consegna
- Fai rivedere le stime grandi da un altro professionista prima di impegnarti
Trasforma il metodo in un preventivo reale
Dividi il lavoro in attività, aggiungi tempi e tariffe e crea un preventivo chiaro per il cliente.
Apri il calcolatore gratuitoDomande frequenti
Quanto buffer devo aggiungere a una stima di progetto?
Non esiste una percentuale universale. Identifica le attività incerte e aggiungi tempo o costo per quei rischi. Se l’incertezza domina il progetto, usa discovery a pagamento o fatturazione oraria invece di nasconderla in un grande buffer.
Cosa faccio se non ho dati storici?
Parti da una scomposizione dettagliata, usa stime a tre punti per il lavoro sconosciuto, fai mettere in discussione le ipotesi da un collega e separa discovery e delivery quando l’intervallo è troppo ampio.
Devo mostrare al cliente ogni ora stimata?
Non necessariamente. Conserva il dettaglio internamente e mostra al cliente deliverable, ipotesi, limiti, milestone, prezzo e processo di gestione delle modifiche.
