Come rispondere "Quando sarà fatto?"

Rispondi sinceramente alla domanda.

Dite loro che è un problema difficile, la soluzione non è ovvia e non siete sicuri di quanto tempo ci vorrà per risolvere. Prometti di aggiornarli sui tuoi progressi ogni [intervallo di tempo], in modo che sappiano che ci stai lavorando e, naturalmente, di inviarli effettivamente gli aggiornamenti.

Gli sviluppatori affrontano un problema complesso scomponendolo in più piccoli e risolvendoli separatamente.

In un mondo ideale , risolvere un problema sarebbe un problema complesso A e potresti, in un dato momento, scomporlo in un breve elenco di piccoli problemi A ₁ a A _n , per ogni valutazione il tempo è semplice, dato che il tempo richiesto per risolvere il problema complesso iniziale sarebbe:

con D è il processo di decomposizione stesso.

Nel mondo reale , l'unico problema è che t ( D ) sarebbe in realtà più grande del tempo impiegato per risolvere i piccoli problemi . In altre parole, per arrivare a questo livello di scomposizione del problema, devi praticamente risolvere il problema stesso.

Puoi ancora:

• Separa l'attività data (risolvendo il problema) in blocchi più piccoli, ogni blocco è ancora un problema complesso,

• Valuta il tempo previsto per ogni blocco e il rischio corrispondente.

  Ad esempio, l'attività 1 richiede ca. 5 ore, ma il rischio di rimanere bloccati è alto, quindi concedici 12 ore come aspettativa al cliente.

• Valuta le dipendenze e in che modo influenzano il tempo.

  Ad esempio, l'attività 19 richiede 2 ore e il rischio è talmente basso che puoi dire che sono 2 ore di sicuro. Non 1. Non 3. Ma l'attività 19 si basa sull'attività 24: l'attività 24 può influire sull'attività 19 in modo da richiedere la riscrittura completa del codice dell'attività 19 utilizzando un approccio diverso.

• Fornisci tutti questi dettagli al tuo cliente. Non fornire la somma.

L'ultimo punto è importante. Se fornisci la somma, diciamo 192 ore, il cliente crede che sia una metrica molto precisa e il tempo che trascorrerai proviene, diciamo, da 189 a 195 ore.

Se, invece, dai i dettagli,

• Il cliente che si preoccuperà capirà che non è 192 ore. È 192 ore se tutto va storto, dato il rischio determinato durante la valutazione. Sono anche 238 ore se tutto va ancora peggio. Anche 85 ore se tutto è ok.

• Per quanto riguarda il cliente a cui non importa, non leggerà la tua risposta in tutti i casi. Tutto quello che vuole è un numero, per poterti incolpare più tardi. Dando una risposta molto dettagliata non leggerà mai, sai che non può chiederti il tempo che ci vorrà ancora: hai già risposto. Inoltre, non può biasimarti più tardi, dal momento che non ha letto la risposta per calcolare la somma.

Qualunque cosa tu stimi non dimenticare di includere legge di Hofstadter : richiede sempre più tempo di quanto ti aspetti, anche quando si tiene conto della legge di Hofstadter.

In genere utilizzo una formula modificata da CPM / PERT. È qualcosa del genere:

Mn + Mx + C(T) / 2 + C, where
Mn is the minimum number of hours you think it will take,
Mx is the maximum number of hours you think it will take,
T is the typical number of hours it takes,
and C is a confidence factor from 1 - 3 based on how much you've done similar things.

(Non sono sicuro di come eseguire tutte le formattazioni matematiche elaborate, se qualcuno vuole modificarlo per questo, sentiti libero.)

So, if you think:
Mn = 60  hours
Mx = 180 hours
T  = 100 hours
C  = 2
Then: 60 + 180 + 2(100) / 4 = 110 hours.

Sottolineo che potrebbe variare in modo significativo, a seconda di come va il progetto. Se rivalorizzi il tuo progetto ogni pochi giorni, potresti persino fornire un aggiornamento settimanale. Fa molto per soddisfare i clienti irritabili. :)

Spiegare scadenze vaghe a utenti non tecnici è difficile. Questo è vero sia nelle fasi creative di un progetto, sia quando si rintraccia un insetto fastidioso. In entrambi i casi il tradizionale "scomporre il lavoro in piccoli pezzi" non funziona altrettanto bene.

L'attività originale si concentra su quest'ultimo caso, quindi soffermiamoci su questo. Se non puoi dare una cronologia, dì all'utente cosa proverai e quando tornerai da loro. Quando raggiungi il punto intermedio sulla timeline auto-imposta, fornisci un breve e onesto aggiornamento via email. Almeno un'ora prima della scadenza dare la tua risposta formale. Ora hai credibilità. Se il problema non è risolto, almeno stai facendo luce. Può sembrare una perdita di tempo, ma non lo è.

Dal momento che non è possibile spiegare i blocchi stradali sconosciuti e le sorprese inaspettate, può essere difficile stimare con sicurezza. Idee:

• Prova un intervallo - "Sono sicuro ci vorranno almeno N giorni (ad es. 3), ma potrebbe prendere il numero 4N."
• Cerca il supporto di ingegneri più esperti nella stima e amp; difendere le stime.
• Lavorare in iterazioni più brevi (stile Agile / Scrum) per produrre un codice minimo che aggiunge valore al business (guadagnando fiducia e fiducia), quindi ripeti.
• Impara le capacità di negoziazione da un libro come il classico Arrivare a Sì (http://www.amazon.com/gp/aw/d/0143118757).

Per nuovi sviluppi, in particolare per lo sviluppo Agile:

"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." -- Antoine de Saint-Exuper

Se stai valutando gli sforzi e il tempo per correggere alcuni errori quasi impossibili da riprodurre in un sistema orribilmente troppo complesso con pochissimi o nessun sviluppatore con conoscenza del dominio intimo del sistema, l'unica risposta corretta è "Quando è fisso ".

In genere, direi loro la verità. Gli direi loro che non so in questo momento, e potrei avere una visione migliore in una settimana. Dopodiché consegnerei loro un parco giochi con tanti ghirigori di fronte ad esso, dato che puoi inserirli sulla carta per indicare che si tratta di un'ipotesi basata sulla sensazione di budello. Se iniziano a ballare duramente, inizia ogni frase con "È possibile ..." Di solito, chiunque faccia qualcosa per me è felice con "Riprova tra una settimana o giù di lì, ma ora tutto quello che posso dire è di circa 2 mesi" o qualcosa del genere.

Il processo di personal software (PSP) si concentra sul miglioramento delle stime. Ciò è ottenuto mediante la registrazione disciplinata delle attività. Questo, in sostanza, un po '"accelera" la parte "esperienza" della stima dal momento che si avranno dati reali sui compiti tipici. Certo, questa professione richiede ancora soluzioni uniche a molti problemi, ma secondo la mia esperienza, le stime sono migliori dopo l'uso di PSP.