Quando vi viene chiesto di indicare una data di completamento, qual è il modo migliore per dire "sarà fatto quando sarà fatto"?

Sono stato un manager sul lato ricevente di “sarà fatto quando sarà fatto”, e si tratta della risposta meno utile che si possa dare+. Dire questo e nient'altro ti mette in grave pericolo di essere considerato non collaborativo. Dovete assolutamente dare più 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 si è finito, ma che devono essere pianificate e programmate in anticipo. Se non si può dire qualcosa su quando si sarà finito, il progetto finisce per essere ancora più tardi e spesso costa di più.

Detto questo, “Quando sarà finito?” non sempre significa “Sbrigati”. Spesso la persona che chiede vuole saperlo per poter pianificare. È meglio presumere che sia così, a meno che non abbiate una ragione per pensarla diversamente.

Ecco alcune possibili circostanze in cui potreste trovarvi:

1. 1. Hai altro lavoro da fare che ha una priorità più alta. Se è possibile, dite anche al richiedente: “Se iniziassi il lavoro adesso e non avessi interruzioni, lo farei entro…”. Se anche voi sapete che lavoro avete in programma, e che probabilmente non ci saranno altri lavori, dite: “Credo che potrò iniziare a lavorare sul vostro progetto il [data], nel qual caso sarà finito entro [data]”. Se la situazione è complicata, riferisci il richiedente al tuo capo, che presumibilmente stabilisce il tuo programma. Spetta al richiedente negoziare con lei su quale sia la priorità del lavoro di cui ha bisogno. **Anche in questo caso, dite che dipendete dal lavoro di qualcun altro, che non si è impegnato a rispettare una data di completamento. Anche in questo caso, dite questo e chi è. Se lo sai, allora puoi dire “se tale e tale si impegna a finire il suo lavoro entro [data], io posso finire entro [data]”. Sarebbe utile.
2. Non hai abbastanza informazioni su ciò che è necessario per fare una stima del lavoro. Anche in questo caso, dillo. (Stai percependo uno schema?). Assicuratevi di aver detto alla persona responsabile di farvi avere le informazioni di cui avete bisogno.
3. **Se stai già lavorando al progetto, allora non sapere quando sarai completo è un problema, e dovresti cercare di fare in modo che non ti succeda più. Se non siete stati in grado di fare una stima perché avete altre cose da fare, allora vedete il punto 1. Se la stima delle date di completamento è importante per la vostra organizzazione (e se ve ne viene richiesta una che di solito significa che lo è), spesso vale la pena prendersi del tempo per aumentare la vostra comprensione del problema in modo da poter fare una stima accurata, anche se ciò significa ritardare leggermente la data di completamento effettiva. Una data di completamento prevedibile è a volte migliore di una breve data di completamento.
4. Se nessuna delle prime tre si applica, allora la migliore risposta che si può dare è “Non prima di [questa data], non dopo [quella data]” Questa è un'informazione utile, anche se ‘quella data’ è molto lontana nel futuro. La data “non più tardi di” dovrebbe essere la vostra migliore ipotesi nel caso peggiore, più un grande fattore di sicurezza.

A volte, naturalmente, durante alcuni lavori vi rendete conto improvvisamente che ci vorrà molto più tempo di quanto pensiate. Se la tempistica del vostro lavoro è importante, di solito è meglio sedersi e cercare di capire quanto tempo ci vorrà veramente, piuttosto che continuare ad arare. A volte (o in realtà sempre, a causa della legge di Murphy) vi verrà chiesto un preventivo mentre state ancora lavorando. In questo caso va benissimo dire “Avrò una stima migliore per te tra [un po’ di tempo]”

A proposito, tutte le risposte di cui sopra presuppongono che tu sia un lavoratore ‘senior level’ responsabile della propria programmazione. In caso contrario, o in caso di dubbio, coinvolgete il vostro capo.

+Non è tecnicamente la risposta meno utile. Una vera e propria bugia, o una data che non avete intenzione di mantenere sarebbe peggiore. Ma “sarà fatto quando sarà fatto” è solo un passo avanti rispetto a questi.

Quando vi viene chiesto di stimare le date di scadenza, c'è un modo particolarmente educato o intelligente per dire che è “Fatto quando è fatto” ?

