Équipes de développement - Une mauvaise pomme peut-elle gâcher le peloton? [fermé]

... L'une des caractéristiques les plus importantes qu'un nouvel employé devrait avoir est la compatibilité avec l'esprit des personnes qui y travaillent déjà.
{...}
Je suis convaincu qu'il est tout aussi important de comprendre la véritable personnalité du développeur que de vérifier ses compétences professionnelles, car un mauvais ajustement peut détruire une équipe entière.

de l' embauche de développeurs - vous vous trompez

Est-ce vrai? Et si oui, est-ce vrai aussi pour les managers?

Plus que vous ne le pensez.

Pensez-y, si vous devez vous battre avec quelqu'un tous les jours, cela devient épuisant. Lorsque cela se produit, seules quelques options s'offrent à vous:

• Abandonnez et laissez la mauvaise personne faire ce qu'elle veut tout le temps, même si cela détruit le projet.
• Quittez l'équipe / l'entreprise pour éviter le mauvais ajustement.
• Tirez le mauvais coup et embauchez quelqu'un avec qui vous pouvez travailler.

Les disputes continues démoralisent l'équipe, et devoir justifier chaque petit point pédant aspire une réelle productivité. Cette personne est comme ça avec tout le monde, donc vous pourriez voir le taux d'attrition de votre équipe augmenter alors que l'irritant est toujours là. Cela devient difficile avec les gestionnaires, car vous n'avez pas le pouvoir de les licencier.

Dans une situation idéale, si quelqu'un agit, asseyez-vous avec lui et dites-lui gentiment mais fermement que ses actions sont destructrices. Expliquez comment vous aimeriez voir leur comportement changer pour aider l'équipe à mieux s'entendre. S'ils le reçoivent bien, tant mieux. Sinon, recourez à l'une des trois options ci-dessus, car cela va empirer. Une chose est sûre, à moins que vous ne le portiez à leur attention, il n'y a aucune chance de changement.

Bien sûr, c'est vrai. L'ajustement est plus important que la plupart des choses. Par exemple, si vous avez une équipe qui travaille en étroite collaboration et que vous embauchez un loup solitaire, vous pouvez vous attendre à des arguments, du code qui ne correspond pas à la conception et qui fait les choses d'une manière que les autres n'aiment pas et aucune intention de le réparer , manque de volonté d'aider les autres quand ils en ont besoin, refus de soumettre des choses au contrôle de code source, réécriture de code sans raison valable, sauf qu'il ne le voulait pas de cette façon, etc.

Si vous avez un groupe de gens sympathiques qui traînent ensemble et que vous embauchez quelqu'un qui veut travailler dans un silence total, vous aurez des frictions. Vous pouvez également être victime de harcèlement de la personne qui ne s'intègre pas.

Si vous avez un groupe de personnes qui veulent la liberté de faire les choses comme elles le souhaitent et que vous embauchez une personne orientée processus, il y aura des arguments continus, surtout si la personne orientée processus est le chef de file.

Si vous embauchez quelqu'un dont l'expérience et les antécédents en font un débutant dans une équipe où tout le monde est censé être senior, vous serez ennuyé car personne ne veut encadrer le gars ou l'aider à apprendre comme ils l'attendent, il devrait être capable de le faire sans aide.

Si vous embauchez quelqu'un qui attend des privilèges spéciaux que les autres employés n'ont pas - vous pouvez vous attendre à une guerre constante. Les sentiments sont "si Sally est si bonne qu'elle se met au travail à la maison alors que je ne le fais pas, alors pourquoi devrais-je l'aider?" Il y a du ressentiment quand quelqu'un entre dans une équipe s'attendant à des choses (et les obtenant) que les autres n'obtiennent pas, surtout quand ils n'ont encore rien accompli. Ou il y a du ressentiment de la part des nouveaux employés s'ils s'attendent à des choses et ne les obtiennent pas quand tout le monde est d'accord avec la façon dont les choses sont. Ensuite, l'employé malheureux perdra son temps à se plaindre et à traîner comme s'il était torturé parce qu'il devait arriver avant 13 heures.

Je dirais que oui, c'est vrai dans les deux cas, mais voici quelques liens qui peuvent intéresser les groupes:

• The Bad Apple: Group Poison par Jeff Atwood
• Tom Wujec: construire une tour, constituer une équipe par Tom Wujec à propos du Marshmallow Challenge

Sur une pensée un peu tangente, Gallup Q12 a quelques questions intéressantes pour mesurer l'engagement des employés si l'on s'intéresse à cette direction des choses. Tout cela n'est pas spécifique aux développeurs, alors peut-être qu'il y a des choses uniques à propos des développeurs qui peuvent rendre certaines de ces questions discutables.

Je me fiche de leur "vraie personnalité". Votre code ne dépend pas de vos passe-temps, par exemple si vous êtes une personne romantique ou très terre-à-terre. Ce qui est crucial, c'est que les gens font preuve de flexibilité et d'adaptabilité dans la vie des affaires . Leur vie personnelle est beaucoup moins pertinente. Mon collègue de travail peut être une personne ennuyeuse, tant qu'il fait du bon travail et que je peux collaborer facilement avec lui. J'ai travaillé avec différentes personnes, qui avaient des personnalités différentes, et j'ai simplement appris à les accepter autant qu'elles ont appris à m'accepter. C'est un travail, pas un mariage.

Ce ne sont pas seulement les programmeurs qui sont concernés par cela. Un bon conseil que j'ai entendu était: «Il n'y a rien de tel qu'une bonne embauche, seulement un bon licenciement».

Il est rare que quelqu'un ait suffisamment de compétences pour surmonter la perturbation d'une équipe solide et productive.

Les membres d'équipes peu performantes doivent être remplacés avant d'infecter la nouvelle recrue.