Sono stato un manager che riceveva "sarà fatto quando sarà finito", e si tratta della risposta meno utile che è possibile dare +. Dire questo e nient'altro ti mette in grave pericolo di essere considerato non collaborativo. Devi assolutamente fornire maggiori informazioni.

Per spiegare un po 'di più sul "perché" di questo, in un progetto software ci sono spesso azioni che possono essere fatte solo quando hai finito, ma che devono essere pianificato e programmato in anticipo. Se non puoi dire qualcosa su quando avrai finito, il progetto finisce per essere anche successivo e spesso costa di più.

Detto questo, "Quando avrai finito?" non significa sempre "Sbrigati". Spesso la persona che chiede vuole sapere in modo da poter pianificare. È meglio presumere che, a meno che tu non abbia un motivo per pensare diversamente.

Di seguito sono riportate alcune possibili circostanze in cui potresti trovarti:

1. Hai altro lavoro da fare che ha una priorità più alta. Dillo. Se possibile, dite anche al richiedente "Se avessi iniziato il lavoro adesso e non avessi interruzioni, lo avrei fatto ...". Se sai anche qual è il lavoro che hai nel piatto e che probabilmente nessun altro lavoro arriverà, dì "Credo che potrò iniziare a lavorare al tuo progetto il [data], nel qual caso sarà finito entro [ Data]". Se la situazione è complicata, indirizza il richiedente al tuo capo, che presumibilmente stabilisce il tuo programma. Spetta al richiedente negoziare con lei quale sia la priorità del lavoro di cui ha bisogno.
2. Dipendi dal lavoro di qualcun altro, che non si è impegnato a una data di completamento. Di nuovo, dillo e chi è. Se lo sai, puoi dire "se tale e tale si impegna a finire il suo lavoro entro il [data], posso farlo entro [data]". Sarebbe utile.
3. Non hai abbastanza informazioni su ciò che è necessario per effettuare stime del lavoro. Dillo di nuovo. (Stai percependo uno schema?). Assicurati di aver comunicato alla persona responsabile che ti ha fornito le informazioni di cui hai bisogno ciò di cui hai bisogno.
4. Non capisci veramente il problema abbastanza bene da saperlo. Se stai già lavorando al progetto, quindi non sapere quando sarai completo è un problema e dovresti cercare di assicurarti che non ti succeda più. Se non sei stato in grado di fare una stima perché hai altre cose da fare, vedi il punto 1. Se la stima delle date di completamento è importante per la tua organizzazione (e se ti viene richiesta una di solito significa che lo è), spesso vale la pena dedicare tempo per aumentare la comprensione del problema in modo da poter effettuare una stima accurata, anche se ciò significa ritardare leggermente la data di completamento effettiva. Una data di completamento prevedibile a volte è migliore di una data di completamento breve.
5. Se nessuna delle prime tre è applicabile, la risposta migliore che puoi dare è "Non prima di [questa data], non oltre [quella data]. " Questa è un'informazione utile, anche se" quella data "è molto lontana nel futuro. La data "non oltre" dovrebbe essere la tua ipotesi migliore nel peggiore dei casi, oltre a un grande fattore di sicurezza.

A volte, naturalmente, ti rendi conto improvvisamente durante un lavoro che ci vorrà molto più tempo che tu pensi. Se il tempismo del tuo lavoro è importante, di solito è meglio sederti e cercare di capire quanto tempo ci vorrà davvero, piuttosto che solo arare. A volte (o in realtà sempre, a causa della legge di Murphy) ti verrà chiesto un preventivo mentre lo stai ancora elaborando. In tal caso è perfettamente corretto dire "Ti fornirò una stima migliore tra [un po 'di tempo]."

A proposito, tutte le risposte precedenti presuppongono che tu sia un lavoratore di "livello senior" responsabile della propria pianificazione. In caso contrario, o in caso di dubbio, coinvolgi il tuo capo.

+ Tecnicamente non è la risposta meno utile. Una vera bugia o un appuntamento che non hai intenzione di mantenere sarebbe peggio. Ma "sarà fatto quando sarà finito" è solo un passo avanti rispetto a quelli.

