Come affrontare i problemi di tempo cronico?

StackOverflow https://stackoverflow.com/questions/612892

Domanda

Ho uno sviluppatore nel mio staff che cronicamente supera scadenze e stime. Su diversi progetti dell'ultima settimana o due ogni giorno ascolto "Dovrebbe essere fatto entro la fine della giornata". Questo sviluppatore fa un buon lavoro.

Gli ho già parlato dei suoi problemi. Sembra sinceramente frustrato e seccato su cosa fare per correggerli.

Le mie domande sono:

  1. Quali tipi di punizioni per il superamento di una scadenza sono efficaci?
  2. In che modo posso costringere questo dipendente a sorvegliare da solo le sue azioni (stime temporali, ecc.)?

Aggiorna : Sulla base delle risposte; ecco cosa ho capito.

  1. La punizione è una cattiva idea.
  2. È naturale che un dipendente non sia in grado di risolvere i problemi di stima senza intervento.
  3. Non fissare scadenze a meno che non ci siano conseguenze aziendali (contratto perso) per non essere state rispettate entro tale termine.
  4. Utilizza i metodi disponibili (Agile, l'elenco di controllo di Joel) per aiutare lo sviluppatore a stimare meglio.

Grazie per i collegamenti e le informazioni. Grazie anche per aver aggiornato il mio pensiero.

È stato utile?

Soluzione

Non credo che il problema sia che manchi queste scadenze.

Penso che abbia un vero problema nella stima del tempo necessario per completare un'attività.

Fagli iniziare a tenere un diario di ciò che dice che ci vorrà un'attività e di quanto tempo effettivamente ha impiegato per completare l'attività. Alla fine, questo diario diventerà una sorta di guida per lui per creare stime migliori. Una volta che diventa più bravo a stimare, non dovrebbe sentirsi affrettato o tormentato.

Altri suggerimenti

C'è un interessante articolo di Joel Spolsky: Pianificazione basata sulle prove

  

1) Rompi "er

     

Quando vedo un programma misurato in giorni o addirittura settimane, so che non funzionerà. Devi suddividere il tuo programma in attività molto piccole che possono essere misurate in ore. Niente più di 16 ore.

     

Questo ti obbliga a capire cosa stai per fare. Scrivi subroutine foo. Crea questa finestra di dialogo. Analizza il file Fizzbott. Le attività di sviluppo individuali sono facili da stimare, perché in precedenza hai scritto subroutine, creato finestre di dialogo e file analizzati.

     

Se sei sciatto e scegli grandi attività di tre settimane (ad esempio, "Implementa l'editor fotografico Ajax"), allora non hai pensato a quello che stai per fare. In dettaglio. Passo dopo passo. E quando non hai pensato a cosa farai, non puoi sapere quanto tempo ci vorrà.

     

L'impostazione di un massimo di 16 ore ti costringe a progettare questa dannata funzione. Se hai una funzione di tre settimane ondulata a mano chiamata "Editor di foto Ajax" senza un design dettagliato, mi dispiace essere quello di romperti ma sei ufficialmente condannato. Non hai mai pensato ai passi che farà e sicuramente ne dimenticherai molti.

Il punto principale è che lui (e te) dovremmo imparare dai suoi errori e tenerne conto nella prossima stima.

Inoltre, se sei uno sviluppatore, farei una revisione periodica del codice alla fine della giornata per avere una visione migliore del suo processo di sviluppo.

E, naturalmente, piccole iterazioni e maggiore granularità con le attività. Impostare la durata massima dell'attività su 1 giorno. Questa è la regola che abbiamo.

Se la tua prima domanda è che tipo di punizioni prendere in considerazione Penso che tu abbia subito un perdente. Se ritieni che faccia un buon lavoro, potresti dover esaminare le scadenze / le stime e vedere se erano realistiche in primo luogo. Chi li ha impostati, se lo sviluppatore in questione non era coinvolto, questo potrebbe essere parte del problema.

Sono d'accordo con @OTisler che accoppiare la programmazione e possibilmente una regolare revisione dei progressi di fine giornata con te stesso può aiutarlo a superare ... anche se se le scadenze / stime non fossero realistiche per iniziare con quello non è dove si trova il tuo problema.

Un monitoraggio più attento su alcune attività specifiche dovrebbe evidenziare la posizione di eventuali problemi.

  

Che tipo di punizioni per il passaggio   una scadenza è efficace?

Nessuno. Se lo fai arrabbiare, non farà il lavoro o troverà un altro lavoro. Dovresti aiutarlo a capire perché le sue stime sono fuori. C'è un libro di Steve McConnell sul fare stime. vorrei iniziare lì.

  

