Vous devez leur dire qu'ils doivent se parler et s'entendre sur les exigences. Dites-leur que vous n'allez pas perdre votre temps à faire deux fois plus de travail par simple manque de communication.

Je ne vois pas de gros problème ici. Le superviseur A vous demande de faire X, puis le superviseur B vient et dit de faire Y ce qui contredit X.

Répondez à B que sa demande contredit A, en citant les instructions données à vous précédemment . Refusez - dans un environnement aussi hostile - de travailler sur les exigences par communication verbale. Insistez pour que vos supérieurs vous envoient un mail avec leurs exigences. Cela réduit l'ambiguïté et vous pouvez revérifier vos instructions en cas de doute. Et bien sûr, vous avez la preuve que vous avez fait ce qu'on vous a dit , si vous êtes blâmé pour le manque de communication de votre superviseur.

Notez, si ils refusent de vous écrire un e-mail, mais ne vous donnent que des commentaires verbaux tout le temps; Aucun problème. Résumez vous-même comment vous avez compris vos exigences et demandez-leur de confirmer votre résumé, avant d'écrire une seule ligne de code.

Ce scénario n'est pas rare dans n'importe quelle profession. Cela m'est arrivé dans deux autres emplois hors programmation.

Votre erreur concernait l'exécution du travail alors qu'il y avait un désaccord sur ce qui constituait une performance acceptable. Ne laissez jamais personne vous donner des exigences contradictoires sans mettre le conflit par écrit, en l'envoyant aux deux personnes pour le résoudre et en n'effectuant pas le travail jusqu'à ce que vous ayez une réponse écrite. S'ils ne parviennent pas à un accord, impliquez leur patron.

Il est de votre responsabilité d'identifier ces conflits et de les amener à être résolus. Il n'est pas nécessaire que ce soit méchant, juste un e-mail qui déclare: "Bob m'a dit de faire ceci et Jane m'a dit de le faire. Puisque je ne peux pas faire les deux, j'ai besoin d'une résolution sur laquelle est la méthode préférée." Dans ce cas, il est évident que la direction est mutuellement exclusive, mais dans certains cas, vous devrez peut-être expliquer pourquoi faire X signifie que vous ne pouvez pas faire Y.

Maintenant où vous devez être vraiment prudent, c'est quand le La raison pour laquelle ils ne sont pas d'accord est politique et non une véritable différence d'opinion technique. Dans ce cas, il est particulièrement important de rester neutre dans ce que vous dites et comment vous le dites. Vous ne savez pas qui va gagner le combat politique, vous ne voulez donc pas mettre la mauvaise personne en colère contre vous.

Une bonne et claire communication avec les membres de l'équipe est MUST pour le projet de développement logiciel! Sinon, c'est un grand candidat à l'échec.

Dans l'ensemble, une mauvaise communication entre les membres du projet et les parties prenantes du projet est responsable de 80 à 90% des raisons d'échec.

Comment y remédier?