Quando ti viene chiesto di stimare le date di scadenza, c'è un modo particolarmente educato o intelligente per dire che è "Fatto quando è finito"?

Ho sempre è piaciuto "una volta che le persone smettono di interrompermi", ma non sono particolarmente educato.

È l'unico modo per dire: "Non posso dire in questo momento, chiedi a me a [data ora ] "?

Certamente no. Ci sono aziende / culture in cui "Quando è finito". è una risposta accettabile ( Blizzard per esempio, almeno esternamente) e ti incoraggerei a lavorare e a cambiare la tua cultura verso questo.

"Non sono sicuro, dipende da Alice e Bob e ..." è una risposta abbastanza passivo-aggressiva che può essere utilizzata in alcune aree per sviare la persona porre la domanda e, se fatto bene, può trasformare quella persona in una risorsa che ti aiuta a rimuovere i blocchi stradali.

"Non sono sicuro, quando mi prendi X?" è una risposta più chiaramente aggressiva in cui qualcuno si intromette nei tuoi affari ma non si prende cura dei loro. Può essere utile per sottolineare che le tue stime non saranno migliori delle loro e mantenerti a uno standard più elevato è sciocco. Non consigliato.

"Non sono sicuro, ho bisogno di verificare con il mio team." può essere una risposta solida che ti dà il tempo di riflettere, oltre che di ritrarre te come qualcuno che rimanda alla conoscenza esperta. È anche utile se controlli effettivamente con il tuo team, dal momento che di solito può fornire un buon input e farsi coinvolgere entro la scadenza a cui essenzialmente li impegni. Fai attenzione però, poiché questa risposta può essere utilizzata in modo improprio e ti dipinge come qualcuno che non fa altro che essere un intermediario.

"Dipende, cosa deve fare?" Un'altra risposta solida che può essere passivo-aggressiva, ma a volte può semplicemente portare a una bella sessione improvvisata di raccolta dei requisiti. Funziona anche per mantenere il business onesto. Se ti impegni a lavorare, è necessario che si impegni in ambito (e risorse).

"Dipende, quanto bene deve funzionare?" Simile all'ultima domanda, aiuta a perfezionare l'ambito e soddisfa il terzo lato del triangolo.

"Non lo so. Questo sprint è XYZ." Una risposta limitata per le persone che usano gli sprint (spesso ingegneri del software). La cosa bella qui è che la società ha probabilmente deciso di fare Agile con Sprint, quindi hai quel sostegno. In un ambiente ideale, le uniche cose pianificate sono per le ~ 2 settimane del tuo attuale sprint. Tutto il resto è intenzionalmente non pianificato in modo che tu possa essere ... agile su ciò che ha la priorità. In un mondo non ideale, le cose sono probabilmente pianificate all'ennesima potenza, e poi suddivise in blocchi di due settimane, ma la domanda ti offre una buona opportunità per commentare malignamente quell'assurdità.

Quindi, in breve , ci sono molti modi sbagliati per schivare la domanda. Probabilmente faresti meglio a fornire un numero di scenario peggiore e poi tornare a fare un lavoro reale.

Mi piace "non c'è ancora una stima per questo".

Fornisce la risposta che desideri, è abbastanza concreta e di tono neutro e suggerisce che una stima potrebbe essere fatta a un certo punto, ma certamente non in questo momento qui alla macchina del caffè senza una chiara immagine di cosa significherebbe effettivamente fare la cosa che sta chiedendo.

Devi essere preparato per la domanda "di cosa avresti bisogno in ordine fare una stima ", in quanto deve essere presa sul serio.

Quando ti viene chiesto di stimare le date di scadenza, c'è un modo particolarmente educato o intelligente per dire che è "Fatto quando è finito"?

Di solito puoi " Non farla franca essendo intelligente e dicendo "Sarà fatto ogni volta che sarà fatto", non importa come lo inquadra. Quando viene chiesto di stimare le date di completamento, di solito non è ciò che il richiedente vuole sentire.

