Comment puis-je traiter avec un collègue lent et non dédié dans l'équipe? [fermé]

85

Je travaille sur un nouveau projet. Le projet fonctionne comme suit: l'utilisateur final peut accéder à une application Web via un lien et il peut ajouter plusieurs systèmes sur son réseau et gérer les détails de ces systèmes. Ma partie concerne le front-end et le serveur Web, ce qui se fait en python. Mon python communique en fait avec un autre projet entièrement en c & c ++. Le projet c / c ++ est l'application principale qui gère toutes les fonctionnalités. Mon python lui envoie la demande de l'utilisateur et en affiche la réponse.

Je connais très bien mon travail et je le terminerai bientôt. Puisque ce n'est pas beaucoup de travail dedans. Et je suis une personne qui aime travailler. Je passe la plupart de mon temps au bureau et je ne rentre chez moi que lorsque je me sens somnolent.

L'application c / c ++ est gérée par un autre collègue ayant plus de 5 ans d'expérience et capable de faire les choses beaucoup plus rapidement que moi, mais il ne le fait jamais. Peut-être qu'il n'aime pas le faire. Son application se bloque souvent lorsque mon python communique avec elle ou renvoie des valeurs erronées. C'est plein de bugs. Puisque mon application en dépend, j'ai du mal à la construire. Au lieu de corriger les bugs, il me demande de ralentir mon travail. Il me demande de dire au responsable que mon travail nécessite beaucoup de temps. Il me demande de tromper le manager et même de me forcer à travailler lentement comme lui.

Lors de la réunion du projet, lorsque le responsable lui pose des questions sur les bugs, il dit qu'il a tout corrigé et que tout fonctionne correctement. Comme il est mon collègue, je ne pouvais rien dire au responsable. Il est évident que je dois entretenir de bonnes relations avec mes collègues plutôt qu'avec mon responsable, car la plupart du temps, nous serons avec nos collègues et non avec le responsable.

Je ne peux rien dire au responsable à ce sujet, car si le responsable lui demande pourquoi, il pourrait penser que je me suis plaint de lui auprès du responsable. Et il continue de mentir dans la réunion. Et comme il corrige le bogue lentement, cela ralentit même mon travail. Maintenant, je pensais travailler sur la partie front-end de mon application et la terminer afin qu'il puisse entre-temps stabiliser son projet. Il me demande maintenant de dire au responsable que ma partie avant nécessite beaucoup de travail et que j'ai peut-être besoin de plus en plus de temps, simplement pour pouvoir faire glisser le projet vers le bas. Et ce qui est triste, c'est que notre responsable actuel est parti aux États-Unis. Nous avons donc un responsable temporaire et ce type ne connaît pas beaucoup le projet. Le c, le c ++ le trompe donc.

Quelqu'un peut-il me suggérer comment je gère cela? Je voulais finir le projet bientôt. Comment puis-je le faire travailler même en maintenant de bonnes relations avec lui?

Réponses aux commentaires:

S'il trompe délibérément la société, vous devriez le signaler à la direction.

Je suis nouveau dans cette société et l'autre type y est depuis de nombreuses années. Et je viens de commencer à connaître mes collègues. Si je vais directement me plaindre de lui, je ne pense pas pouvoir nouer de bonnes relations avec mes autres collègues. Même il a le pouvoir de les tromper. Je ne dis pas qu'il est un méchant, il peut faire le travail, mais il ne le fait pas.

Votre entreprise ne dispose-t-elle pas d'un système de suivi des bogues?

Ici, le système de suivi des bogues n'existe pas. L'entreprise essaie d'achever le projet le plus rapidement possible et le confie à l'AQ. Et corrige ensuite les bugs signalés par QA.

C'est pourquoi les entreprises devraient donner aux employés des actions / options ou une forme de propriété. De cette façon, vous pouvez littéralement dire au gars "Vous me coûtez la croissance monétaire ... vous ne voulez pas gagner de l'argent aussi?".

La société a les options d’achat d’actions qu’elle m’a remises à 2500 actions. La plupart du temps, lui aussi en aurait eu davantage.

L’ancienneté mérite le bénéfice d’un doute. Vous devez vraiment lui parler d'abord et essayer de comprendre le problème. Il est peut-être hors de propos, vous pouvez peut-être l'aider, il peut facilement y avoir des variables que vous ignorez. Cela peut être difficile maintenant, mais vous pourriez facilement aggraver la situation en sautant le pistolet.

Je le fais même. D'abord, son application ne traitait pas plusieurs demandes à la fois, il utilisait une file d'attente pour traiter les demandes que je lui avais envoyées. Je lui ai même suggéré certaines de mes idées à ce sujet. Il a dit qu'il avait déjà ces idées et qu'il les exécuterait. Ses explications étaient les suivantes: "Tout nécessite un certain temps et c'est un projet qui peut nécessiter deux ans à compléter et on nous demande de le terminer dans deux mois". Auparavant, j'avais du mal à coder pendant les premières semaines à cause de ce bug. Mais maintenant, il l'a réparé. Mais il utilise une seule file d'attente pour les demandes des utilisateurs, ce qui ralentit maintenant l'application, car elle ne traite qu'une demande à la fois.

