Come rispondere quando viene richiesto un preventivo?

Come programmatori, ci viene costantemente chiesto 'Quanto ci vorrà'?

E sai, la situazione è quasi sempre così:

• I requisiti non sono chiari. Nessuno ha fatto un'analisi approfondita di tutte le implicazioni.
• La nuova funzionalità probabilmente interromperà alcune ipotesi che hai fatto nel tuo codice e inizierai a pensare immediatamente a tutte le cose che potresti dover riflettere.
• Hai altre cose da fare da incarichi passati e dovrai elaborare una stima che tenga conto di quell'altro lavoro.
• La definizione "fatto" probabilmente non è chiara: quando sarà fatto? 'Fatto' come appena finito di codificarlo, o 'fatto' come in "gli utenti lo stanno usando"?
• Non importa quanto tu sia consapevole di tutte queste cose, a volte il tuo "orgoglio del programmatore" ti fa dare / accettare tempi più brevi di quanto pensi inizialmente. Soprattutto quando si sente la pressione delle scadenze e delle aspettative della direzione.

Molti di questi sono problemi organizzativi o culturali che non sono semplici e facili da risolvere, ma alla fine la realtà è che ti viene chiesto un preventivo e si aspettano che tu dia una risposta ragionevole. Fa parte del tuo lavoro. Non puoi semplicemente dire: non lo so.

Di conseguenza, finisco sempre per fornire stime che in seguito mi rendo conto di non poter soddisfare. È successo innumerevoli volte e prometto sempre che non accadrà più. Ma lo fa.

Qual è il tuo processo personale per decidere e consegnare un preventivo? Quali tecniche hai trovato utili?

Da The Pragmatic Programmer: Da Journeyman a Master :

Cosa dire quando viene chiesto un preventivo

Dici "Torno da te."

Quasi sempre si ottengono risultati migliori se si rallenta il processo e si trascorre del tempo attraverso i passaggi descritti in questa sezione. Le stime fornite alla macchina del caffè torneranno (come il caffè) a perseguitarti.

Nella sezione, gli autori raccomandano il seguente processo:

• Determina la precisione di cui hai bisogno. In base alla durata, è possibile citare il preventivo con precisione diversa. Dire "da 5 a 6 mesi" è diverso dal dire "150 giorni". Se scivoli un po 'nel settimo mese, sei ancora abbastanza preciso. Ma se scivoli nel 180 ° o nel 210 ° giorno, non tanto.
• Assicurati di capire cosa ti viene chiesto. Determinare 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. Assegnare valori e intervalli di errore (+/-) a ciascun valore.
• Calcola il preventivo in base al tuo modello.
• Tieni traccia delle tue stime. Registra informazioni sul problema che stai stimando, sulla tua stima e sui valori effettivi.
• Altre cose da includere nel preventivo sono lo sviluppo e la documentazione dei requisiti o le modifiche alle specifiche dei requisiti, la creazione o l'aggiornamento di documenti e specifiche di progettazione, i test (unità, integrazione e accettazione), la creazione o l'aggiornamento dei manuali dell'utente o le LETTURE con le modifiche. Se 2 o più persone lavorano insieme, c'è un sovraccarico di comunicazione (telefonate, e-mail, riunioni) e la fusione del codice sorgente. Se si tratta di un'attività lunga, tenere conto di cose come altri lavori, tempo libero (ferie, ferie, malattia), riunioni e altre attività generali quando si sceglie una data di consegna.

La stima del software è il singolo compito più difficile nell'ingegneria del software: un secondo è la richiesta di requisiti.

Ci sono molte tattiche per crearle, tutte basate prima di ottenere 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 ipotesi per colmare le lacune in base alla tua migliore ipotesi su ciò che vogliono
3. Scrivi tutte le tue assunzioni
4. Falli sedere, leggi e accetta le tue assunzioni (o, se sei fortunato, fai in modo che si arrendano e ti diano requisiti reali).
5. Ora hai requisiti dettagliati dai quali puoi stimare.

È come quando mia madre minacciava mia madre da piccola "Sbrigati a scegliere dei vestiti, o li sceglierò io per te!"

Ho fatto lo sviluppo per un ragazzo che era molto irremovibile nel desiderare stime accurate. Ciò su cui ci siamo accordati, che ha funzionato molto bene, è stato questo:

• Ho fatturato per tutto il tempo trascorso a stimare. È arrivato a circa il 20-25% di quello che ho fatturato.
• Ho fatto un esame estremamente dettagliato dei compiti. Nessun tiro dall'anca. Ho inserito il codice, ho capito quali linee dovevano essere modificate, quali altre parti del programma avrebbero influenzato, quanti test avrei dovuto fare per assicurarmi che le cose funzionassero ancora. Stimerei ogni pezzo in unità di 0,1 ore (6 minuti).
• Gli ho inviato il mio preventivo per ogni attività insieme a quella suddivisione dettagliata.

Il 20-25% della fatturazione sembra molto.

Ma mi chiedeva di fare il cambiamento XYZ, pensando che ci sarebbero volute circa 2 ore. In 1 ora di stima dettagliata, determinerei che occorrerebbero 8,5 ore. Quindi avrebbe deciso se valesse 8,5 ore di paga. In caso contrario, ha risparmiato 7,5 ore rispetto a quanto gli sarebbe costato se l'avessi fatto senza una stima.

E se lui ha voglia di investire i 8,5 ore, il lavoro di dettaglio che ho fatto per la stima era un lavoro che avrei dovuto fare comunque.

Ho scoperto che con questo metodo sono stato in grado di portare la maggior parte dei compiti in tempo o addirittura in anticipo, senza dover sopravvalutare pesantemente. Poiché il tempo è stato suddiviso in modo così minuzioso, potrei dire presto se stavo scivolando. Se avessi raggiunto i blocchi stradali 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 altro tempo in modo che potesse rivalutare e strappare la funzionalità se era preoccupato per il costo .

Stava nichelando? No, l'ho guardato mentre gli permetteva di applicare i suoi soldi dove vedeva il massimo beneficio. E sono stato felice di fare esperienza nella stima, a cui ero sempre stato terribile.

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

Quasi sempre ottengono il punto.

Dipende da cosa serve la stima.

Per una stima iniziale di alto livello per un caso aziendale, le cose chiave sono:

1. Velocità. Qualunque metodo tu usi, deve essere veloce. Il punto è che le parti interessate non sono sicure se valga la pena fare il progetto, motivo per cui hanno bisogno dei numeri per il caso aziendale. Se il caso aziendale fosse solido, non avrebbero bisogno delle tue stime. La maggior parte di questi progetti non andrà avanti, quindi è importante che non venga speso troppo sforzo per fornire la stima.
2. Dai un intervallo. Rendilo ampio. Non hai avuto tempo di analizzare i requisiti, organizzare seminari con le parti interessate, convalidare i presupposti. Un'ampia gamma dice al destinatario del preventivo "I progetti software sono naturalmente complessi e rischiosi - se vuoi un preventivo adeguato devi darmi maggiori dettagli e più tempo". Il problema nel dare un singolo numero o un intervallo ristretto è che ti dipinge in un angolo impostando le aspettative prima che venga fatta qualsiasi analisi reale.

Trovo la tecnica migliore per scegliere un progetto comparabile che "senta" lo stesso. "Feel" è completamente soggettivo, ma con questo tipo di stima la mia esperienza mi dice che non troverai misurazioni 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 di basso livello:

1. Hai bisogno di una base. Se la previsione non è stabile, la stima non ha senso.
2. Bottom up è il migliore. Ottieni un'analisi dettagliata del lavoro, stima ogni componente e arrotolalo in un numero maggiore. Trovo che pianificare il poker sia un'ottima tecnica qui.
3. Document contingency. Spiegare dove viene aggiunta l'eventuale contingenza. Viene aggiunto a ciascun elemento pubblicitario? O per l'intero preventivo? O a rischi specifici? O non c'è nessuno?
4. Esprimi i tuoi presupposti. Convalida il maggior numero possibile in base al periodo di tempo.
5. Indicare esplicitamente cosa è incluso ed escluso nel preventivo. Ad esempio, è inclusa la recensione? I ritardi tecnici sono inclusi?

Qualche consiglio dal lato oscuro di chi ha imparato a fatica.

I requisiti non sono chiari. Nessuno ha fatto un'analisi approfondita di tutte le implicazioni.

Non fare una stima a questo punto. Non si stima il numero di soldati necessari per vincere una battaglia senza indizi sui numeri dei nemici. La stima viene effettuata dopo lo scouting. Questo a meno che tu non abbia già combattuto questo nemico.

La nuova funzionalità probabilmente interromperà alcune ipotesi che hai fatto nel tuo codice e inizierai a pensare immediatamente a tutte le cose che potresti dover riflettere.

