Perché non fai mai tanto quanto avevi pianificato? [chiuso]


26

Comincio sempre la giornata pensando "Lo farò facilmente entro la fine della giornata" e stabilirò quello che sembra un obiettivo realistico.

Quindi perché non l'ho mai colpito? L'attività finisce sempre impiegando 3 volte di più a causa di bug imprevisti, modifiche dell'ultimo minuto ecc.

Sono solo io? Non riesco a prevedere meglio cosa si può fare in un giorno.


8
Non sei solo tu. Vedi la legge di Hofstadter .
Peter Boughton,

18
Perché stai perdendo tempo a fare domande su P.SE, invece di fare il tuo lavoro :) :)
Jas

2
La prossima volta che

3
Non ho intenzione di fare nulla e vinco sempre. Ridimensiono tutti i miei bug come infinito, quindi la mia velocità è sempre indefinita.
Giobbe

1
Il mio vecchio capo diceva che le mie citazioni di tempo erano in anni cat . Penso che abbia appena spostato ogni citazione di un ordine di grandezza. Ore -> Giorni; Giorni -> Settimane; Settimane -> Mesi; Mesi -> Rimborso cliente.
Orbling

Risposte:


17

Perché non ti è mai stato insegnato come pianificare.

Pianificare è un'abilità , proprio come scrivere codice o scrivere. Ma in qualche modo è escluso da quasi tutti i programmi.

Deve essere appreso e messo in pratica e le tue stime delle tue capacità devono essere continuamente aggiornate. Ecco perché le pratiche di lavoro come Agile enfatizzano la misurazione del lavoro effettivo passato e il confronto con le stime, in modo da poter migliorare le capacità di pianificazione.

Come altri hanno già detto, devi tenere conto non solo del compito, ma di tutti i suoi predecessori, dei compiti relativi (ad esempio, imparare a fare X) e devi essere consapevole dei tuoi preconcetti mentali interni che ti impediranno di tenendo correttamente conto del modo in cui lavori effettivamente.

Allenati e, chissà, potresti migliorare.


8
Oltre a non pianificare per tutti i piccoli mangiatori di tempo in un giorno che rendono difficile la pianificazione, la pianificazione è anche un'abilità che non è divertente da imparare. Quando commetti un errore di codifica, ricevi un bug, lo risolvi e impari una lezione. Quando viene visualizzato un errore di pianificazione, SEI NON RIUSCITO !!! Il mancato rispetto delle scadenze ti fa stare male e ti fa sentire un fallimento, quindi molte persone non pianificano. Per contrastare questo, ho iniziato a tenere liste di cose da fare molto dettagliate e dettagliate, ma mi concedo sempre stupide quantità di tempo extra. Poi mi sento davvero realizzato perché sono sempre sotto il budget in tempo!
CodexArcanum,

@Codex, ottimo punto. Esistono modi per trasformare "errori di pianificazione" in qualcosa in cui è possibile "programmare una correzione". Ogni fallimento della pianificazione è un'opportunità per imparare. Esamina una tecnica come Root Cause Analysis per capire il contesto del fallimento, in modo da poter pianificare meglio la prossima volta e introdurre contromisure specifiche che elimineranno il fallimento in futuro.
Alex Feinman,

1
Non solo non è divertente da imparare, spesso sembra una perdita di tempo. Lo chiamo "metawork": passare il tempo ad analizzare o organizzare il tuo corpo di lavoro. Quando ci sono molte cose da fare, il meta-lavoro può farti sentire come se stessi costruendo una caverna isolata sotto la valanga invece di cercare di scavare te stesso, ma davvero quello che stai facendo è affilare i tuoi strumenti in preparazione per il lavoro da svolgere.
nlawalker,

Al momento della stesura di questo articolo, ci sono 11 persone che hanno votato a favore di questa risposta. Ciò significa che ci sono 11 persone che si illudono che in realtà esiste qualcosa come un piano che stimerà correttamente il tempo richiesto.
Robert Harvey,

@nlawalker: Non è divertente da imparare? Se non ho imparato qualcosa di nuovo in un giorno, l'inferno in ogni ora del giorno di veglia, considero il giorno un fallimento.
Orbling

26

Difficile credere che nessuno abbia ancora menzionato la legge di Hofstadter .

Penso che la vera risposta sia che la tua pianificazione assume sempre uno scenario ottimale, come se tutto funzionasse immediatamente e non si fosse mai verificata alcuna interruzione. Nella vita reale, inizi a scrivere codice, poi squilla il telefono, sei distratto per 5 minuti, passi altri 15 minuti su stackoverflow o programmatori.stackexchange per calmarti e rifocalizzare, fare un po 'di codice, imbatterti in un comportamento inaspettato di alcune API, fare alcuni googling, passare 2 ore per testare le possibili soluzioni ecc.

In altre parole: il "caso migliore" accade solo nei tuoi sogni.


1
Vedi il commento di @Peter Broughton (5 ore prima della tua risposta!).
ChrisF

Sì, hai ragione, ChrisF. Deve aver perso quello.
user281377

+1. Questo è essenzialmente il motivo per cui seguo la regola "fai una stima ragionevole, quindi raddoppia". E anche allora spesso ci vuole più tempo. Uno dei miei docenti alla uni era solito dire "triplicalo". Quindi immagino che sto bene. :)
Bobby Tables,

10

