Come rispondere quando viene richiesto un preventivo?

Da Il programmatore pragmatico: da Journeyman a Master :

What to Say When Asked for an Estimate

You say "I'll get back to you."

You almost always get better results if you slow the process down and spend some time going through the steps we describe in this section. Estimates given at the coffee machine will (like the coffee) come back to haunt you.

Nella sezione, gli autori raccomandano il seguente processo:

• Determina la precisione di cui hai bisogno. In base alla durata, è possibile citare la stima con una precisione diversa. Dire "da 5 a 6 mesi" è diverso da dire "150 giorni". Se scivoli un po 'nel settimo mese, sei ancora abbastanza preciso. Ma se scivoli nel 180 ° o 210 ° giorno, non così tanto.
• Assicurati di capire cosa viene chiesto. Determina l'ambito del problema.
• Modella il sistema. Un modello potrebbe essere un modello mentale, diagrammi o record di dati esistenti. Decomporre questo modello e creare stime dai componenti. Assegna valori e intervalli di errore (+/-) a ciascun valore.
• Calcola la stima in base al modello.
• Tieni traccia delle tue stime. Registra informazioni sul problema che stai valutando, la tua stima e i valori effettivi.
• Altre cose da includere nella stima stanno sviluppando e documentando i requisiti o le modifiche alle specifiche dei requisiti, creando o aggiornando i documenti e le specifiche di progettazione, test (unità, integrazione e accettazione), creando o aggiornando i manuali o README dell'utente con le modifiche. Se due o più persone lavorano insieme, c'è un sovraccarico di comunicazioni (telefonate, e-mail, riunioni) e unendo il codice sorgente. Se si tratta di un'attività lunga, tenere conto di cose come altro lavoro, tempo libero (vacanze, ferie, tempo di malattia), riunioni e altre attività generali quando si seleziona una data di consegna.

La stima del software è il compito più difficile nell'ingegneria del software, il secondo più vicino è l'elicitazione dei requisiti.

Ci sono molte tattiche per crearle, il tutto basato sul raggiungimento di buoni requisiti. Ma quando la tua schiena è contro il muro e si rifiutano di darti dettagli migliori, Fake It:

1. Dai un'occhiata ai requisiti che hai.
2. Fai delle ipotesi per colmare le lacune basandoti sulla tua ipotesi migliore su ciò che vogliono
3. annota tutte le tue ipotesi
4. Falli sedere, leggi e accetta le tue ipotesi (o, se sei fortunato, convincili a cedere e darti reali requisiti).
5. Ora disponi di requisiti dettagliati che puoi stimare.

È come quando mia madre minacciava quando ero un ragazzino "Sbrigati e scegli alcuni vestiti, o io li li prenderò per te!"

Ho fatto lo sviluppo per un ragazzo che era molto irremovibile nel volere stime accurate. Quello su cui ci siamo stabiliti, che ha funzionato molto bene, è stato questo:

• Ho fatturato per tutto il tempo che ho speso per la stima. È arrivato a circa il 20-25% di quello che ho addebitato.
• Ho fatto un esame estremamente dettagliato dei compiti. Nessun tiro dal fianco. Sono andato nel codice, ho capito quali linee dovevano essere cambiate, quali altre parti del programma avrebbero influenzato, quanti test avremmo dovuto fare per garantire che le cose funzionassero ancora. Stimo ogni pezzo in unità di 1 ora (6 minuti).
• Gli ho inviato la mia stima per ogni attività insieme a quell'analisi dettagliata.

Il 20-25% della fatturazione suona molto.

Ma mi chiedeva di cambiare XYZ, pensando che ci sarebbero voluti circa 2 ore. In 1 ora di stima dettagliata, direi che ci vorranno 8,5 ore. Quindi avrebbe deciso se valesse 8,5 ore di paga. In caso contrario, ha risparmiato 7,5 ore rispetto a quello che gli sarebbe costato se l'avessi fatto senza un preventivo.

E se ha voluto investire le 8,5 ore, il lavoro di dettaglio che ho fatto per il preventivo era un lavoro che avrei dovuto fare comunque.

Ho scoperto che con questo metodo ero in grado di portare la maggior parte dei compiti in tempo o anche prima, senza dover sopravvalutare pesantemente. Perché il tempo è stato suddiviso in modo così minuscolo, potrei dire presto se stavo scivolando. Se avessi colpito i posti di blocco in modo che dopo 3 ore potessi dire che il mio compito di 8,5 ore avrebbe richiesto 12, avrei potuto parlargli prima che passasse più tempo in modo che potesse rivalutare e strattonare la funzione se fosse preoccupato per il costo .

