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

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.

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.

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.

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.

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.

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.

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.

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.

"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 ++).

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.

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.

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.

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.

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.

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!

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.

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.