Quanto è dettagliata la stima che mostri ai tuoi clienti?

Non vuoi essere troppo dettagliato o troppo vago - entrambi ti daranno problemi.

Troppo vago e non avrai una chiara idea di cosa sia coinvolto te stesso e ciò causerà problemi quando qualcosa di inaspettato si presenterà.

Troppo dettagliato e si corre il rischio reale di sovraccarico di informazioni. Potresti anche chiedere a qualcuno di mettere in discussione ogni singola cosa che fai.

Ciò che è "giusto" dipenderà dal cliente, ma è necessario disporre di dettagli sufficienti tali da essere sicuri che tu sappia cosa stai facendo e non stia cercando di cancellarli. Dividere il lavoro in fasi è un buon modo per raggiungere questo obiettivo. Ogni fase dovrebbe essere un insieme autonomo di lavoro che può essere consegnato. (Puoi dividere la fase in blocchi più piccoli per i tuoi processi di sviluppo).

Questo dà anche al cliente la possibilità di rivedere i progressi e ri-stabilire la priorità del resto del lavoro, se necessario.

Nel tuo scenario, penso che la strada da percorrere sia quella di fornire un preventivo per Use Case o Feature. Se il cliente si lamenta della stima del caso d'uso concreto, è possibile spiegare ulteriormente quale parte di Use Case è la più difficile e consumerà più tempo / denaro. Il cliente può decidere di modificare il caso Use little bit per ridurre la complessità ma ottenere il massimo dalle funzionalità.

Questo funziona per progetti che sono già in esecuzione - alcune versioni sono state fatte e tu conosci il prodotto. Se inizi un nuovo progetto hai molte incertezze e per questo devi farlo in blocchi più grandi - set di funzionalità / casi d'uso, punti cardine, ecc.

L'unità minima del tempo stimato dovrebbe essere basata sulla dimensione del progetto. Se stai creando alcune applicazioni web rapide che vengono eseguite in poche settimane, puoi probabilmente utilizzare le stime in ore, ma per le app più grandi con molte funzionalità dovresti utilizzare le stime in giorni uomo, uomo settimane o uomo mesi. L'arte deve essere accurata abbastanza. Essere troppo precisi nelle stime iniziali ti porterà solo problemi quando non li adempi.

Raccomando di leggere Stima del software: Demistificare l'arte nera (di Steve McConnell) .

Un altro modo è l'approccio agile in cui si costruisce il software in modo incrementale aggiungendo prima le funzioni più importanti e ricevendo il feedback il più velocemente possibile. Le stime in agile vengono generalmente eseguite in modo più astratto.

Per leggere le stime agili, ti consiglio Agile Estimating and Planning (di Mike Cohn) .

Hai bisogno di una stima abbastanza buona per avere fiducia in essa e deve corrispondere al rischio dell'investimento. Sì, è vago. Quello che voglio dire è che non vorrei specificare il mio viaggio al negozio per un po 'di latte. Voglio una catalogazione per i $ 10.000 necessari per sistemare il mio portico!

In primo luogo, avere un'organizzazione che consenta al lettore di approfondire. Fornisci 5 o meno aree di immagine grandi e quindi dai gruppi di dettagli. Nessuno può leggere nulla se è inondato da 7 o più pezzi di informazioni apparentemente uguali.

Inoltre, pianifica di dividere il costo della manodopera e il costo delle parti (software acquistato, hardware acquistato). E le parti dovrebbero includere un elenco di dette parti. Il cliente potrebbe essere in grado di ridurre il conto, fornendo cose come le licenze del sito che ridurrebbero drasticamente i costi, quindi è un utile punto di contrattazione.

Per rispondere a domande specifiche:

• scomposizione in piccole attività che possono essere eseguite in poche ore e fornire loro l'elenco completo?

Le ore sarebbero troppo piccole, IMO. Minimo giorni / settimane. Se hai davvero un lavoro che dura solo 8-20 ore, questo è il modo di andare al negozio e ottenere il latte. Costa quanto costa.

• dargli un grande numero e lavorare in tal senso? E se così viene da una stima più dettagliata che non è necessario mostrarli?

Dai un senso a ciò che costano le caratteristiche. Un cliente può decidere di cambiare ambito quando vede il prezzo e non può scegliere meno materiale con meno soldi se non ha una ripartenza con cui lavorare. Considero questa divisione più importante dei compiti, perché è uno strumento di discussione. Il cliente vuole un sacco di funzionalità, vuoi soldi. Se non hanno tutti i soldi di cui hai bisogno, allora un po 'di soldi è meglio di niente, ma non puoi definire quanto meno da fare senza un po' di suddivisione di quanto costano le varie funzionalità.

Sono stato in situazioni in cui era necessario un po 'di base per fare qualsiasi cosa, o almeno per fare una serie massiva di sottofunzionalità. In questo caso, ho definito il lavoro per la linea di base, e poi menzionato in ogni funzione di scrittura - "richiede anche la baseline", per mostrare il lavoro di costruzione della base, oltre a ciascuna caratteristica unica.

• Lo suddividete in grandi "fasi" e date loro un numero di ore per ogni fase?

L'ho visto fare in questo modo, ma personalmente, non lo trovo utile. Se stai lavorando a un progetto di tipo a cascata, potresti aver bisogno di questa suddivisione internamente, quindi sai che hai pianificato il lavoro in modo appropriato. Ma la mia preferenza è sempre quella di guardare le caratteristiche. Posso raggruppare le caratteristiche in fasi per dare un senso del programma al miglior scatto in termini di efficienza, ma preferisco non legarmi a ore per fase se posso aiutarlo.