Que fait le contrôle qualité pendant tout ce temps? Pourquoi ne font-ils pas rapport / confirmation du statut du projet?

Le responsable est la personne qui décide quand donner à l'AQ. Pour l'instant, il n'a pas encore donné à QA. Il a dit que nous devrions le donner d'ici la fin du mois.

muntoo
la source
6
Comment savez-vous que le gars C ++ est plus rapide que vous? Il pourrait être naturellement lent.
Job
3
Commentaires: les commentaires ont pour but d'obtenir des éclaircissements sur la question et des liens vers des ressources connexes. Si vous êtes d’accord avec l’une des réponses ci-dessous, votez pour cela. Si vous avez une meilleure réponse, laissez-la comme une réponse: ne la laissez pas comme un commentaire. Si vous souhaitez discuter du sujet de cette question avec d'autres personnes, utilisez le chat .
1
@Job, on suppose que l'ancienneté est synonyme de meilleur codeur, ce qui n'est pas toujours le cas.
Rudolf Olah

Réponses:

126

Tu es dans une mauvaise situation, je ne voudrais pas être à ta place. Il est peu probable que vous puissiez résoudre ce problème sans entrer en conflit avec votre collègue.

Voici ce que je ferais:

  • Ne deviens pas son partenaire dans le crime. Refuse de mentir sur le statut de votre projet ou de son projet.

  • Implémentez (pendant votre temps libre si nécessaire) les rapports de bogues dans votre application, de sorte que tous les bogues soient envoyés par courrier électronique à vos collègues et à votre responsable. Si le bogue est causé par son application, rendez-le visible dans le courrier électronique (mettez [XYZ APP BUG] dans le sujet du courrier électronique ou quelque chose du genre).

  • Maintenir une base de données de bogues (en plus de l’envoi de bogues par courrier électronique). Vous pouvez dire que son objectif principal est de suivre vos bogues, alors qu'en fait vous suivrez surtout ses bogues. Entre autres choses, il devrait suivre le temps nécessaire pour résoudre un bogue spécifique.

  • Ayez toutes les communications inter-processus avec son application couvertes de tests ("quand je vous ai envoyé ceci, vous devriez me rendre ce style"). Vous pouvez configurer une tâche périodique qui exécute ces tests chaque jour et en cas d'échec, un courrier électronique est envoyé à tout le monde.

En gros, essayez de ne pas perdre votre temps à discuter avec lui de bugs et à vous concentrer sur votre travail. Si son application est en panne et que vous ne pouvez donc pas travailler sur votre application et que le responsable n'en fait rien - eh bien, c'est un problème de gestion et vous êtes couvert d'une base de données de bogues, de courriels et de rapports de test.

Cependant, faites attention et ne le sous-estimez pas. Un fainéant de longue date comme lui pourrait avoir un tour ou deux dans sa manche. Il peut retourner toute l'équipe contre vous ou quelque chose, mais cela dépend de votre situation et c'est un peu hors de portée de cette question.

Lukas Stejskal
la source
45
+1 pour souligner que le questionneur ne doit jamais mentir sur le statut de son projet.
Eric Hydrick
6
J'allais suggérer une bêtise, mais les suggestions de Lukas sont meilleures!
Russ Clarke
9
+1 pour 'attention et ne le sous-estime pas. Un fainéant de longue date comme lui pourrait avoir un tour ou deux dans sa manche ». Il doit vraiment avoir ...
amyassin
3
@ Brian, je crois que ces solutions techniques peuvent résoudre le problème de la relation. Notez que le collègue est âgé de 5 ans et développeur prétendument assez capable. Ashin, quant à lui, est un débutant et n'a donc pas beaucoup de poids. Dans ce cas, il est préférable de s'en tenir à des faits concrets plutôt que de parler du problème avec le (s) collègue (s) et éventuellement le responsable. Si c'est mot contre mot, le responsable fera probablement confiance au collègue - ou non, mais il n'a pas les moyens de le contrarier de toute façon car il pourrait être précieux pour l'entreprise (maintenance des systèmes hérités, etc.)
Lukas Stejskal
3
Pour ajouter au point d'intercommunication, simulez également le système externe (c / c ++). Vous avez votre projet, il a le sien, alors ne laissez pas son projet en cours d’arrêter le vôtre. Faux les résultats attendus de son service pour votre application et écrivez un test qui compare les deux. Je crois que Martin Fowler a un bon article sur cette pratique et je peux le recommander sans hésiter.
Cthulhu
128

Je vais présenter un point de vue légèrement controversé: vous dites que vous travaillez autant d’heures que vous pouvez rester éveillé. Alors peut-être qu'il n'est pas particulièrement injuste de dire "vous me faites mal paraître et je travaille en fait autant d'heures que je le souhaite." Peut-être qu'il a été là et a fait cela et peut-être qu'il a brûlé. Je vous promets que vous le ferez si vous continuez comme ça.

Sortez boire un verre avec lui un soir et voyez si vous ne pouvez pas bâtir une meilleure relation personnelle sur laquelle baser votre professionnel. Peut-être qu'en acceptant de mettre un peu plus et en acceptant de mettre un peu moins, vous pouvez travailler beaucoup mieux ensemble.