Invece, puoi trasmettere la tua stima e dare un grado di precisione alla tua stima.

Qualcosa sulla falsariga di "Sulla base della mia attuale comprensione del progetto, la mia stima è di 3 mesi. Ma, poiché i Requisiti non sono ancora scritti, sarò in grado di fornire una stima più precisa una volta che li avrò letti." (Di nascosto, li chiamo " stime ipotetiche ".)

Se il tuo ambiente di lavoro richiede qualcosa di più formale di questo tipo di stima improvvisata parlata o inviata per e-mail, fai assicurati di includere tutte le tue ipotesi nella stima formale, insieme alla tua valutazione della precisione con cui sei in grado di stimare in quel momento.

Puoi fare di meglio, se ti viene concesso più tempo per preparare il tuo preventivo e ti vengono dati più dati su cui basare il tuo preventivo. Ma puoi sempre stimare in qualsiasi periodo di tempo, purché non ci si aspetti che la stima sia particolarmente accurata.

Dopo aver fornito le stime (indipendentemente da come vengono derivate), mantieni i tuoi stakeholder in il ciclo se accade qualcosa che cambierà la tua stima, in particolare quando le scadenze incombono.

Presumo che tu sia la persona responsabile del progetto o dell'attività su cui si sta indagando. In tal caso, perché non puoi dirlo?

• Il tuo tempo viene consumato con altre attività
• Stai aspettando che i blocchi vengano cancellati prima di fare progressi
• Ci sono troppe incognite o dipendenze future nel compito per stimare in modo sensato
• Il compito come ti è stato dato non è definito

