Stima del tempo di una complessa ricerca di bug (non diretta) [duplicato]

Questo non è praticamente utile per te, ma non vorrei affondare al livello di spiegare ai colleghi non tecnici perché alcuni compiti tecnici sono più difficili di altri. Il punto di assumere specialisti per compiti di programmazione che sono più bravi in cose tecniche e peggio per affari o gestione dei loro datori di lavoro è che sono migliori con loro . In gran parte, capire perché si presenta un difetto equivale a essere in grado di risolverlo e, in misura minore, di essere in grado di evitare errori simili in futuro.

In breve e brutalmente, se i tuoi superiori capissero perché alcune attività di debug sono così difficili, sarebbero in grado di eseguire autonomamente quei compiti, che non sono, dal momento che ti hanno assunto. È difficile per chiunque accettare che ci sono distinzioni che non possono apprezzare, quindi non ha molto senso spiegare a un manager che hai difficoltà che non puoi spiegare a lui. La cosa migliore che puoi fare è salire al suo livello di vista e dirgli: "Senti, so che questo suona zoppo, ma non posso dirti molto bene quanto tempo ci vorrà non importa quale sia l'incentivo" . Una volta che hai detto questo nei casi in cui è vero, e hanno visto che è effettivamente vero (perché il tuo sforzo ha varia imprevedibilmente), forse inizieranno a crederti quando dici che non sai qualcosa. Ma non terrei il respiro. Dire "non so" a qualcosa in un ambiente competitivo è molto difficile da fare e molti professionisti evitano di farlo a tutti i costi; e così tendono a credere che non è vero quando anche qualcun altro lo sta dicendo. Strano, ma (nella mia precedente esperienza) fin troppo vero.

A seconda della gravità del problema e dell'urgenza di risolverlo, vedi se accetteranno uno sforzo "time-box". Dì, due giorni di ricerca / tentativo di ricreare il problema. Se non lo possiedi, segnalerai ciò che hai eliminato come problema e vedrai se vogliono continuare a scavare.

Per problemi minori, è probabile che acconsentano a un breve intervallo di tempo, purché il lavoro continui su altri problemi o funzionalità. Per quelli importanti, specialmente quelli con maggiore visibilità, il time-box consentirà loro di ottenere rapporti regolari sul tuo sforzo.

Combina due approcci: la "stima del tempo fisso" e l'approccio "Non so" senza dire letteralmente che non lo so. Ammettiamolo, se tu sapessi esattamente che cosa sta causando il bug, non lo avresti scritto in quel modo in primo luogo (sì, so che non sistemiamo sempre il nostro codice, ma non ripuliamo il casino di qualcun altro ancora peggio?).

Prendi l'abitudine di rispondere alle richieste di quotazione bug con "Daremo un'occhiata a questo e ti farò sapere quanto tempo ci vorrà". Le persone vogliono sapere che ti preoccupi abbastanza dimostrando che stai prendendo provvedimenti per risolvere il problema e che stai dando priorità al loro compito in modo appropriato. Fare promesse (e sono promesse nella loro mente) che non puoi mantenere diminuirà il loro livello di fiducia in te.

Non dimenticare di riorganizzare gli altri impegni. In termini semplici, non riesco a correggere il nuovo bug trovato e a fornire una nuova funzionalità allo stesso tempo. Quale vuoi che faccia per primo? Speriamo che toglieranno il bug, ma non lo saprai mai.

Non vogliono una spiegazione tecnica. quando un utente non tecnico chiede "Perché ci vorrà così tanto tempo?" non vogliono necessariamente una risposta tecnica e in realtà non vogliono dettagli. Prendendo tempo per indagare sull'errore e quindi dando una stima del tempo in seguito, è anche possibile riepilogare la soluzione. Potrebbero essere modificate più aree dell'app che devono essere modificate (il debito tecnico è ora scaduto), patching di altre tecnologie, ecc.

Suggerisco di fornire un intervallo come stima.

Ad esempio, per problemi facili potrebbe essere "tra 15 minuti e tre ore", per problemi complessi potrebbe essere "tra due ore e una settimana".

Questo dovrebbe comprendere il tuo punto di vista. Se chiedono perché la tua stima del caso migliore e peggiore è così selvaggia, puoi iniziare a spiegare le cose che hai menzionato nella tua domanda (processo ciclico, ecc.) E anche dare esempi per il caso migliore e peggiore. / p>     

Cercare una soluzione a un problema può essere molto simile alla ricerca di qualsiasi altra cosa che manca. Prendi le chiavi della macchina, per esempio. Se il mio non è sullo scaffale a cui appartengono, controllo l'altro lato dello scaffale & un paio di tasche del cappotto e di solito li trovi in pochi minuti.

Quando mia moglie ha perso le chiavi qualche tempo fa, abbiamo dovuto aspettare prima che la neve si sciogliesse. Ci sono voluti un paio di mesi.

Penso che l'hai inchiodato con "easy", "hazy" e "hard". Un bug è facile da trovare quando puoi restringere rapidamente lo spazio di ricerca a qualcosa di ragionevole. È difficile quando non puoi.

Tutti i tuoi superiori hanno davvero bisogno di sapere è che questa è una priorità, stai lavorando in modo metodico / hai un piano di ricerca e non sei ancora fuori dalle idee.

La stima del tempo per il completamento delle attività nello sviluppo del software è davvero un'arte oscura. Penso che i tuoi argomenti siano buoni, ma ne hai dimenticato uno critico:

Per quanto tempo pensi che succederà, moltiplicalo per due.

Ho trovato che funziona abbastanza bene. Le cose richiederanno sempre più tempo di quanto pensi, specialmente nello sviluppo del software.