Si j'étais vous, je ferais également très attention à toute cette attitude "mon travail, votre travail". Entre vous deux, vous avez un produit à commercialiser et cela ne peut pas être bon pour ce produit, ce qui n'est pas bon pour l'entreprise ni pour le client et ils paient pour que vous travailliez tous les deux .

Cependant, je suis toujours d'accord avec les autres points de vue sur le fait que vous devez réexaminer l'importance de votre relation avec votre responsable et que vous devez faire attention à ne pas faire confiance à votre collègue. Je dis simplement que peut-être, juste peut-être, vous devez regarder vos propres actions ainsi que les siennes.

pdr
la source
44
Je conviens que travailler jusqu'à ce que vous ayez sommeil soit contre-productif. Personne ne devrait travailler plus de 40 heures à moins que ce ne soit un moment critique et certainement pas de façon régulière.
HLGEM
36
Considérez que si vous travaillez 12 heures et qu'il travaille 7 heures et que vous ne pouvez pas avancer s'il ne progresse pas, vous pourriez être celui qui finit par avoir mauvaise mine . Après tout, il vous fallait 12 heures pour faire ce que le gars vient de faire en 7! Alors peut-être qu'au lieu de ralentir ou d'accélérer, vous devriez demander un projet supplémentaire sur lequel vous pourrez passer des heures supplémentaires, en attendant que vous fassiez sa part. Il y a sûrement d'autres choses que vous pourriez faire / apprendre / documenter?
Konerak
4
C'est un bon conseil pour ashin. Il peut (devrait) bien sûr se défendre avec de bons tests unitaires, une bonne documentation, des informations de type CYA, mais en tant qu'êtres humains, nous sommes dans le même bateau. Étirez-vous et trouvez un moyen d'approcher votre collègue - travaillez avec lui et non avec lui. Ne soyez pas si étroit avec "le vôtre" et "le mien" si vous n'avez pas à tracer cette ligne. Cela pourrait empêcher de résoudre ce problème entre vous. Vous devrez apprendre à être ouvert et flexible, alors pourquoi ne pas le faire lorsque vous n'êtes pas surchargé et voir si vous pouvez faire en sorte que cela fonctionne sans la participation du responsable. Cela sera sûrement remarqué sans que vous ne disiez jamais un mot.
bmike
9
+1 pour les srs. Je me rends compte que le format correspond à la question qui a été posée, mais tout le monde semble vraiment heureux de parler du parti B après avoir entendu l’un des aspects d’une histoire qui implique au moins trois personnes. Peut-être que le niveau de sortie de la partie B est tout à fait satisfaisant et conforme à son niveau de rémunération depuis des années, jusqu'à ce qu'un nouveau membre du groupe préfère rester au bureau 12 heures et parler du manque de dédicace de tous les autres?
Affe
15
@Ashin: Sérieusement, je comprends ce désir en début de carrière et je ne cherche pas à l'annuler. Mais je vous préviens que cela finit par conduire à l'épuisement professionnel et que ce n'est pas une chose agréable à vivre. Même si vous passez votre temps libre sur des projets personnels, cela vous aidera. Mais quelqu'un m'a dit quand j'ai commencé cette carrière que j'avais besoin de passe-temps en dehors du codage. Je ris et le renvoyai - pourquoi voudrais-je faire cela? Et j'ai payé pour plus tard.
pdr
40

Tenir des registres. Documentez chaque erreur que vous obtenez en communiquant avec son équipe, lorsque vous lui demandez de réparer et quand (le cas échéant) il le fait. C’est la seule façon dont je connaisse la situation. Ainsi, lorsque votre responsable vous demande pourquoi les choses ne progressent pas, vous pouvez clairement le montrer sans être perçu comme un vengeur ou un mauvais collègue.

Otávio Décio
la source
5
Les enregistrements de courrier électronique sont particulièrement utiles pour cela. Je fais toujours un suivi de chaque accord avec un courrier électronique et avertis toujours lorsque j'ai terminé par courrier.
Pelshoff
5
@ Pelshoff - absolument. Même si chaque personne se trouve dans une seule pièce, envoyez un e-mail avec le document contenant vos demandes et le suivi avec cc au responsable.
Otávio Décio
16
Il vous a demandé de ne pas informer le responsable devant le responsable? S'il vous le demande personnellement, dites-lui que vous le ferez après l'avoir clarifié avec le responsable. Autre chose - ne donnez JAMAIS la moindre impression que vous vous plaignez. Formulez-le toujours de manière à montrer simplement les faits, rien de plus, rien de moins.
Otávio Décio
3
Le problème est qu’en tant que salarié, vous avez la responsabilité de faire réussir l’entreprise. Et si l'entreprise réussit, cela signifie que vous réussissez (augmentation, bonus, avantages). Cette personne nuit à l'entreprise et donc indirectement à vous. Levez-vous pour la compagnie et vous-même :)
Pelshoff
3
@Ashin: Il peut vous demander de ne pas copier le responsable, mais cela ne signifie pas que vous devez vous conformer. At-il le pouvoir de faire quoi que ce soit si vous continuez à diriger le directeur CC? En outre, vous pouvez utiliser la fonctionnalité BCC pour qu'il ne sache pas que le responsable a été traité par CC.
FrustratedWithFormsDesigner
34