Mi è sempre piaciuto “una volta che la gente smette di interrompermi”, ma non sono particolarmente educato.

È l'unico modo per dire: “Non posso dire in questo momento, controlla con me a [data ora]” ?

Certamente no. Ci sono aziende/culture dove “Quando è fatto” è una risposta accettabile Blizzard per esempio , almeno esternamente), e vi incoraggerei a lavorare e a cambiare la vostra cultura verso questo.

“Non sono sicuro, dipende da Alice e Bob e… ” è una risposta abbastanza passivo-aggressiva che può essere usata in alcune aree per deviare la persona che fa la domanda e se fatta bene può trasformare quella persona in una risorsa che ti aiuta a rimuovere i blocchi stradali.

“Non sono sicuro, quando mi prenderai X? ” è una risposta più chiaramente aggressiva in cui qualcuno si intromette nei tuoi affari ma non si prende cura dei suoi. Può essere utile sottolineare che le vostre stime non saranno migliori delle loro, e che mantenervi ad uno standard più elevato è sciocco. Sconsigliato.

“Non ne sono sicuro, devo verificare con il mio team ” può essere una risposta solida che vi dà il tempo di considerare, oltre a ritrarre voi stessi come qualcuno che si rimette alle conoscenze degli esperti. È utile anche verificare con il proprio team, che di solito è in grado di fornire un buon contributo, oltre che di farsi comprare nella scadenza che si sta essenzialmente impegnando a rispettare. Fate attenzione, però, perché questa risposta può essere usata in modo improprio e vi ritrae come qualcuno che non fa altro che fare da intermediario.

“Dipende, cosa deve fare? ” Un'altra risposta solida che può essere passivo-aggressiva, ma che a volte può portare solo a una bella sessione di raccolta di requisiti improvvisati. Funziona anche per mantenere gli affari onesti. Se tu ti impegni a lavorare, allora loro devono impegnarsi per quanto riguarda lo scope (e le risorse).

“Dipende, quanto bene deve funzionare? ” Simile all'ultima domanda, aiuta ad affinare lo scope e soddisfa il terzo lato del triangolo .

“Non lo so. Questo sprint è XYZ. ” Una risposta limitata per chi usa gli sprint (spesso ingegneri del software). La cosa bella qui è che l'azienda ha probabilmente comprato a fare Agile con gli sprint, quindi avete quel sostegno. In un ambiente ideale, le uniche cose previste sono per le ~2 settimane dello sprint in corso. Tutto il resto è volutamente non pianificato in modo che si possa stare bene… agile su ciò che ha la priorità. In un mondo non ideale, le cose sono probabilmente pianificate all'ennesima potenza, e poi spezzate in pezzi da due settimane, ma la domanda offre una buona opportunità per commentare in modo sprezzante questa assurdità.

Quindi, in breve, ci sono molti brutti modi per schivare la domanda. Probabilmente è meglio dare qualche numero di scenario peggiore e poi tornare a fare un lavoro vero.

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

Dà la risposta che si vuole, è abbastanza fattuale 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 un quadro chiaro di cosa significherebbe effettivamente fare la cosa che sta chiedendo.

Devi essere preparato alla domanda “di cosa avresti bisogno per fare una stima”, perché questo deve essere preso sul serio.

Quando vi viene chiesto di stimare le date di scadenza, c'è un modo particolarmente educato o intelligente per dire che è “Fatto quando è fatto” ?

Di solito non si può farla franca con l'essere intelligenti e dire “Sarà fatto ogni volta che sarà fatto”, non importa come lo inquadrate. Quando ti viene chiesto di stimare le date fatte, di solito non è quello che chi ti chiede di fare una stima, ma puoi trasmettere la tua stima e dare un certo grado di precisione alla tua stima.

Qualcosa del tipo “In base alla 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 letti". Se il vostro ambiente di lavoro richiede qualcosa di più formale di questo tipo di stima, assicuratevi di includere tutti i vostri presupposti nella vostra stima formale, insieme alla vostra valutazione della precisione con cui siete in grado di stimare in quel momento.

