È normale che il programmatore lavori simultaneamente su più progetti [chiuso]

Non sono affatto d'accordo quando la gente dice "sì, il multitasking è normale"

È non normale! Niente affatto, è molto innaturale per uno sviluppatore multi-task in diversi progetti (spiegherò più avanti). D'altra parte il multi-tasking è molto comune tra gli sviluppatori. Questo è sicuramente qualcosa a cui dovresti abituarti. Quindi la vera risposta alla tua domanda è: come multi-task?

Prima di tutto, non dovresti semplicemente accettare il tuo destino perché "sei un impiegato eccellente" e questo significa che devi svolgere più compiti di quanti tu possa gestire. Niente affatto, non lo fai. A volte le persone hanno più compiti perché non c'è nessun altro. A volte i manager non sono in grado di gestire il loro lavoro in modo che delegano, rafforzando il multitasking nel loro team perché loro non sono in grado di gestire correttamente la pianificazione del progetto. Quindi dovresti assolutamente provare a determinare se ti viene chiesto di eseguire più task perché fa parte del tuo lavoro o perché altre persone sono incompetenti . Ad ogni modo, puoi giudicare da solo se è accettabile o meno. Se non ti senti a tuo agio [con il tuo lavoro], ci sono altri posti dove puoi trovare lavoro. [Tu, lo sviluppatore, sei la merce. I datori di lavoro lo sanno e pregano che non te ne accorga mai.]

Ora, riguardo al multi-tasking, non sono d'accordo al 100% quando la gente dice "sì, passa semplicemente avanti e indietro e assicurati di fare la stessa quantità su ogni progetto". Scusa, ma questo è un pessimo consiglio.

Per prima cosa devi capire come funziona il tuo cervello quando sviluppi un software (so che ci sono altri compiti in gioco ma concentriamoci su quello). Devi prima essere "cablato", il che significa che devi concentrarti molto e mettere la tua mente in una posizione in cui hai tutto mappato nella tua testa. Tutti i nomi di variabili e metodi, il flusso di lavoro del codice, il modello a oggetti, i thread affiancati, tutto. Di solito mi bastano 15 o 20 minuti per arrivare "nella zona".

Quando arrivi a quello stato stai davvero volando e scrivendo codice come se stessi andando in bicicletta. Nel momento in cui vieni interrotto puoi perdere tutto. Se l'interruzione è abbastanza lunga (5, 10 forse 30 minuti) perderai questo stato d'animo e dovrai ricominciare da capo.

Quindi il multitasking è terribile perché ti costringe a lasciare "la zona" e passare a qualcos'altro. Se si cambia continuamente significa che non si è produttivi perché ogni volta che si passa a una nuova attività / progetto è necessario perdere quei 15-20 minuti per rientrare nella zona (senza menzionare che scioglie lentamente il cervello).

È come il multi-threading: ad un certo punto il costo di cambiare il contesto del thread ogni paio di cicli è troppo alto, quindi la CPU finisce per passare più tempo a cambiare contesto rispetto all'esecuzione delle attività reali.

Consiglio vivamente di leggere un articolo di Joel Spolsky su questo argomento:

link

Quindi il mio consiglio è: prova ad imparare come (non) multi-task perché è davvero comune. Ma assicurati anche di essere a tuo agio nel farlo. Alcune persone possono impiegare più tempo per concentrarsi e soffriranno più di altre in caso di multi-tasking; e va bene anche questo. Non è perché è comune che dovrebbe essere considerato normale.

Joel ha detto bene quando ha detto:

In fact, the real lesson from all this is that you should never let people work on more than one thing at once. Make sure they know what it is. Good managers see their responsibility as removing obstacles so that people can focus on one thing and really get it done.

Sì, è prevedibile. E accolto con favore.

Ci sono un paio di modi per osservare questo:

1. Ci si aspetta un multi-task ed è quasi impossibile concentrarsi. Ciò si traduce in processi ingegneristici non ottimali, confusione occasionale quando si passa avanti e indietro, una sensazione di sfruttamento, frustrazione, stress, ecc. Questo è tutto negativo, naturalmente; tuttavia,

2. Ti stai affidando a più progetti, che riflettono bene i risultati che produci e la fiducia che il tuo datore di lavoro ha nelle tue capacità. È un'opportunità per mostrare loro che la fiducia è garantita.

Il mio consiglio è di sviluppare un giudizio sobrio di quali attività richiedono la tua attenzione immediata e quali possono attendere. A volte la risposta è che nessuno dei due può aspettare ed è necessario adottare un approccio creativo per fornire risultati (un po 'per il progetto A, poi un po' per il progetto B, quindi risciacquo e ripetizione). Coltiva le competenze per prosperare in questo tipo di situazione.

