Situation compliquée. Vous avez mentionné l’éloquence comme l’un de ses pouvoirs spéciaux, mais dans une bonne équipe qui disparaîtra rapidement à la lumière d’une mauvaise prise de décision ou d’un travail de qualité médiocre. Ne sachant pas quelle est la culture de votre équipe ou comment les décisions sont prises, voici quelques suggestions générales:
- Espérons qu’il existe des processus de conception et de révision de code que le travail de chacun passe et est contrôlé par les membres de l’équipe. C’est une bonne idée pour n’importe quelle équipe, personne ne devrait construire ou prendre des décisions isolément.
- Développez une relation avec votre collègue. Ils sont beaucoup plus susceptibles de réagir à votre coaching technique ou à vos désaccords s’ils ont l’impression que vous êtes (sincèrement) de leur côté et qu’ils peuvent vous aider. Plusieurs fois, une conversation 1: 1 avant / après une révision d’équipe peut aider à changer d’opinion plus facilement qu’en groupe. Retournez toujours à l’équipe avec la mise à jour de la décision.
- Concentrez-vous sur les aspects techniques de la décision prise. Ne vous occupez jamais des personnes impliquées, concentrez-vous sur le meilleur résultat pour le projet et l’équipe.
- Pensez à ce qui intéresse les personnes / rôles de votre équipe et quels résultats ils voudraient ainsi éviter et concentrez-vous sur ceux de votre argument. Pour un ingénieur fainéant qui cherche la «bonne solution», montrez-lui comment il passera beaucoup plus de temps à supporter les bugs de la mauvaise conception. Pour le responsable qui s’inquiète pour les ressources, montrez qu’il devra consacrer plus d’argent à la maintenance d’un produit buggy. Etc.
J’espère que cela t’aides. Difficile de donner des conseils plus spécifiques sans en savoir plus.