Tutti questi sono motivi legittimi per non avere una buona stima, ma sono anche problemi che devi sollevare in modo proattivo con il tuo manager (o nel primo caso, potresti ottenere un riconoscimento da loro che l'attività può scivolare per consentire cose con priorità più alta). "Fatto quando è fatto" trasmetterà semplicemente l'impressione che non lo sai e che non stai facendo nulla per scoprirlo. In quanto tale, questo impedisce al tuo manager di pianificare il quadro più ampio.

Dalle tue risposte ai commenti e alle risposte, sospetto che la tua domanda dovrebbe davvero essere:

Il mio lavoro consiste in molti piccoli compiti, che posso ricevere in qualsiasi ordine e che hanno priorità diverse . Ho una coda costante di attività con priorità più bassa che posso fare solo quando non ci sono attività con priorità più alta da completare.

Mi viene spesso chiesto di fornire stime su quando le attività con priorità più bassa saranno completate. La mia risposta attuale, "Sarà fatto quando sarà finito" non viene accolta bene.

Cosa dovrei fare?

Da questo punto di vista, la risposta è ovvio: è necessario migliorare il monitoraggio e la gestione delle attività. Ciò non comporterà una modifica al processo / coda / priorità: solo un po 'di lavoro extra nel monitoraggio del tempo di ciascuna attività.

1. Stimare il numero di ore necessarie per completare ciascuna attività quando arrivano nella tua coda.
2. Ogni settimana rivedi il numero di ore trascorse su ciascun livello di priorità e mantieni una media corrente in modo da sapere quante ore hai normalmente a settimana per un determinato livello di priorità.

Il numero 1 è probabilmente abbastanza facile per un'ipotesi approssimativa. "Tra le 6 e le 10 ore" va bene, non è necessario lottare per la precisione qui, solo una stima approssimativa. È probabile che tu abbia una conoscenza sufficiente del compito da poter dare una stima decente qui con un probabile minimo e massimo.

Il numero 2 richiederà un po 'più di lavoro ogni settimana. Se tieni già traccia di attività e tempo, non dovrebbe essere difficile, ma anche se non tieni solo un blocco note e ogni volta che finisci un'attività annota il livello di priorità e quante ore ci hai dedicato. Alla fine della settimana puoi sommare il tempo per ciascuna priorità e, una volta che lo hai fatto per alcune settimane, dovresti avere una media decente.

Quando qualcuno ti chiede una data di completamento, aggiungi tutte le ore per la loro attività e le attività prima di loro a un determinato livello di priorità insieme per il tempo minimo e massimo, quindi dividi per il numero medio di ore disponibili per quello livello di priorità a settimana. Non dire loro quante ore hai assegnato per attività o quante ore hai assegnato a settimana, hanno solo bisogno di sapere il giorno in cui non accadrà prima e il giorno in cui dovrebbe essere fatto. "Ci sono 3 attività prima di quella e sembra che il caso migliore sia venerdì prossimo e il caso peggiore il mercoledì successivo. Controlla con me tra qualche giorno e avrò una stima migliore."

Se ci sono attività che devono essere svolte che non vengono mai svolte, puoi prendere in considerazione l'implementazione di un aumento del livello di priorità basato sul tempo. Le attività a bassa priorità, se non svolte entro N settimane, passano al livello di priorità successivo.

In questo modo puoi fornire stime che gestiranno le aspettative dei tuoi colleghi e superiori.

Nessuna informazione, "Sarà fatto quando sarà finito" è peggio di informazioni sgradite, "Le attività con priorità più alta ci stanno sommergendo. passeranno 8 settimane prima che questo riceva un aggiornamento prioritario automatico, quindi ci vorranno una o due settimane in quella coda fino al termine. "

Questo è qualcosa che non dovresti mai dire. Tutto ciò che farà è irritare il tuo manager e farti sembrare un incompetente.

Digli cosa pensi che servirà (se non puoi definire i passaggi e approssimativamente cosa faranno, allora probabilmente devi chiedi a qualcuno di fare un lavoro migliore sui requisiti, quindi digli che i requisiti non sono chiari e quindi non puoi determinare cosa ci vorrà.), quali ritardi hai generalmente a causa di un lavoro con priorità più alta e poi dagli una data. I clienti non accetteranno ogni volta come data di scadenza e quindi non dovresti dargliela. Quando le cose cambiano la priorità e altre cose vengono inviate prima, invia un'email al manager e imposta una nuova data in base al ritardo. Spesso quando indichi il cambiamento nella data di scadenza, le cose con priorità più alta vengono spostate verso il basso. Quando accadono cose che fanno sì che il lavoro richieda più tempo di quanto stimato, assicurati che il manager sia immediatamente consapevole dell'impatto che ha sulla data di scadenza.

Qualsiasi sviluppatore dovrebbe essere in grado di fornire stime di tempo. Fa parte di ciò per cui vieni pagato, quindi smettila di litigare con "ogni volta". Se non sei bravo in questo, migliora registrando ciò che hai stimato e il tempo effettivo. Includere il tempo di ritardo e il tempo per le riunioni, la comunicazione e-mail, i requisiti di raffinamento, i test di unità, i test di qa di supporto, ecc. Se ti viene chiesto un appuntamento diretto, presumi non più di 6 ore produttive al giorno quando converti le ore che pensi ci vorranno in giorni e metti un paio di giorni per gli inevitabili ritardi.

Sulla base dei commenti su altre risposte, sembra che il tuo problema non sia la stima del tempo, ma la comunicazione dei ritardi in base al cambiamento delle priorità. Ciò di cui hai bisogno è essere più, non meno comunicativo quando questo accade. Devi far sapere alle persone quando il loro compito è rientrato nell'elenco delle priorità (ea cosa) e sarà ritardato e per quanto tempo ti aspetti che sia prima di tornare al punto. Lasciali andare a combattere le priorità con i manager. Dite loro che possono parlare con il manager se non sono d'accordo con le priorità attuali.

Ma è tuo obbligo assoluto far sapere loro quando le cose cambieranno e che lavorerai su qualcosa prima del loro progetto. Questo non dovrebbe aspettare fino a quando non ti chiederanno perché non è ancora stato fatto. In ogni caso, "ogniqualvolta" non è una risposta accettabile. Fingere di essere troppo occupato per rispondere non è accettabile.

Devi capire che i rapporti sui progressi, le stime dei tempi, ecc. importante o più importante delle parti di sviluppo effettivo. Questa non è un'interruzione inutile, fa parte del tuo lavoro. Queste persone stanno pagando il tuo stipendio con i loro progetti. Inizia a trattarle con rispetto e rispettando Una volta che sanno che possono fidarsi di te per dirgli quando le cose saranno ritardate, ti daranno meno fastidio.

Dovresti rispondere con una distribuzione, non un singolo numero: qualcosa del tipo "Potrebbe essere fatto la prossima settimana, se siamo fortunati. Se siamo sfortunati, tra sei settimane. La migliore ipotesi riguarda due settimane." Quella risposta spesso avrà una reazione negativa. In tal caso, puoi indicare un numero qualsiasi di trattati di stima dei costi del software che dimostrano che tale incertezza è comune e realistica.

In alcuni campi, le attività sono chiaramente definite e gestite in sequenza: Costruire una casa : richiede X settimane, altre attività non intervengono. Se hai già 6 progetti in fila, semplicemente ne rifiuti altri.

Sviluppo software : le attività possono richiedere da 1 minuto ad anni di tempo di qualsiasi persona. Le attività vengono aggiunte e (a volte) rimosse dalla coda costantemente. Le priorità sono cambiate a caso. Non si può rifiutare di più, vengono semplicemente rimandati all'infinito da compiti con priorità sempre più alta.

Se l'ambiente di lavoro è molto incerto, le stime diventano impossibili. Potremmo trasformare questi campi nello stesso ambiente della costruzione di case? Non probabile.

Penso che le persone che gestiscono il lavoro debbano aggiungere NO al vocabolario. O forse: No, a meno che quest'altra attività non possa essere scartata (in modo permanente). Ricordo che qualcuno al di sopra del mio manager cercava di assegnare una seconda "priorità n. 1" e il mio manager protestò per mio conto: "Non possono essere ENTRAMBI n. 1!" Se le persone fossero costrette ad assegnare numeri prioritari ai compiti, allora inizierebbe a diventare più chiaro: il tuo numero 1 di 3 settimane fa è diventato il numero 7, quindi è davvero necessario? Se non è possibile assumere più persone, basta avere a disposizione un gruppo di appaltatori e distribuire loro i compiti. "I nostri non dipendenti sono la nostra più grande risorsa!"

Puoi chiedere un po 'di tempo per esaminare ulteriormente la richiesta e quindi fornire una stima in quel momento. Potrebbero volerci alcune ore, giorni, settimane. Qualunque cosa tu dica loro, assicurati di seguire in quel momento anche se significa che hai bisogno di più tempo. Altrimenti, penseranno che hai lasciato cadere la palla. Potrebbe essere necessario far loro sapere che ci sono altri progetti / attività che creano una contingenza che non puoi controllare e che influirà quando puoi anche solo iniziare a esaminare il problema.

Ho avuto meccanici di automobili, idraulici, costruttori di case, ecc. fammi sapere che hanno bisogno di valutare la situazione e trovare una soluzione. Una volta che hai una soluzione, la stima è più facile.

È importante ricordare che cos'è una stima, in molti casi un'ipotesi. Troppo spesso le persone si sentono sotto pressione e commettono l'errore di promettere troppo. Dopo aver messo in relazione una richiesta con un'attività precedente, puoi utilizzarla come linea guida.

Ho lavorato a un progetto simile a questo. Un compito che pensavo avrebbe richiesto due settimane ha finito per richiedere un mese e mezzo.

Per fortuna sapevo di non avere una comprensione adeguata del tempo richiesto. Quindi, quando il mio capo ha chiesto di entrare lo standup (lavoriamo con lo sviluppo Agile) gli darei la mia migliore stima e gli spiegherei perché lo pensavo. Sebbene le mie stime alla fine si siano rivelate imprecise, gli ho dato quello che pensavo sarebbe stato necessario per richiesta, ma mi sono assicurato che sapesse che era soggetto a modifiche.

In generale, l'onestà è la cosa migliore, sii sincero e mantieni lui nel ciclo. A volte non c'è una risposta chiara e tutto ciò che possiamo fare è tenere i nostri capi il più informati possibile sulla questione.