In quali modi posso coerenza   impiegato per sorvegliare le sue azioni (tempo   stime, ecc.) stesso?

Aiutandolo a trovare il modo giusto di fare stime.

Innanzitutto, assicurati di essere cristallino nelle tue esigenze.

Odio dirlo, ma nella mia esperienza, le scadenze saltate sono altrettanto spesso una questione di requisiti poco chiari o specifiche deboli da parte di un supervisore. La prima cosa da fare è assicurarsi che il problema non sia originato o esacerbato da te.

Inoltre, assicurati che i tuoi requisiti siano realistici, così come le sue stime.

Assicurati che le tue stesse aspettative non lo stiano spingendo a fare stime non realistiche al fine di soddisfare requisiti non realistici.

Ricorda, fai i requisiti, ma lo sviluppatore fa SEMPRE le stime e non dovrebbe essere influenzato da "possiamo farlo più velocemente" a meno che non si specifichi anche la funzionalità da eliminare.

Quindi, assicurati che stia monitorando accuratamente il suo tempo / le sue attività, in modo da poter avere una buona visione di ciò che sta succedendo con il progetto.

Questo processo mostrerà la mancanza di un adeguato monitoraggio del tempo / attività, che potrebbe finire per essere il primo passo per il miglioramento. Se non riesci a vedere dopo il progetto quanto tempo ha impiegato un determinato articolo, questa è probabilmente la causa del problema proprio lì - non abbastanza definizione nella stima, o mancante "dipendenza". attività che vengono scoperte a metà progetto, ma mai stimate.

DEVI sapere quanto tempo è stato dedicato a fare cosa, accuratamente, prima di scoprire dove si trovava il brivido o cosa si può fare al riguardo.

Quindi, vedi dove le sue stime non riescono e scopri perché. Esamina una stima di un progetto saltato, trasformalo in un progetto stesso: un problema da risolvere.

Dopo aver determinato che le sue stime sono effettivamente la fonte del problema, ripassa una stima che è andata oltre a lui, e forse a un altro sviluppatore, e scopri perché.

Questo ti aiuterà a capire qual è la causa del problema. Una solida comprensione del problema sarà probabilmente la soluzione effettiva.

Infine, se in realtà raggiungi un punto in cui devi provare punizione o coercizione, è tempo di licenziarlo e ricominciare da capo.

La punizione e la coercizione sono le risposte appropriate alle infrazioni intenzionali in determinate situazioni.

Tuttavia, se questo sviluppatore sta attivamente cercando di fare un buon lavoro, peggioreresti la situazione solo generando atteggiamento negativo e frustrazione.

Se il problema non può essere risolto e sei sicuro che sia il problema con lui e non tu, allora è il momento di licenziarlo e ottenere uno sviluppatore in grado di rispettare le scadenze. Un grande lavoro non significa molto quando i tuoi costi vengono fatti saltare e il profitto esce dalla finestra.

Va ??bene, questo è abbastanza comune - gli sviluppatori sono ottimisti. È compito del management occuparsene. Se qualcuno dovrebbe essere punito, è il manager (tu?)

Sono contento che tu almeno ti abbia chiesto, sembra che tu abbia ottenuto delle buone risposte da questa lista, spero che ti aiutino e trovi un modo per implementare effettivamente alcune di quelle che funzionano.

Quando ero giovane, il mio primo bravo manager ha affrontato la questione in questo modo:

Prima di tutto, mi ha fatto venire in mente un elenco dettagliato - suddividendo le attività in ore e stimando ognuna con una stima molto liberale - nessun periodo dovrebbe essere inferiore a 4 ore indipendentemente da quanto piccola fosse l'attività .

Poi li guardò e mi disse di raddoppiare tutte le mie stime. (Gli sviluppatori, in particolare gli sviluppatori più giovani, non pensano al fatto che sei produttivo solo per circa 1/2 della giornata, se sei fortunato - e metà di ciò viene speso in cose che non ti aspettavi di dover fare).

Quindi, prima di creare il suo programma, ha raddoppiato tutte le mie stime (senza dirmelo).

Li ha trasformati in questo modo indipendentemente dai requisiti di pianificazione dall'alto. Un buon manager dovrebbe rendersi conto che dire che deve essere fatto in 2 giorni, non lo rende possibile.

Man mano che miglioravo nella stima, entrambi abbiamo notato e adattato di conseguenza.

