Domanda:
Alla domanda su una data di completamento, qual è il modo migliore per dire "sarà fatto quando sarà finito"?
nobrandheroes
2014-11-04 22:25:30 UTC
view on stackexchange narkive permalink

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

È l'unico modo per dire "Posso" Non dico adesso, controlla con me a [data ora] "?

C'è un motivo per cui non puoi fornire almeno una stima approssimativa?
Spesso viene semplicemente sviato da altri progetti, costantemente sviato. Dire a qualcuno che sei stato sviato può essere interpretato come incolpare la persona che ti ha allontanato dal progetto. Tuttavia, non cerco una risposta ogni volta che ho un progetto, a volte un progetto non viene completato finché non viene completato.
@DavidK, sì, è davvero una pessima idea dare a qualcuno una stima improvvisata perché, sfortunatamente agli occhi dei PM e di molti altri, le "stime" diventano "scadenze".
Qualunque cosa tu faccia non dare mai date assolute - solo ore.
@user1220 Questo è il miglior consiglio del pezzo finora, e non mi è mai venuto in mente. Non darei un appuntamento a un cliente freelance, quindi immagino perché darlo a qualcuno che non fa parte del processo. Ottimo punto.
Una volta che lo hai chiarito in modo abbondante, fornisci la tua migliore stima data la quantità di informazioni che hai e non essere timido nel porre domande, non necessariamente come tattica di stallo, ma aiuta a chiarire e ti dà più tempo per fare la stima meglio. Quindi, come al solito, moltiplica per 2, 3, 4, qualunque cosa riesca a farla franca. E se premuto contro il muro per consegnare, fallo quando hai qualcosa di presentabile, dopodiché diventa un problema di manutenzione, non più sviluppo.
E quando il libro paga commette un errore e ti paga meno, consideri questa una risposta accettabile quando chiedi quando verrà corretto?
Questo è per me? Ho avuto lavori in cui questa è l'unica risposta che puoi accettare. Tuttavia, sembra che tu stia assumendo un certo contesto, come se questo fosse qualcosa da dire ogni volta che qualcuno chiede una data di completamento, quando tutto quello che ho chiesto erano suggerimenti per quando non è disponibile una data di completamento, o "È fatto quando è fatto."
Non fornire una stima, probabilmente risulterà che la persona che lo chiede farà la sua stima (qualcosa del tipo "beh, dice che è stato fatto quando è finito, ma non può ragionevolmente richiedere più di 6 mesi"), e ora tu avere un problema. Hai un'aspettativa sconosciuta su quando il tuo compito deve essere portato a termine che potrebbe essere ragionevole o altamente irragionevole, quando avresti potuto impostare tu stesso l'aspettativa semplicemente fornendo una stima.
Indirizza l'interrogante a Orson Welles: https://www.youtube.com/watch?v=oSs6DcA6dFI
Rispondi solo che sarà fatto in sei-otto settimane. Ha funzionato bene per lo stack overflow. Rif: http://meta.stackexchange.com/a/19514/153954
@teego1967 - dopo la raccolta e la revisione, quella diventa "le informazioni che hai", non è vero
@user1220 .. OK, pensavo mi avessi suggerito di rispondere sul posto con le informazioni attuali.
seriamente, se potessi doppiamente preferito questa domanda in modo che rimanga in cima a tutti i miei preferiti, lo farei. questa deve essere la domanda più grande mai posta su questo forum, considerando la sua applicabilità e semplicità
Questo è uno dei motivi per cui devi prima fare un proof-of-concept con quantità adeguate di nastro adesivo virtuale. Risolvi il problema ma senza tutto l'80-90% del codice che lo rende pronto per la produzione.
Ecco perché hai pianificazioni del progetto, usi le durate per le attività, quindi allochi le risorse e se ci lavori il 2% del tuo tempo, lo indichi e la data di completamento salirà alle stelle nel futuro.Quando richiesto, puoi fare riferimento al programma."Oh, vuoi che venga fatto prima? Quale di questi altri progetti posso mettere in attesa per completarlo?".
Correlati: [Come rispondere a "Quanto tempo ci vorrà?"quando in una nuova posizione di lavoro] (https://workplace.stackexchange.com/q/74589)
Undici risposte:
DJClayworth
2014-11-05 00:24:54 UTC
view on stackexchange narkive permalink

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.

Questa è probabilmente la migliore risposta finora, ma ecco la mia domanda per te. Se un lavoratore sa che è probabile che tu dia più lavoro, non correlato al compito, ma non cosa, quando, dove, perché, come, quale sarebbe la tua risposta preferita?
Questa risposta rafforza la mia convinzione che le stime debbano essere fornite in ore, non in date precise.
@nobrandheroes A rischio di ripetermi, dillo al richiedente. Possono, se possibile, negoziare con chiunque stabilisca il tuo programma per far salire il loro lavoro nell'elenco delle priorità, oppure possono accettare l'incertezza.
@user1220 Il problema è che non puoi pianificare un programma basato sul tuo impegno. Tuttavia, destreggiarsi nel completare priorità del genere non è qualcosa che uno sviluppatore dovrebbe fare. I loro compiti di manager.
Si, puoi. È compito del Primo Ministro determinare quando queste ore dovrebbero essere spese e capire la data corretta. Non lo sviluppatore non ha alcun ruolo nel determinare le priorità.
@user1220 Credo di averlo appena detto.
Ottimo, siamo d'accordo. Il PM * può * pianificare un programma basato sugli orari.
@DJClayworth Mi dispiace, hai frainteso la mia domanda. Ipoteticamente, vieni da me, dici che X deve essere fatto, dico 3 giorni. Domani, vieni da me, dì che Y deve essere fatto adesso, dico 3 giorni. Faccio Y. Vieni da me il giorno 3, chiedimi perché X non è finito. Supponi di non essere il mio diretto manager, ma trasmetti comunque le indicazioni (gerarchia molto superficiale), cosa vuoi sentire?
@nobrandheroes Probabilmente vale un'altra domanda. Un buon manager dovrebbe capire che se ti danno un'attività con priorità più alta, l'attività con priorità più bassa verrà ritardata. Ma nel caso tu non stia lavorando con un buon manager, la risposta alla richiesta di Y dovrebbe essere: "Posso fare Y in tre giorni. Ma ti rendi conto che X sarà ritardato di tre giorni se lo faccio, giusto?"
Vorrei controbattere dicendo che "la risposta meno utile che è possibile dare", essendo il destinatario di "quando sarà fatta?", È la domanda meno utile da porre a qualcuno. Per le stesse ragioni che dai.
@nicodemus13 Potrebbe non esserti utile, ma è una parte assolutamente essenziale dello sviluppo del software.
@DJClayworth: Non necessariamente, comunque il mio punto era che la domanda "quando sarà fatto?" È considerata una domanda perfettamente ragionevole, mentre "Quando è pronto" non lo è. In pratica quella domanda di solito significa qualcosa sulla falsariga di "perché non l'hai finita, mi sono già impegnato perché sia ​​pronta".
Non è questo il posto per discuterne. Se vuoi approfondire ulteriormente, crea una chat room e sarò felice di spiegarti.
Onestamente, vedendo le tue risposte e sapendo che sei un manager, sembra che a volte ti manchi il buon senso, perché a volte il lavoro può essere davvero imprevedibile, quindi potrebbe non essere possibile che la persona si adatti alle tue risposte date e considerando che la persona è irresponsabile se è solo onesto e dice che non può saperlo, è davvero un modo molto sbagliato di valutare il lavoratore.
@ArturasM In qualità di manager con 25 anni di esperienza come sviluppatore, il numero di volte in cui non ho letteralmente saputo nulla di quando avrò finito (esclusi i casi in cui dipendo dal lavoro di qualcun altro) è forse il doppio su migliaia di compiti. Puoi quasi sempre dire qualcosa. Anche dire "Ci vorrà più di un giorno, ma meno di un mese" è più utile che non dire nulla.
@DJClayworth Non hai mai avuto un caso in cui quando hai detto che ti aspettavi che ci volessero 2-3 settimane, ma ci sono voluti 3-4 mesi? O fallito affatto? Soprattutto nei casi in cui non puoi cambiare gli strumenti o ottenere altre risorse / aiuto esterno? Beh, forse ho a malapena esperienza, quindi forse ho un'impressione sbagliata.
@ArturasM Assolutamente questo accade. Ma quello che sto cercando di trasmettere è che quando realizzi che il tuo compito di 3 settimane richiederà 4 mesi, dici "ci vorranno 4 mesi", non "Non lo so". Se sei sfortunato e qualcuno ti chiede tra il momento in cui ti rendi conto che c'è un problema e prima che tu abbia capito quanto sia grave, è perfettamente OK dire "Sarò in grado di darti una stima migliore [a volte]".
Beh, sono contento che tu sia d'accordo almeno su questo. Immagino sia una questione di atteggiamento. Non sono un tipo il fan che dice quanto tempo ci vorrà se non ho un'idea, preferirei non dirlo affatto piuttosto che dire che ci vorranno 5 giorni, quindi dopo 4 correggerlo a 15 giorni e in seguito a pochi mesi. Forse devo cambiare il mio atteggiamento? Non so forse le persone accettano risposte sbagliate meglio della nuda verità che potrebbe essere brutta. A proposito assicurati di leggere la risposta "no comprende", sembra che abbia un'opinione più vicina alla mia immagino.
Telastyn
2014-11-05 00:40:48 UTC
view on stackexchange narkive permalink

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.

I principi alla base di queste risposte sono buoni, ma il tono passivo-aggressivo è un problema. Non sono sicuro che tu stia sostenendo queste risposte effettive o una risposta non aggressiva che trasmette le stesse informazioni.
@DJClayworth - come ho detto alla fine, queste sono tutte risposte in gran parte negative che non consiglio nella maggior parte delle situazioni. Non mi aspetto che possano essere resi non aggressivi.
L'indicazione del contesto è molto buona, anche +1 per la menzione di Blizzard. Immagino che alla fine dipenda dalla cultura aziendale o dall'indole di coloro con cui lavori.
Almeno il secondo può essere riformulato in una forma meno aggressiva senza compromettere molto il suo contenuto: ** Dopo aver ottenuto X, ci vorranno circa T **. Ovviamente questo presuppone che l'unico problema sia che stai aspettando X e che puoi ragionevolmente stimare T.
RemcoGerlich
2014-11-05 03:42:37 UTC
view on stackexchange narkive permalink

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.

Questo.E la risposta alla domanda successiva è "una giornata di lavoro interamente dedicata alla ricerca e alla stima".
Joe Strazzere
2014-11-04 23:35:34 UTC
view on stackexchange narkive permalink

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.

Quindi, secondo te, non è mai accettabile dire che non è possibile effettuare una stima accurata?
per accurato intendo dire che uno stakeholder ti ritiene responsabile. Idealmente, le persone in un'organizzazione sono consapevoli che le cose accadono, i progetti scivolano via via che le priorità cambiano, ma non è sempre così. Quindi, se il tuo CEO è incline a ricamare un membro del tuo team e, sapendo questo, chiede un preventivo, il tuo suggerimento è fornire una stima vaga, non importa cosa?
Essendo stato il destinatario di uno sviluppatore dicendo "sarà fatto quando sarà finito", ti assicuro che è un grosso problema. le persone potrebbero cercare di pianificare le cose in base a quando il lavoro sarà completato. Senza * nessuna idea * di quando sarà, rende impossibile un altro lavoro.
@DJClayworth ti aiuta in qualche modo se ti viene comunicata una data arbitraria, fai piani basati su quella data e in quella data scopri la realtà di "sarà fatto quando sarà finito"?
@Peteris Certo che no. Vedi la mia risposta per quali informazioni utili sarebbero.
Un PM lo sentirà come risposta a quando sarà fatto: "### #### # #### ## 3 mesi ### #### ## #####"
@teego1967 Nel peggiore dei casi, sì. Tranne che penso che "###" subito dopo "3 mesi" avrebbe dovuto essere "$$$",;)
Julia Hayward
2014-11-04 22:54:35 UTC
view on stackexchange narkive permalink

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.