Potete fare meglio, se vi è concesso più tempo per preparare la vostra stima, e vi vengono forniti più dati su cui potete basare la vostra stima. Ma è sempre possibile stimare in qualsiasi periodo di tempo, purché non ci si aspetti che la stima sia particolarmente accurata.

Una volta fornite le vostre stime (indipendentemente dal modo in cui sono derivate), tenete informati i vostri stakeholder se succede qualcosa che cambierà la vostra stima, soprattutto perché le scadenze incombono.

Presumo che lei sia la persona responsabile del progetto o del compito oggetto della richiesta. In tal caso, perché non può dirlo?

• Il vostro tempo viene consumato con altri compiti
• Aspettate che i bloccanti si liberino prima di fare progressi
• Ci sono troppe incognite o dipendenze future nel compito per poter fare una stima sensata
• Il compito che vi è stato assegnato è mal definito

Tutti questi sono motivi legittimi per non avere una buona stima, ma sono anche problemi che dovete sollevare in modo proattivo con il vostro manager (o nel primo caso, potreste ottenere un riconoscimento da loro che il compito può scivolare per consentire una maggiore priorità). “Fatto quando è fatto” darà semplicemente l'impressione che non lo sappiate e che non stiate facendo nulla per scoprirlo. Questo impedisce al vostro manager di pianificare il quadro generale.

Dalle vostre risposte ai commenti e alle risposte, sospetto che la vostra domanda dovrebbe essere davvero:

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

Spesso mi viene chiesto di fare una stima di quando i compiti a priorità più bassa saranno completati. La mia attuale risposta, “Sarà fatto quando sarà finito”, non è stata accolta bene.

Cosa devo fare?

Da questo punto di vista, la risposta è ovvia - è necessario fare un migliore monitoraggio e gestione dei compiti. Questo non comporterà una modifica del vostro processo/quota/priorientamento - solo un po’ di lavoro in più nel controllo del tempo di ogni attività.

1. 1. Stimate il numero di ore necessarie per completare ogni attività quando arrivano nella vostra coda.
2. Ogni settimana esaminate il numero di ore trascorse per ogni livello di priorità e mantenete una media di esecuzione in modo da sapere quante ore avete di solito a settimana per un determinato livello di priorità.

Numero 1 è probabilmente abbastanza facile per un'ipotesi approssimativa. “Tra 6 e 10 ore” va bene, non c'è bisogno di sforzarsi di essere precisi, solo una stima approssimativa. È probabile che abbiate una comprensione abbastanza buona del compito da poter dare una stima decente con un probabile minimo e massimo.

Numero 2 richiederà un po’ più di lavoro ogni settimana. Se si tiene traccia dei compiti e del tempo già impiegato non dovrebbe essere difficile, ma anche se non si tiene solo un blocco note, e ogni volta che si finisce un compito si scrive il livello di priorità e quante ore ci si è dedicato. Alla fine della settimana potete aggiungere il tempo insieme per ogni priorità, e una volta che lo avete fatto per qualche settimana dovreste avere una media di esecuzione decente.

Quando qualcuno vi chiede una data di completamento, aggiungete tutte le ore per il suo compito e le attività che lo attendono ad un dato livello di priorità insieme per il tempo minimo e massimo, e poi dividete per il numero medio di ore disponibili a quel livello di priorità per settimana. Non dite loro quali ore avete assegnato per ogni compito, o quante ore avete assegnato alla settimana, hanno solo bisogno di sapere il giorno in cui non accadrà prima, e il giorno in cui dovrebbe essere completato. Ci sono 3 compiti prima di questo, e sembra che il caso migliore sia il prossimo venerdì, e il peggiore è il mercoledì successivo. Verificate con me tra qualche giorno e avrò una stima migliore". _

Se ci sono compiti che devono essere svolti e che non vengono mai eseguiti, potete considerare di implementare un aumento del livello di priorità basato sul tempo. Le attività a bassa priorità, se non vengono eseguite entro N settimane, passano al livello di priorità successivo.

In questo modo potete fornire stime che gestiranno le aspettative dei vostri colleghi e superiori.

Nessuna informazione, “Sarà fatto quando sarà fatto” è peggio di un'informazione indesiderata, “Le attività a priorità più alta ci stanno sommergendo. Ci vorranno 8 settimane prima di ricevere un aggiornamento automatico della priorità, e poi ci vorranno una o due settimane in quella coda fino a quando non sarà finito”.

