Question:
Le manager semble contrarié chaque fois que je l'informe d'un obstacle (mineur)
noteme123
2015-08-18 23:36:26 UTC
view on stackexchange narkive permalink

Mon responsable semble irrité lorsqu'il demande une mise à jour et que je l'informe d'un obstacle sur lequel je travaille. Par exemple, je travaillais sur l'implémentation d'un appel de sous-processus, et quand je l'ai essayé sur le programme à lancer, j'ai obtenu une erreur mais j'ai essayé une simple commande système et cela a fonctionné. J'ai alors commencé à rechercher en ligne des informations sur le message d'erreur.

Mon responsable est entré et a demandé une mise à jour au moment du dépannage. Je lui ai expliqué la commande que j'utilisais pour lancer le nouveau processus et lui ai dit que je l'avais fait fonctionner avec un exemple simple mais que j'avais une erreur lors du lancement du programme cible; lui a montré le message d'erreur. Je lui ai dit que je recherchais la cause de l'erreur. En lisant entre les lignes, il était mécontent et a fait un bruit moqueur et a dit "vous êtes le programmeur, je ne peux pas vous aider avec ça".

C’est mon observation si jamais je parle d’un «revers» ou montre un signe d’incertitude, il est mécontent. Comment dois-je résoudre ce problème ou dois-je l'ignorer? Dois-je toujours laisser de côté les obstacles?

Le manager est un peu technique mais ne connaît pas la programmation. Il vient de Russie et a grandi dans l'armée et il est clair qu'il vient d'une culture différente. Je ne dis pas que je pense que c'est comme ça que la culture russe est, mais je remarque avec mon manager qu'il pense très linéairement, en termes de binaire (que ce soit fait ou pas, oui ou non) et il est très en phase avec la structure des choses (par exemple, il ne se réfère souvent pas aux personnes par leur nom mais par leur position, par exemple le programmeur, le compte, etc.). Cette description n’est pas destinée à être sectaire, j’ai des amis russes et la différence de communication n’est peut-être pas du tout causée par la culture.

MODIFIER: Je suis un peu surpris par toutes les suggestions disant de ne pas donner de détails techniques mais de se concentrer sur le moment où les choses seront faites. Je pensais que plus de personnes sur ce site étaient nouvelles qu'il ne pouvait pas être prédit avec précision quand un programme sera terminé. Pour référence https://softwareengineering.stackexchange.com/questions/648/how-to-respond-when-you-are-asked-for-an-estimate