Era nichelino e oscurante? No, l'ho guardato come se gli permettesse di applicare i suoi soldi dove ha visto il massimo beneficio. E sono stato contento di avere esperienza nella stima, che sono sempre stato terribile.

Spesso ci viene chiesto un "preventivo del ballpark" durante le riunioni in cui vengono fornite idee molto ampie e utili su ciò che vorrebbero fare. Dico sempre, "se vuoi una risposta oggi è un anno e un milione di dollari. Se vuoi darmi molti più dettagli e un po 'di tempo per rivederli, posso perfezionare quei numeri per te."

Quasi sempre ottengono il punto.

Dipende da cosa è la stima.

Per una stima iniziale di alto livello per un business case, le cose chiave sono:

1. Velocità. Qualunque sia il metodo che usi, deve essere veloce. Il punto è che gli stakeholder non sono sicuri se valga la pena di fare il progetto, motivo per cui hanno bisogno dei numeri per il business case. Se il business case fosse solido, non avrebbero bisogno delle tue stime. La maggior parte di questi progetti non andrà avanti, quindi è importante che non si spenda troppo per fornire il preventivo.
2. Dai un intervallo. Rendilo ampio. Non hai avuto il tempo di analizzare i requisiti, workshop con le parti interessate, convalidare ipotesi. Una vasta gamma dice al destinatario della stima "I progetti software sono naturalmente complessi e rischiosi - se si desidera una stima adeguata è necessario darmi maggiori dettagli e più tempo". Il problema con il dare un singolo numero o una gamma ristretta è che ti dipinge in un angolo impostando le aspettative prima che venga eseguita qualsiasi analisi reale.

Trovo la tecnica migliore per scegliere un progetto simile che "sente" lo stesso. "Sentire" è completamente soggettivo, ma con questo tipo di stima la mia esperienza mi dice che non troverete misure oggettive. Quindi fornire una vasta gamma. Ho letto alcuni libri che dicono che un intervallo compreso tra -50% e + 100% è buono ma dipende da molti fattori.

Per una stima dettagliata e di basso livello:

1. Hai bisogno di una linea di base. Se la linea di base non è stabile, la stima non ha senso.
2. Il migliore è il bottom up. Ottieni un'analisi dettagliata del lavoro, valuta ogni componente e arrotolalo in un numero più grande. Trovo che la pianificazione del poker sia una grande tecnica qui.
3. Document contingency. Metti in chiaro dove viene aggiunta qualsiasi contingenza (se presente). È aggiunto a ogni elemento pubblicitario? O all'intero preventivo? O a rischi specifici? O c'è nessuno?
4. Indica le tue ipotesi. Convalidare il maggior numero possibile data l'intervallo di tempo.
5. Indicare esplicitamente cosa è incluso ed escluso nella stima. Ad esempio, è inclusa la revisione? Sono inclusi ritardi tecnici?

"Due settimane!"

Scherzi a parte. La mia prima stima è sempre di due settimane. Perché ho una specie di bizzarro blocco mentale che mi fa pensare che tutto somigli a due settimane.

Cerco di aggirare il problema, provo a pensare veramente a quanto tempo penso che ci vorrà qualcosa, cercando di identificare tutti i potenziali punti problematici e bit che sembrano troppo black-box-y per me per essere stimati accuratamente. E prova a riconoscere che se la mia risposta è "Due settimane!", Probabilmente non ci sono riuscito.

Praticamente ogni buon manager che ho avuto ha imparato a riconoscere "Due settimane!" come risposta che richiede un blando schiaffo verbale in risposta.

Alcuni consigli dal lato oscuro di chi ha imparato a fondo.

The requirements are unclear. Nobody has done an in depth analysis of all the implications.

Non fare una stima a questo punto. Non si stima quanti soldati sono necessari per vincere una battaglia senza alcun indizio sui numeri nemici. La stima è fatta dopo lo scouting. Questo è a meno che tu non abbia già combattuto questo nemico.

The new feature will probably break some assumptions you made in your code and you start thinking immediately of all the things you might have to refactor.

Questa è la tua responsabilità di partecipare, a meno che tu non si aspetti che gli altri abbiano esperienza in quest'area.

You have other things to do from past assignments and you will have to come up with an estimate that takes that other work into account.

Come sopra, anche per il lavoro inatteso creato da un compagno di squadra di slob accanto a te con una procedura di test quasi inesistente che causa il glitch del codice che non è possibile prevedere perfettamente in anticipo. È una previsione del tempo.

The 'done' definition is probably unclear: When will it be done? 'Done' as in just finished coding it, or 'done' as in "the users are using it"?

