Comment gérer un collègue lent et non dédié dans l'équipe?
Je travaille sur un nouveau projet. Le projet fonctionne comme ceci: L'utilisateur final peut accéder à une webapp en utilisant un lien et il peut ajouter plusieurs systèmes sur son réseau et gérer les détails de ces systèmes particuliers. 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 qui est entièrement fait en c & c ++. Le projet c/c ++ est l'application principale qui fait toutes les fonctionnalités. Mon python = lui envoie la requête de l'utilisateur et affiche sa réponse à l'utilisateur.
Je connais très bien mon travail et je le terminerai bientôt. Puisque ce n'est pas beaucoup de travail. Et je suis une personne qui aime travailler. Je passe la plupart du temps au bureau et ne rentre à la maison que lorsque j'ai sommeil.
L'application c/c ++ est gérée par un autre collègue qui a plus de 5 ans d'expérience et peut 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. Elle est pleine 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 manager que mon travail a besoin de 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 de projet, lorsque le gestionnaire lui pose des questions sur les bogues, il dit qu'il a tout corrigé et que cela fonctionne bien. Comme il est mon collègue, je n'ai rien pu dire au manager. J'ai évidemment besoin d'avoir une bonne relation avec mes collègues plus qu'avec mon manager, car la plupart du temps nous serons avec nos collègues, pas avec le manager.
Je ne suis pas en mesure de dire quoi que ce soit au manager à ce sujet, car si le manager lui demande pourquoi, alors il peut penser que je me suis plaint de lui auprès du manager. Et il continue de mentir dans la réunion. Et comme il corrige le bug lentement, cela ralentit même mon travail. Maintenant, j'ai pensé à travailler sur la partie front-end de mon application et à la terminer afin que, dans l'intervalle, il puisse stabiliser son projet. Maintenant, il me demande de dire au gestionnaire que ma partie frontale nécessite beaucoup de travail et que j'ai peut-être besoin de plus en plus de temps, simplement pour qu'il puisse faire glisser le projet vers le bas. Et le plus triste, c'est que notre manager actuel est parti aux États-Unis, nous avons donc un manager temporaire et ce type ne connaît pas grand-chose du projet, donc le c, c ++ le trompe.
Quelqu'un peut-il me suggérer comment je gère cela? Je voulais terminer le projet bientôt. Comment puis-je le faire travailler même en maintenant une bonne relation avec lui?
Réponses aux commentaires:
S'il trompe vraiment délibérément l'entreprise, vous devez le signaler à la direction.
Je suis nouveau dans cette entreprise et l'autre gars est là depuis de nombreuses années. Et je viens de commencer à connaître mes collègues. Si je vais directement le plaindre, je ne pense pas que je puisse nouer de bonnes relations avec mes autres collègues. Même lui a le pouvoir de les induire en erreur. Je ne dis pas qu'il est un méchant, il peut faire le travail, mais il ne le fait pas.
Votre entreprise n'a-t-elle aucun type de système de suivi des bogues?
Ici, le véritable système de suivi des bogues n'est pas là. L'entreprise essaie de terminer le projet dès que possible et le donne au QA. Et puis corrige les bugs signalés par QA.
C'est pourquoi les entreprises devraient offrir aux employés des actions/options ou une sorte de propriété. De cette façon, vous pouvez littéralement dire au gars "Vous me coûte la croissance monétaire ... ne voulez-vous pas faire de l'argent aussi?".
La société dispose des options d'achat d'actions qu'ils m'ont accordées pour 2500 actions, la plupart du temps lui aussi en aurait obtenu davantage.
L'ancienneté mérite un certain bénéfice. Vous devez d'abord lui parler et essayer de comprendre le problème. Il peut être hors de sa profondeur, vous pourrez peut-être l'aider, il pourrait 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 gérait pas plusieurs demandes à la fois, il utilisait une file d'attente pour gérer les demandes que je lui envoyais. Je lui ai même suggéré quelques-unes de mes idées à ce sujet. Il a dit qu'il avait déjà ces idées et qu'il les mettra en œuvre. Ses explications étaient: "Tout nécessite un certain temps pour le faire et c'est un projet qui peut nécessiter deux ans et nous sommes priés de le terminer en deux mois". J'ai eu 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 d'un utilisateur et cela ralentit maintenant l'application, car elle traite une demande à la fois.
Que fait QA pendant tout ce temps? Pourquoi ne signalent-ils/ne confirment-ils pas l'état du ou des projets?
Le manager est la personne qui décide quand donner à l'AQ. Pour l'instant, il n'a pas encore été accordé à l'AQ. Il a dit que nous devrions le donner d'ici la fin de ce mois.
Vous êtes dans une mauvaise situation, je ne voudrais pas être à votre place. Il est peu probable que vous puissiez régler le problème sans entrer en conflit avec votre collègue.
Voici ce que je ferais:
Ne devenez pas son partenaire dans le crime. Refusez de mentir sur le statut de votre projet ou de son projet.
Implémentez (dans votre temps libre si nécessaire) des rapports de bogues dans votre application, de sorte que tous les bogues soient envoyés par e-mail à vos collègues et à votre responsable. Si le bogue est causé par son application, rendez-le visible dans l'e-mail (mettez [BUG APP XYZ] dans l'objet de l'e-mail ou quelque chose).
Maintenir une base de données de bogues (en plus d'envoyer des bogues par e-mail). Vous pouvez dire que son objectif principal est de suivre vos bogues, alors qu'en fait vous suivrez principalement ses bogues. Entre autres choses, il devrait suivre le temps qu'il faut pour corriger un bug spécifique.
Avoir 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 cron qui exécute ces tests tous les jours et s'ils échouent, un e-mail est envoyé à tout le monde.
Fondamentalement, essayez de ne pas perdre votre temps à vous disputer avec lui sur les bugs et à vous concentrer plutôt sur votre travail. Si son application est en panne et que vous ne pouvez donc pas travailler sur votre application et que le gestionnaire n'en fait rien - eh bien, c'est un problème de gestion et vous êtes couvert de base de données de bogues, d'e-mails et de rapports de test.
Cependant, faites attention et ne le sous-estimez pas. Slacker 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 spécifique et c'est un peu hors de portée de cette question.
Je vais jeter 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 "tu me fais mal paraître et je travaille en fait autant d'heures que je le veux". Peut-être qu'il a été là et l'a fait et peut-être qu'il s'est épuisé. 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 construire une meilleure relation personnelle sur laquelle baser votre professionnel. Peut-être qu'en acceptant d'en mettre un peu plus et en acceptant d'en mettre un peu moins, vous pouvez tous les deux travailler beaucoup mieux.
Si j'étais vous, je ferais aussi très attention à toute cette attitude "mon travail, votre travail". Entre vous deux, vous avez un produit à sortir et cela ne peut pas être bon pour ce produit, qui à son tour n'est bon ni 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 selon lesquels vous devez revoir l'importance de votre relation avec votre manager et vous devez faire attention à faire confiance à votre collègue. Je dis juste 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 lors de la communication avec son côté, lorsque vous lui avez demandé de corriger et quand (si jamais) il l'a fait. C'est le seul moyen que je connaisse pour faire face à cette situation. Ainsi, lorsque votre manager vous demande pourquoi les choses ne progressent pas, vous pouvez clairement le montrer sans être considéré comme un pleurnichard ou un mauvais collègue.
Je voudrais 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 "travailler moins d'heures" ou qu'il dit "écrire des tests, tester davantage, écrire de la documentation" et d'autres choses qui, selon vous, vous ralentiront? J'ai vu de nouvelles personnes courir autour du code pendant 16 heures par jour, puis se plaindre de bogues dans le code qu'ils appellent alors qu'en fait ils transmettent des paramètres invalides, ils ne vérifient pas les valeurs de retour, etc. Je ne peux pas exclure que votre collègue pense à ces choses.
La prochaine fois que vous êtes en réunion et il dit que tout son code est bien, dites "oh, bien, la chose que je vous ai dite il y a environ une heure, où ça explose quand j'appelle XYZ avec une date qui n'est pas un jour ouvrable, est réparé maintenant? " Une des trois choses va se produire:
- Il mentira et dira qu'il n'y a pas un tel problème, vous direz "il en est ainsi! Nous en avons discuté! Je vous ai envoyé un e-mail!" et le tout sera porté à l'attention d'un gestionnaire
- Il vous dira qu'en fait, ce n'est pas un bug dans son code, c'est un bug dans votre code, parce que vous êtes censé passer des jours ouvrables, et vous découvrirez bientôt ce qu'il a pensé mais ne dit pas
- Il dira "non, celui dont vous venez de me parler je vais m'en occuper aujourd'hui, mais tout le reste est bon." S'il le dit, remerciez-le pour l'instant.
Vous pouvez apprendre que vos longues journées de codage rapide ne produisent pas de bon code, et quelqu'un (votre responsable peut-être) pourrait traduire pour que l'autre développeur vous explique quel est le problème. Ou, vous pouvez apprendre que vous travaillez avec un serpent couché qui vous fera mal paraître pour protéger sa position moelleuse. Mettre les choses au grand jour ne peut pas vraiment aggraver la situation. Ou, vous pouvez simplement obtenir suffisamment de mouvement de sa part pour que vous puissiez le supporter, sans vous laisser entraîner dans la politique.
Ce que vous avez, c'est un problème politique. D'abord, l'opinion de votre manager est de loin, beaucoup plus importante que vous ne le pensez. Ce gars vous blâme pour les retards et vous le laissez faire. C'est vous qui serez licencié si quelqu'un est jeté sous le bus. Pour autant que le gestionnaire le sache, vous êtes celui qui est incapable de faire le travail en temps opportun.
Protégez-vous de toutes les manières possibles, grâce au suivi des bogues, aux e-mails, 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 avez (et montrez la preuve) avec son code qui ne fonctionne pas.
Cette personne qui vous demande de vous relâcher pour ne pas avoir l'air mal est un serpent (enfin c'est une insulte à la communauté des serpents (référence subtile de Firefly), désolé pour tous les serpents réels là-bas). Il fera tout pour vous jeter sous le bus à sa place. Ne lui fait pas confiance.
Tout d'abord:
Comme il est mon collègue, je n'ai rien pu dire au manager.
Vous pouvez et devez absolument vous assurer que votre manager connaît la vérité, même si votre collègue lui 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 devez au moins retirer votre gestionnaire (le vrai, pas seulement le temp) de côté et leur faire savoir que votre travail est presque terminé et attend les corrections de bogues de la part de l'autre développeur avant que l'application entière ne soit prête pour les heures de grande écoute . N'accusez pas votre collègue de mentir, mais ne vous asseyez pas là et laissez votre patron fonctionner avec des informations incomplètes.
Signalez honnêtement vos statuts. Si votre travail est bloqué par des bogues d'un autre développeur, documentez que vous avez trouvé des bogues dans le C/C++ et que vous les avez signalés (veuillez me dire que vous utilisez une forme de documentation qui laisse une trace papier).
En attendant, allez-y et terminez votre travail, et informez votre patron lorsque vous avez terminé. Si votre gestionnaire veut savoir pourquoi le reste du projet n'est pas encore opérationnel, vous pouvez le référer à l'autre développeur, et peut-être mentionner qu'il est probablement très compliqué/grand/nécessite beaucoup de tests/un autre développeur est très occupé/etc. Si vous connaissez C/C++, vous pouvez également proposer de l'aide sur la logique principale de l'application pour faire avancer les choses. Oui, vous ferez le travail de l'autre gars, mais il est clair que vous êtes l'employé qui travaille dur et est productif, et l'autre non, sans parler de vous rendre encore plus précieux pour votre patron. Cela peut même mettre la pression sur l'autre développeur pour accélérer les choses et les faire plus rapidement.
Il y a un certain nombre de problèmes à résoudre. Soit conscient que:
- Vous faites des hypothèses sur les motivations des autres
- Vous colorez des faits avec des opinions.
- Les étrangers (personne d'autre) ne connaissent pas l'histoire et ne sont pas conscients de vos frustrations avec votre collègue.
- Vous pouvez avoir l'air enfantin s'il apparaît que vous jouez à un jeu "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:
- Ne mentionnez pas l'autre personne.
- 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". Ensuite, tout problème n'est pas une attaque personnelle, vous parlez simplement de code - pas de personnes.
- s'en tenir aux faits dont vous avez la preuve.
- Si votre collègue devient défensif ou hostile, posez des questions. "Je ne comprends pas pourquoi tu penses que je devrais faire _"
- Soyez inconscient des insultes sociales ou des insinuations. Imaginez que vous n'obtenez pas l'attaque personnelle.
- Dormez beaucoup la nuit avant toute réunion de mise en état, afin d'être mentalement agile.
- Document, document, document.
- N'hésitez pas à demander à ce type de vous aider avec un problème intéressant, il pourrait vous en parler s'il sent que vous le respectez. Il s'agit de créer des relations. (notez que c'est pas sucer - c'est autre chose)
- Soyez prêt à partir si vous le devez, afin que vous ne soyez pas dans le besoin ou pris au piège émotionnellement. Cela vous aidera à garder la tête dans les réunions.
"Je suis une personne qui aime travailler. Je passe la plupart de mon temps au bureau et ne rentre à la maison que lorsque j'ai sommeil."
Ce n'est pas sain et ne peut pas être attendu de collègues, à moins que vous ne soyez compensé au point de pouvoir prendre des années de congé pour l'épuisement professionnel inévitable. (Quelque chose comme> 10% de participation dans l'entreprise ou plus de 200 000 $ par an). Maintenir l'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 fait toutes les fonctionnalités. Mon python lui envoie la requête de l'utilisateur et affiche la réponse de celui-ci à l'utilisateur. ... Peut-être qu'il ne le fait pas 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. Il est plus probable qu'improbable que ces difficultés ne sont pas égales. Il peut ne pas produire de code rapidement; mais le codage de qualité est bien meilleur que le codage de quantité. Vous pouvez très bien avoir des attentes irréalistes quant à la vitesse à laquelle il peut coder les heures qu'il souhaite/s'attendre à travailler (généralement environ 40 heures par semaine; et rappelez-vous s'il est là depuis des années, il a probablement accumulé d'autres tâches comme gérer les autres ou aider à maintenir les personnes âgées). projets qui occupent une partie importante de la semaine de travail).
Ne mentez pas pour lui; mais encore une fois, ne le critiquez pas non plus. Parlez de la qualité de son système; étant donné qu'il a besoin de plus de travail jusqu'à ce qu'il soit terminé. Donnez à votre responsable une mise à jour de statut précise sans nommer de nom/sans blâmer. Écrivez une version maquette de son système qui est conforme à la même norme à laquelle son système doit se conformer. Assurez-vous que votre système fonctionne parfaitement avec votre système maquette avec une suite de tests automatisée. 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 bogué.
Ensuite, vous pouvez écrire une suite de tests automatique pour son système appelé en externe qui est conforme aux normes convenues. Par exemple, tester que Foo (1,2,3) donne une réponse de "Bar 4 5 6". Cela pourrait l'aider à identifier les bogues et à accélérer son développement (et n'a pas besoin de jouer avec son code). Une fois ces choses terminées, vous pourrez passer à un autre projet/tâche (comme l'aider avec les parties C/C++).
Comme d'autres l'ont mentionné, un 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 la façon dont ceux qui vous entourent se comportent.
Dans cette situation, vous devez prendre en compte quelques éléments.
Tout d'abord, vous devez comprendre que vous êtes responsable du fonctionnement de votre programme selon les spécifications souhaitées, dans le délai imparti. Si votre programme interagit avec le programme de quelqu'un d'autre, vous êtes également responsable de vous assurer que cet autre programme fonctionne également dans le même délai. 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 propriétaire des entrées .
Vous avez correctement noté que lorsque votre collègue déclare lors d'une réunion que les bugs de son programme sont corrigés, vous ne pouvez pas immédiatement le déclarer incorrect au manager (votre manager verrait cela comme "jeter votre collègue sous le bus"; un très mauvais mouvement de carrière). D'autres, d'autre part, ont souligné qu'il n'est pas professionnel pas de déclarer le véritable état du projet au gestionnaire. Les deux côtés sont complètement corrects.
Donc, si c'est mauvais de contredire votre collègue devant le manager, et c'est aussi mauvais de le contrer pas alors, que faites-vous?
La réponse est en fait assez simple: vous devez parler à votre collègue bien avant la réunion avec le gestionnaire et lui faire savoir qu'à la réunion à venir, vous devrez informer le gestionnaire des problèmes que vous avez rencontrés avec leur programme, et que cela a un impact sur votre capacité à livrer votre côté du projet à temps, et si vous pouvez 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 parlerez au 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 devrez répertorier son programme comme un risque lors d'une réunion particulière les motivera à résoudre les problèmes que vous rencontrez et vous n'aurez jamais à parler au gestionnaire du tout . 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 rendre tous les deux au directeur.
Je n'ai jamais eu de collègue qui n'a pas arrangé les choses pour moi rapidement ou qui n'a pas été d'accord avec mes préoccupations, exprimées de cette façon. Mais si cela arrivait, en prévenant à l'avance votre collègue, vous seriez toujours mieux placé pour parler au responsable. Puisque vous avez parlé à votre collègue et essayé de trouver une solution par vous-même, et que vous les avez avertis bien à l'avance que vous auriez besoin de soulever la question lors de cette réunion, votre collègue ne sera pas surpris quand ils le feront, et le manager a gagné pensez pas que vous essayez simplement de rejeter la faute.
N'oubliez pas que lorsque vous exprimez vos préoccupations, soit au collègue, soit au responsable, vos préoccupations concernent le programme de votre collègue qui renvoie de mauvaises données (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 être vraies ou non, et qui sont peu susceptibles d'être corrigées en les évoquant lors d'une réunion devant le patron.
Quel système de suivi des bogues utilisez-vous? Je m'attendais à ce que, au moins, pour souligner 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. Cela ne se produit-il pas non plus?
Il me semble que la gestion de projet est inadéquate ici. Vous devez a) suivre les bogues qui vous affectent 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 manager. Dans l'état actuel des choses, vous couvrez votre collègue et cela se retournera certainement.
Il n'y a rien de mal à rester pour un collègue, mais pour que quelqu'un s'attende à ce que vous mentiez quotidiennement à votre patron, il faut y aller. Je ne pouvais pas le respecter en tant que personne et je ne souhaiterais pas avoir cette personne comme connaissance occasionnelle. Il veut être un ennemi, amenez-le.
Comment pouvez-vous argumenter 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 prochaine étape, il a encore plus de retards parce que quelqu'un veut construire un front end mobile?
Faites votre travail. Documentez tous les problèmes que vous rencontrez avec un échec sur son application. Et puis GO HOME! Je me fiche de savoir si vous avez sommeil ou pas. Trouvez des amis qui en valent la peine.
Je viens de lire "The Clean Coder" de R.C. Martin (oncle Bob). Le point principal du livre est que les programmeurs en général n'obtiennent pas beaucoup de respect car ils ne se comportent pas professionnellement. Cela signifie principalement qu'ils ne communiquent pas efficacement avec la direction au sujet de l'état du projet.
Le mensonge est certainement une très mauvaise forme de communication. Votre collègue est extrêmement peu professionnel et vous aussi. Vous ne faites rien de bon pour améliorer la perception des programmeurs.
Je vous conseille d'aller tout de suite à la direction. Cependant, j'ai eu des ennuis par le passé pour avoir été trop "honnête" (dans une situation sans rapport), donc je ne suis pas sûr que vous devriez suivre mon conseil. De plus, comme beaucoup l'ont souligné, votre perception de la situation n'est peut-être pas aussi exacte 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 familier avec la base de code. Vous dites que son code est sujet aux erreurs, mais il pourrait être en grande forme avec tous les problèmes restants à un niveau d'abstraction très élevé ... Le problème est que c'est le code seulement que votre front besoins finaux!
Ou, peut-être qu'il est un mauvais employé et qu'il emmène l'entreprise faire un tour. Je ne peux pas le dire et vous ne disposez peut-être pas non plus de toutes les informations dont vous avez besoin.
Je suggérerais une tactique à mi-chemin. La prochaine fois que vous vous rencontrerez, apportez quelques détails sur un bug majeur de son code qui vous affecte. Quand il dit que tout va bien, dites poliment là c'est un problème en suspens qui bloque votre progression.
Politiquement, le dire comme ça vous permet d'affirmer qu'il n'est pas tout à fait correct, tout en lui donnant une ouverture pour jouer muet et ne pas être mis sur la défensive.
Votre responsable devrait demander à la prochaine réunion si cela est résolu. Sinon, la pression retombe sur lui pour corriger un bug. S'il est correct, merci, il 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, et 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 passent vraiment pas si bien.
Il est tentant de simplement parler à votre manager, mais n'oubliez pas avec lequel vous devez travailler le plus.
La réponse de Pat était excellente. Je suis d'accord à 100%. N'allez pas faufiler une réunion avec le patron. Soit le prendre avec votre collègue entre 4 yeux ou le faire avec vous 3. Mais la suggestion de Pat de se concentrer sur les problèmes de code et non sur les gens est la bonne voie à suivre.
Au fait, 40h/semaine c'est assez mec. Vous devez garder votre motivation élevée!
Demandez-en d'autres pour vous aider dans les tests d'intégration. La personne doit être en mesure de dire où le problème se produit. Comme l'a souligné Temptar, je me demande pourquoi il n'y a même pas d'Excel pour suivre les problèmes! comme il n'y a pas de suivi, c'est comme chaque fois que l'autre gars s'échappe en disant que tout va bien maintenant! ç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 du côté ur. L'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 dit, même je pense qu'il y a une mauvaise gestion du projet qui se passe ici.