È una cosa che non si dovrebbe mai dire. Tutto ciò non farà altro che irritare il tuo manager e farti sembrare incompetente.

Digli cosa pensi che ci vorrà (se non riesci a definire i passi e più o meno quello che faranno, allora probabilmente hai bisogno di far fare a qualcuno 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 mai come data di scadenza e quindi non dovreste dargliela. Quando le cose cambiano la priorità e altre cose vengono anticipate, inviate un'e-mail al manager e fissate una nuova data in base al ritardo. Spesso quando si segnala il cambiamento della data di scadenza, le cose a priorità più alta vengono spostate verso il basso. Quando accadono cose che richiedono più tempo del previsto, assicuratevi che il manager sia immediatamente consapevole dell'impatto che ha sulla data di scadenza.

Qualsiasi dev dovrebbe essere in grado di fornire stime di tempo. Fa parte di ciò per cui siete pagati, quindi smettetela di dire “quando”. Se non siete bravi a farlo, allora miglioratevi tenendo traccia di ciò che avete stimato e di ciò che è stato il tempo effettivo. Includete nella vostra stima il tempo di ritardo e il tempo per le riunioni, la comunicazione via e-mail, i requisiti di raffinazione, i test delle unità, i test di supporto del qa, ecc. per ottenere un numero migliore. Se vi viene chiesta una data diretta, supponete non più di 6 ore produttive al giorno quando convertite le ore che credete che ci vorranno in giorni e metteteci un paio di giorni per gli inevitabili ritardi.

In base ai commenti su altre risposte, sembra che il vostro problema non sia la stima del tempo ma la comunicazione dei ritardi in base al cambiamento delle priorità. Ciò di cui avete bisogno è di essere più, non meno comunicativi quando ciò accade. Dovete far sapere alle persone quando il loro compito è caduto nella lista delle priorità (e a che cosa) e sarà ritardato e quanto tempo vi aspettate che sia prima di tornare ad esso. Lasciate che vadano 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 è vostro obbligo assoluto fargli sapere quando le cose cambieranno e che lavorerete a qualcosa prima del loro progetto. Questo non dovrebbe aspettare fino a quando non dovranno chiedervi perché non è ancora stato fatto. In ogni caso, “quando” non è una risposta accettabile. Fingere di essere troppo occupati per rispondere non è accettabile.

Dovete capire che i rapporti sui progressi, le stime dei tempi, ecc. sono tutto il vostro lavoro e sono altrettanto importanti o più importanti delle parti di sviluppo reali. Questa non è un'inutile interruzione, fa parte del vostro lavoro. Queste persone pagano il vostro stipendio con i loro progetti. Inizia a trattarli con rispetto e a rispettare le loro esigenze. Una volta che sanno di potersi fidare di te per dir loro quando le cose saranno ritardate, ti daranno meno fastidio.

Dovreste rispondere con una distribuzione, non con un solo numero: qualcosa del tipo: “Si potrebbe fare la prossima settimana, se siamo fortunati”. Se siamo sfortunati, tra sei settimane. La migliore ipotesi è di circa due settimane". Questa risposta spesso avrà una reazione negativa. In tal caso, si può puntare a un numero qualsiasi di trattati di stima dei costi del software che mostrano una tale incertezza è comune e realistica.

Ho lavorato a un progetto simile a questo. Un compito che pensavo avrebbe richiesto due settimane e che alla fine si è concluso con un mese e mezzo.

Per fortuna sapevo di non avere un'adeguata conoscenza dei tempi necessari. Così, quando il mio capo me lo chiedeva al banco dei testimoni (lavoriamo con Agile development), gli davo il mio miglior preventivo e gli spiegavo perché lo pensavo. Anche se alla fine le mie stime si sono rivelate imprecise, gli ho dato quello che pensavo sarebbe stato necessario per ogni richiesta, ma mi sono assicurato che sapesse che era soggetta a cambiamenti.

In generale, l'onestà è la cosa migliore, sii sincero e tienilo informato. Ci sono momenti in cui non c'è una risposta chiara e tutto quello che possiamo fare è tenere i nostri capi il più possibile informati sulla questione.