J'aimerais signaler une autre possibilité qui n'a pas été évoquée. Vous dites qu'il veut que vous ralentissiez votre travail. Voulez-vous dire littéralement qu'il dit «travaillez moins d'heures» ou qu'il dit «écris des tests, teste-le davantage, écris de la documentation» et d'autres choses qui, selon toi, vont te ralentir? J'ai vu de nouvelles personnes écrire du code 16 heures par jour, puis se plaindre de bogues dans le code qu'elles appellent alors qu'elles transmettaient des paramètres non valides, qu'elles ne vérifiaient pas les valeurs renvoyées, etc. Je ne peux pas exclure que votre collègue pense à ces choses.

La prochaine fois que vous participez à une réunion et qu'il vous dit que tout son code est bon, dites: "Oh, bien, ce que je vous ai dit il y a une heure, et qui explose lorsque j'appelle XYZ avec une date qui n'est pas un jour ouvrable, est corrigé maintenant? " Une des trois choses va se passer:

  • Il mentira et dira qu'il n'y a pas un tel problème, vous direz "il y en a donc! Nous en avons discuté! Je vous ai envoyé un e-mail!" et le tout viendra à l'attention d'un gestionnaire
  • Il vous dira qu'en fait, ce n'est pas un bogue dans son code, c'est un bogue dans votre code, car vous n'êtes censé passer que quelques jours ouvrables, et vous découvrirez bientôt ce à quoi il pensait sans le dire.
  • Il dira "non, celui dont vous venez de me parler, je le traiterai aujourd'hui, mais tout le reste est bon." S'il dit ça, merci de le remercier pour le moment.

Vous apprendrez peut-être que vos longues journées de codage rapide ne produisent pas un bon code et que quelqu'un (votre responsable, par exemple) peut traduire pour que l'autre développeur vous explique le problème. Ou, vous pouvez apprendre que vous travaillez avec un serpent couché qui vous fera paraître mauvais pour protéger sa position pépère. Mettre les choses au clair ne peut pas vraiment aggraver la situation. Vous pouvez également obtenir assez de mouvement de sa part pour pouvoir le supporter, sans vous laisser entraîner par la politique.

Kate Gregory
la source
1
Oui, pendant ma phase de démarrage, il avait l'habitude de dire que l'erreur était due au fait que je n'avais pas passé les arguments corrects. Et donc j'ai créé un journal en python qui va enregistrer une information avant et après avoir appelé ses méthodes. Et je vais enregistrer les arguments que j'ai passés et le statut de retour que j'ai obtenu. Et quand encore il m'a dit ça. Je lui ai montré mon journal et il a donc commencé à corriger ses bogues un par un. Mais ce qui est triste, c’est qu’il le savait très bien, qu’il pense peut-être à le réparer plus tard ou qu’il ne le teste pas du tout. il ne fait que donner ses méthodes.
HOT
32

Ce que vous avez est un problème politique. Tout d’abord, l’opinion de votre responsable est bien plus importante que vous ne le pensez. Ce mec vous blâme pour les retards et vous le laissez faire. Vous êtes celui qui sera renvoyé si quelqu'un est jeté sous le bus. À la connaissance du responsable, vous êtes celui qui est incapable de faire le travail rapidement.

Protégez-vous de toutes les manières possibles, par le biais du suivi des bogues, des courriels, etc. Ne donnez jamais au patron un faux rapport de situation, il reviendra vous mordre. Dites au patron la vérité sur les problèmes que vous rencontrez (et montrez-lui la preuve) avec le code qui ne fonctionne pas.

Cette personne qui vous demande de vous relâcher pour ne pas avoir mauvaise mine est un serpent (bien que ce soit une insulte à la communauté des serpents (référence subtile de Firefly), désolée pour tous les serpents qui existent actuellement). Il fera tout pour vous jeter sous le bus à la place de lui. Ne lui fait pas confiance.

HLGEM
la source
4
Je seconde ceci. Le logiciel de suivi des bogues est d’une importance capitale ici. Cela peut sembler gourmand, mais vous ne devriez jamais, jamais, mentir à votre patron pour dissimuler ses fautes. Cela ressemble à une situation très dangereuse, alors faites attention. Les courriels avec le responsable CCed sont une bonne idée. Et il peut vous demander de ne pas le faire, mais vous avez tout à fait le droit de l'ignorer et / ou de répondre à nouveau au courrier électronique et à votre responsable CC, refusant de suivre son exemple. Très douloureux pour la politique, mais montre la vérité de la question comme rien d'autre.
WolfgangSenff
1
+1 pour le premier paragraphe. En outre, le PO dit qu'il veut de bonnes relations avec ses collègues, ce qui implique en quelque sorte le pluriel, mais est principalement concerné par ce type injuste. Maintenant qu'il travaille avec ce gars-là, demain, d'autres collègues travailleront avec lui et recevront le même traitement. S'attaquer à la situation profitera à tous ses collègues à long terme.
Sharptooth
"Dites au patron la vérité sur les problèmes que vous rencontrez (et montrez les preuves) avec le code ne fonctionne pas." Mais quelle preuve? Si le responsable ne connaît pas le projet au niveau code / composants, vous ne pouvez pas lui montrer simplement le code. De plus, je crains que venir à une réunion avec le patron avec des impressions d'exceptions ne me paraisse trop attrayant.
Maayank
28