Comprendi il requisito dell'utente finale qui, pensa come un utente. Non fare ciò che fanno i tuoi pari se stimano qualcosa da "fare" solo perché alcune funzionalità di base con un flusso di lavoro barebones che nessun utente può tollerare è ciò che considerano "fatto" . Pensaci dal punto di vista dell'utente, perché è tutto il cliente che stai facendo la stima che in genere comprenderà. Stima verso i requisiti completi dell'utente finale, non verso i requisiti tecnici barebone. E renditi conto che i tuoi clienti che chiedono stime saranno totalmente imprecisi su come esprimono le cose e comprendono gli aspetti tecnici di ciò che dici.

No matter how conscious you are of all these things, sometimes your "programmer's pride" makes you give/accept shorter times than you originally suppose it might take. Specially when you feel the pressure of deadlines and management expectations.

Non farlo! Sembri un duro lavoratore motivato e forse uno che cede facilmente alla coercizione.

Il problema qui è questo: diciamo che tu e Joe avete fatto delle stime di tempo per lo stesso compito (ma tra due dipendenti separati, inconsapevoli di entrambe le stime contemporaneamente). Stimiamo valorosamente "una settimana" . Va bene, pensi, lavorerai oltre 100 ore alla settimana, gli straordinari non retribuiti. Ora hai tre giorni di ritardo.

Nel frattempo, Joe stima 5 mesi. Pensi che sia ridicolo, pensi di poterlo fare in una settimana. Quanto funziona Joe? 10 ore a settimana? ... eccetto che termina in tempo esattamente in 5 mesi.

Indovina chi viene percepito come un idiota? Esatto, tu. Joe sembra un grande lavoratore, ora sembri inaffidabile. Non importa così tanto che potresti aver ottenuto un risultato ancora migliore nel ~ 7% del tempo che Joe ha preso. Ciò che conta è che hai trascorso 3 giorni liberi da una stima di una settimana.

Non commettere errori sul lato della stima più stretta. Err sul lato della stima più flessibile. C'è una reputazione da costruire nella tua azienda e non si baserà sulla durata delle tue stime quasi quanto sulla precisione delle tue stime. È facile essere precisi con una stima troppo lunga, hai solo più tempo per lavorare sul problema e risolverlo meglio. Una stima troppo corta non lascia affatto respiro, o la incontri disperatamente o sei fregato.

C'è un post di blog che descrive come tenere un registro di quanto accurato sia il tuo precedente le stime sono andate, e poi la prossima volta che dici a qualcuno "saranno due settimane", puoi guardare la tua storia precedente e vedere quanto tempo ha impiegato l'ultima volta che hai detto "ci vorranno due settimane".

Non l'ho provato da solo, ma mi piacerebbe, per vedere quanto sono accurate le mie stime.

Dipende dall'organizzazione e da come vengono utilizzate le stime.

Se la stima è solo per fornire un'idea generale su quando sarà pronta, in genere posso fare una stima veloce in base alla mia esperienza. Spesso includo qualsiasi incertezza o possibili variazioni con la stima e il modo in cui i cambiamenti possono influire su altre aree del sistema e sull'entità dei test di regressione richiesti.

Se la stima viene utilizzata per qualsiasi cosa contrattuale o in uno scenario in cui è richiesta una tempistica più precisa, eseguo un'interruzione completa del lavoro. Questo è più lavoro e richiede una riflessione più approfondita sulla progettazione e sulle modifiche al sistema, ma è molto più accurato, soprattutto per lavori di dimensioni maggiori.

In entrambi i casi, la comunicazione continua è la chiave. Se ti imbatti in qualcosa di inaspettato, fallo sapere al momento invece di aspettare fino alla scadenza. Se i requisiti non sono chiari, assicurati di documentare la tua comprensione di essi e le funzionalità che intendi fornire. Questo è anche utile per qualsiasi ipotesi tu faccia. E per quanto riguarda le priorità in competizione, quando un pezzo di lavoro urta un altro, sii chiaro su come questo avrà un impatto sul programma.

Stima di cosa? Piccole attività o soluzioni complete.

Quest'ultimo raramente lo faccio, ma poi indovina un po ', aggiungi un po' il gestore e aggiungilo a un intervallo, con accanto una piccola nota che afferma che quanto sopra è una supposizione.