Cosa suggerisci quando il tuo manager diretto si trova nella stessa posizione e lo stakeholder (la persona che chiede informazioni sul completamento) e il manager sono due persone non correlate. Sono nello sviluppo di software e le persone al vertice sembrano pensare che siamo maghi (a volte è vero).
A parte l'ovvio problema del tuo stakeholder che aggira il tuo manager e viene da te, non sono sicuro di cosa cambia: o dovresti sapere quanto tempo impiegheranno le tue attività, o dovresti sapere perché non lo sai e puoi fare riferimento lo stakeholder altrove.
Non è che non saprei quanto tempo impiegherebbero, è che non saprei quanto tempo impiegherebbe "compito + compito assegnato in modo casuale", ma devi comunque considerare le variabili inestimabili nelle tue stime.
Non sono d'accordo - puoi dire "il compito stesso richiederà X ma altri compiti non stimabili possono essere assegnati casualmente da Joe Y che hanno la priorità". OK, forse più diplomaticamente di così. Ma poi spetta a loro o passare a Joe Y per dare priorità al loro compito, o alzarsi e stare zitti.
Adam Davis
2014-11-05 19:05:27 UTC
view on stackexchange narkive permalink

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. "

Questa è una buona risposta, ma un problema con questo approccio è che, per implementarlo, il PO ha bisogno di a) priorità chiare e concordate per i compiti in arrivo, oppure b) autorità per assegnare le priorità da sole (e non soffrire se alcune attività vengono eliminate dalla priorità). Sfortunatamente, se le attività provengono da più fonti, è fin troppo probabile che tutti vorranno che le * loro * attività abbiano la priorità. [...]
... Passare il denaro (ad esempio "Prendilo con il manager * X *, decidono a cosa dare la priorità.") Può aiutare se c'è qualcuno a cui passarlo, ma se non è un'opzione, nel peggiore dei casi la coda delle priorità può finire per degenerare in una coda last-in-first-out (con tutti che chiedono che ogni nuova attività prevenga tutte quelle precedenti) in cui le attività vengono completate rapidamente o per niente. Certo, questo è davvero un segno di una disfunzione organizzativa e / o di risorse insufficienti, ma vale la pena tenere presente che tali situazioni esistono.
HLGEM
2014-11-04 23:24:47 UTC
view on stackexchange narkive permalink

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.