Il me semble que vous venez de découvrir un modèle dans le comportement de votre responsable. Il n'est clairement pas intéressé à entendre parler de petits obstacles comme celui-ci et s'attend à ce que vous les résolviez vous-même, ce que vous êtes en fait. Ajustez simplement vos futures réponses en gardant cela à l'esprit. Ou est-ce aussi ainsi qu'il réagit lorsque de véritables problèmes graves nécessitant une action de sa part surviennent?
il est normal que lorsque vous commencez à coder quelque chose, vous rencontrez une erreur. Pourquoi a-t-il besoin d'en entendre parler? Dites simplement "J'ai commencé à appliquer le bla bla, j'espère l'avoir fait d'ici X fois." Imaginez que vous embauchez un nouveau cuisinier pour votre restaurant et que vous le vérifiez. Préférez-vous entendre, 1) "J'essaie d'utiliser la cuisinière mais c'est différent de ce à quoi je suis habitué. Peut-être y a-t-il un moyen de l'allumer avec une allumette ... Y a-t-il des allumettes dans cette cuisine ?? J'espère Je peux en trouver un à la pharmacie alors! " ou 2) "Je m'installe dans une nouvelle cuisine et je devrais être prêt à partir dans un jour ou deux."
@Chan-HoSuh: dans ce cas précis, allumer la cuisinière peut être quelque chose pour lequel le restaurateur peut aider, auquel cas "je n'ai pas encore compris comment allumer le poêle" ne provoquerait pas la réaction "tu es le cuisinier je peux 't help you with that ", cela provoquerait la réaction" nous gardons les allumettes sur l'étagère du haut là-bas ", alors que sortir à la pharmacie pour acheter des allumettes provoquerait la réaction" pourquoi n'avez-vous pas simplement demandé à quelqu'un où les correspondances sont?" L'important est d'apprendre à identifier les problèmes qui bénéficieront de l'apport de la direction et ceux qui ne le seront pas.
duplication possible de [Tenir le responsable non technique informé et comment répondre à «quel est l'obstacle?»] (http://workplace.stackexchange.com/questions/50804/keeping-non-technical-manager-informed-and-how -pour-répondre-à-quel-obstacle-)
Il m'a fallu un certain temps pour apprendre à ne rien mentionner de tel qui a pris moins d'une journée complète. Après tout, c'est une partie essentielle du travail. De nombreux gestionnaires perçoivent cela comme une demande d'aide plutôt que comme une mise à jour sur ce que vous faites réellement. "voici ce que j'ai terminé, voici ce sur quoi je travaille." fonctionne beaucoup mieux et est beaucoup mieux perçue.
La culture de l'armée a probablement laissé un plus grand impact sur la personnalité de votre manager que le fait qu'il soit russe. Je n'ai moi-même pas été dans l'armée, mais les gens que je connais (qui l'étaient) ont tendance à ne pas avoir de sens et lorsqu'ils rencontrent un problème, ils trouvent un moyen de le faire avec ce qu'ils ont. Il est probablement habitué à cette attitude «sans problème, je ne peux pas gérer». Pour relier cela à toutes les autres réponses / commentaires, il ne comprend pas pourquoi vous lui parlez du problème et suppose que vous voulez qu'il vous aide à le résoudre, ce qu'il est incapable de faire au niveau technique que vous parlent.
Vous avez raison de ne pas pouvoir prédire avec précision quand les choses seront terminées. Vous devriez être capable de faire une supposition éclairée. Quand mon manager (pas super technique) demande quand quelque chose sera fait, je dis quelque chose comme "JE PENSE que cela devrait prendre environ 3 ou 4 jours, mais cela suppose que je ne rencontre aucun problème, et je vais probablement courir en accrocs. " J'ai remarqué qu'il est utile de proposer également dans quel délai vous pouvez terminer l'étape suivante. "Cela dit, je pense que la partie A devrait être prête à être testée d'ici cet après-midi ..." Donner quelque chose de concret semble l'aider à accepter de manière incertaine à grande échelle.
Six réponses:
user8365
2015-08-19 00:44:04 UTC
view on stackexchange narkive permalink

Les techniciens sont constamment pris dans ce genre de choses. Arrêtez d'inclure des détails dans votre explication. Je sais qu'il a demandé ce qui n'allait pas, mais tout ce qu'il entend est "bla, bla, commande, bla bla cible, bla, bla erreur". Soit vous y travaillez encore, soit il est terminé. Peu importe pourquoi pour lui. Essayez d'inclure un délai lorsque vous pensez qu'il est prêt. Certaines personnes demanderont: "Quel est le problème?" mais ne vous laissez pas entraîner en pensant qu'ils veulent des détails. Vous obtenez une erreur. C'est ça.

De plus, vous pourriez probablement supprimer l'exemple technique détaillé de votre question pour vous entraîner.

Ce. En tant que technicien _et_ manager, quand je demande combien de temps va durer quelque chose, je n'ai pas besoin de l'histoire de la vie derrière le problème. Je suis juste intéressé par le temps que ça va prendre parce que je dois déterminer si je dois vous dire d'arrêter de travailler dessus, vous aider, repousser l'entreprise, je vous laisse simplement continuer. Certaines choses sont binaires et ce n'est pas grave ...
De plus, lorsque quelqu'un demande une mise à jour, il veut savoir ce que vous avez accompli depuis la dernière mise à jour. Ils ne veulent pas savoir ce que vous n'avez pas accompli au cours des 10 dernières minutes, mais espèrent accomplir dans les 10 prochaines minutes. «Déterminer ce que signifie ce message d'erreur» n'est pas une étape importante dans l'avancement du projet. une mise à jour consistant en "J'ai commencé à comprendre ce que ce message d'erreur signifie mais je n'ai pas encore terminé cela" n'est pas une mise à jour significative. Dites à votre patron ce que vous avez fait.
Totalement. Je déteste quand je demande l'état d'avancement d'un article et que j'obtiens une diatribe technique similaire. Si vous ne demandez pas spécifiquement mon aide technique, alors tout ce que je veux savoir "est-ce que ce rapport va être fait aujourd'hui comme vous l'avez dit ou demain ou quoi? Avez-vous besoin de ressources ou d'aide pour être débloqué?" Pas les détails de votre trace de pile actuelle dont vous êtes obsédé.
-1
@Ben Lorsqu'un responsable me demande "Combien de temps pour résoudre {problème x}?", Je réponds toujours: "Je peux vous dire, si vous pouvez répondre à 2 questions pour moi: Premièrement, combien de temps vous faudra-t-il pour répondre à ma deuxième question ? " Chaque manager des 30 dernières années a immédiatement compris. Lors de mes recherches, je ne peux pas savoir combien de temps il faudra pour résoudre un problème que nous n'avons jamais vu auparavant. Je ne peux pas savoir combien de temps il faudra pour apprendre ce que je ne sais pas. Parfois, il n'y a jamais de réponse. La question fondamentale est fausse. Demandez «Vaut-il la peine de poursuivre les recherches? ou similaire.
@mxyzplk Si nous, les programmeurs, savions combien de temps cela prendrait, nous serions trop heureux de vous le dire. Nous ne pouvons pas savoir avec certitude si quelque chose va être fait d'ici la fin de la journée, et nous ne savions pas vraiment quand nous avons dit que cela commencerait. Vous obtenez une "diatribe technique" en partie parce que nous essayons de tirer un certain nombre de nos arrières et nous essayons de lui donner une sorte de raisonnement dans l'espoir qu'il aura une certaine base dans la réalité. Parfois, cette trace de pile est une montagne dont nous ne pouvons même pas mesurer la hauteur. Il est naturel pour nous de patauger en essayant de répondre à une question littéralement impossible.
@Ben vous vient-il à l'esprit que l'expliquer à quelqu'un les aide à commander toutes les pièces et à les résoudre eux-mêmes? Vous n'avez pas besoin de comprendre ou de prêter attention à tous les petits détails pour que ce type de conversation soit utile pour résoudre le problème. Exiger une mise à jour du statut binaire et une estimation du temps pour une enquête ouverte est un signe clair de mauvaise gestion, prétendant être technique afin que vous puissiez rejeter la réalité qu'il y a des inconnues inconnues ne vous rend pas plus crédible, cela le rend juste plus déraisonnable .
Pourquoi supposez-vous que nous parlons d'enquêtes ouvertes @James? Vous avez émis un certain nombre d'hypothèses négatives sur mon style de gestion; dont la plupart sont faux. Il est peut-être temps de prendre du recul et d'assumer le meilleur au départ plutôt que le pire?
@Ben Je n'ai rien supposé, j'ai répondu exactement à ce que vous avez écrit dans votre commentaire "Je n'ai pas besoin de l'histoire de la vie derrière le problème. Je suis juste intéressé par le temps que cela va prendre", si vous voulez dire autre chose, ce n'est pas ce que vous avez écrit. En ce qui concerne les enquêtes ouvertes, chaque nouvelle tâche commence comme une seule et peut le devenir par les obstacles rencontrés en cours de route, c'est exactement ce que décrit le PO. L'erreur n'est pas de reconnaître que des problèmes seront rencontrés et doivent être étudiés avant de pouvoir évaluer le temps qu'il faudra pour les surmonter.
re user2338816 commentaire: parfois, j'aimerais pouvoir créer un lien vers des commentaires spécifiques et pas seulement la réponse entière.
`En tant que technicien et manager, quand je demande combien de temps va prendre quelque chose, je n'ai pas besoin de l'histoire de la vie derrière le problème. Je suis juste intéressé par le temps que cela va prendre. Mais souvent, il est * impossible * de vous dire combien de temps cela va prendre. Résoudre le problème actuel peut prendre 10 minutes de travail ou prendre près de 2 jours ... Si nous avons ce type de variation pour chaque tâche, cela signifierait que l'ensemble du projet pourrait prendre de 2 semaines à 10 ans! Nous ne pouvons raisonnablement estimer que de gros morceaux de travail, pas chaque tâche individuelle.
@Ben - «Je suis juste intéressé par le temps que cela va prendre.» Nous devrions demander à un manager de travailler sur ce ** cancer **. "Quand est-ce que ça va être guéri?"
@jhocking: * "Parfois, j'aimerais pouvoir créer un lien vers des commentaires spécifiques et pas seulement vers la réponse entière" * Vous pouvez: Faites un clic droit sur l'heure du commentaire et choisissez "Copier le lien dans le presse-papier". Exemple: http://workplace.stackexchange.com/questions/52277/manager-sounds-upset-every-time-i-inform-him-of-a-minor-obstacle#comment133753_52280 (c'était moi faisant un clic droit sur "15 il y a des heures "(au moment où j'écris ceci) sur ce commentaire et en copiant le lien, puis en le collant ici). (Je ne le savais pas avant d'avoir contribué à Stack Overflow pendant plus de 4 ans. Peut-être que cela a été ajouté à un moment donné, ou peut-être qu'il était toujours là. :-))
Si vous faites un travail depuis un certain temps et que vous trouvez qu'il est complètement impossible de fournir une estimation raisonnable de la durée d'une tâche, vous n'êtes pas très bon dans ce travail.
@mxyzplk: exactement. Bien que j'aimerais me cacher derrière l'impossibilité de donner une estimation de temps fiable à 100% pour bon nombre de mes activités, je peux en pratique donner des estimations de temps avec une confiance raisonnable pour la plupart. Plaidoyer autrement n'aide pas à faire avancer les choses, et le fait de mal comprendre la demande d'un responsable "combien de temps cela prendra-t-il" pour signifier "me donne un temps de confiance à 100%, précis à 10 minutes près". Ce dernier est impossible, mais à l'exception de l'incompétent désespéré occasionnel n'est pas non plus ce que signifie la question.
Les techniciens sont tout le temps pris dans cette situation, probablement parce qu'ils ne savent pas mieux et n'ont jamais appris le contraire. J'aurais aimé avoir appris cela dans l'un de mes cours d'université, plutôt que de passer des années sur le marché du travail avant de comprendre cela par moi-même.
@Michael Ce n'est pas seulement une chose que les techniciens «ne comprennent pas», c'est une situation sans issue. Lorsque vous oubliez les détails, les gens supposent que vous leur cachez des choses ou que les tâches étaient plus simples qu'elles ne le sont. Si vous mettez en évidence que vous simplifiez ou résumez, cela apparaîtra comme condescendant même s'ils ne comprendraient pas ou si vous savez qu'ils ne veulent pas vraiment connaître l'explication complète. Le problème est qu'en particulier avec les retards ou les problèmes sur un projet, le diable est souvent dans les détails parce que vous avez prévu d'éviter les plus évidents.
s1lv3r
2015-08-19 02:36:58 UTC
view on stackexchange narkive permalink

En lisant entre les lignes, il était mécontent et a fait un bruit moqueur et a dit "vous êtes le programmeur, je ne peux pas vous aider avec ça".

Il a peut-être un très manière directe de dire: "Trop d'informations". La prochaine fois qu'il pose une question, vous connaissez mieux et ne pouvez donner que les informations pertinentes.

C’est mon observation si jamais je parle d’un «revers» ou montre un signe d’incertitude, il est mécontent. Comment dois-je résoudre ce problème ou dois-je l'ignorer? Dois-je toujours laisser de côté les obstacles?

Votre responsable doit prendre des décisions en fonction des informations qu'il obtient de vous. Il est évident qu'il devient nerveux si vous montrez des signes d'incertitude. Si vous étiez un manager et que vous obteniez des réponses incertaines ou évasives d'un subordonné, vous ne seriez pas non plus satisfait. Je pense qu'il y a deux solutions si vous n'êtes pas sûr de quelque chose sans le lui montrer directement:

  • Dites-lui ce que vous devez avoir fait pour être certain (par exemple, plus de temps pour creuser un sujet) .
  • Soyez franc sur l'incertitude. Dites-lui d'une certaine manière cela et pourquoi une situation est incertaine et quelle est la meilleure et la pire estimation des cas.

mais je remarque avec mon manager qu'il pense de manière très linéaire, en termes de binaire (cela a été fait ou non, oui ou non)

Vous vous rendez compte que d'un point de vue contractuel la plupart des projets sont de nature binaire?

Bien que de votre point de vue technique, il y ait bien sûr beaucoup de nuances, en termes de contrat, un projet est soit terminé et peut être facturé, soit il ne l'est pas - auquel cas le projet peut être retardé. Votre responsable est en fin de compte payé pour recueillir ces informations auprès de vous et prendre les mesures appropriées en fonction de ces informations.


À mon avis honnête, toute votre question se lit comme si elle se résumait à la question du point de vue (technique ou gestion). Peut-être qu'à l'avenir, vous pourriez plus souvent essayer de passer à la «vision de la direction» d'une certaine situation et essayer de comprendre les implications de ce point de vue - je pense personnellement que cela pourrait faire de vous un employé beaucoup plus précieux à long terme.

D'accord - OP est mauvais pour gérer.
@Davor Vous avez raison, les managers sont payés pour gérer cela afin que les programmeurs n'aient pas à s'en préoccuper. Mais je ne dirais pas que cela «fuit» dans cette situation - je dirais plutôt qu'il y a une frontière de communication et si le PO pouvait mieux comprendre les implications de cette frontière, il serait en mesure d'améliorer la communication avec son responsable et facilitera ses managers et sa vie professionnelle.
On dirait que le gestionnaire d'OP est * aussi * mauvais pour gérer le bas. Le problème de la communication existe des deux côtés.
Daniel Nalbach
2015-08-19 23:07:23 UTC
view on stackexchange narkive permalink

Les réponses et commentaires existants contiennent de nombreuses informations. Certaines choses m'ont sauté à la lecture de ce que vous avez écrit.

  • Votre responsable est passé en personne pour une mise à jour. C'est en fait un bon signe. Il ne se cache pas derrière un e-mail ou une porte fermée, il veut une interaction en face à face, même si ce n'est que brièvement.

  • On dirait qu'il est resté et écouté pendant que vous lui montriez les détails d'un problème auquel il ne pouvait pas aider. Il aurait pu simplement vous interrompre et sortir. Il aurait pu demander immédiatement à quelqu'un d'autre de «vous aider» ou même de prendre le relais.

  • La formulation de sa réponse semble impolie, mais l'intention est encourageante. Il a dit qu'il ne pouvait pas vous aider. Il n'a pas dit qu'il s'en fichait, que cela n'avait pas d'importance ou n'était pas son problème. Il y a beaucoup de véritables rudethings auxquels il aurait pu répondre. J'ai vu des managers insulter des employés ou recourir à des attaques ad hominem dans ces situations («pourquoi vous ai-je embauché?»). Au lieu de cela, il a exprimé sa frustration de ne pas pouvoir vous aider et vous avez eu l'impression de demander de l'aide. C'est une différence subtile, mais qui compte.

  • Il est probablement là pour savoir s'il doit agir. La seule action qu'il peut entreprendre est d'annuler le travail, de retarder le travail ou de l'attribuer à quelqu'un d'autre. Ce qu'il attend de vous, c'est la confiance que vous allez le résoudre d'une manière ou d'une autre, ou de savoir s'il doit l'attribuer à quelqu'un d'autre parce que vous ne pouvez pas le faire (trop de cela signifie généralement qu'une personne n'est pas qualifiée ).

  • Vous n'avez pas vraiment répondu à sa question. Un responsable demandant une mise à jour et un employé entrer dans les détails techniques équivaut à une incompatibilité de type. Il a posé une question booléenne et vous avez renvoyé un tableau d'informations en guise de réponse. Cela donne en fait l'impression que vous ne l'écoutez pas, ce qui peut être frustrant.

  • Si vous ne pouvez pas estimer correctement, prenez du temps, mais soyez précis. S'il est 9h, demandez si vous pouvez le mettre à jour à midi, ou après le déjeuner, ou fermer du travail. Donnez-lui quelque chose de concret sur lequel il pourra planifier. La réponse adodgy l'empêche de communiquer l'information à toute autre personne qui en dépend (y compris son patron). À l'heure prévue, donnez une estimation réelle.

  • Obtenez de l'aide d'un collègue qui a de bonnes relations avec votre patron. Il y a généralement quelqu'un avec qui ils s'entendent sur le lieu de travail. Découvrez-leur ce qui fait le succès de leur communication avec lui.

  • Soyez humble. Dans votre prochain tête-à-tête, avouez à votre patron que vous ne vous sentez pas comme si vous communiquiez avec succès avec lui et demandez-lui ce qu'il veut entendre de vous. Ce sera probablement une réponse courte et simple. Écoutez-le, puis faites un effort pour le faire. S'il pense que vous voulez l'aider à atteindre ses objectifs, il est plus susceptible de travailler avec vous (même s'il est frustré).

mcknz
2015-08-19 00:38:37 UTC
view on stackexchange narkive permalink

Il est très difficile de fournir une mise à jour cohérente lorsque vous êtes en train de dépanner ou de concevoir une solution à un problème.

Pensez à retarder votre réponse jusqu'à ce que vous ayez une idée claire du problème, et un ou plusieurs plans à atténuer ou à résoudre.

Si votre responsable demande une mise à jour instantanée et immédiate, dites simplement que vous ne disposez pas de suffisamment d'informations pour le moment et que vous ne voulez pas perdre son temps avec des informations incomplètes.

Ensuite, rédigez dès que raisonnablement possible un e-mail de mise à jour court et concis que vous pourrez suivre avec une discussion en personne.

D'après mon expérience, les gestionnaires qui demandent fréquemment des mises à jour de statut / chronologie doivent généralement les transmettre à quelqu'un d'autre, et leur dire "je ne peux pas dire" entraînera simplement plus de demandes pour votre meilleure estimation. Vous devez dire quelque chose pour vous en débarrasser, et comme ce que vous dites ne sera jamais exact à ce stade, [apprenez à leur donner une estimation qui fonctionne à votre avantage] (http://c2.com/cgi/wiki ? ScottyFactor).
@Air Ce qui, bien sûr, conduit à des estimations gonflées, et a finalement manqué les délais de toute façon. Mais le point clé est que c'est la décision du manager - s'il veut un développement agile, il devra être suffisamment flexible pour accepter que ce qui aurait dû prendre une heure prendra dix heures à la place (soit en vous donnant le temps, soit en modifiant les spécifications), et vous devriez donner vos meilleures estimations. S'il veut un chiffre précis, donnez-lui vos 90% - même si cela signifie dire dix heures pour quelque chose qui ne prendra probablement qu'une heure.
@Air était d'accord, mais parfois cela ne prend que quelques minutes pour se vider la tête et trouver une réponse cohérente. Si vous pouvez dire quelque chose comme "Je serai dans votre bureau dans 15 minutes avec une mise à jour", cela vous coûtera au moins du temps. Si le manager veut constamment des mises à jour MAINTENANT, eh bien c'est un problème mieux résolu avec un changement de décor.
Oui, dans cette situation où je ne sais vraiment pas pour le moment si ce problème va être réglé, ou quand, dis-je, je vais vous y répondre mardi à minuit. Et donc j'ai une date limite pour moi-même, si je ne peux pas le comprendre d'ici mardi 11 heures, je ne vais pas le faire, et j'ai besoin de beaucoup plus d'aide, ou d'un spécialiste de l'entrepreneur ou autre.
cdkMoose
2015-08-18 23:51:44 UTC
view on stackexchange narkive permalink

Lorsque vous informez votre patron d'un obstacle, proposez-vous également une solution? Je me rends compte que le timing ne le permet pas toujours (comme dans votre exemple quand il est venu comme vous l'avez identifié). Les responsables (devraient) souhaiter que les membres de leur équipe résolvent les problèmes et non les rapporteurs.

À moins que la solution ne soit réellement quelque chose dont vous avez besoin que le patron fasse personnellement, qu'espérez-vous que votre patron fasse des informations? Vous n'avez pas nécessairement besoin de savoir que votre solution fonctionnera, mais vous devez proposer un plan. "hé patron, je viens de rencontrer ce problème, et voici ce que je vais essayer de faire pour le résoudre." S'ils ont une meilleure idée qu'ils ne peuvent vous donner des idées ou des commentaires.

Si vous ne proposez pas de plan proposé, il semble que vous leur demandez simplement de résoudre votre problème. Je pense que c'est probablement la raison pour laquelle il a dit "vous êtes le programmeur, je ne peux pas vous aider avec ça". Vous avez mentionné qu'il est un peu technique, mais pas un programmeur. Que pensez-vous qu'il peut faire avec votre rapport de problème et aucune idée de solution?

"Que pensez-vous qu'il peut faire avec votre rapport de problème et aucune idée de solution?" Je ne m'attends pas à ce qu'il fasse quoi que ce soit, mais il semble penser que je le fais. Y a-t-il un moyen pour que je puisse le formuler différemment? Il est venu me demander ce que je fais, je ne suis pas allé le voir pour lui parler du problème.
Je comprends que cette fois, il est arrivé au milieu du problème, mais le titre de votre question dit «à chaque fois». Si cela s'est produit juste, oubliez-le. Si cela s'est produit plus souvent (comme la question le suggère), alors vous allez parfois le voir. Dans ces cas, ayez un plan. Vous ne vous attendez peut-être pas à ce qu'il fasse quoi que ce soit, mais si vous vous adressez à lui sans plan, c'est probablement ainsi qu'il envisage les choses. Si vous avez un plan, sachez que vous ne lui demandez rien
À votre patron, "que faites-vous?" n'est pas "Je corrige une implémentation incorrecte du modèle Observer" mais "J'ai résolu tous les problèmes prioritaires et je suis à travers 10 des 30 problèmes non prioritaires, le projet devrait être prêt d'ici lundi prochain".
Jef Menguin
2015-08-19 05:12:26 UTC
view on stackexchange narkive permalink

Différents traits pour différentes personnes.

Votre responsable a déjà indiqué ce qu'il attendait de vous. Il ne veut pas des détails parce que ce n'était pas son truc.

Qu'y a-t-il pour moi? est une question à laquelle vous devez répondre chaque fois que vous parlez à quelqu'un - que ce soit un manager ou votre subordonné. Ses antécédents peuvent avoir quelque chose à voir avec sa réponse, mais vous devez d'abord répondre à la question en fonction de ce qu'il a besoin de savoir.

Prenez les êtres humains comme des êtres humains. Suspendez votre jugement sur leur race ou leurs croyances et vous pourrez voir les choses clairement d'où elles en sont.



Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...