Quand affronter un bon chef de projet ou patron

Notre chef de projet est un architecte logiciel de génie, une personne douce et attentionnée en général, un geek par nature et délicat par la voix. Mais, parfois, nous (mes coéquipiers et moi) différons d'opinion - en particulier sur les problèmes d'architecture logicielle, de conception de système, d'interface utilisateur, etc., avec notre chef.

Quand et comment (si jamais) devrions-nous exprimer la différence d'opinions?

Supposons que vous pensez que votre patron a tort. Vous avez trois options

• faire ce qu'il dit et finir frustré en pensant que vous faites quelque chose de stupide - pas très bon à long terme
• dites-lui qu'il est un idiot - il l'ignorera ou vous aurez des problèmes de communication - ne vous apportera rien ou vous blessera.
• dites-lui que vous avez des préoccupations spécifiques concernant les idées qu'il propose et expliquez ces préoccupations - tout bon patron expliquera sa position et vous pourrez alors prendre une décision qui soit bonne pour l'entreprise. Il est fort probable que vous verrez que son idée est meilleure que la vôtre et que vous avez ignoré quelque chose de très important.

Pensez toujours au résultat. Dans la plupart des cas, vous ne voulez pas avoir raison pour avoir raison, il vous suffit de faire du bon travail. La troisième option aide à atteindre cet objectif.

Traitez-le de la même manière - avec douceur et respect lors de votre opposition.

Être professionnel implique d'être respectueux de vos pairs et supérieurs, cela ne signifie pas que vous ne pouvez pas être en désaccord, cela signifie simplement qu'il doit être poli et respectueux.

Lorsque mon équipe a un doute ou une opinion dissidente sur mes orientations, je la considère comme une opportunité de formation, pour moi et les membres de mon équipe.

N'est-ce pas là un exemple de l'ancien sophisme, soit agressif, soit passif?

La troisième option classique est l'assertivité, qui permet une critique constructive et un désaccord poli .

Tout aussi important - accepter une critique constructive (sans nécessairement être d'accord avec elle) et accepter un désaccord raisonnable (ne pas être obsédé par un concours qui a raison et qui a tort).

http://en.wikipedia.org/wiki/Assertivité

Et à la fin de la journée, une sorte de passivité - s'en remettre à votre supérieur - sera toujours nécessaire. Il est celui qui a la responsabilité ultime de la décision - capacité, autorité et responsabilité ne sont pas la même chose, mais au moins ils devraient aller de pair.

BTW - "People Skills" par Robert Bolton est un bon livre (et assez bon marché) pour des choses comme ça - l'écoute, l'assertivité, et plus encore.

http://www.amazon.com/People-Skills-Yourself-Resolve-Conflicts/dp/067162248X

Puisque vous semblez le respecter et qu'il ressemble à un gars intelligent, pourquoi ne pas simplement lui demander de la manière suivante:

"Comment votre méthode / méthode / architecture gère-t-elle le problème x?" Si ce n'est pas le cas, dites quelque chose comme: "Et pourquoi ne pas le faire comme ça, de cette façon que le problème x est géré?"

De cette façon, vous pouvez savoir s'il a déjà pensé à "problème x" et s'il a appris quelque chose. Ou s'il ne l'a pas fait, il y réfléchira et peut-être utilisera votre solution ou en pensera à une autre (peut-être que vous travaillerez ensemble).

J'aimerais pouvoir donner un exemple plus concret, mais je pense que vous devriez pouvoir comprendre l'idée.

Je ne pense pas que vous arriverez d'abord à votre patron, surtout s'il n'est pas programmeur ou quelque chose comme ça.

Et il n'est pas nécessaire de dire que son chemin est mauvais, mais en lui demandant comment il gère certaines situations, il pourrait réaliser un problème ou être en mesure de vous dire pourquoi ce n'est pas un problème.

J'espère que ça aide.

En utilisant le mot CONFRONT, vous montrez que vous n'abordez pas le problème avec la bonne mentalité.

Ce n'est pas une confrontation. Ce n'est pas hostile. Ce n'est pas belliqueux ou en colère. Il s'agit d'une discussion des différentes approches et des coûts et avantages.

N'entrez pas avec six armes à feu. Dites-lui simplement quelque chose à quoi vous avez pensé. "Et si on le faisait comme ça?" Qui sait, vous pourriez le convaincre.

Et si vous ne le faites pas - et parfois vous ne le savez pas - rappelez-vous qu'il sait peut-être des choses que vous ne connaissez pas, sur les budgets, les calendriers, les exigences, les autres priorités, etc. Ce n'est pas nécessairement un idiot juste parce qu'il n'est pas d'accord avec vous.

Il n'est pas faux de douter de décisions ou d'une architecture de conception / logiciel donnée. À moins que vous ne commenciez votre premier emploi, auquel cas vous vous tromperez 99% du temps car vous manquez certaines parties de la situation dans son ensemble .

Lorsque vous (et / ou l'équipe) différez d'opinions, demandez au chef de projet s'il a un peu de temps pour en discuter, ou peut-être même prévoyez une petite réunion (15-30 minutes). Exprimez votre propre opinion avec respect et écoutez pourquoi il a pris sa décision autrement. Si je vois comment vous l'avez décrit, il se fera un plaisir de discuter et de partager ses idées sur le problème. Il ne dira pas "parce que je l'ai dit" (de telles personnes existent malheureusement). Dans ce cas, ignorez simplement votre propre opinion si vous souhaitez conserver votre emploi, ou évacuez-le et partez pour un autre emploi parce que vous serez malheureux.

Une bonne discussion peut se terminer de plusieurs manières:

• Le chef de projet acceptera votre solution comme un meilleur moyen de résoudre le problème (et il a peut-être appris une nouvelle technologie, un modèle, ... avec lequel il n'avait pas encore beaucoup d'expérience).
• Vous et l'équipe pouvez voir une plus grande partie de l'image, ou obtenir une bonne explication pourquoi vous devriez le faire de cette façon et de cette façon. Vous apprendrez quelque chose de nouveau et comprendrez que la solution initiale était la bonne, ou vous trouverez peut-être même un moyen de l'améliorer avec les nouvelles informations (bien que vous deviez à un moment donné être d'accord).
• La discussion n'aide pas et vous n'êtes toujours pas d'accord. Aspirez-le et implémentez sa solution (car il aura probablement plus d'expérience), ou partez.