Piccole attività - Pianificazione del poker Ho trovato che funziona molto bene (non perfetto, alcuni compiti 1pt hanno richiesto molto più a lungo e alcune attività di 5pt hanno richiesto minuti, ma alla fine tutto si uniforma.

Presenta un intervallo basato su ciò che conosci oggi. Utilizza il Cono di incertezza per fornire l'intervallo attorno alle tue ipotesi iniziali.

Ogni settimana calcola quanto rimane da fare, ri-stimare in base a ciò che sai. Una volta ottenuto un numero sufficiente di dimensioni del campione di quanto lavoro passi ogni settimana, fornisci un intervallo di confidenza del 90% per ciò che resta da offrire un intervallo di date (solitamente) sempre restrittivo man mano che il progetto procede e la quantità di lavoro rimasta (si spera ) si restringe.

Con confidenza. Non posso dirti quante volte ho fatto un primo incontro con un cliente non prestando professionalità nel fornire un preventivo. Anche se stai facendo saltare i numeri dal nulla, assicurati di mantenere sempre una stima. Detto questo, fai attenzione a non stimare te stesso in un buco. Cose diverse richiedono quantità diverse di tempo, sforzi e risorse da mettere insieme. Ecco un buon modo per farlo:

Them: How much will it cost?

Me: It depends on what you want me to do. Generally, I start this sort of project at around $X.

A volte la stima diventa una sfida enorme per te e il tuo team, specialmente quando parliamo di stima del progetto software.

Una volta deciso di condividere la nostra esperienza e le nostre conoscenze sul processo di stima del software e definito quattro tipi distinti di stime :

• figura del ballpark
• stima del servizio
• funzione stimata
• stima componenziale

Naturalmente, questi tipi sono distinti. Ballpark è quello che viene spesso definito "guesstimate". Quindi è un numero o un intervallo approssimativo che dà un'idea generale del costo e questo può aiutare una prospettiva a decidere se vorrebbero continuare la discussione.

Di norma, i clienti hanno bisogno di una figura del ballpark all'inizio del progetto. E il nostro consiglio è: la discussione del progetto e la fornitura di figure di ballpark dovrebbero essere solo passi avanti verso la stima componenziale (che è flessibile, si può fare uso di stime di tipo componenziale per l'intero processo di sviluppo. per stimare nuovamente da zero quando si desidera aggiungere, rimuovere o sostituire funzionalità, servizi, ecc.

Tutti dovrebbero tenere a mente i rischi associati alla stima dello sviluppo del software: sottovalutazione, sovrastima, scenario di errore epico totale ecc.

Puoi leggere di più sul nostro blog!

link

Spero che questa informazione ti aiuti!

I always end up giving estimates that I later realize I cannot fulfill. It has happened countless of times, and I always promise it won't happen again.

Sembra che ti venga chiesto un impegno, non una stima. Queste sono cose diverse, ma se riesci a gestire gli impegni in modo affidabile, sarà davvero di aiuto per la tua credibilità e carriera.

Alcuni consigli basati sui miei ~ 10 anni di esperienza:

• Fornisci sempre un intervallo (cioè inferiore e superiore). Questo comunicherà il tuo livello di incertezza
• Se hai un'incertezza molto grande, richiedi un differimento (ad esempio 1 giorno per fare analisi, e quindi fornire un intervallo più stretto)
• Se l'attività è troppo grande, suddividila e fornisci un intervallo per ogni pezzo

Innanzitutto, se mi è stato assegnato un compito, lo suddivido in sottoattività. Vorrei stimare il tempo per ogni sottoattività e probabilmente con le sottoattività sarei in grado di trovare l'area problematica e quindi sarei in grado di prevedere come lungo ci vorrebbe in una certa misura.

Ma ancora tutta la pianificazione aiuterebbe solo in una certa misura. Solo quando inizi a programmare puoi trovare i problemi esatti

Se fai molti progetti per lo stesso capo o cliente, puoi provare a stimare in ampi tratti di complessità invece di settimane o mesi, possibilmente in t-shirt taglie. Identifica alcuni progetti passati e assegna loro le taglie S, M, L, XL.

E poi chiedi a te stesso: quale progetto sembra simile al campo di applicazione? E poi, invece di rispondere con "2 mesi", puoi rispondere con "sembra una L per me" (o qualunque sia la tua calibrazione per il progetto).

Questo è abbastanza facile da capire, ed è anche chiaro che c'è molta incertezza in quelle ipotesi.

Quindi, quando cambiano i requisiti, puoi dire "quel cambiamento fa sembrare più un XL".

Un po 'tardi ma quando ero in campo militare ci è stato chiesto di usare PERT per determinare le stime. Richiede una certa esperienza nel tuo campo e il compito a portata di mano. È stato sorprendentemente accurato nel determinare il tempo di completamento stimato durante la manutenzione e la riparazione di dispositivi elettronici (apparecchiature radio complesse e comunicazioni satellitari), in cui qualsiasi numero di cose può essere errato o trovato e deve essere corretto durante la manutenzione ordinaria. Le stime erano importanti perché altre unità potrebbero essere inutilizzabili fino a quando non hanno ricevuto le loro apparecchiature di comunicazione. Uno che ho usato è questo Calcolatore PERT online gratuito