Un lavoro da manager non è solo quello di creare un progetto, è quello di costruire un team. Molto spesso ciò richiederà una formazione di qualche tipo. Questo è anche il motivo per cui un manager di ingegneria che non è un ingegnere è inaccettabile, non possono davvero aiutare con questo tipo di cose.

Il fallimento di un progetto o programma non è MAI VIRTUALMENTE MAI colpa dello sviluppatore (tranne in alcuni casi cronici in cui non è realmente riparabile o di alcun valore e deve essere licenziato). Il manager ha preso decisioni sbagliate assumendo lo sviluppatore, fidandosi di lui, gestendolo o dando il personale al progetto.

E davvero, cos'è comunque un difetto? Suppongo che se il manager non è molto bravo a realizzare il progetto, avrà bisogno di qualcuno su cui puntare ... Se il suo manager è bravo, ti chiederà perché è arrivato così lontano, cosa hai fatto per risolverlo , ecc.

Assumere un manager sta assumendo qualcuno per risolvere i problemi. Per rendere produttivi gli sviluppatori. Se non riesce a renderli produttivi, non è la persona giusta.

  

Che tipo di punizioni per il passaggio   una scadenza è efficace?

Hai dichiarato il punto e l'hai perso. L'ovvia punizione per aver superato una scadenza è la morte. Se lo sviluppatore è ancora vivo dopo aver superato una scadenza, la "scadenza". ovviamente non era una vera scadenza. Pensi che sia divertente mettere gli sviluppatori sotto pressione usando il linguaggio marziale?

Correggi la tua formulazione.

Motivazione

Prima di tutto: leggi Peopleware

Avanti. Perché pensi che la punizione sarà un modo efficace per gestire le persone che dovrebbero essere creative? Penso che tu debba ripensare l'intero approccio al management rispetto al team.

A mio avviso, i gestori per primi, e soprattutto, hanno il compito di assicurarsi che gli sviluppatori possano essere creativi e produttivi. Non che siano produttivi. C'è una grande differenza in quelle piccole parole. Per essere creativi hai bisogno di un ambiente sicuro. Essendo costantemente sotto pressione da entrambe le scadenze e le minacce di punizione si crea l'esatto contrario di sicuro.

Inoltre, come manager, hai bisogno di informazioni precise su cui basare le decisioni. Ciò richiede anche un ambiente sicuro. Se esiste il rischio di una punizione per essere onesto e schietto, si ha la certezza di ricevere bugie e assenza di informazioni. Una base molto pericolosa da cui prendere decisioni.

Le stime