Tout d'abord:

Comme il est mon collègue, je ne pouvais rien dire au responsable.

Vous pouvez absolument et devez vous assurer que votre responsable connait la vérité, même si votre collègue ment au visage. Si vous ne voulez rien dire lors d'une réunion avec vous trois dans la salle, c'est tout à fait compréhensible. Mais vous devriez au moins tirer votre manager (le vrai, pas seulement le temporaire) de côté et leur faire savoir que votre travail est presque terminé et attend des corrections de bugs de la part de l'autre développeur avant que l'ensemble de l'application ne soit prêt pour le prime-time . N'accusez pas votre collègue de mentir, mais ne vous asseyez pas et laissez votre patron travailler avec des informations incomplètes.

Signalez vos statuts honnêtement. Si votre travail est bloqué par des bogues posés par un autre développeur, indiquez que vous avez trouvé des bogues dans le C / C ++ et les avez signalés (dites-moi que vous utilisez une forme de documentation qui laisse une trace écrite).

En attendant, terminez votre travail et informez votre patron lorsque vous avez terminé. Si votre responsable souhaite savoir pourquoi le reste du projet n’est pas encore opérationnel, vous pouvez le renvoyer à l’autre développeur, et peut-être mentionner que le projet est probablement très compliqué / volumineux / nécessite beaucoup de tests / que les autres développeurs sont très occupé / etc. Si vous connaissez le C / C ++, vous pouvez proposer une aide sur la logique principale de l'application pour que les choses bougent également. Oui, vous ferez le travail de l'autre personne, mais cela montre clairement que vous êtes un employé qui travaille dur et que vous êtes productif, et l'autre personne ne le fait pas, sans parler de vous rendre encore plus précieux pour votre patron. Cela peut même forcer un autre développeur à accélérer et à accélérer les choses.

Eric Hydrick
la source
5
Peut-être que son logiciel est d'un ordre de grandeur plus complexe que celui d'Ashin. Prendre la ligne dure avec un collègue avec lequel vous devez travailler en étroite collaboration mais que vous n'avez pas la peine d'apprendre à connaître est antisocial, contre-productif et très peu professionnel.
hplbsh
3
Celui qui paie votre salaire est votre entreprise et non votre collègue.
Rudy
@lttlrck Je suis d'accord avec vous, son application est plus complexe que moi. Mais c'est un projet existant. Comme notre société a une application autonome existante écrite en c & c ++ qui fait le même travail. Et maintenant, ils ont prévu de le construire sur le Web pour que l’utilisateur puisse l’utiliser directement sans l’installer. Et ainsi, autant que je sache dès le début de mon expérience auprès de lui et du responsable, ils utilisent le même code du projet existant légèrement modifié et exposent en outre ses classes et méthodes au python à l'aide de boostlibrary.
HOT
3
@Ashin kn, le fait que sa partie de l'application soit un projet existant n'implique pas nécessairement que sa tâche est plus facile que la vôtre. Peu d'applications initialement conçues pour être utilisées sur un bureau ne nécessitent que de légères modifications pour les exposer en tant que services (par exemple via une interface Web); les changements sont souvent plus importants malheureusement. Lorsque vous utilisez du code hérité pour changer complètement son utilisation, un léger changement peut rapidement entraîner de nombreux effets secondaires indésirables, même dans des applications qui n'étaient pas trop mal conçues au départ. Cela pourrait expliquer son attitude plus prudente, en paraissant aussi lente.
Bruno
1
+1 pourIf you know C/C++, you can offer to help on the main application logic to get things moving with that as well.
gyozo kudor
27

Il y a un certain nombre de problèmes au travail. Soit conscient que:

  1. Vous faites des suppositions sur les motivations des autres
  2. Vous colorez les faits avec des opinions.
  3. Les étrangers (quiconque) ne sont pas au courant de l'histoire et de vos frustrations avec votre collègue.
  4. Vous pouvez avoir l’air enfantin s’il semble que vous jouez à un jeu de type "gotcha". Votre collègue peut probablement mieux jouer. Après tout, il a toujours un travail, n'est-ce pas?