NOTA: come hai detto, questa non è un'offerta contrattuale, che spesso ha una formalità definita dal cliente. Questo è il mio scatto al perfetto formato di programmazione se riesco a sedermi con il cliente e in realtà a discutere su cosa vogliono pagare. In questo spirito, le descrizioni di buone caratteristiche sono tanto importanti quanto i numeri, dal momento che si desidera rendere molto chiaro ciò che stanno ottenendo.

Di solito lo suddivido in due sezioni:

• Panoramica
• dettagliata

In genere mi assicuro che la panoramica sia una sorta di sommario esecutivo (breve e comprensibile da tutti). La sezione dettagliata suddividerà quindi le attività atomiche con le stime.

Anche se non conosco una tonnellata di veicoli, non vorrei solo Fixed Car: $900 nella mia ripartizione dei costi;)

Regola 1: Le stime sono un gioco .

Conseguenza: Non fornire una stima fino a quando non sai per cosa viene utilizzato .

C'è un piccolo significato reale in una stima. Eppure, tutti pensano che siano molto importanti. Cambiano ogni giorno, eppure, in qualche modo, c'è una magia gestionale nell'avere un numero o un programma basato su assurdità.

Una stima potrebbe essere utilizzata per prendere una decisione di andare / non andare. Un singolo grande numero è probabilmente più utile.

Potrebbe essere utilizzata una stima per tenere traccia dei progressi in corso. Probabilmente è più utile una sequenza di versioni con budget per ogni versione.

Potrebbe essere utilizzata una stima per costringerti a chiedere una tariffa fatturabile più bassa. Non importa quale stima fornisci, ti ritroverai comunque a discutere della tua tariffa fatturabile.

Una stima potrebbe essere utilizzata per mettere in imbarazzo un manager in futuro. Non importa ciò che fornisci qui, il progetto si romperà in pochi mesi e le persone verranno spostate, e rimarrai incerto su cosa è successo.

Devi sapere quale scopo serve la stima.

La cosa divertente è che una stima di offerta bassa potrebbe far avviare un progetto. Una volta che stai rotolando, puoi aumentare il preventivo e a nessuno importa.

A volte, la stima deve essere molto alta per far sembrare il progetto grande e importante. Una volta che rotoli, scopri che i primi rilasci risolvono il problema aziendale e il resto del progetto viene annullato perché le versioni successive sono una cattiva idea.

break it down into small tasks that can be done in a few hours and give them the full list?

Di solito una cattiva idea. Dipende da ciò di cui il cliente ha bisogno.

La tua ipotesi originale nei piccoli compiti deve contenere errori, omissioni e stime errate. Non puoi prevedere il futuro.

Tenere traccia di tutti i tuoi errori disturberà la maggior parte dei clienti, quindi è raramente utile rivelare questo livello di dettaglio.

give them one big number and work towards that?

Di solito una cattiva idea. Dipende da ciò di cui il cliente ha bisogno. A volte hanno solo bisogno di un gran numero di giustificare il budget rispetto al costo del problema che stai per risolvere.

Cambiando questa stima, la tua mossa nel progetto disturberà alcuni clienti. Alcuni sono a loro agio con il cambiamento.

Alcuni, tuttavia, saranno disturbati dalle discrepanze tra la stima originale e le eventuali revisioni. Alcuni possono seppellirti con documenti di controllo del cambiamento per tenere traccia delle modifiche nel grande numero.

And if so does that come from a more detailed estimate that you don't need to show them?

Non è una cattiva idea. Non aiuta in generale, ma non è una cattiva idea.

Ricorda. È un gioco. Non puoi predire il futuro. Lavorare dai dettagli è l'unico modo per "giustificare" il numero casuale alla fine del processo.

Do you break it up into big "phases" and give them a number of hours for each phase?

Questo è il meglio che puoi fare.

Non puoi vincere questo gioco. Non puoi andare in pareggio. Non puoi nemmeno uscire.

Le tue stime hanno errori e alcuni clienti saranno sconvolti quando correggi tali errori e rivedi la stima.

Le "fasi" dovrebbero essere in ordine di importanza. Dovrebbero corrispondere alle storie degli utenti. Dovrebbero essere rilasciabili (in linea di principio) come funzionalità incrementali di funzionalità.

La cosa più importante è scoprire quale sarà la stima utilizzata e fornire qualcosa che si adatti al caso d'uso.

A mio modesto parere -

[a] Una dettagliata disaggregazione sta solo chiedendo al ragazzo di fare acquisti altrove e cercare di contrattare su ogni punto. Se ottieni 100.000 per la costruzione di una casa, ne vuoi veramente 50.000 per la fondazione?

[b] Può ottenere una stima del prezzo per ogni passaggio che termina con un deliverable. Se non ci sono risultati, allora non sono affari suoi se si dice che è fatto o quando si dice che è fatto. I risultati sono realtà; tutto il resto è l'aria calda.

[c] Fai attenzione alla differenza tra un prezzo e un programma. Ad esempio, fatturare per un mese di lavoro ma consentire una pianificazione di due mesi. Potresti essere sottopagato in alcune parti e strapagare gli altri, ma puoi comunque mantenere il programma che rende felici tutti, compresi te.

Di solito fornisco un preventivo per ogni articolo che il cliente potrebbe ordinare o meno; per esempio, se vuole tre cambiamenti nel programma, la mia offerta dice "cambia A costa xxx, cambia B costa xxx, cambia C costa xxx". In questo modo, potrebbe decidere che B non vale i soldi e solo ordinare A e C. Andando più in dettaglio, come "analisi xxx ore, progettazione ore xxx, ore di implementazione xxx, ore di test xxx, ore di documentazione xxx" per ogni parte del programma porta solo a discussioni improduttive e, francamente, non penso che il cliente abbia bisogno di quel livello di dettaglio per prendere decisioni commerciali.