Questa è la tua responsabilità da tenere in considerazione a meno che tu non preveda che gli altri abbiano le competenze su quest'area.

Hai altre cose da fare da incarichi passati e dovrai elaborare una stima che tenga conto di quell'altro lavoro.

Come sopra, anche per un lavoro imprevisto creato da un compagno di squadra sciatto accanto a te con una procedura di test quasi inesistente che fa sì che il tuo codice si accorga che non puoi predire perfettamente in anticipo. Sono previsioni del tempo.

La definizione "fatto" probabilmente non è chiara: quando sarà fatto? 'Fatto' come appena finito di codificarlo, o 'fatto' come in "gli utenti lo stanno usando"?

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

Non importa quanto tu sia consapevole di tutte queste cose, a volte il tuo "orgoglio del programmatore" ti fa dare / accettare tempi più brevi di quanto pensi inizialmente. Soprattutto quando si sente la pressione delle scadenze e delle aspettative della direzione.

Non farlo! Sembri un lavoratore motivato e forse uno che si arrende facilmente alla coercizione.

Il problema qui è questo: diciamo che tu e Joe avete fatto stime temporali per la stessa attività (ma tra due impiegati separati, ignari di entrambe le stime contemporaneamente). Stimate valorosamente "una settimana" . Va bene, pensi, lavorerai più di 100 ore alla settimana, lavoro straordinario non retribuito. Adesso sei in ritardo di tre giorni.

Nel frattempo, Joe stima 5 mesi. Pensi che sia ridicolo, pensi di poterlo fare in una settimana. Quanto lavora Joe? 10 ore settimanali? ... tranne che termina puntualmente tra 5 mesi esatti.

Indovina chi viene percepito come il cretino? Esatto, tu. Joe sembra un grande lavoratore, sembri inaffidabile ora. Non importa così tanto che potresti aver ottenuto un risultato ancora migliore nel ~ 7% delle volte che Joe ha impiegato. Ciò che conta è che ti mancassero 3 giorni da una stima di una settimana.

Non sbagliare mai dal lato della stima più rigorosa. Err sul lato della stima più libera. C'è una reputazione da costruire nella tua azienda e non si baserà sulla lunghezza delle tue stime quasi quanto sull'accuratezza 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 breve non lascia affatto spazio alla respirazione, o la incontri disperatamente o sei fregato.

"Due settimane!"

Sul serio. La mia prima stima è sempre di due settimane. Perché ho una sorta di bizzarro blocco mentale che mi fa pensare che tutto sembri due settimane.

Provo a aggirarlo, provo a pensare davvero a quanto tempo ci vorrà qualcosa, cercando di identificare tutti i potenziali punti problematici e bit che sembrano troppo neri per poter essere accuratamente stimati. E prova a riconoscere che se la mia risposta è "Due settimane!", Probabilmente non ci sono riuscito.

Praticamente ogni bravo manager che ho avuto ha imparato a riconoscere "Due settimane!" come risposta che richiede un lieve pimp-slap verbale in risposta.

C'è un post sul blog che delinea come tenere traccia dell'accuratezza delle tue stime precedenti e poi la prossima volta che dici a qualcuno "saranno due settimane", puoi guardare la tua storia precedente e vedere per quanto tempo in realtà ha preso l'ultima volta che hai detto "saranno due settimane".

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

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

Se il preventivo è solo per fornire un'idea generale su quando sarà pronto, in genere posso fare un preventivo rapido basato sulla mia esperienza. Spesso includerò eventuali incertezze o possibili variazioni con la stima, insieme a come le modifiche possono influire su altre aree del sistema e sull'entità dei test di regressione richiesti.

Se il preventivo viene utilizzato per qualsiasi cosa contrattuale o in uno scenario in cui sono richiesti tempi più precisi, eseguo un'analisi completa del lavoro. Questo è più lavoro e richiede una riflessione più approfondita sulla progettazione e le modifiche al sistema, ma è molto più accurato, specialmente per lavori di grandi dimensioni.

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 prevedi di fornire. Questo è utile anche con qualsiasi ipotesi che fai. E per quanto riguarda le priorità in competizione, quando un pezzo di lavoro ne sbatte un altro, sii chiaro su come questo avrà un impatto sul programma.

Preventivi per cosa? Piccoli compiti o soluzioni complete.

