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

40

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?

moucheron
la source
pour moi, travailler sur plusieurs projets est plus adapté au terme «atelier de carrosserie», ce qui est une mauvaise chose, n'est-ce pas?
Le pire, c’est que je ne supporte pas l’imprévoyance qui se présente lorsque vous n’êtes pas très expérimenté dans votre projet. Et le fait de travailler avec plusieurs projets m'empêche d'acquérir une compréhension solide et cela me rend fou, parce que je suis sorti de ma zone de vie confortable \ work.
ne veux pas fermer cette question. Tout simplement parce que, à mon avis, si vous travaillez en tant que programmeur, vous devez fournir la garantie que votre code ne sera pas affecté par vos modifications. Mais si vous manquez d'expertise dans le système, quelle garantie pouvez-vous fournir? Mettre un contrôle nul sur chaque appel de méthode '' égaux '' ou autres objets? - Enfer ouais!
Êtes-vous autorisé à utiliser les technologies de collaboration et de gestion des connaissances au travail? (Exemples: wiki, outils de révision de code, accès aux documents de conception, outils de gestion de projet, listes de tâches personnelles, suivi des bogues, messagerie instantanée, etc.) Sans ces technologies, il est impossible de travailler sur plusieurs projets.
Rwong
Cette question est-elle "plus de 50% des entreprises autorisent-elles le multitâche" ou "Le multitâche est-il bon ou mauvais"?
Martin Wickman

Réponses:

54

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.

Alex
la source
5
Avoir plusieurs projets en même temps ne signifie pas que vous codez simultanément. Ce serait multitâche. S'attendre à avoir un projet à la fois peut être préférable, mais rêve seulement de La La Land.
JeffO
1
+1 excellent. Si les entreprises réalisaient cela, elles s'en sortiraient beaucoup mieux. Certains le font cependant, et c'est là que les gagnants de demain sont!
Martin Wickman
Merci @Martin. Je me sens drôle de voir à quel point certaines personnes ne comprennent pas que «faire plusieurs tâches» équivaut à travailler sur plusieurs projets. Je n'ai jamais dit que le codage simultané était la même chose que le multitâche. Où avez-vous obtenu cela auprès de @Jeff? Boire du café et coder? Vous plaisantez j'espère? Donc, si vous respirez et clignez des yeux en même temps, êtes-vous également multitâche ??? Au moins, lisez tout le post geez! Le lien vers les articles de Joel a des idées très similaires, veuillez le lire avant de mettre votre commentaire ici.
Alex
2
@Alex - @bjarkef et @Jeff ont absolument raison; avoir deux projets! = multitâche. Le message de Joel et votre article sur le multitâche, coûteux et inutile, sont corrects, mais ils ne sont pas nécessairement pertinents pour travailler sur plusieurs projets.
Nick Knowlson
5
Par exemple, supposons que vous décidiez de travailler sur les deux projets en alternance. D'où vient le coût du changement de contexte? Et comment est-ce que cette interruption est dans la zone? Il se peut que gasan soit constamment interrompu par des problèmes urgents liés à l’autre projet, voire par des problèmes urgents liés au même projet. C'est là que le multitâche devient un problème, mais ce n'est pas inhérent au travail sur deux projets et c'est souvent un problème même avec un seul projet.
Nick Knowlson
33

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.

facture de tisserand
la source
7
Au lieu d'être un serviteur obéissant et d'espoir pour les richesses, peut-être être assertif et ajouter de la valeur en soulignant l'inefficacité?
Joppe
6
@Tungano - Je ne suggère en aucun cas d'être "un serviteur obéissant", mais plutôt que de se voir confier de multiples responsabilités simultanées est un effet secondaire naturel d'être bon dans ce que vous faites. Les gens ont tendance à compter sur ceux qui peuvent faire bouger les choses. Gérer plusieurs responsabilités n’est pas nécessairement inefficace, servile ou obéissant. Si vous (ou @gasan) ne parvenez pas à gérer efficacement plusieurs tâches, signalez-le à votre employeur afin qu'il ne commette pas l'erreur de penser que vous le pouvez. (FWIW, je ne dit rien au sujet de la richesse.)
pc
Cela vous évite également de vous lasser du projet quand vous ne faites que ça. J'ai actuellement environ 100 tâches différentes en attente d'être effectuées, réparties sur 17 projets. Bien sûr, cela crée parfois une certaine pression, mais je suis malheureux quand il ne reste rien à faire à part mettre toute mon énergie dans un seul grand projet.
Htbaa
7
Je suis fortement en désaccord avec cette réponse. Le multitâche n'est pas une mesure du succès, c'est une mesure de l'incompétence de votre responsable. Savoir effectuer plusieurs tâches à la fois n'est pas si simple. PS: J'ai posté une réponse moi-même mais elle va jusqu'au bout de la ligne.
Alex
6
Cette réponse n'a aucun sens. Il est "normal" dans un sens que de nombreuses entreprises y contraignent les programmeurs, mais cela reste un gaspillage de leurs ressources. S'ils devaient se concentrer sur une chose à la fois , le travail serait terminé beaucoup plus rapidement.
Martin Wickman
15

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.

