Fornire stime e aspettative del cliente?

2

Quando un cliente chiede una stima su quanto tempo impiegare per sviluppare diverse sezioni di un'app, è meglio dare loro un importo totale o quello che servirebbe per ogni sezione?

È meglio / più comune fornire un intervallo di ore / giorni o un solo numero?

Pensi che la maggior parte dei clienti pensi che se un programmatore dice che dovrebbero impiegare 50 ore per essere fatturati per 50 ore?

Se dico che ci vorrebbero 50 e in realtà ne occorrono 60, devo dire loro in anticipo che sto andando oltre la mia stima o semplicemente addebito ciò che è stato originariamente citato?

    
posta FishOrDie 11.02.2011 - 06:26
fonte

3 risposte

2

Questa dovrebbe essere una discussione tra te e il cliente.

When a client asks for an estimate on how long it would take to develop different sections of an app, is it best to give them a total amount or what it would take for each section?

Idealmente, vuoi abbattere il progetto nelle attività e sottoattività e dare una stima per ogni attività. Includere tempi supplementari per affrontare disavventure impreviste e simili.

Do you think most clients feel that if a programmer says it should take 50 hours that they should be billed for 50 hours?

If I say it would take 50 and it actually takes 60, do I tell them in advance that I'm going over on my estimate or just charge what was originally quoted?

Questo è ciò che vuoi discutere con il cliente in quanto è un accordo o una comprensione tra entrambe le parti. Per esempio. se hai detto qualcosa come "Ho intenzione di finire questo progetto in 50 ore, periodo", allora dovresti caricare solo per 50 ore, punto.

Vuoi evitare di offuscare la tua reputazione in ogni caso, quindi sembra che comunicare di più con il tuo cliente non vada male.

    
risposta data 11.02.2011 - 06:49
fonte
1

When a client asks for an estimate ... is it best to give them a total amount or what it would take for each section?

Pezzi. Fornisci sempre i dettagli a pezzi. Dai sempre la priorità ai pezzi e costruisci sempre il pezzo più importante e prezioso.

Is it better/more common to give a range of hours/days or just a single number?

Meglio e più comune non hanno nulla a che fare l'uno con l'altro.

Le persone non conservano molti dettagli, quindi puoi dare tutti i tipi di fasce e probabilità di fantasia e ricordano solo un numero. Il numero che ricordano è essenzialmente casuale, quindi non importa molto quello che dici, lo interpreteranno male.

Poiché varia, devi sapere cosa ricorderanno. Devi conoscerli e come affrontare l'incertezza.

Stai prevedendo il futuro. Non puoi sapere quanto tempo ci vorrà.

Do you think most clients feel that if a programmer says it should take 50 hours that they should be billed for 50 hours?

Questo varia. Chiedi loro.

If I say it would take 50 and it actually takes 60, do I tell them in advance that I'm going over on my estimate or just charge what was originally quoted?

Se lo sviluppo non è un "dialogo", lo stai facendo male. Dato che stai costruendo pezzi, ogni pezzo è un altro scambio in quella finestra di dialogo.

    
risposta data 11.02.2011 - 12:59
fonte
0

In primo luogo, per quanto piccola sia la quantità di lavoro, ti suggerirei di spazzolare te stesso su alcune tecniche di stima del software. Con questo, non ti sbaglierai con le tue stime (la maggior parte delle volte) e il cliente sarà anche sollevato di sapere che stai usando una tecnica standard piuttosto che un calcolo approssimativo. Successivamente, non penso ci siano progetti che non affrontano un aumento di sforzo. Conservare un po 'di buffer Potrebbe essere compreso tra il 5-10% in base alla complessità.

Fare il punto ogni settimana / paio di settimane e informare definitivamente il cliente se prevedi problemi nel rispettare la scadenza. Se è causa di un aumento della portata, è possibile addebitare al cliente, ma se a causa di alcune difficoltà tecniche, dovrai gestirlo da solo.

Puoi dare le stime finali o se il cliente lo richiede, scomporlo in moduli. Non andare su tutti gli oggetti di lavoro ma fare un raggruppamento e dare le stime.

E non scendere a compromessi su design e test. Ciò garantirà un'esecuzione regolare del progetto.

    
risposta data 11.02.2011 - 08:56
fonte

Leggi altre domande sui tag