Come indicato, le stime sono stime. Nel nostro team non facciamo alcuna stima individuale, facciamo stime come squadra. (Sono un po 'riluttante a chiamare ciò che facciamo Scrum, ma la maggior parte cerca di emulare se non di meno) Penso che questo sia davvero un ottimo modo per fare stime: ogni membro del team riceve un mazzo di carte composto da numeri 0 , 1 / 2,1,3,5,8,13,20,40,60,100 e quando stimano un compito ogni sviluppatore prende una carta (le carte sono nascoste fino a quando tutti hanno scelto una carta per evitare di influenzare le stime) e la media di le carte selezionate vengono prese come stima.

Nota come i numeri diventano progressivamente meno precisi. Questo è in base alla progettazione perché le stime di grandi dimensioni sono necessariamente meno accurate.

Per il nostro team abbiamo scelto di utilizzare l'unità "giorni uomo ideali" per stime. Fino a quando qualcuno di noi può ricordare che non è ancora accaduto un giorno ideale, ma è una buona base quando sai come tradurre i giorni del calendario in "giorni ideali dell'uomo".

Come prescrive Scrum, lo sviluppo avviene in sprint di due settimane dopo le quali la nuova versione viene distribuita nell'ambiente di produzione. Dopo ogni sprint prendiamo la somma delle stime delle attività completate e la dividiamo per i giorni previsti per lo sprint. Questo fattore è quindi la base per stimare quante "giornate uomo ideali" la squadra può trascorrere in un periodo di due settimane.

Gli elementi di lavoro effettivi eseguiti da un singolo sviluppatore non richiedono una stima. La prima approssimazione è sempre 1/2 - 1 giorno per il completamento. Se questa stima risulta essere falsa, basta prendere un collega sviluppatore e farlo insieme per farlo. Oppure puoi scomporre l'elemento di lavoro in attività più piccole in modo che possa essere distribuito meglio.

Imposta Pietre miliari e prova Agile come suggerito da @OTisler.

Non credo che dovresti punirlo. Fagli capire come fare stime accurate.

Come capo squadra ho fatto dire ai membri del mio team che non sarà un problema "quot" per terminare la funzione X entro la scadenza. Quindi di solito mi siedo con loro e ripasso quali attività e sotto-attività ritengo debbano essere fatte per completare la funzione e per quanto tempo lo sviluppatore pensa che ciascuna richiederà.

Dopo aver fatto questo esercizio e aver sommato tutte le stime dell'attività e delle attività secondarie, ci vorrà inevitabilmente molto più tempo di quanto lo sviluppatore pensi nella loro stima originale. Di solito devo solo fare questo esercizio con loro alcune volte prima che inizino a fare stime più accurate.

Quello che mi stupisce è che hai solo uno di questi ragazzi.

Gli ingegneri sono orribili nel stimare quanto tempo impiegherà qualcosa. Scommetto che se osservi attentamente le stime dei tuoi altri sviluppatori, troverai molte imbottiture. A volte il riempimento non è necessario, ma l'attività si espande per riempire comunque il tempo disponibile.

La soluzione a questo è cambiare il modo in cui fai le stime - per tutti. Gli sviluppatori possono essere pessimi nel stimare il tempo assoluto, ma sono piuttosto bravi nel momento relativo. Quindi lunedì, invece di " quanto tempo ci vorrà per aggiungere un whoosiwhatsit?, & Quot; chiedi " cosa puoi fare sul whoosiwhatsit in meno di una settimana? " Questo diventa il loro compito per la settimana.

Il lunedì seguente guardi come è andata. " Beh, ho installato il floogle in due giorni, ma si è scoperto che ha influito sul mcphee ... quindi questa settimana ho bisogno di disaccoppiare quei ragazzi in modo che i file whoosiwhatsit non vengano sovrascritti. " Ok, c'è il loro compito per la settimana.

Potresti pensare che non aiuterà, perché non sai ancora quando il whoosiwhatsit sarà pronto. È vero. Hai due scelte qui:

Se hai bisogno di una scadenza, allora devi forzare il tuo sviluppatore errante a riempire le sue stime come tutti gli altri. Non gli ci vorrà molto per capire, e in pochissimo tempo impiegherà "2 settimane". per scrivere qualcosa che avrebbe dovuto richiedere un giorno.

L'altra scelta è quella di scambiare le stime fittizie per una maggiore visibilità. A lungo termine questo approccio ti rende ingegneri più produttivi e molto più felici.

Quindi lo sviluppatore fa un buon lavoro, ma è scarso nel stimare il tempo di consegna? Non sono sicuro che tu abbia ancora una situazione di punizione nelle tue mani.

Forse andando avanti per un po 'di tempo, fagli guidare attraverso il suo processo per stimare un punto di consegna. Questa può essere un'opportunità per chiedergli perché i passaggi X, Y e Z richiedono un certo periodo di tempo. Potrebbe trovarsi a rivedere le sue stime semplicemente facendo l'esercizio a un ritmo quasi certamente più lento.

chiediti questo: cosa comporta il tuo lavoro?

Se stai semplicemente passando ciecamente stime dagli sviluppatori (che conosci non sono in grado di fornire buone stime) sulla linea di gestione e non decidi tu stesso se tale stima è realizzabile, allora non stai facendo il tuo lavoro.

Prova a pensare in termini di "valore aggiunto" (Uno dei miei vecchi datori di lavoro ha usato molto quel termine e lo odiavo, ma probabilmente funziona per te in questa situazione). Quale valore stai aggiungendo? Se stai solo passando cose in entrambe le direzioni tra i dirigenti e gli sviluppatori, alla fine non stai guadagnando i tuoi soldi. Potresti essere rimosso e nulla cambierebbe.

Il miglior allenatore che abbia mai avuto è stato uno che ha esaminato una serie di requisiti datigli da un'altra squadra e ha detto loro che quasi un terzo di loro era toro e li aveva rimossi, prima ancora di vedere elenco. Il peggiore che mi avessi mai fatto scrivere tutta questa documentazione extra di tipo gestionale che nessuno degli altri manager che mi avessi mai chiesto di fare (ho davvero avuto l'impressione che stavo letteralmente facendo il suo lavoro per lui), no mi dà persino le date di scadenza del progetto, e difficilmente si presenta al lavoro. Erano entrambi nella stessa compagnia, abbastanza stranamente.

90 ore è una scadenza comune breve del progetto. Il modo più semplice è invece di stimare "il tuo tempo", ne misuri un altro. I programmatori di computer non dovrebbero fare stime di tempo per i loro progetti poiché le prove mostrano che il calcolo del proprio tempo comporta un errore più grande rispetto all'osservazione di un altro.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top