Est-il normal que le programmeur travaille sur plusieurs projets simultanément [fermé]

Sur un emploi actuel, j'ai deux projets sur lesquels travailler. Le premier est un très gros système et le second est plus petit mais il est aussi grand (le premier projet est en développement depuis 12 ans, le second en 4 ans).

Au début, je ne travaillais que sur le premier projet et essayais de m'y habituer. Ensuite, j'ai été transféré dans un deuxième projet et essayé, ma connaissance du premier projet est devenue obscure. Maintenant, je dois travailler sur les deux projets en même temps.

C'est très difficile pour moi car, bien qu'ils utilisent tous les deux Java, ils utilisent des cadres différents et que la quantité de code et de logique commerciale à comprendre est très importante, je ne peux donc vraiment pas garder ces deux projets en tête.

Est-ce normal et je devrais m'y habituer, bien que mon expertise soit devenue très délicate, qu'est-ce qui ne se passera pas si je ne travaillais que sur un seul projet? Ou devrais-je soulever une préoccupation ou peut-être changer d'employeur?

Je suis complètement en désaccord quand les gens disent "oui, le multitâche est normal"

Ce n'est pas normal! Pas du tout, il est très peu naturel pour un développeur d'effectuer plusieurs tâches à la fois dans plusieurs projets (je l'expliquerai plus tard). D'autre part, le multitâche est très courant chez les développeurs. C’est définitivement quelque chose auquel vous devriez vous habituer. La vraie réponse à votre question est donc: comment effectuer plusieurs tâches à la fois?

Tout d’abord, vous ne devez pas simplement accepter votre destin, car «vous êtes un excellent employé», ce qui signifie que vous devez assumer plus de tâches que vous ne pouvez en gérer. Pas du tout, vous ne le faites pas. Parfois, des tâches multiples sont confiées à des personnes car il n'y a personne d'autre. Parfois, les responsables ne peuvent pas gérer leur travail, alors ils délèguent leurs tâches et imposent plusieurs tâches à leur équipe, car ils ne peuvent pas gérer correctement le planning de leurs projets. Donc, vous devriez certainement essayer de déterminer si on vous demande de faire plusieurs tâches à la fois parce que cela fait partie de votre travail ou parce que d' autres personnes sont incompétentes.. De toute façon, vous pouvez juger par vous-même si cela est acceptable ou non. Si vous n'êtes pas à l'aise [avec votre travail], il existe d'autres endroits où vous pouvez aller chercher du travail. [Vous, le développeur, êtes la marchandise. Les employeurs le savent et prient pour que vous ne le réalisiez jamais.]

En ce qui concerne le multitâche, je suis en désaccord à 100% lorsque les gens disent: "Oui, changez de place et assurez-vous de faire la même chose pour chaque projet". Désolé mais c'est un très mauvais conseil.

Tout d'abord, vous devez comprendre le fonctionnement de votre cerveau lorsque vous développez un logiciel (je sais que d'autres tâches sont en cause, mais concentrons-nous sur celle-ci). Vous devez d’abord être «câblé», c’est-à-dire que vous devez vous concentrer beaucoup et mettre votre esprit dans une position où tout est cartographié dans votre tête. Tous les noms de variable et de méthode, le flux de travail de votre code, le modèle d'objet, les threads côte à côte, tout. Cela me prend habituellement 15 peut-être 20 minutes pour arriver "dans la zone".

Quand vous arrivez dans cet état, vous vous échappez et écrivez du code comme si vous rouliez à vélo. Dès que vous êtes interrompu, vous pouvez tout perdre. Si l'interruption est suffisamment longue (5, 10 ou 30 minutes), vous perdrez cet état d'esprit et vous devrez tout recommencer.

Le multitâche est terrible, car il vous oblige à quitter "la zone" et à passer à autre chose. Si vous changez constamment de poste, cela signifie que vous n'êtes pas productif, car chaque fois que vous passez à une nouvelle tâche / projet, vous devez perdre ces 15 à 20 minutes pour revenir dans la zone (sans mentionner que cela fait fondre votre cerveau lentement).