Oh, e nelle date, non dimenticare di considerare le ferie ei giorni di ferie pianificati, in modo da non rimanere bloccato perché hai avuto meno giorni di lavoro di quelli che avevi previsto.
Non ho problemi con le mie scadenze con il mio manager, faccio parte del dipartimento IT di un'azienda e la maggior parte delle attività proviene da persone abbastanza lontane dal processo. Inoltre, non rispondo con "qualunque cosa", sono abbastanza abile nello stimare le scadenze, ma non ho il linguaggio per gestire le aspettative delle persone che non hanno aspettative gestibili.
John Connell
2014-11-05 04:13:36 UTC
view on stackexchange narkive permalink

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.

user37746
2014-11-05 23:14:55 UTC
view on stackexchange narkive permalink

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!"

Che ne dici di una bacheca kanban per ogni dipendente? Quindi qualcuno potrebbe semplicemente guardare la lavagna e rendersi conto che la loro richiesta dovrà fare i conti con altre N richieste. Ovviamente, rendila un'applicazione per computer, non una scheda fisica. I premier sarebbero responsabili di questo.
user8365
2014-11-06 00:05:11 UTC
view on stackexchange narkive permalink

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.

FreakyDan
2014-11-15 04:43:57 UTC
view on stackexchange narkive permalink

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.

Ciò non aggiunge nulla di sostanziale alle altre risposte già fornite


ⓘ
Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...