Quest'ultimo lo faccio raramente, ma poi indovino, aggiungo un po ', chiedo al manager di aggiungere un po' e trasformarlo in un intervallo, con una piccola nota accanto che afferma che quanto sopra è un'ipotesi.

Piccoli compiti - Pianificazione del poker Ho scoperto di funzionare davvero bene (non perfetto, alcuni compiti da 1pt hanno richiesto molto più tempo e alcuni compiti da 5pt hanno richiesto minuti, ma alla fine tutto è andato a segno).

Presenta una gamma basata su ciò che conosci oggi. Utilizzare il cono di incertezza per fornire l'intervallo attorno alle stime iniziali.

Ogni settimana calcola quanto resta da fare, rivaluta in base a ciò che sai. Una volta che hai una dimensione del campione sufficiente di quanto lavoro stai svolgendo ogni settimana, fornisci un intervallo di confidenza del 90% per ciò che resta per dare un intervallo di date (di solito) sempre più restrittivo man mano che il progetto avanza e la quantità di lavoro rimanente (si spera ) si restringe.

Con fiducia. Non posso dirvi quante volte ho fallito un incontro iniziale con un cliente non mettendo su professionalità nel dare un preventivo. Anche se stai soffiando numeri dal nulla - assicurati di tenere sempre qualche stima in giro. Detto questo, fai attenzione a non stimarti in un buco. Cose diverse richiedono quantità diverse di tempo, sforzi e risorse da mettere insieme. Ecco un buon modo per farlo:

Loro: quanto costerà?

Io: dipende da cosa vuoi che faccia. In genere, inizio questo tipo di progetto a circa $ X.

A volte la stima diventa un'enorme sfida per te e il tuo team, specialmente quando parliamo di stima di progetti software.

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

• cifra approssimativamente
• preventivo di servizio
• stima delle funzionalità
• stima componenziale

Naturalmente, questi tipi sono distinti. Ballpark è quello che viene spesso chiamato un "indovinello". Quindi è un numero o un intervallo approssimativo che dà un'idea generale del costo e che può aiutare un potenziale cliente a decidere se desidera approfondire la discussione.

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

Tutti dovrebbero tenere a mente i rischi che derivano dalla stima dello sviluppo del software: sottostima, sopravvalutazione, scenario di fallimento epico totale ecc.

Puoi leggere di più sul nostro blog!

http://blog.lemberg.co.uk/project-management/software-estimation-process/

Spero che queste informazioni ti possano aiutare!

Finisco sempre per fornire stime che in seguito mi rendo conto di non poter soddisfare. È successo innumerevoli volte e prometto sempre che non accadrà più.

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

Alcuni consigli basati sulla mia ~ 10 anni di esperienza:

• Fornire sempre un intervallo (ovvero limite inferiore e superiore). Questo comunicherà il tuo livello di incertezza
• In caso di incertezza molto grande, chiedere un differimento (ad es. 1 giorno per eseguire l'analisi, quindi fornire un intervallo più stretto)
• Se l'attività è troppo grande, suddividila e fornisci un intervallo per ogni pezzo

Innanzitutto, se un compito fosse assegnato a me, lo suddividerei in sottoattività. Stimerei il tempo per ogni attività secondaria e probabilmente con attività secondarie sarei in grado di trovare l'area problematica e quindi sarei in grado di prevedere per quanto tempo prendere in una certa misura.

Ma tutta la pianificazione avrebbe aiutato solo in una certa misura. Solo quando inizi a scrivere codice puoi trovare i problemi esatti

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

E poi chiediti: a quale progetto sembra simile nell'ambito? E poi invece di rispondere con "2 mesi", puoi rispondere con "mi sembra una L" (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 i requisiti cambiano, puoi dire "che il cambiamento lo fa sembrare più un XL".

Un po 'tardi, ma quando ero nell'esercito, fummo incaricati di usare il PERT per determinare le stime. Richiede una certa esperienza nel tuo campo e il compito da svolgere. È stato sorprendentemente preciso nel determinare il tempo stimato di completamento durante la manutenzione e la riparazione di dispositivi elettronici (radio complesse e apparecchiature di comunicazione via satellite), in cui un numero qualsiasi di cose può essere errato o trovato e deve essere riparato durante la manutenzione ordinaria. Le stime erano importanti perché altre unità potrebbero essere inoperabili fino a quando non avessero ricevuto le loro apparecchiature di comunicazione. Uno che ho usato è questo calcolatore PERT online gratuito