Quoi qu'il en soit, vous devriez le voir comme une occasion d'apprendre et tant que vous le gardez civilisé et respectueux, vous aurez de grandes expériences avec ces discussions.

Apportez-le!

De la manière la plus civile et la plus compliquée que je puisse, je dirai généralement "Je suis préoccupé par cet aspect, que pensez-vous de ce problème potentiel?"

Je mettrai la balle dans son camp pour m'instruire.

Le signe n ° 1 d'un développeur et gestionnaire mature est qu'il est capable d'admettre qu'il a tort. Démontrez d'abord à votre patron que vous êtes tous parfaitement prêts à admettre que vous avez tort lorsque vous l'êtes, et dites clairement à votre patron que vous attendez de lui la même courtoisie.

Si vous avez un bon patron (et vous dites que c'est le cas), ce ne sera généralement pas un problème du tout! Vous verrez que vous pouvez avoir une discussion constructive et trouver la meilleure solution pour vous tous.

Une chose à laquelle vous devez faire attention: assurez-vous que la plupart du temps vous avez de réelles raisons techniques et fondées de douter de la conception proposée. "Ça ne va pas" n'est généralement pas suffisant et ne contribuera pas à une discussion constructive. Si cela se produit trop souvent, votre patron n'aura d'autre choix que de court-circuiter la "discussion" (qui est factuelle, donc pas vraiment une discussion) et de dire "désolé les gars, mais vous ferez ce que j'ai suggéré jusqu'à ce que vous puissiez démontrer par des faits pourquoi une autre idée est clairement meilleure. "

C'est pourquoi votre patron est le patron - pour prendre les décisions que les développeurs peuvent avoir du mal à prendre.

À mon avis et comment je me comporte généralement avec mon patron:

Donnez toujours votre avis et faites-le dès que possible pendant que le sujet est chaud. Idéalement, lorsque vous avez une mêlée sur un nouveau problème ou projet plutôt que de le faire plus tard, lorsque vous avez rassemblé votre courage et que les décisions sont déjà prises.

Vous devez suggérer ouvertement vos opinions, vos préoccupations, vos problèmes et vous assurer qu'ils apparaissent comme des suggestions ou des préoccupations plutôt que d'imposer que cela doit être fait de cette manière.

Prenez l'habitude de cela et devenez un meilleur communicateur, un membre de l'équipe et à son tour, une meilleure équipe. Une bonne équipe parlera ouvertement des choses négatives et positives. Un bon chef d'équipe écoutera son équipe et prendra une décision en tenant compte des informations fournies.

Bonne chance.

S'il est aussi bon architecte que vous décrivez, approchez-le de manière instruite avec des raisons logiques et spécifiques à vos préoccupations.

Si vous avez le temps / les ressources, essayez de faire des tests des scénarios qui prouveraient que vous avez raison, avoir des données de votre côté est un énorme avantage.

Une fois que vous lui avez parlé, il ne peut que:

a) D'accord avec vous: problème résolu!