Par conséquent, lors de la présentation de l’état de votre projet:

  1. Ne mentionnez pas l'autre personne.
  2. Lorsque vous signalez des erreurs ou des problèmes avec le code - pas le développeur. Dites "L'appel à la méthode FooBar () renvoie 1 alors qu'il devrait renvoyer un 2". Alors, tout problème n’est pas une attaque personnelle, vous ne faites que parler de code - pas de personnes.
  3. tenez-vous en aux faits pour lesquels vous avez des preuves.
  4. Si votre collègue devient défensif ou hostile, posez des questions. "Je ne comprends pas pourquoi tu penses que je devrais faire _ "
  5. Soyez inconscient des affronts sociaux ou des insinuations. Imaginez que vous n'obtenez pas l'attaque personnelle.
  6. Dormez bien la nuit avant une réunion de mise en état, vous êtes donc agile mentalement.
  7. Document, document, document.
  8. Ne craignez pas de demander à ce gars de vous aider avec un problème intéressant, il pourrait vous contacter s'il sent que vous le respectez. Il s’agit de construire un rapport. (notez ceci n'est pas sucer - c'est autre chose)
  9. Préparez-vous à partir si vous devez le faire pour ne pas être pris au piège ni être pris au piège émotionnel. Cela vous aidera à garder votre tête dans les réunions.
Tapoter
la source
4
Jusqu'à présent, l'un des meilleurs plans ici. J'ajouterais seulement "sors et sens les fleurs" puisque la partie "travailler jusqu'à ce que je sois somnolent" semble effrayante.
Leonardo Herrera
@ Leonardo - merci :-) Je suis d'accord. L'équilibre travail / vie privée et tout cela, mais dépasse le cadre de la question du PO.
Pat
+1 pour signaler des erreurs ou des problèmes avec le code - pas le développeur
Ubermensch
16

"Je suis une personne qui aime travailler. Je passe la plupart de mon temps au bureau et je ne rentre chez moi que lorsque je me sens fatigué."

Cela n’est pas sain et on ne peut l’attendre de collègues, à moins d’être indemnisé au point de pouvoir prendre des années pour subir l’inévitable épuisement. (Quelque chose comme> 10% de propriété dans la société ou au-dessus de 200 dollars par an). Maintenir son expertise pour arriver au point où il peut se développer très rapidement prend du temps. Une partie de votre temps devrait être consacrée au développement de l'expertise.

"Le projet c / c ++ est l'application principale qui gère toutes les fonctionnalités. Mon python lui envoie la demande de l'utilisateur et en affiche la réponse. ... Peut-être qu'il n'aime pas le faire."

Python est un langage plus agile que C / C ++. Son application semble contenir toutes les fonctionnalités. votre application juste l'interface utilisateur. Plus probablement qu'autrement, ils ne sont pas égaux en difficulté. Il ne peut pas produire du code rapidement; mais le codage de qualité est bien meilleur que le codage de quantité. Vous avez peut-être des attentes irréalistes quant à la rapidité avec laquelle il peut coder pendant les heures où il est disposé / attendu à travailler (généralement environ 40 heures par semaine; et rappelez-vous que s'il est là depuis des années, il aura probablement accumulé d'autres tâches telles que la gestion des autres ou la maintenance des personnes plus âgées. projets qui occupent une partie importante de la semaine de travail).

Ne ment pas pour lui; mais encore une fois ne le critiquez pas non plus. Parlez de la supériorité de son système. étant donné qu'il a besoin de plus de travail jusqu'à son achèvement. Donnez à votre responsable une mise à jour précise de son statut sans nommer de noms ni attribuer de faute. Écrivez une version simulée de son système conforme à la même norme que son système. Assurez-vous que votre système fonctionne parfaitement avec votre système fictif avec une suite de tests automatisés. Ensuite, votre système peut être terminé (par exemple, il se synchronise parfaitement avec la maquette), même si le système en direct est toujours défectueux.

Ensuite, vous pouvez écrire une suite de tests automatique pour son système appelé en externe, conforme aux normes convenues. Par exemple, test que Foo (1,2,3) donne une réponse de "Bar 4 5 6". Cela pourrait l'aider à identifier les bugs et à accélérer son développement (et n'a pas besoin de jouer avec son code). Une fois ces opérations terminées, vous pourrez passer à un autre projet ou à une autre tâche (comme l’aider à utiliser les parties C / C ++).

dr jimbob
la source
12

Comme d'autres l'ont mentionné, le comportement professionnel est la chose la plus importante pour votre carrière à long terme. Et honnêtement, tant que vous vous comportez de manière professionnelle, vous serez en assez bonne forme, peu importe comment se comportent ceux qui vous entourent.

Dans cette situation, vous devez prendre en compte quelques considérations.

Tout d'abord, vous devez comprendre que vous êtes responsable de la conformité de votre programme aux spécifications souhaitées, dans les délais impartis. Si votre programme interagit avec le programme de quelqu'un d'autre, vous devez également vous assurer que cet autre programme fonctionne également dans les mêmes délais. En d'autres termes: si l'autre personne manque son délai, vous avez également manqué votre délai, même si votre propre partie du projet était à l'heure. En termes de gestion, cela s'appelle posséder les entrées .

Vous avez correctement noté que lorsque votre collègue déclare lors d'une réunion que les bogues de son programme sont corrigés, vous ne pouvez pas immédiatement le déclarer inexact au responsable (votre responsable verrait cela comme "jetant votre collègue sous le bus"; un très mauvais mouvement de carrière). D'autres, en revanche, ont fait remarquer qu'il est peu professionnel de ne pas déclarer le véritable état du projet au gestionnaire. Les deux côtés sont complètement corrects.

Donc, s'il est mauvais de contredire votre collègue devant le responsable et s'il est également mauvais de ne pas le contredire, que faites-vous?

