Come rispondere "Quando sarà fatto?"

Abbiamo tutti, problemi che si rivelano difficili da risolvere e che risolvono un problema attraverso un codice oscuro e una bizzarra funzionalità inaspettata. Lentamente, logicamente facendoti strada cercando di trovare schemi, errori, errori. Questo processo richiede tempo e spesso i problemi non sono facilmente comprensibili da parte del cliente.

Come si risponde quando viene posta la domanda "Quando verrà eseguita?", In particolare quando il client potrebbe non comprendere le complessità intrinseche dello sviluppo del software?

Rispondi alla domanda onestamente.

Dici che è un problema difficile, la soluzione non è ovvia e non sei sicuro di quanto tempo ci vorrà per risolverlo. Prometti di aggiornarli sui tuoi progressi ogni [time frame], in modo che sappiano che ci stai lavorando e, naturalmente, invii loro gli aggiornamenti.

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

In un mondo ideale , risolvere un problema sarebbe un problema complesso A e si sarebbe in grado, in un dato momento, di scomporlo in un breve elenco di piccoli problemi da A ₁ a A _n , poiché ogni valutazione del tempo è semplice, dato che il tempo necessario per risolvere il problema complesso iniziale sarebbe:

con D è il processo stesso di decomposizione.

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

Puoi ancora:

• Separare l'attività specificata (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 essere bloccati è elevato, quindi dai 12 ore come aspettativa al cliente.

• Valuta le dipendenze e il modo in cui incidono sul tempo.

  Ad esempio, l'attività 19 richiede 2 ore e il rischio è così basso che si può dire che sono sicuramente 2 ore. Non 1. Non 3. Ma l'attività 19 si basa sull'attività 24: l'attività 24 può influire sull'attività 19 in un modo che sarebbe necessario riscrivere completamente il codice dell'attività 19 utilizzando un approccio diverso.

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

L'ultimo punto è importante. Se dai la somma, diciamo 192 ore, il cliente crede che si tratti di una metrica molto precisa e che il tempo che passerai va da, diciamo, da 189 a 195 ore.

Se invece dai i dettagli,

• Il cliente che si prende cura capirà che non sono le 192 ore. Sono 192 le ore se tutto va storto dato il rischio determinato durante la valutazione. Sono anche 238 ore se tutto va ancora peggio. Sono 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 in seguito. Dando una risposta molto dettagliata che non leggerà mai, sai che non può chiederti il ​​tempo che ci vorrà di nuovo: hai già risposto. Inoltre non può biasimarti più tardi, dal momento che non ha letto la risposta per calcolare la somma.

Qualunque cosa tu stia stimando, non dimenticare di includere la legge di Hofstadter : ci vuole sempre più tempo del previsto, 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 tutta la formattazione matematica di fantasia; se qualcuno vuole modificarlo per questo, allora 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 rivaluti il ​​tuo progetto ogni pochi giorni, potresti persino fornire un aggiornamento settimanale. Fa molto per soddisfare i clienti irritabili. :)

Spiegare tempistiche vaghe per utenti non tecnici è difficile. Questo è vero sia nelle fasi creative di un progetto, sia nel rintracciare un fastidioso bug. In entrambi i casi il tradizionale "scomporre il lavoro in pezzi più piccoli" non funziona altrettanto bene.

Il compito originale si concentra su quest'ultimo caso, quindi soffermiamoci su quello. Se non riesci a fornire una sequenza temporale, indica all'utente cosa proverai e quando tornerai da loro. Quando raggiungi il punto a metà della sequenza temporale autoimposta, invia 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 viene risolto, almeno stai facendo luce. Può sembrare una perdita di tempo, ma non lo è.

Dal momento che non è possibile tenere conto dei blocchi sconosciuti e delle sorprese impreviste, può essere difficile stimare con fiducia. idee:

• Prova un intervallo - "Sono sicuro che ci vorranno almeno N giorni (ad es. 3), ma potrebbero richiedere fino a 4N."
• Cerca il supporto di ingegneri più esperti nella stima e nella difesa delle stime.
• Lavora in iterazioni più brevi (stile Agile / Scrum) per produrre un codice minimo che aggiunga valore al business (acquisendo sicurezza e fiducia), quindi ripeti.
• Impara le capacità di negoziazione da un libro come il classico Come arrivare a (http://www.amazon.com/gp/aw/d/0143118757).

Per i nuovi sviluppi, in particolare lo sviluppo Agile:

"La perfezione si ottiene, non quando non c'è altro da aggiungere, ma quando non c'è più niente da togliere". - Antoine de Saint-Exuper

Se stai valutando gli sforzi e il tempo per correggere alcuni errori quasi impossibili da riprodurre in un sistema orribilmente eccessivamente complesso con pochissimi o nessuno sviluppatore con una conoscenza del dominio intima del sistema, l'unica risposta corretta è "Quando viene risolto".

In genere, direi loro la verità. Direi loro che non lo so in questo momento, e potrei avere una visione migliore in una settimana. Vorrei quindi consegnare loro un parco di palline con tutti gli scarabocchi davanti ad esso che puoi adattare sulla carta per indicare che si tratta di una supposizione basata sul sentimento intestinale. Se iniziano a farti duro, basta iniziare ogni frase con "È possibile ..." Di solito chiunque faccia qualcosa è contento del "Torna tra una settimana o giù di lì, ma ora posso solo dire che è di circa 2 mesi" o qualcosa di simile.

Il Personal Software Process (PSP) si concentra sul miglioramento delle stime. Ciò è possibile grazie alla registrazione disciplinata delle attività. Questo, in sostanza, "accelera" in qualche modo la parte "dell'esperienza" della stima poiché si avranno dati reali su attività tipiche. Naturalmente, questa professione richiede ancora soluzioni uniche a molti problemi, ma secondo la mia esperienza, le stime sono migliori dopo aver usato PSP.