Comment éviter les conflits avec le chef d'équipe?

Question

Actuellement, nous rencontrons des problèmes avec notre chef d'équipe concernant la hiérarchie de l'affectation du travail et la responsabilité du travail effectué. On voit généralement que si certaines cibles ne sont pas atteintes par l'équipe, le chef d'équipe commence ouvertement à blâmer l'équipe et parfois à pointer certains développeurs. De plus, lors de l'attribution du travail aux développeurs, le chef d'équipe n'explique pas correctement le travail à faire mais s'attend à ce que nous le complétons complètement. Le pire, c'est que le chef de projet et le chef d'équipe sont de vrais cousins ​​et que le chef de projet prend toujours le rôle de chef d'équipe lorsque de tels problèmes lui sont soumis par les développeurs.

Veuillez guider ce que les développeurs peuvent faire de mieux pour créer un environnement de travail sain.

Merci d'avance.

Answer 1

Bien les relations personnelles ne devraient pas être liées à la vie professionnelle. Les développeurs doivent tout d'abord organiser une réunion avec le chef d'équipe et présenter leurs problèmes de manière saine et explicative. Gardez également en boucle le gestionnaire de projet avec vos points de vue. N'attendez pas que quelqu'un fasse un environnement sain pour vous ... commencez-vous dans cette direction.

On devrait être capable de s'adapter à divers environnements et cultures différents selon les organisations. Toujours être avec le flux.

Answer 2

Ceci est double face, et très objectif. Cela dépendra peut-être du type de personne que le chef d'équipe est, et s'il est ouvert à des discussions/questions.

Le chef d'équipe devrait être ouvertement à ce sujet, MAIS aussi, si un développeur ne sait pas quoi faire, il devrait le demander.

Il ne fait jamais de mal à poser des questions, vous serez étonné de ce que vous pouvez apprendre.

Answer 3

Si possible, planifiez une réunion avec le chef de projet et le chef d'équipe. Discutez ouvertement des problèmes de façon mature et positive. Dites au chef d'équipe ce que vous aimez (en groupe), et dites-lui ce que vous pensez pouvoir faire pour améliorer la qualité, les attentes, les délais, etc. Si des exigences critiques sont habituellement manquantes, faites-le le savoir. Bien que son cousin soit le gestionnaire de projet, ses réponses peuvent être gardées et il pourrait être sur la défensive, peu importe les circonstances réelles. En fin de compte, à mon avis, la relation PM/TL est une formule pour un désastre. Si le problème est le chef d'équipe et que le chef de projet fait partie de ce problème, la prochaine étape logique est d'aller voir le chef du premier ministre.

Answer 4

Je ne suis pas sûr que vous pouvez éviter les conflits! Le défi est de décider quoi faire pour que tout le monde puisse apprendre et pas trop de gens se blessent.

Une équipe bien gérée devrait s'exécuter elle-même. C'est-à-dire que le rôle du chef d'équipe devrait être de mettre en place un bon cadre pour que l'équipe puisse décider des priorités, des techniques, des méthodologies et même des processus en discutant ensemble.

Alors les bons gestionnaires demanderont aux membres de l'équipe "OK, alors que feriez-vous?" Ils obtiendront alors le soutien approprié mis en place pour que cela puisse arriver.

Je suggère qu'en tant que groupe vous

• Régulièrement vous réunissez (peut-être par semaine) pour examiner les progrès et apprendre des erreurs commises dans la mise en œuvre.
• Assurez-vous que toutes les tâches sont attribuées à l'équipe dans son ensemble, et non à des développeurs individuels. Tout le monde devrait connaître le résumé de haut niveau d'un travail.
• Réunissez-vous tous les jours pour résumer très rapidement les progrès. Gardez cette réunion limitée à 10 minutes.

Dans ces réunions, il est préférable d'éviter de blâmer les gens. Blâmer le code à la place, ou le processus, mais ne soyez pas personnel. Et si la culture de votre entreprise le permet, essayez de lire quelques ouvrages sur la gestion de projet agile: de nombreuses parties de ce processus sont conçues pour éviter les conflits de cette nature. Cependant, il peut être assez difficile pour certaines organisations de déléguer autant de pouvoir aux développeurs ...