C'est comme faire du multi-threading: à un moment donné, le coût de la commutation du contexte du thread tous les deux cycles est trop élevé, de sorte que le processeur passe plus de temps à changer de contexte qu'à l'exécution des tâches réelles.

Je recommande fortement de lire un article de Joel Spolsky à ce sujet:

http://www.joelonsoftware.com/articles/fog0000000022.html

Mon conseil est donc le suivant: essayez d’apprendre à (ne pas) effectuer plusieurs tâches à la fois car c’est vraiment courant. Mais assurez-vous également que vous êtes à l'aise pour le faire. Certaines personnes peuvent prendre plus de temps à se concentrer et souffriront plus que d'autres lors de tâches multiples; et ça va aussi. Ce n'est pas parce qu'il est commun que cela devrait être considéré comme normal.

Joel l'a bien dit quand il a dit:

En fait, la vraie leçon à tirer de tout cela est qu'il ne faut jamais laisser les gens travailler plus d'une chose à la fois. Assurez-vous qu'ils savent ce que c'est. Les bons gestionnaires considèrent que leur responsabilité consiste à éliminer les obstacles afin que les employés puissent se concentrer sur une chose et le faire vraiment.

Oui, il faut s'y attendre. Et accueilli.

Il y a plusieurs façons de regarder ceci:

1. Vous êtes censé effectuer plusieurs tâches à la fois et il est presque impossible de se concentrer. Cela se traduit par des processus d'ingénierie sous-optimaux, une confusion occasionnelle lors des échanges, un sentiment d'exploitation, de frustration, de stress, etc. Tout cela est négatif, bien sûr; cependant,

2. Vous faites confiance à plusieurs projets, ce qui reflète bien les résultats que vous produisez et la confiance de votre employeur en vos capacités. C'est une occasion de leur montrer que la confiance est justifiée.

Mon conseil est de développer un jugement objectif sur les tâches qui requièrent votre attention immédiate et sur celles qui peuvent attendre. Parfois, la réponse est qu’aucun d’eux ne peut attendre et que vous devez adopter une approche créative pour obtenir des résultats (un peu pour le projet A, puis un peu pour le projet B, puis rincez et répétez). Cultivez les compétences pour réussir dans ce genre de situation.

Normalement (mais pas toujours), cela sera récompensé par plus de responsabilité, plus de projets à jongler et plus d'attentes. À un moment donné, vous pourrez et serez en droit de déléguer une partie de ce travail. C'est une mesure du succès.

Ainsi, même si vos compétences de jonglage croissantes ne sont exploitées que par votre société actuelle, il s'agit de bonnes compétences à posséder et qui vous serviront bien dans votre carrière.

Pour ce que cela vaut, je travaille habituellement sur un projet majeur, un projet plus petit, la maintenance et le support d'anciens projets, et en gère au moins un autre. C'est frustrant, déroutant, fatigant et je suis très reconnaissant.

Oui! C'est tout à fait "normal" / habituel lorsque vous travaillez dans une entreprise de service xD

Aussi, si vous collaborez avec des projets open source, c'est la règle

Peut-être n'est pas et l'état idéal, mais est le pain de tous les jours.

C'est courant. Mais ce n'est pas bon, pour les raisons que vous avez exposées. Changer de contexte consomme de la productivité. Si vous le pouvez, essayez de travailler sur un projet pendant une grande partie de votre temps, par exemple une journée.

Je travaille activement sur 2 à 3 projets différents chaque jour. Et maintenez quelques douzaines de plus. Certaines semaines, cela devient un peu écrasant. Certains des projets sont énormes, certains sont si petits qu'ils ont été codés en quelques jours et nécessitent rarement des modifications. Cela varie, mais cela me laisse exposé à différentes façons de penser et de résoudre des problèmes, des technologies et des domaines d'activité différents. J'apprécie.

Donc, pour répondre à votre question, oui, c'est très courant.