• Rendez vos instructions extrêmement claires (c'est-à-dire clarifiez chaque détail des exigences et faites-les correspondre aux exigences approuvées), demandez à votre superviseur de vous envoyer un e-mail sont censés faire. Faites enregistrer régulièrement toutes vos exigences et tâches. Ainsi, en cas de défaillance, vous ne seriez pas tenu responsable. Plus important encore, personne ne vous envoie un black-mail ou votre travail.

Vous aurez peut-être besoin de plusieurs stratégies. En toute honnêteté, cela pourrait être un problème que vous ayez fini par coder deux projets car vous avez essentiellement perdu la moitié de votre temps en faisant le même travail deux fois. En tant que premier échec de travail, ce n'est pas un problème énorme - après tout, une partie du blâme est sur votre direction. Mais ce n'est pas une erreur que vous voulez répéter.

1. Commencez par une réunion - parlez aux autres membres de votre entreprise de la meilleure façon de procéder. Cela peut être aussi informel qu'un e-mail - envoyer un message aux deux en même temps pour demander des éclaircissements sur les divergences. Si l'un répond sans copier l'autre, copiez-le vous-même et dites «êtes-vous d'accord?». Ou cela peut nécessiter un face à face ou une conférence téléphonique où vous pouvez passer en revue les points un par un et obtenir un accord. Essentiellement, vous devez forcer un contexte dans lequel l'un ne peut pas vous guider sans que l'autre écoute et y accepte.
2. S'il ne peut pas être résolu de cette manière en temps opportun, faites remonter le temps. Ces deux ne peuvent pas être votre seul management. S'ils ne parviennent pas à un accord ou ne prennent pas les mesures nécessaires pour résoudre le problème dans les 1 à 2 réunions ou 2 jours suivant l'e-mail, communiquez avec leur patron. Expliquez la situation difficile en vous concentrant sur le problème - l'équipe ne s'entend pas sur la manière d'aller de l'avant. À ce stade, vous voulez vraiment recevoir des conseils par écrit. C'est bien au jour le jour d'obtenir des conseils sous forme verbale, mais vous avez DOUBLÉ le travail qui vous est demandé et ne résolvez pas réellement le problème de communication. C'est désormais un problème d'efficacité et vous avez besoin de la sauvegarde.

C'est une zone grise et je ne suis pas d'accord avec la ligne dure de certaines affiches. J'ai été dans une position où je devais continuer à travailler même si la direction ne pouvait pas être d'accord, mais je savais et me tenais responsable de la perte de ma propre productivité pendant que je travaillais pour résoudre le problème . Ce faisant, j'ai clairement indiqué que l'entreprise gaspillait de l'argent en termes de salaire, alors que la stratégie n'était pas claire.

Votre entreprise exploite-t-elle un wiki? Si c'est le cas, la solution la plus simple est peut-être d'exiger qu'ils vous donnent une spécification écrite de ce qu'ils veulent que vous fassiez, sous forme de page wiki. De cette façon, les deux superviseurs doivent mettre leurs idées sur une seule page (avec un peu de chance, résoudre leurs différences au fur et à mesure), et l'historique des modifications fournira un enregistrement clair de qui a dit faire quoi et quand.

Les wikis sont inestimables pour les projets techniques / logiciels, à mon avis. J'espère donc que votre entreprise en gère un. Sinon, vous voudrez peut-être voir si vous pouvez les convaincre d'en essayer un.

Votre problème ne vient pas de vos supérieurs. Vous pourriez avoir la même situation si vous n'avez qu'un seul superviseur qui ne cesse de changer les exigences. Il pouvait dire d'inclure la validation de l'e-mail, puis a changé d'avis le lendemain. Comment gérez-vous cela?

Votre problème est le manque d'exigences écrites .

Si vous aviez des exigences bien documentées, il vous suffisait pour écrire des logiciels selon les exigences. Par exemple. si les exigences stipulent que la validation des e-mails doit être mise en œuvre, vous le faites. Sinon, vous n'avez pas besoin de le faire. Si vous êtes invité à le mettre en œuvre, demandez les spécifications.

Je ne suis pas sûr que vous utilisiez correctement le mot «superviseurs». il semble que ce ne sont pas des superviseurs, juste des membres plus expérimentés de l'équipe qui vous évaluent. Ceci est étayé par leur réponse à votre mention des exigences contradictoires. Les superviseurs ont tendance à ne pas être sur la défensive face à de telles choses, seules les personnes qui ont peur de paraître mal le font. allez voir le chef d'équipe et dites à cette personne ce qui se passe. Organisez une réunion avec vous quatre, et par-dessus tout, OBTENEZ TOUTES LES EXIGENCES PAR ÉCRIT.

Demandez à votre superviseur direct ce qu'il doit faire. Bien qu'il puisse y avoir plusieurs membres seniors de l'équipe, vous n'avez qu'une seule personne qui rédige votre évaluation. C'est la personne à qui parler lorsque vous avez des problèmes.

Pour le moment, j'ai mon superviseur direct, son patron (son patron, etc.) plus quelqu'un avec qui je suis géré par la matrice. Quand il y a des conflits, je demande des éclaircissements. Le gestionnaire de matrice est sur un projet différent, donc nous n'avons pas de "problèmes dans les mauvaises herbes d'un projet".

Je partirais. Mais si vous voulez rester et essayer de vous en occuper (et y remédier, vous devez ou la vie sera un enfer pour vous), alors je ferais ce qui suit:

Organisez une réunion avec chacun d'eux.
Mais ne dites pas à chacun d'entre eux que l'autre sera également présent. Pensez fortement à inviter quelqu'un d'autre ou son manager.
Oui, tout cela prendra vraiment du courage mais vous pouvez le faire!

Soyez positif, soyez élogieux, parlez de votre enthousiasme pour le projet pour mettre les gens un peu plus à l'aise et allez-y directement. "Je suis horriblement en conflit parce que j'essaie de faire du bon travail, mais deux personnes différentes m'ont donné des instructions complètement contradictoires et je suis vraiment confus et bouleversé." vous allez devoir ÊTRE HONNÊTE AVANT sur ce que vous faites avec les deux versions pour essayer de faire la bonne chose, mais vous avez réfléchi plus tard et réalisé à quel point c'était une erreur.Oh et enterrer une de ces versions

Par définition, vous ne pouvez pas demander à deux superviseurs, quelqu'un est votre supérieur hiérarchique de faire ce qu'ils disent et de le documenter.

Ou en tant que développeur professionnel, implémentez simplement la validation de base pour les e-mails, c'est-à-dire que quelque chose @ quelque chose est professionnel à faire - le livre o reily sur les regexes est un bon point de départ.

C'est une situation difficile et pourquoi avoir une seule ligne de rapport a du sens.

Asseyez-vous avec les deux et expliquez que vous ne pouvez pas faire votre travail correctement avec des exigences contradictoires. Donnez-leur des exemples concrets de situations où cela a été un problème et expliquez à quel point c'est frustrant pour vous parce que vous voulez faire de votre mieux mais que vous ne pouvez pas à cause de la situation. exigences et qu'un processus de gestion du changement soit mis en place, exigeant l'approbation des deux avant que les exigences ne soient modifiées.

Lorsque vous êtes développeur de logiciels, le travail que vous effectuez est défini par une (série de) tickets. Vous recevez un ticket qui définit une tâche que vous devez effectuer. Le ticket est la Bible quand il s'agit de ce que vous devez livrer. Si le ticket ne dit pas que vous avez besoin de validation, vous n'avez pas besoin de validation (sauf dans la mesure où vous vous protégez contre les entrées malformées, les valeurs nulles, l'injection SQL, etc., dans la mesure où de telles choses ont du sens). S'il apparaît lors de la révision du code que vous avez besoin d'une validation supplémentaire, demandez au réviseur de modifier le ticket et de vous dire d'ajouter une validation dans le ticket. Ensuite, si vous ajoutez la validation et que l'autre critique demande pourquoi, alors vous pointez sur le ticket et dites "il est dit là-dedans pour faire la validation; si vous ne l'aimez pas, discutez avec la personne qui a écrit cela, pas moi , Je fais ce que dit le ticket ".

La seule chose importante à ce sujet est de ne jamais modifier vos propres tickets. Si vous modifiez le ticket, il semble que vous ajoutez simplement des éléments parce que vous le souhaitez, sans comprendre un contexte plus large. Demandez toujours à quelqu'un d'autre (idéalement quelqu'un de plus haut que vous dans la chaîne alimentaire et, de manière optimale, l'auteur original du ticket si possible) de modifier le ticket.