Ogni programmatore, una volta ogni tanto, ha una giornata perfetta. Ti svegli 5 minuti prima che la sveglia suona alla grande. La colazione è fatta e sul bancone, insieme al caffè fresco, così puoi prendere qualcosa ed uscire dalla porta. Durante il tuo tragitto giornaliero raggiungi ogni semaforo verde e il traffico sembra essere particolarmente leggero. Contemplando il giorno che ci aspetta, sei in grado di comprendere appieno il design e le conseguenze del compito che ti attende, che è stato ben pianificato con requisiti fermi.

Ti metti al lavoro e scopri di non avere email importanti, messaggi di posta vocale in attesa e che i tuoi colleghi sono fuori o in riunioni a cui non devi partecipare. Accendi il tuo editor e sei immediatamente nella zona, puoi sentire la struttura del codice e vedere le strutture dei dati e gli algoritmi adattarsi al loro posto in un insieme bello e coeso. I pensieri scorrono attraverso le tue mani verso la tastiera, inserendo un codice perfettamente formato che è elegante, mantenibile e senza alcun bug da trovare.

Durante il giorno in cui lavori senza interruzioni, l'ufficio è silenzioso e sei così concentrato che non sei mai tentato di passare il tempo a recuperare notizie, blog, ecc. Quando compili ed esegui i test, scopri che tutto funziona senza intoppi, ovviamente sapevi che sarebbe successo e alla fine della giornata ti impegni senza conflitti. Guardando l'orologio uscendo ti rendi conto di aver impiegato 12 ore e mi è sembrata una breve sessione di programmazione di 20 minuti.

Quel giorno, quel giorno perfetto, è quello che assumiamo che avremo ogni volta che dovremo stimare qualcosa.


7

Non dimenticare le riunioni, le persone che ti interrompono, ecc. I bug che non vengono esaminati sono difficili da prevedere, ma nel tempo dovresti essere in grado di avere un'idea di quanti bug hai scoperto in un determinato periodo di tempo. Quando si stima quanto tempo impiegherà qualcosa, è necessario considerare il contesto. Vale a dire "Supponendo che non vengo interrotto o scoperto bug, dovrei essere in grado di fare qualcosa in X tempo"

Come un piccolo esercizio per te stesso, considera di fare quanto segue:

  • All'inizio della giornata, scrivi qual è il tuo obiettivo e il tempo stimato per raggiungerlo.
  • Ad ogni interruzione (incontro, collega, ecc.), Annotare la durata approssimativa del tempo
  • Ogni volta che trovi un nuovo bug, annotalo come un'attività non pianificata insieme a circa il tempo impiegato per svilupparlo.

Scoprirai che alcuni schemi iniziano a emergere e puoi pianificare di conseguenza per quelli. Ogni volta che comunichi al tuo manager un tempo stimato di completamento, basta avvertirlo nel primo paragrafo. Potresti essere sorpreso dalla precisione del tuo preventivo quando rimuovi il tempo impiegato per interruzioni e bug.

Quando stai lavorando a un elenco di bug o a un elenco di funzionalità, probabilmente stai già facendo il primo e il terzo punto elenco. Quel piccolo esercizio ti dirà dove sta andando tutto il tuo tempo e potresti essere sorpreso dalla risposta.


+1 Se annotassi ogni interruzione ricevuta, a parte la necessità di ordinare più volte la cancelleria, perderei una notevole parte della giornata con la notazione.
Orbling

3

Potresti voler espandere il tuo periodo di prevedibilità. Riesci a determinare cosa puoi fare in una settimana? Se ogni attività richiede tre volte più tempo di quanto pensassi, sembra che tu sia abbastanza coerente da essere prevedibile. Hai solo bisogno di regolare di 3x;)


+1 Coerentemente l'errore è ancora coerente! Risultato.
Orbling

2

perché hai semplicemente ignorato il fatto che potrebbero verificarsi bug imprevisti.

Fai delle statistiche sul tempo medio impiegato per i bug e tieni conto di quel tempo quando fai il tuo piano.


1

Perché non stai pianificando correttamente. Ahi .

Scommetto che se mantieni un totale parziale di quanto scivoli (anche su carta), quindi aggiusta le tue stime di quella%, sarai in grado di pianificare correttamente.

FWIW, il software è notoriamente difficile da stimare. McConnell (di fama di Code Complete) ne ha addirittura pubblicato un libro.


1

Qualcosa che mi trovo spesso a fare è essere distratto da cose casuali non correlate a ciò che sto facendo. Un elenco di cose da fare può essere d'aiuto; quando pensi a qualcosa, scrivilo e fallo dopo aver finito ciò che ti sta di fronte.



1

Matrice urgente / importante può valere la pena considerare di vedere dove va la tua giornata. È su cose urgenti ma non importanti come riunioni e interruzioni non preparate? È su cose urgenti e importanti che non sapevi all'inizio della giornata? Solo un esercizio per considerare dove va il tuo tempo.


Tenderei a pensare che le cose più interessanti siano importanti, altrimenti perché sono interessanti? Solo un pensiero.


1
Il mio problema con quella tecnica è sempre stato la "terza dimensione" invisibile: quanto è interessante qualcosa. Sfortunatamente, per me l'interesse supera ogni volta l'urgenza e l'importanza.
giorno

0

Questa è una buona domanda e una su cui continuo a riflettere. Tendo a pensarlo

  • è molto facile giudicare erroneamente la quantità di lavoro che X richiederà.
  • Non ho mai pianificato bug o viaggi nel bollitore.
  • o fai molto con poco codice o nulla viene fatto molto e sembra che non ci sia nulla in mezzo.
  • a volte perdi la tua "zona", a volte le cose devono riflettere.
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.