Consultez l'article intitulé Le multitâche vous y rend plus tard . Ce graphique raconte l'histoire:

En d’autres termes, la société perd son temps en faisant travailler ses programmeurs sur plus d’un projet à la fois. Avec seulement trois projets, les déchets représentent 40%! Le reste du temps est divisé en trois projets.

La raison du multitâche est souvent indiquée comme "faire plus de choses". Mais c'est un raisonnement erroné. Le multitâche entraîne uniquement le retard de toutes les versions. Cette image montre l'effet de la double tâche par rapport à la finition d'un projet à la fois:

(L'image ignore complètement les frais généraux. En réalité, le temps perdu rendrait les deux projets 20% plus tard.)

Cela dépend de la compagnie. IMO, il est souhaitable de travailler principalement sur un seul projet, mais ce n'est souvent pas possible, surtout avec les petites entreprises.

Bien sûr, les corrections de bugs, etc. peuvent toujours arriver avec n'importe quel projet.

Oui, selon mon expérience, c'est normal (même si certains des «projets» sont assez similaires, par exemple un projet de maintenance et de fonctionnalités sur le même produit). Pour éviter les conflits et les attentes irréalistes, convenez avec les responsables du projet et votre responsable d’attribuer certaines fractions de votre temps à chaque projet (par exemple, trois jours sur le projet X, deux sur le projet Y par semaine). Vous pouvez normalement ensuite répartir ces allocations comme bon vous semble, par exemple lundi à mercredi sur X, jeudi à vendredi sur Y.

Il y aura parfois des moments où un projet "lève une exception" et doit être travaillé maintenant . Il y a deux choses à faire ici:

1. Assurez-vous qu’il s’agit réellement d’une exception et non d’un gestionnaire de projet insistant: repoussez-vous dans ce dernier cas.
2. permutez vos allocations de temps pour que vous travailliez toujours sur la même fraction pour chaque projet.

Si vous avez du mal à vous familiariser avec le framework ou la logique métier d'un projet lorsque vous y revenez, vous devez saisir cette opportunité pour rédiger autant de documentation que possible pendant que vous y travaillez. Détailler le fonctionnement d’un système complexe, selon vos propres termes, facilitera beaucoup la tâche de revenir ultérieurement au projet. De plus, cette documentation peut être utile à vos collègues s'ils ont besoin d'aide.

Si la documentation technique du projet est déjà bien couverte, il peut toujours être utile d'écrire vos pensées pendant que vous travaillez sur des domaines complexes. De cette façon, vous pourrez reprendre votre processus de pensée la prochaine fois que vous reviendrez.

Eh bien, cela ne devrait pas être normal, mais j’ai beaucoup de projets sur les épaules de mon employeur actuel. Je dois admettre qu’il faut s’y habituer. Le conseil le plus important que je puisse vous donner est de toujours prioriser votre travail. Forcez votre patron à vous dire quelle est la tâche prioritaire et à ne travailler que sur celle-ci. Ne cédez pas à la pression de quiconque se plaint de vos autres projets. Vous n'avez pas nécessairement besoin de mettre à jour votre CV pour le moment, mais assurez-vous que la charge n'augmente pas au-delà de ce que vous pouvez raisonnablement gérer.

Je pense que c'est normal La façon dont mon travail fonctionne actuellement (je suis dans une entreprise avec environ 40 développeurs, taille totale de l'entreprise d'environ 700). Et j'ai généralement un projet "à long terme" avec beaucoup de petits tickets / défauts qui apparaissent, donc il finit généralement par être de 50% de petits tickets et 50% de travailler sur le projet à long terme. Ce qui peut être difficile, c’est que l’interruption constante puisse ralentir et faire dérailler le projet à long terme.

Je pense qu'il est normal de travailler sur plusieurs projets. La clé est d’accepter que vous soyez confronté à une certaine ambiguïté en ce qui concerne l’ensemble du système.

Si vous vous efforcez d'obtenir une image plus grande, vous obtiendrez une clarté et serez en mesure de repérer les pièces mobiles / fixes du système et la manière dont vos modifications affectent le système.

Au fil du temps, vous apprendrez à trouver des modèles communs dans les différents systèmes sur lesquels vous travaillez. Celles-ci, vous pouvez les appliquer à vos autres projets, ce qui réduira la quantité d'informations granulaires que vous devez conserver dans votre tête à la fois.

Dans tout projet non-trivial, plusieurs personnes sont affectées. Cela signifie que vous devez collaborer avec les autres et attendre qu'ils fassent leur travail, de même qu'ils doivent vous attendre.

Au lieu de laisser les gens inactifs, il est courant d'avoir plusieurs projets actifs, de sorte qu'il y ait toujours une tâche ouverte à faire si nécessaire.

Vous devez tout de même travailler par lots considérables sur chaque projet pour pouvoir rester "dans la zone" tout en restant productif.

Je suis d'accord avec ceux disent que c'est normal / commun.

Considérez-le comme positif, vous deviendrez plus utile, plus flexible, un type capable de faire avancer les choses! Peut-être plus précieux alors que vous finissez par connaître 2 systèmes à l’intérieur.

IMHO, non seulement c'est habituel, mais c'est aussi souhaitable.

Le pire travail de développement que j'ai jamais eu a été de travailler sur la même petite partie de la même partie de la même application pendant des mois. Ennui. Et quand tu t'ennuies, tu lèves les yeux du ballon ...

Je comprends ce que vous ressentez, il est difficile de faire comprendre aux nouveaux employeurs l’évolution du processus de développement impliqué, en particulier si votre employeur n’est pas axé sur le développement.

Le problème, c’est qu’ils voient 3 emplois en train d’être travaillés ensemble plus comme un fabricant d’argent qu’un à la fois, et les statistiques montrent une baisse de 40% des performances. Thats 40% de perte de profit ..

Auparavant, je travaillais pour une organisation qui me permettait de me concentrer sur un grand projet à la fois, avec des petits travaux intermédiaires, des tickets et du support, etc. Nous avons travaillé sur un contrat dans lequel 8h00 à 10h00 était Ticket et support des systèmes actuels. qui passent par e-mail / téléphone / service d’assistance puis de 10 h à 16 h 30 ou votre heure de la fin a été un développement complet et solide. Cela fonctionnait extrêmement bien, car nous avions un service d'assistance pour prendre les appels et les courriels. J'ai pu faire les billets le matin et développer le reste de la journée. Le problème est si vous avez une mauvaise gestion. Un responsable rend tout cela possible, et sans leur soutien ni leur compréhension des défis auxquels vous êtes confrontés quotidiennement, ils ne le savent pas.

J'ai été particulièrement reconnaissant, dans mon dernier travail, du soutien et de la compréhension de mon responsable. Cela m'a facilité la vie, moins de stress et nous avons quand même effectué TOUT le travail.

Un autre problème est celui-ci: l'argent de Boss, ils voient les projets dans l'argent, quand ils ont 5 projets pour 20 000 £ en même temps (et que vous êtes un développeur solo), c'est 100 000 £ dans les livres. nuire à la réputation de la société lorsque ceux-ci ne sont pas respectés, les délais ne sont pas respectés et les systèmes sont bogués en raison du manque de concentration.

Je sympathise avec vous complètement, je suis dans votre position en ce moment.

Cela dépend de la façon dont vous décrivez le projet. Généralement, les développeurs travaillent avec un problème et s’il existe plusieurs produits en même temps que plusieurs.

Les projets logiciels, comme les partenaires amoureux, peuvent être nombreux et bons pour plusieurs, mais ils ne sont bons que s’ils ne le font qu’un à la fois.

En ajoutant à ce que @Martin Wickman a dit, essayez de ne pas trop changer de tâche. Par exemple, travailler sur les projets A et PM sur les projets B. Indiquez également non à l'ajout de fonctionnalités; C'est plus pénible quand vous ne travaillez pas à plein temps sur le projet.