Mon collègue est un gars sympa, mais sa performance est médiocre. Dois-je le dire à mon patron? [fermé]

J'ai été placé sur un projet il y a environ trois mois qui était jusque-là en cours de développement par un seul développeur nouvellement embauché parce qu'il était en retard. Pour être juste, le projet est une interface avec un dispositif médical qui a beaucoup de subtilités et est relativement complexe, donc placer une personne sur le projet qui n'avait aucune expérience dans l'entreprise était probablement une mauvaise décision d'un point de vue managérial.

Quoi qu'il en soit, une fois que j'ai commencé à travailler dessus, j'ai réalisé que ... eh bien, ça n'a tout simplement pas fonctionné du tout. L'interface utilisateur avait l'air bien, mais elle ne faisait pas grand-chose et ce qu'elle faisait faisait mal. Encore une fois, pour être honnête, cela était dû en grande partie au fait que ce développeur n'était pas correctement préparé pour écrire une interface sur notre appareil. Cependant, j'ai aussi rapidement réalisé que le code qui était en place était fragile et extrêmement difficile à maintenir.

Maintenant, je ne prétends pas être le meilleur programmeur du monde. Je travaille avec beaucoup de gens très intelligents qui sont de meilleurs développeurs que moi. J'essaie cependant très fort d'écrire du code aussi simple que possible et robuste. Je teste mes checkins. Si je constate que mon code devient désordonné et difficile à travailler au début, je le change. J'ai eu quelques discussions avec mon collègue pour essayer de l'aider à écrire un meilleur code. C'est un peu délicat car a) il a plus de 20 ans d'expérience dans le domaine et je n'en ai que 5, et b) il a été embauché en tant que soi-disant "expert UX" et d'autres le considèrent comme une personne expérimentée.

Cela dit, je ne le vois tout simplement pas. C'est un gars très gentil et il est raisonnable, mais à chaque fois il vérifie un code fragile, ne fonctionne que dans les cas les plus optimistes, et 9 fois sur 10 je finis par corriger des bugs dans son travail. Son code semble juste amateur et il n'a manifestement pas le niveau d'expérience qu'il prétendait avoir quand il a été embauché. Il est arrivé au point où les heures supplémentaires que je passe à refactoriser son code et à corriger ses bugs m'ont coûté cher. La façon dont je le vois, j'ai deux options:

1. Ne faites rien, cassez mes fesses pour vous assurer que ce produit sort à temps et est robuste et attendez qu'il échoue à l'avenir (je ne travaillerai pas avec lui sur ce projet après la sortie initiale.)
2. Parlez à mon patron de sa performance. Mon patron est un homme raisonnable, mais je me sens mal à l'aise en adoptant cette approche. Je n'aime pas «bash» (faute d'un meilleur terme) mes collègues et je ne sais pas comment il va le prendre.

Alors, c'est à peu près tout. J'ai essayé de résoudre ce problème avec mon collègue en expliquant pourquoi son implémentation ne fonctionnera pas ou comment son code pourrait être rendu plus facile à maintenir, mais il continue de faire les mêmes erreurs. Je suis très intéressé d'entendre comment d'autres ont géré des situations similaires, en particulier les membres de la direction actuellement. Merci d'avance pour tout conseil que vous pouvez m'offrir.

J'envisagerais au moins la possibilité que s'il était embauché en tant que gars UX, il se pourrait bien que personne n'attende vraiment de lui un code vraiment génial - ils peuvent s'attendre à ce que son code ne soit essentiellement qu'un prototype qui décrit l'UX, et c'est aux autres codeurs d'écrire du code de production basé sur cela.

Maintenant, je ne dis certainement pas que c'est le cas, mais cela ne me semblerait pas terriblement surprenant. Au moins d'après mon expérience, il n'est pas du tout rare que les gens UX produisent principalement des choses comme des prototypes et des storyboards. Si quoi que ce soit, si le gars a vraiment été embauché spécifiquement en tant que spécialiste UX, je suis un peu choqué par la notion de son contrôle du code. Je suis sûr que je n'ai jamais vu ça se faire.

Si le gars est vraiment un spécialiste UX, le remède n'est peut-être pas d'essayer de lui faire produire un meilleur code, mais de le faire sortir du codage (au moins tout sauf des prototypes). S'il est honnêtement bon en conception UX, la vraie erreur est probablement de lui demander même d'écrire du code de production. Au lieu de cela, il devrait probablement (au plus) travailler dans un sandbox de prototypage UX où son résultat est utilisé pour guider la prochaine série de code réel qui est produit, mais jamais archivé en tant que code de production.

J'essaie d'avoir une règle selon laquelle je tiens toujours mon patron informé des choses qui affectent le projet. Positivement et négativement ... et dans des cas comme celui-ci, j'essaie de blâmer des choses comme le code par opposition à la personne qui l'a écrit. Cela ressemble beaucoup moins à dénigrer un collègue et plus à essayer d'améliorer la qualité du produit.

Du point de vue de la direction, il existe 3 façons courantes de traiter avec les employés dans cette situation:

1. Maîtrisez leurs faiblesses
2. Jouez sur leurs points forts
3. Débarrassez-vous d'eux (pas vraiment votre choix)

Contrôlez leurs faiblesses en recherchant une aide extérieure.

Hé patron, je suis un peu inquiet de l'état du code ... il est assez fragile et se brise beaucoup. Il faudra un certain travail pour le mettre dans un état où je pense qu'il peut faire confiance. Y a-t-il une possibilité que je puisse emprunter l'un des architectes pour un jour ou deux pour voir si nous pouvons trouver un bon design?

Vous ne demandez pas à une autre personne de se joindre au projet, vous demandez davantage de «contributions d'experts» pendant une courte période. Produisez les documents dont ils ont besoin, des diagrammes UML et des extraits de code si tel est le souhait de l'architecte. Ils verront dans quel état se trouve le code, puis votre patron aura quelqu'un d'autre faisant écho à vos opinions.

Avec la réunion, vous obtiendrez, espérons-le, un meilleur design que vous et l'autre développeur pouvez suivre sans qu'il ne s'en défonce beaucoup. C'est pour cela que les conceptions et les spécifications dans de nombreux cas: réduire les dommages que les mauvais développeurs peuvent faire.

Jouez sur leurs points forts

Hey Boss, je travaille avec le code du projet x, et c'est magnifique. Le code, en revanche, pourrait utiliser un peu de travail. Je pense que le projet serait mieux si [ux guy] était capable de se concentrer davantage sur l'UX, tandis que je refactorisais pour le mettre dans un état plus stable. Une fois que l'UX est solide, le projet b pourrait probablement utiliser sa touche Midas.

Ici, votre patron va probablement voir à travers; que tu lui dis que l'autre dev n'est pas très bon ... mais au moins tu n'es pas un connard à ce sujet. Et s'il est vraiment très bon dans le travail UX, alors il pourrait trouver une position stable en sautant sur chaque projet et en les rendant grands du point de vue de l'utilisabilité. J'imagine qu'il aimerait mieux de cette façon aussi.

Arrêtez de réparer à plusieurs reprises ses erreurs. Il n'apprendra pas; Je sais que non.

La programmation est en grande partie une tâche logique, mais elle implique également le souvenir de la mémoire. Lorsque vous écrivez souvent du code commun, vous vous rappelez comment vous avez implémenté la solution la dernière fois , plutôt que de tout repenser. S'il n'a jamais implémenté le bon code, je peux voir pourquoi il continue de répéter les mêmes erreurs.

Montrez-lui ce qu'il a fait de mal et corrigez-le peut-être la première fois. Pour toute autre occurrence du même incident, demandez-lui de mettre en œuvre le correctif que vous lui avez montré.

Je serais très prudent pour plusieurs raisons:

1. Comment êtes-vous sûr de ne pas travailler avec lui après la sortie initiale? Votre direction pourrait penser: "Quelle équipe, regardez comment ils ont livré cette impression ensemble!" et je veux vous garder ensemble.

2. Si vous vous adressez à votre patron, dans quelle mesure voulez-vous être technique pour expliquer votre position? Combien de documents avez-vous sur les mauvaises performances de vos collègues?

Ce seraient les pièges que je noterais de ce que vous avez demandé. Je vous suggère de lui poser des questions sur le code et de voir s'il a des justifications pour expliquer pourquoi c'est ainsi. Peut-être qu'il tourne en rond tout en le codant, ce qui cause des problèmes. Le cercle est l'endroit où vous codez quelque chose, puis à travers une série de modifications, vous vous retrouvez à peu près exactement au même point que vous avez commencé, car la liste des modifications de quelqu'un s'annule à la fin. J'ai été dans des situations où cela change et annule les changements après les changements qui se fatiguent assez rapidement.

Quelles sont les conséquences si vous ne refaites pas tout son travail et laissez simplement le projet échouer? Les conséquences pour toi je veux dire.

Certes, quelqu'un de son niveau d'expérience et de sa position n'est pas arrivé par accident, alors soit son travail n'est pas aussi mauvais que vous le percevez, soit toute sa carrière est composée de gens comme vous qui le portent.

Si vous travaillez plus de 50 heures par semaine sur un projet, leur problème est grave et vous vous rendez service en ne le signalant pas au PM ou en partant. Je suis un fervent partisan du travail PLUS INTELLIGENT et NON PLUS DUR.

Travaillez un smart 50 et si le projet ne fonctionne pas, alors ce n'est pas votre faute. Si cela échoue à cause de son incompétence et qu'ils vous en veulent, ce n'est probablement pas l'environnement pour lequel vous voudriez travailler de toute façon.

Tant d'amis à moi travaillent BIEN au cours des 40 / semaine typiques sur un projet mal géré parce qu'ils ont peur de l'échec quand ils ne réalisent pas à quel point l'échec OU le succès affecte directement l'ensemble de votre carrière.

Plus de 80% des projets échouent, il n'y a pas de honte à cela.

Son appelé un examen par les pairs. Votre manager l'attend en quelque sorte de vous et doit être informé de l'endroit où son précieux temps de développeur est passé. Je suis surpris qu'il ne le sache pas déjà - mais encore une fois, j'ai vu pire.

Ne lui parlez pas en termes de l'autre type, parlez-lui en termes de travail quotidien que vous faites. Si cela signifie dissiper son code, tant pis. Allez armé de liens d'enregistrement, etc. pour donner une sorte de preuve de votre travail quotidien. Votre manager peut vouloir exactement cela de votre part - il apporte les 20 ans d'expérience utilisateur et vous obtenez le code robuste. Au lieu de faire des wireframes, il écrit simplement du code de niveau prototype. Parlez à votre manager.

Et j'espère que vous n'avez pas été embauché comme baby-sitter. Bonne chance.

Le projet sera-t-il lancé plus tôt si vous n'avez pas eu à réécrire / refaire son travail? Aidera-t-il à entrer sous le budget? Vous n'êtes pas obligé de dénigrer vos préoccupations. C'est là que la plupart des gens font une erreur, ils se plaignent sans proposer de solutions.

Y a-t-il des recommandations spécifiques que vous pouvez proposer à votre patron pour améliorer le résultat? Une meilleure documentation? Test utilisateur robuste? Votre objectif est de réussir l'entreprise, le projet, votre collègue et vous-même. Faire semblant qu'il n'y a pas de problème assure l'échec du tout pour trois des quatre --- et vous n'êtes pas le plus chanceux.

Vous devez aller voir votre patron dès que possible et lui dire clairement ce que vous avez dit ici.

Tout d'abord, il s'agit d'un appareil médical. Quelqu'un pourrait-il être blessé ou mourir s'il y avait un bug? Le code dont dépend la vie ou la santé des gens doit être aussi robuste que possible humainement, et non des ordures buggy rédigées par un optimiste pour le meilleur des cas.

D'accord, en mettant mon chapeau d'ex-manager ... vous ne savez pas si votre patron est au courant de cela, ou quelle sera sa réponse si c'est une nouvelle pour lui. Mais s'il ne le sait pas, il doit le faire, et vous ne devriez pas le deviner en cachant ces informations. S'il est d'accord avec le codage de votre collègue de cette façon, il vous le fera savoir.

Je suis tombé sur une situation comme celle-ci il y a de nombreuses années. Un «gourou du réseautage» et moi travaillions sur une preuve de concept en tant que contractants. En fait, il n'obtenait pratiquement rien, et faisait la plupart du temps des gaffes. Un jour, notre patron nous a dit que nous avions une démo à venir. Bientôt, le «gourou du réseautage» a commencé à recevoir beaucoup d'appels téléphoniques silencieux, et il m'a finalement dit qu'il allait partir avant la démo pour prendre un autre concert de contrat. Dès que j'ai pu obtenir notre patron seul, je lui en ai parlé. Il a jeté le «gourou du réseautage» et a fait venir quelqu'un que j'ai recommandé, qui a lancé plus de code en trois jours que le «gourou» a fait en trois mois. La démo a été un succès retentissant - mais si j'avais gardé le silence, le projet aurait complètement échoué.

Oui, dites-le à votre patron. Ensuite, vous verrez si ce n'est pas vous qui êtes à sa place. C'est le travail du manager de savoir comment fonctionne l'équipe et si le patron ne l'a pas encore remarqué, peut-être qu'il ne se soucie pas autant que vous du bon codage - comme beaucoup, beaucoup d'endroits où je suis allé.

Et parmi tous ces différents lieux de travail, si je suis plein d'amis (c'est-à-dire 5) d'amis, c'est déjà un grand nombre. Ils avaient tous des gars et des filles sympas, mais vous ne perdrez pas d'amitié en faisant votre travail - si vous les perdez, c'est une bonne chose. Dans votre cas, il valoriserait le travail plus que vous.

Certes, ce n'est pas une tentative de le faire virer. Cela montre simplement votre inquiétude sur le bien-être du projet, c'est pourquoi vous êtes tous (ou devriez) être là.

Vous avez essayé de lui parler, après tout, et si vous ne faites rien, vous risquez votre emploi là-bas.