La réponse est en fait assez simple: vous devez parler à votre collègue bien avant la réunion avec le responsable et leur faire savoir que lors de la prochaine réunion, vous devrez informer le responsable des problèmes que vous avez rencontrés. leur programme, leur impact sur votre capacité à livrer votre partie du projet à temps, et sur la possibilité de faire quelque chose pour les aider à résoudre les problèmes que vous avez rencontrés. Vous devez avoir cette conversation au moins deux jours complets avant la réunion, où vous en informerez le responsable, et de préférence une semaine complète à l’avance.

Dans la plupart des cas, le simple fait de dire à votre collègue que vous allez devoir inscrire son programme à un risque lors d'une réunion en particulier les motivera à résoudre les problèmes que vous rencontrez et vous n'aurez jamais à parler au responsable. . Dans d'autres, où les problèmes sont davantage liés à l'emploi du temps, le collègue est souvent d'accord avec vous et vous pouvez vous adresser au responsable en même temps.

Je n'ai jamais eu de collègue qui n'ait pas résolu le problème rapidement ou qui soit d'accord avec mes préoccupations, lorsqu'il est exprimé de cette façon. Mais si cela se produisait, en avertissant votre collègue à l'avance, vous seriez toujours mieux placé pour parler au responsable. Puisque vous avez parlé à votre collègue et que vous avez essayé de trouver une solution par vous-même, et que vous l'aviez prévenu bien à l'avance que vous deviez soulever la question lors de cette réunion, votre collègue ne serait pas surpris quand ils le feraient et le manager a gagné. Je ne pense pas que vous essayez simplement de déplacer le blâme.

N'oubliez pas que lorsque vous exprimez vos préoccupations, que ce soit au collègue ou au responsable, vous vous inquiétez du programme de votre collègue qui renvoie des données incorrectes (ou quoi que ce soit d'autre). Ce sont des choses mesurables qui peuvent être vérifiées et corrigées. Vos préoccupations ne concernent pas le fait que votre collègue soit lent ou non dédié; ce ne sont pas des choses mesurables, qui peuvent ou non être vraies, et qu'il est peu probable que l'on corrige en les évoquant lors d'une réunion devant le patron.

Trevor Powell
la source
3
+1 pour souligner que "se comporter de manière professionnelle est la chose la plus importante pour votre carrière à long terme".
Skarab
1
+1 excellente réponse - certainement le meilleur que j'ai jamais vu ici. Une solution humaine à un problème humain. Aucune mention des
suiveurs de
8

Quel système de suivi de bogues utilisez-vous? Je me serais attendu au moins à souligner les endroits où les bugs ne sont pas corrigés en temps voulu. Lorsque votre code attend une entrée de l'autre couche, les retards doivent être mis en évidence dans la documentation de suivi du projet. N'est-ce pas ce qui se passe non plus?

Il me semble que la gestion de projet est inadéquate ici. Vous devez a) suivre les bugs qui vous concernent et b) suivre les discussions par écrit.

Votre collègue ne devrait pas vous demander de gonfler votre temps de développement pour couvrir son manque de volonté. À un moment donné, c'est quelque chose qui devra être abordé avec votre responsable. Dans l’état actuel des choses, vous couvrez votre collègue et cela se retournera contre vous.

Temptar
la source
2
Le système de suivi des bogues n’est pas là. L'entreprise essaie d'achever le projet le plus rapidement possible et le confie à l'AQ. Et corrige ensuite les bugs signalés par QA. Je devrais même suggérer au responsable de démarrer un système de suivi des bogues capable de résoudre de nombreux problèmes comme ceux-ci, je l’espère.
HOT
Comment QA signale-t-il les bugs - par courrier électronique? Je veux dire, si vous étiez désespérément bloqué, vous pourriez faire quelque chose d'aussi simple qu'un tableur Excel avant de vous donner la peine de mettre en place un système de suivi des bogues complet.
Temptar
2
Exactement. Cacher pour des collègues ne peut jamais vraiment vous faire avancer dans une entreprise, ou du moins dans aucune entreprise avec des équipes de direction, même minimes.
WolfgangSenff
@temptar - QA signale par courrier électronique et il enregistre même les bogues, mais je ne suis pas aussi clair à ce sujet, car je suis ici depuis seulement 3 mois et c'est mon premier projet en cours. oui, comme vous l'avez tous dit, laissez-moi garder des dossiers par moi-même et laissez-moi informer mon responsable à ce sujet par courrier électronique. Merci pour les suggestions
HOT
2
@Ashin, vous voudrez peut-être examiner Trac ou Mantis car il s’agit de systèmes de suivi de bogues gratuits, relativement simples à configurer et à utiliser.
Tangurena
8

Il n'y a rien de mal à rester pour un collègue, mais quelqu'un doit s'attendre à ce que vous mentiez tous les jours à votre patron. Je ne pouvais pas le respecter en tant que personne et je n'avais aucun désir d'avoir cette personne comme connaissance occasionnelle. Il veut être un ennemi, amenez-le.