Normalmente (anche se non sempre), questo sarà ricompensato con più responsabilità, più progetti da destreggiarsi e più aspettative. Ad un certo punto sarai in grado, e ci si aspetta, di delegare parte di questo lavoro. È una misura di successo.

Quindi, anche se le tue crescenti capacità di giocoleria sono sfruttate solo dalla tua attuale compagnia, queste sono buone abilità da avere e ti serviranno bene nella tua carriera.

Per quel che vale, di solito lavoro su un grande progetto, uno più piccolo, la manutenzione e il supporto di vecchi progetti e la gestione di almeno un altro. È frustrante, confusionario, noioso e sono molto grato.

Sì! Questo è completamente "normale" / normale quando lavori su una società di servizi xD

Inoltre, se collabori con progetti open source, questa è la regola

Forse non lo è e lo stato ideale, ma è il pane di tutti i giorni.

È comune. Ma non va bene, per le ragioni che hai delineato. Cambiare contesto richiede produttività, quindi se puoi, prova a lavorare su un progetto per una grande quantità di tempo, ad es. un giorno.

Lavoro attivamente su 2 o 3 progetti diversi ogni giorno. E mantieni alcune decine di altre. Alcune settimane diventa un po 'opprimente. Alcuni dei progetti sono enormi, alcuni sono così piccoli che sono stati codificati in pochi giorni e raramente necessitano di modifiche. Varia, ma mi tiene esposto a diversi modi di pensare e risolvere problemi, diverse tecnologie e aree di business. Mi piace.

Quindi, per rispondere alla tua domanda, sì, è molto comune.

Guarda l'articolo chiamato Il multitasking ti porta più tardi . Questo grafico racconta la storia:

Inaltreparole,lasocietàstaperdendotempoavendoipropriprogrammatorilavoraresupiùdiunprogettoallavolta.Consolotreprogetti,losprecoèdel40%!Ilrestodeltempoèsuddivisointreprogetti.

Laragioneperilmultitaskingèspessodefinitacome"fare più cose". Ma questo è un ragionamento errato. Il multitasking ha come risultato solo il ritardo di tutte le versioni. Questa immagine mostra l'effetto del doppio tasking rispetto al completamento di un progetto alla volta:

(L'immagine ignora completamente il sovraccarico, in realtà il tempo sprecato renderebbe entrambi i progetti il 20% più tardi.)

Dipende dalla compagnia. IMO è desiderabile lavorare principalmente su un solo progetto, ma spesso non è possibile, specialmente con le piccole imprese.

Ovviamente, correzioni di bug, ecc. possono sempre accadere con qualsiasi progetto.

Sì, nella mia esperienza è normale (anche se alcuni dei "progetti" sono abbastanza simili, ad esempio un progetto di manutenzione e funzionalità sullo stesso prodotto). Per evitare conflitti e aspettative non realistiche, concorda con i project manager e il tuo manager di assegnare determinate frazioni del tuo tempo a ciascun progetto (ad esempio tre giorni sul progetto X, due sul progetto Y a settimana). In genere, puoi quindi distribuire tali assegnazioni come preferisci, ad es. Lun-Mer su X, Gio-Ven su Y.

Occasionalmente ci sono momenti in cui un progetto "lancia un'eccezione" e deve essere lavorato su ora . Ci sono due cose da fare qui:

1. assicurati che sia davvero un'eccezione, non solo un gestore di progetti invadente: respingi in quest'ultimo caso.
2. scambia le allocazioni di tempo in modo che funzioni sempre la stessa frazione su ciascun progetto.

Se hai difficoltà a tornare al passo con il quadro di un progetto o la logica aziendale quando torni indietro, dovresti cogliere l'opportunità di scrivere tutta la documentazione possibile mentre ci stai lavorando. Spiegare come funziona un sistema complesso, con parole tue, renderà molto più facile tornare al progetto più tardi. Inoltre, questa documentazione può essere utile per i tuoi colleghi se hanno bisogno di assistenza.

Se il progetto ha già una buona copertura della documentazione tecnica, può comunque essere utile scrivere i propri pensieri mentre si lavora su aree complicate. In questo modo puoi riprendere il tuo processo di pensiero la prossima volta che torni indietro.

Beh, non dovrebbe essere normale, ma ho molti progetti sulle spalle del mio attuale datore di lavoro. Ci vuole un po 'per abituarsi ad ammettere. Il consiglio più importante che potrei dare è di dare sempre la priorità al tuo lavoro. Costringi il tuo capo a dirti qual è il compito prioritario e lavora solo su questo. Non fare pressione su chi si lamenta degli altri tuoi progetti. Non hai necessariamente bisogno di aggiornare il tuo curriculum ma assicurati che il carico non si estenda oltre qualcosa che puoi ragionevolmente gestire.

Penso sia normale Il modo in cui il mio lavoro funziona in questo momento (sono in una compagnia con circa 40 sviluppatori, una dimensione totale dell'azienda di circa 700). E di solito ho un progetto a "lungo termine" con molti piccoli biglietti / difetti che emergono, quindi di solito finisce con il 50% di piccoli biglietti e il 50% di lavoro sul progetto a lungo termine. Ciò che può essere difficile è che l'interruzione costante può rallentare e far deragliare il progetto a più lungo termine ...

Penso che sia normale lavorare su più progetti. La chiave è accettare che si troveranno ad affrontare alcune ambiguità in termini di immagine complessiva del sistema inizialmente.

Se ti sforzi di ottenere un'immagine più ampia, otterrai chiarezza e sarai in grado di individuare le parti mobili / fisse nel sistema e in che modo le tue modifiche influenzano il sistema.

Durante un periodo di tempo imparerai a trovare schemi comuni nei vari sistemi su cui lavori. Questi possono essere applicati ad altri progetti che ridurranno la quantità di informazioni granulari che è necessario tenere in testa alla volta.

In qualsiasi progetto non banale è assegnato più di una persona. Ciò significa che devi collaborare con gli altri e aspettare che facciano il loro lavoro, così come devono aspettarti.

Invece di avere persone sedute inattive, è comune avere più progetti attivi in modo che ci sia sempre un'attività da svolgere se necessario.

Dovresti comunque lavorare in blocchi considerevoli su ciascun progetto in modo da poter ottenere "nella zona" ed essere produttivi, comunque.

Sono d'accordo con chi dice che è normale / comune.

Guardalo come positivo, diventerai più utile, visto come flessibile, un tipo che può fare le cose! Forse più prezioso in quanto alla fine conoscerai 2 sistemi al limite.

IMHO, non solo è normale, ma è anche auspicabile.

Il peggior lavoro di sviluppo che abbia mai avuto è stato lavorare sulla stessa piccola sezione della stessa parte della stessa applicazione per mesi e mesi. Tedio. E quando sei annoiato, distogli lo sguardo dalla palla ...

Capisco come ti senti, è difficile far capire ai nuovi datori di lavoro lo sviluppo processato, specialmente se il tuo datore di lavoro non è focalizzato sullo sviluppo.

Il problema è che vedono 3 lavori su cui si lavora insieme più di un money maker di uno alla volta, e le statistiche mostrano una diminuzione del 40% delle prestazioni. Questo è il 40% di perdita di profitto ..

Ho lavorato precedentemente per un'orgonizzazione che mi ha permesso di concentrarmi su un progetto di grandi dimensioni alla volta con piccoli lavori in mezzo, biglietti e supporto ecc. Abbiamo lavorato a un accordo dove 8: 00-10: 00AM era Ticket e supporto per i sistemi attuali che arrivano tramite e-mail / telefono / helpdesk, quindi dalle 10:00 alle 16:30 o il tuo orario di fine è stato un solido sviluppo. Questo ha funzionato molto bene, perché avevamo un helpdesk per rispondere alle chiamate e alle e-mail, sono riuscito a fare i biglietti al mattino e sviluppare il resto della giornata. Il problema è se hai una cattiva gestione. Un manager fa tutto questo e, senza il loro supporto o la comprensione delle sfide che affrontate quotidianamente, ignorano il fatto.

Sono stato grato soprattutto nel mio ultimo lavoro di supporto e comprensione da parte del mio manager, mi ha reso la vita più facile, meno stress e abbiamo ancora TUTTO il lavoro svolto ..

Un altro problema, i soldi d'amore di Boss, vedono i progetti in denaro, quando hanno 5 progetti per £ 20.000 tutti allo stesso tempo (e sei uno sviluppatore solista) questo è 100.000 sterline nei libri. Sembra fantastico su carta ma può danneggiare la reputazione della società quando questi non vengono rispettati, le scadenze vengono perse ei sistemi sono bacati a causa della mancanza di concentrazione.

Sono solidale con te, sono nella tua posizione in questo momento.

Dipende da come descrivi il progetto. Generalmente lo sviluppatore lavora con qualche problema e se in azienda c'è più di un prodotto di quello con cui lavori più.

I progetti software, come i partner d'amore, possono essere molti e validi per molti, ma sono validi solo se uno alla volta.

Aggiungendo a ciò che @Martin Wickman ha detto, prova a non eseguire molte operazioni. Ad esempio, lavoro AM sul progetto A, PM sul progetto B. Dire anche no all'aggiunta di funzionalità; è più doloroso quando non lavori al progetto a tempo pieno.