b) Rejette-les et explique pourquoi: peut-être qu'après tout, c'est toi qui a tort.

c) Rejetez-les sans raison: s'il est déraisonnable et que vous êtes totalement sûr, exprimez votre inquiétude au responsable du projet, dans ce cas vous avez vraiment besoin de données froides, et si vous le pouvez, du soutien des autres membres de l'équipe. Cela ne rendra pas l'architecte très heureux, mais c'est la chose éthique à faire (imaginez que vous conceviez un bâtiment et que vous avez vu un défaut dans la structure ...)

Ma question est: quand et comment (si?) Exprimer les différences d'opinions.

Absolument oui est la réponse. À moins que vous ayez une situation rare hors de votre contrôle plus grande où même le potentiel de turbulence ou de perdre votre emploi à cause de cela est si grand, vous devriez confronter les autres lorsque vous avez des opinions divergentes.

La vraie clé ici est quand et comment.

Premièrement, le «quand»: chaque environnement est différent, mais certains endroits ont des réunions hebdomadaires ou des tables rondes / ouvertes où aborder certains sujets est l'arène appropriée pour ce faire. La principale chose que vous ne voulez pas faire, c'est de faire comme si vous dépréciez ou de rendre public un argument de conception personnelle qui se situe entre vous et seulement 1 ou 2 autres. Les personnes que vous défiez n'apprécieront pas d'être interpellées et peut-être même embarrassées en public. Pour ces situations, essayez de planifier une réunion 1 contre 1 avec la ou les personnes en question pour détailler vos pensées.

2e le «comment»: si vous allez à une personne âgée, assurez-vous d'avoir tous vos canards d'affilée sur vos pensées. Vous ne pouvez pas simplement vous promener dans un bureau de personnes de niveau supérieur en disant "Tous les formulaires Web doivent être arrêtés et nous devons faire MVC!". Lorsqu'on lui a demandé "Pourquoi?" et vous dites: "Eh bien, c'est ce que tout le monde fait et c'est dans tous les magazines", ça n'ira pas loin. Préparez-vous à des discussions de va-et-vient et à être invité à justifier vos réflexions sur l'architecture, le codage, la conception, les meilleures pratiques, etc. Si vous avez des exemples de code de travail à justifier (c.-à-d. aider aussi. L'important ici est de ne pas entrer dans une bataille de l'ego ou de laisser les émotions monter.

En fin de compte, si vous avez des suggestions solides, justifiables et logiques, elles doivent être prises en compte. Cependant, soyez également prêt à ce qu'il n'y ait que des gens déraisonnables dans ce monde qui ne veulent écouter personne d'autre qu'eux-mêmes. J'espère que vous n'êtes pas pris dans un coin avec ce type de personnalité.

Bonne chance!

Je ne sais pas comment vous pouvez devenir un brillant architecte logiciel sans faire d'erreurs et être interrogé à leur sujet. Je pense qu'il est prudent de supposer qu'il a déjà été dans cette situation.

Les gens intelligents, matures et professionnels ne peuvent pas résister longtemps à l'attrait de meilleures idées. Même s'il est bouleversé au début par la remise en question de ses idées, à la fin il devrait revenir et vous gagnerez en respect. S'il n'est ni mature ni professionnel, vous avez un plus gros problème, et cela va peut-être l'éclairer.

S'il est architecte professionnel, il respectera et acceptera un deuxième avis. Cependant, dans tous les cas, vous devez bien préparer l'alternative en fonction des faits / expertise et également la présenter. Gardez également à l'esprit qu'en ce qui concerne l'architecture, il existe essentiellement deux possibilités différentes pour ces problèmes:

1. Une approche / conception peut être simplement bonne ou mauvaise, comme en mathématiques 2 + 2 = 4 et non cinq. En cas d'erreur, vous devez trouver la bonne solution dès que possible, sur la base d'objections factuelles.
2. De loin, la plupart des sujets de conception de systèmes sont des approches possibles qui ne sont pas exclusives. Il existe également d'autres alternatives qui fonctionnent, dont le choix dépend de l'expérience, de la saveur, du parti pris, de l'image globale, etc. Mais gardez également à l'esprit qu'il y a des périodes de discussions et des périodes de mise en œuvre, dans la programmation agile ces étapes sont bien définies.