Comment pouvez-vous discuter des retards sur la couche application à cause du front-end? C'est pourquoi vous faites cela pour qu'ils puissent être séparés. Quelle est la suite, il a encore plus de retards parce que quelqu'un veut construire un frontal mobile?

Faites votre travail. Documentez tous les problèmes que vous rencontrez avec un échec sur son application. Et puis rentrez chez vous! Je me fiche de savoir si vous avez sommeil ou pas. Trouvez des amis qui valent la peine d'avoir.

JeffO
la source
4

Je viens de lire "The Clean Coder" de RC Martin (Oncle Bob). Le point principal du livre est que les programmeurs en général n’ont pas beaucoup de respect parce qu’ils ne se comportent pas de manière professionnelle . Cela signifie principalement qu'ils ne communiquent pas efficacement avec la direction à propos de l'état du projet.

Mentir est certainement une très très mauvaise forme de communication. Votre collègue est extrêmement professionnel et vous aussi. Vous ne faites rien tous les deux pour améliorer la perception des programmeurs.

Je vous conseillerais d'aller tout de suite à la direction. Cependant, j’ai eu des ennuis dans le passé pour avoir été trop «honnête» (dans une situation différente), je ne suis donc pas sûr que vous deviez suivre mon conseil. En outre, comme beaucoup l'ont souligné, votre perception de la situation n'est peut-être pas aussi précise que vous le pensez.

toto2
la source
3

Il est difficile et déraisonnable d'estimer l'effort relatif et la complexité d'un autre projet si vous n'êtes pas familiarisé avec la base de code. Vous dites que son code est sujet à des erreurs, mais il pourrait très bien fonctionner avec tous les problèmes restants à un niveau d'abstraction très élevé ... Le problème est que c'est le seul code dont votre front-end a besoin!

Ou peut-être qu'il est un mauvais employé et qu'il emmène l'entreprise en voiture. Je ne peux pas dire, et vous n’avez peut-être pas toutes les informations dont vous avez besoin de savoir en toute confiance.

Je suggérerais une tactique à mi-chemin. La prochaine fois que vous vous rencontrerez, apportez quelques détails sur un bogue majeur de son code qui vous concerne. Quand il dit que tout va bien, dites poliment qu'il existe un problème en suspens qui bloque vos progrès.

Politiquement, en disant cela, vous affirmerez qu’il n’est pas tout à fait correct, tout en lui laissant la possibilité de jouer le con et de ne pas être mis sur la défensive.

Votre responsable devrait demander lors de la prochaine réunion si le problème est résolu. Sinon, la pression lui incombe pour corriger un bogue. Si le problème est résolu, merci, cela fonctionne très bien maintenant et vous avez trouvé un nouveau bloqueur. Si vous voulez être particulièrement gentil, dites que vous l'avez rencontré peu de temps avant la réunion.

Vous ne mentez pas, en soi, vous ne prenez pas parti. Vous faites de la politique en attirant l'attention sur les problèmes et en laissant votre collègue sauver la face si les choses ne se déroulent vraiment pas très bien.

Il est tentant de parler à votre responsable, mais n'oubliez pas avec lequel vous devez travailler le plus.

Stefan Mohr
la source
2

La réponse de Pat était excellente. Je suis d'accord à 100%. Ne va pas faufiler une réunion avec le patron. Prenez-le avec votre collègue entre 4 yeux ou faites-le avec vous 3. Mais la suggestion de Pat de se concentrer sur les problèmes de code et non sur les personnes est la bonne voie à suivre.

Btw, 40h / semaine est assez mec. Vous devez garder votre motivation élevée!

AndSoYouCode
la source
1

Demandez quelque chose d'autre pour vous aider à tester l'intégration. La personne doit pouvoir dire où le problème se produit. Comme l'a fait remarquer temptar, je me demande pourquoi il n'y a même pas un excellent outil pour suivre les problèmes! comme il n’ya pas de suivi, c’est comme chaque fois que l’autre type s’échappe pour dire que tout va bien pour le moment! ça ne marche pas comme ça!

C'est votre module si vous avez besoin de le faire, vous devez lever le drapeau rouge sur ce qui cause le retard sur votre côté. Expérience dans MERE Years n’a rien à voir, c’est juste la connaissance et c’est ce sur quoi votre manager devrait insister. Comme je l'ai déjà dit, j'estime qu'il y a une mauvaise gestion du projet ici.

ioWint
la source
-1
  1. Faire preuve d'initiative en demandant des tâches supplémentaires et en vous demandant comment vous pouvez ajouter de la valeur à votre organisation est le meilleur moyen de gagner la confiance.

Votre responsable n’est peut-être pas assez technique pour savoir qui ralentit le projet, mais il est probablement assez intelligent pour reconnaître qu’un développeur qui recherche activement de nouvelles tâches accomplit ses tâches actuelles. Cela mènera à une conversation au cours de laquelle vous pourrez indiquer clairement que vous attendez que des correctifs soient apportés par d'autres sur votre tâche actuelle. Décrivez la discussion de la manière dont vous pouvez ajouter de la valeur à l’organisation en utilisant efficacement votre temps libre, et non comment votre collègue ralentit trop avec ses corrections de bugs.

KyleM
la source