Yeradis
la source
En fait, ce qui me rend triste, c’est le niveau d’expertise que j’ai obtenu en résultat. Je n'ai tout simplement pas assez de mémoire pour me souvenir à la fois de la logique commerciale et de la logique technique des systèmes qu'il me semble impossible. Toutes les fois que je reçois une tâche, je dois chercher et déboguer très fort, car je ne connais pas bien ces systèmes. Ai-je raison de dire que "ne pas savoir beaucoup mais faire tous les travaux pas très rapidement" est ce qu'un programmeur devrait être, pas le "système complet connaissant parfaitement et fixant en quelques heures un ninja"?
4
@gasan Nous aimerions tous travailler sur "une chose à la fois". Cependant, travailler sur plus d'un projet, lire le code des autres et faire face à diverses exigences est le chemin qui mène à ninja-hood.
Bogeymin
12

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.

Anthony
la source
9

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.

CaffGeek
la source
alors, tu es un peu Shiva-guy? Je peux difficilement imaginer votre contribution à ces projets.
@gasan, c'est ridicule. Parties petites, mais souvent critiques, des autres. Et quelques-uns que je dois juste maintenir parce que le dev original est parti ... et ceux-là sont les plus longs
CaffGeek
8

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

entrez la description de l'image ici

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:

entrez la description de l'image ici

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

Martin Wickman
la source
4

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.

utilisateur281377
la source
vous avez raison, je travaille maintenant dans une petite entreprise, mais auparavant je ne travaillais que pour les grandes; cela fait donc peut-être partie d'un problème, je veux dire que je n'ai pas l'habitude de travailler dans des petites entreprises.
4

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.
utilisateur4051
la source
3

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.

Matt G
la source
1
Très bon conseil. Je prends des notes détaillées et elles me sont très utiles à plus d’une occasion.
Adam Lear
2

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.

ChaosPandion
la source
2
En effet, forcez votre patron à vous dire ce qui est important. La communication est très importante et si elle n’est pas maintenue, elle peut causer beaucoup de frustration et de déception à l’une ou l’autre des parties.
Htbaa
0

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.

BMW
la source
0

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.

Pradeep
la source
0

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.

utilisateur1249
la source
-1

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.

ozz
la source
-1

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 ...

cjmUK
la source
Si votre travail est ennuyeux, vous devriez peut-être en trouver un autre plus intéressant, plutôt que d'essayer d'en faire juste une partie plus intéressante.
Acumenus
C'est ce que j'ai fait, mais il est naïf de penser que chaque aspect de chaque travail sera passionnant.
cjmUK
Désolé, mais je ne peux pas comprendre. En tant que programmeur, je trouve tous les projets assignés intéressants, non seulement dans mon travail actuel, mais également dans celui que j’avais auparavant. Ce n'est pas forcément excitant. c'est différent. Il existe un spectre intéressant entre excitant et ennuyeux.
Acumenus
Ensuite, je pense que vous êtes très chanceux ... Cependant, je soupçonne que je suis un groupe démographique plus important qui doit faire face à la dure.
cjmUK
-1

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.

Steve Church
la source
Comment cela répond-il à la question posée?
moucher
-2

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.

Dainius
la source
Nous fournissons 2 produits distincts et ils partagent un petit morceau de code. Ces produits répondent à différents besoins des utilisateurs, mais restent dans le même domaine.
-2

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.

Apalala
la source
-2

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.

Brian Carlton
la source