Est-il normal que le programmeur travaille simultanément sur plusieurs projets
Sur un emploi actuel, j'ai deux projets à travailler. Le premier est un système très énorme et le second est plus petit mais il est également grand (le premier projet est en cours de développement pendant 12 ans, le second pendant 4 ans).
Au début, je ne travaillais que sur le premier projet et j'essayais de m'y habituer. Ensuite, j'ai été transféré au deuxième projet et j'ai essayé là-bas, donc mes connaissances sur le premier projet sont devenues louches. Maintenant, je dois travailler sur les deux projets en même temps.
C'est très difficile pour moi car malgré qu'ils utilisent tous les deux Java, ils utilisent des cadres différents et la quantité de code et de logique métier à comprendre est très grande, donc je ne peux vraiment pas avoir les deux projets en tête.
Est-ce normal et je devrais m'y habituer, même si mon expertise est devenue très délicate, que ne se passera-t-il pas si je ne travaille 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, c'est très contre nature pour un développeur d'effectuer plusieurs tâches dans plusieurs projets (je l'expliquerai plus tard). D'autre part, le multitâche est très courant parmi les développeurs. C'est certainement quelque chose auquel vous devriez vous habituer. La vraie réponse à votre question est donc: comment effectuer plusieurs tâches?
Tout d'abord, vous ne devez pas simplement accepter votre sort car "vous êtes un excellent employé" et cela signifie que vous devez prendre plus de tâches que vous ne pouvez en gérer. Pas du tout, non. Parfois, les gens se voient confier plusieurs tâches parce qu'il n'y a personne d'autre. Parfois, les gestionnaires ne peuvent pas gérer leur travail, alors ils délèguent, imposant le multitâche à leur équipe car ils ne peuvent pas gérer correctement le calendrier de leur projet. Donc, vous devez absolument essayer de déterminer si on vous demande d'effectuer plusieurs tâches parce que cela fait partie de votre travail ou parce que d'autres personnes sont incompétentes. Quoi qu'il en soit, vous pouvez juger par vous-même si c'est acceptable ou non. Si vous n'êtes pas à l'aise [avec votre travail], il existe d'autres endroits où vous pouvez trouver du travail. [Vous, le développeur, êtes la marchandise. Les employeurs le savent et prient pour que vous ne vous en rendiez pas compte.]
En ce qui concerne le multitâche, je ne suis pas d'accord à 100% lorsque les gens disent "oui, il suffit de basculer et de s'assurer que vous faites la même quantité sur chaque projet". Désolé mais c'est un très mauvais conseil.
Vous devez d'abord comprendre comment fonctionne votre cerveau lorsque vous développez un logiciel (je sais que d'autres tâches sont impliquées, mais concentrons-nous sur celle-ci). Vous devez d'abord vous "brancher", ce qui signifie que vous devez vous concentrer beaucoup et mettre votre esprit dans une position où vous avez tout cartographié dans votre tête. Tous les noms de variables et de méthodes, le flux de travail de votre code, le modèle d'objet, les threads côte à côte, tout. Cela me prend généralement 15 à 20 minutes pour arriver "dans la zone".
Lorsque vous arrivez à cet état, vous vous envolez vraiment et écrivez du code comme si vous faisiez du vélo. Au moment où vous êtes interrompu, vous pouvez tout perdre. Si l'interruption est assez longue (5, 10 peut-être 30 minutes), vous perdrez cet état d'esprit et devrez recommencer à zéro.
Le multitâche est donc terrible car il vous oblige à quitter "la zone" et à passer à autre chose. Si vous changez constamment, 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 le mentionner, cela fait fondre votre cerveau lentement).
C'est comme le multi-threading: à un moment donné, le coût de la commutation du contexte de thread tous les deux cycles est trop élevé, de sorte que le processeur finit par passer plus de temps à changer de contexte qu'à exécuter les tâches réelles.
Je recommande fortement de lire un article de Joel Spolsky sur ce sujet:
http://www.joelonsoftware.com/articles/fog0000000022.html
Donc, mon conseil est: essayez d'apprendre à (pas) effectuer plusieurs tâches car c'est en effet courant. Mais assurez-vous également que vous êtes à l'aise de le faire. Certaines personnes peuvent prendre plus de temps pour se concentrer et souffriront plus que d'autres lorsqu'elles effectuent des tâches multiples; et c'est ok aussi. Ce n'est pas parce qu'il est courant que cela soit considéré comme normal.
Joel l'a bien dit quand il a dit:
En fait, la vraie leçon de tout cela est que vous ne devez jamais laisser les gens travailler sur plus d'une chose à la fois. Assurez-vous qu'ils savent de quoi il s'agit. Les bons gestionnaires considèrent que leur responsabilité consiste à éliminer les obstacles afin que les gens puissent se concentrer sur une chose et vraiment y arriver.
Oui, c'est normal. Et bienvenu.
Il y a deux façons de voir les choses:
Vous devez effectuer plusieurs tâches et il est presque impossible de se concentrer. Il en résulte des processus d'ingénierie sous-optimaux, une confusion occasionnelle lors des allers-retours, un sentiment d'être exploité, de la frustration, du stress, etc. Tout cela est bien sûr négatif; cependant,
On vous fait confiance pour plusieurs projets, ce qui reflète bien les résultats que vous produisez et la confiance que votre employeur a en vos capacités. C'est l'occasion de leur montrer que la confiance est garantie.
Mon conseil est de développer un jugement sobre quelles tâches nécessitent votre attention immédiate et qui peuvent attendre. Parfois, la réponse est que ni l'un ni l'autre ne peut attendre et vous devez adopter une approche créative pour fournir 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 nécessaires pour prospérer dans ce genre de situation.
Normalement (mais pas toujours), cela sera récompensé par plus de responsabilités, plus de projets à jongler et plus d'attentes. À un moment donné, vous serez en mesure, et prévu, de déléguer une partie de ce travail. C'est une mesure de succès.
Donc, même si vos compétences croissantes de jonglage ne sont exploitées que par votre entreprise actuelle, ce sont de bonnes compétences à avoir et qui vous serviront bien dans votre carrière.
Pour ce que ça vaut, je travaille généralement sur un grand projet, un plus petit, la maintenance et le support d'anciens projets, et en gère au moins un autre. C'est frustrant, déroutant, ennuyeux et je suis très reconnaissant.
Oui! C'est complètement "normal"/habituel lorsque vous travaillez dans une entreprise de services xD
Aussi, si vous collaborez avec des projets open source, c'est la règle
Ce n'est peut-être pas un état idéal, mais c'est le pain de tous les jours.
C'est courant. Mais ce n'est pas bon, pour les raisons que vous avez décrites. Changer de contexte se répercute sur la productivité, donc si vous le pouvez, essayez de travailler sur un projet pendant une grande partie du temps, par exemple un jour.
Je travaille activement sur 2 à 3 projets différents chaque jour. Et maintenez quelques dizaines de plus. Certaines semaines, cela devient un peu écrasant. Certains 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 garde exposé à différentes façons de penser et de résoudre des problèmes, à différentes technologies et à différents domaines d'activité. J'apprécie.
Donc, pour répondre à votre question, oui, c'est très courant.
Consultez l'article intitulé Le multitâche vous y amène plus tard . Ce graphique raconte l'histoire:
En d'autres termes, l'entreprise perd du temps en faisant travailler ses programmeurs sur plus d'un projet à la fois. Avec seulement trois projets, les déchets sont de 40%! Le reste du temps est réparti sur 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 ne fait que retarder 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.)
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 chefs de projet et votre responsable d'allouer 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 distribuer ces allocations comme vous le souhaitez, par exemple Lun-mer le X, jeu-ven le Y.
Il y aura parfois des moments où un projet "lèvera une exception" et devra être travaillé maintenant. Il y a deux choses à faire ici:
- assurez-vous que c'est vraiment une exception, pas seulement un chef de projet arrogant: repoussez-vous dans ce dernier cas.
- échangez vos allocations de temps afin que vous travailliez toujours la même fraction sur chaque projet.
Cela dépend de l'entreprise. OMI, il est souhaitable de travailler principalement sur un seul projet, mais ce n'est souvent pas possible, en particulier avec les petites entreprises.
Bien sûr, des corrections de bugs, etc. peuvent toujours se produire avec n'importe quel projet.
Si vous avez du mal à vous remettre à jour avec le cadre ou la logique métier d'un projet lorsque vous y revenez, vous devriez en profiter pour écrire autant de documentation que possible pendant que vous travaillez dessus. Détailler le fonctionnement d'un système complexe, selon vos propres mots, facilitera le retour au projet plus tard. De plus, cette documentation peut être utile à vos collègues s'ils ont besoin d'aide.
Si le projet a déjà une bonne couverture de la documentation technique, il peut toujours être utile d'écrire vos pensées lorsque vous travaillez sur des domaines complexes. De cette façon, vous pouvez reprendre votre processus de réflexion la prochaine fois que vous revenez en arrière.
Ça ne devrait pas être normal mais j'ai de nombreux projets sur les épaules chez mon employeur actuel. Il faut un certain temps pour s'y habituer, je l'avoue. Le conseil le plus important que je pourrais donner est de toujours prioriser votre travail. Forcez votre patron à vous dire quelle est la tâche prioritaire et travaillez-y uniquement. Ne cédez pas à la pression de quiconque se plaint de vos autres projets. Vous n'avez pas encore nécessairement besoin de mettre à jour votre CV, mais assurez-vous que la charge n'escalade pas au-delà de quelque chose que vous pouvez raisonnablement gérer.
Je pense que c'est normal. La façon dont mon travail fonctionne en ce moment (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 "à plus long terme" avec de nombreux petits tickets/défauts qui surviennent donc il finit généralement par être 50% de petits tickets et 50% de travail sur le projet à long terme. Ce qui peut être difficile, c'est que l'interruption constante peut ralentir et faire dérailler le projet à plus long terme.
Je pense qu'il est normal de travailler sur plusieurs projets. La clé est d'accepter que vous serez confronté à une certaine ambiguïté en termes de vue d'ensemble du système au départ.
Si vous vous efforcez d'obtenir une image plus grande, vous obtiendrez de la clarté et pourrez repérer les parties mobiles/fixes dans le système et comment 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. 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, plus d'une personne lui est affectée. Cela signifie que vous devez collaborer avec les autres et attendre qu'ils fassent leur travail, ainsi qu'ils doivent vous attendre.
Au lieu de laisser les gens inactifs, il est courant d'avoir plusieurs projets actifs afin qu'il y ait toujours une tâche ouverte à faire si nécessaire.
Vous devriez quand même travailler en gros morceaux sur chaque projet afin de pouvoir "entrer dans la zone" et être productif.