Comment puis-je soulever des préoccupations légitimes et faire des critiques? (et demandez-leur de les prendre en considération, de les accepter et / ou de les traiter en dernier lieu)

• En personne.
• Un- en un seul.
• Et uniquement pour les choses qui comptent vraiment.

Ce que vous devez savoir, c'est que vous êtes ne va pas changer de manière significative la façon dont les autres développeurs codent. Hormis la religion, avez-vous déjà entendu parler de la prière de la sérénité? Comment le code des autres développeurs est pour la plupart, hors de votre contrôle et le sera toujours, et plus tôt vous pourrez être en paix avec cela, mieux ce sera pour tout le monde.

J'ai peut-être déjà ruiné la chance d'avoir une relation de travail cordiale avec certains développeurs. Comment changer / réparer ça? (comment les autres me perçoivent, écoutez-moi à nouveau)

Oui, vous avez peut-être des compétences techniques incroyables, mais vous êtes toujours en train d'acquérir des compétences relationnelles. Faites preuve d'empathie. La prochaine fois que vous pensez à critiquer, ce que vous pouvez considérer comme une tentative d'aider quelqu'un à s'améliorer, pensez-y d'abord du point de vue de ses besoins. De quoi vos collègues ont-ils besoin? Respect de leur code, reconnaissance, journée de travail facile et amusante. Commencez à leur donner cela et vous commencerez à arranger les choses.

Comment puis-je soulever des préoccupations légitimes et faire des critiques? (et demandez-leur de les prendre en compte, de les accepter et / ou de les traiter en dernier lieu)

Réfléchissez à la manière dont vous en parlez. Croyez-vous qu'il n'y a qu'une seule façon de faire les choses et que si ce n'est pas le cas, cela doit être faux, médiocre ou sous-optimal? Il peut y avoir de nombreuses façons de faire les choses et il se peut que vous ne compreniez pas le point de vue de quelqu'un d'autre ici pour un point.

Considérez dans quelle mesure utilisez-vous ces habitudes de 7 Habitudes des personnes très efficaces:

  Habit 1: Soyez ProactiveHabit 2: Commencez par la fin dans MindHabit 3: Commencez par les choses d'abord Habit 4: Pensez Win-WinHabit 5: Cherchez d'abord à comprendre, puis à être compris Habit 6: SynergizeHabit 7: Aiguisez la scie  

Remarque, les habitudes 2,4 et 5 pour quelques-unes qui peuvent valoir la peine d'être considérées ici dans votre environnement. Quelle fin spécifique voulez-vous lorsque vous soulevez des préoccupations? Dans quelle mesure comprenez-vous les compromis à faire de diverses manières? Certaines entreprises peuvent avoir à faire des choix difficiles et donc, même si vous venez du monde universitaire où il y a beaucoup de temps pour bien faire les choses, ce n'est pas nécessairement ainsi que les entreprises fonctionnent dans le monde réel.

J'ai peut-être déjà gâché la chance d'avoir une relation de travail cordiale avec certains développeurs. Comment puis-je changer / résoudre ce problème?

Comment gagner des amis et influencer les gens a quelques idées que je vous suggère de considérer attentivement:

Techniques fondamentales pour gérer les gens

1. Ne critiquez pas, ne condamnez pas et ne vous plaignez pas.
2. Donnez une appréciation honnête et sincère.
3. Suscitez l'envie de l'autre personne.
4. Ne montrez jamais aux autres que vous n'êtes pas intéressé par ce qu'ils ont à dire.

Six façons de faire aimer les gens Vous

1. Devenez véritablement intéressé par les autres.
2. Souriez.
3. N'oubliez pas que le nom d'une personne est, pour cette personne, le son le plus doux et le plus important dans n'importe quelle langue.
4. Soyez un bon auditeur. Encouragez les autres à parler d'eux-mêmes.
5. Parlez en fonction de l'intérêt de l'autre personne.
6. Faites en sorte que l'autre personne se sente importante - et faites-le sincèrement.

Douze façons d'amener les gens à adopter votre façon de penser

1. La seule façon de tirer le meilleur parti d'un argument est de l'éviter.
2. Montrez du respect pour l'autre les opinions de la personne. Ne dites jamais "Vous avez tort".
3. Si vous vous trompez, admettez-le rapidement et avec insistance.
4. Commencez de manière amicale.
5. Commencez par questions auxquelles l'autre personne répondra oui.
6. Laisser l'autre personne parler beaucoup.
7. Laisser l'autre personne sentir que l'idée est la sienne.
8. Essayez honnêtement de voir les choses du point de vue de l'autre personne.
9. Soyez sympathique avec les idées et les désirs de l'autre personne.
10. Faites appel aux motifs les plus nobles.
11. Dramatisez vos idées.
12. Lancez un défi.

Soyez un leader: comment changer les gens sans offenser ni susciter de ressentiment

1. Commencez par des éloges et une appréciation honnête.
2. Attirez indirectement l'attention sur les erreurs des gens.
3. Parlez de vos propres erreurs avant de critiquer l'autre personne.
4. Posez des questions au lieu de donner des ordres directs.
5. Laissez l'autre personne sauver la face.
6. Félicitez chaque amélioration.
7. Donnez à l'autre personne une belle réputation à la hauteur.
8. Utilisez des encouragements. Faites en sorte que l'erreur semble facile à corriger.
9. Rendez l'autre personne heureuse de faire ce que vous suggérez.

Avez-vous déjà indiqué où les choses vont bien? Avez-vous déjà reconnu le bon travail que font les autres? Sinon, je pourrais facilement voir où vous causez beaucoup de problèmes en essayant d'apporter des choses sans me rendre compte à quel point c'est bien ou pas si bien que pour cette équipe et cette situation. Certaines bonnes pratiques peuvent ne pas toujours être excellentes, car tous les endroits n'auront pas un environnement dans lequel vous aurez ce qui peut sembler être un budget et du temps illimités pour faire des choses avec les dernières technologies, de superbes machines et pas de délais serrés.

Félicitations. Si vous pouvez en tirer parti, vous avez une opportunité qui peut lancer votre carrière dans la stratosphère.

Selon vous, quelles sortes de choses se passent sur les CV d'ingénieurs hautement qualifiés? Cela pourrait-il être des choses comme la mise en œuvre de pratiques à partir de zéro dans une équipe, l'éducation des coéquipiers, etc.? Vous n’avez pas l’opportunité de faire ces choses dans une équipe qui a déjà obtenu de bons résultats au test Joel. Donc, atterrir dans une équipe de personnes qui ne se soucient pas de ces choses est une bénédiction déguisée - il y a toutes ces choses d'ingénierie senior qui attendent d'être faites, et exactement une personne qui se soucie de les faire.

Si vous voulez tirer parti de cette opportunité, vous devrez quelque peu ajuster votre réflexion.

1. Sachez que vos coéquipiers ne se soucieront jamais autant de la qualité du code et des bonnes pratiques que vous faites. Vos attentes ont été augmentées par des sites comme celui-ci, ce qui implique que la plupart des développeurs s'efforcent constamment d'apprendre les dernières et meilleures choses et de faire les choses conformément aux «meilleures pratiques». La réalité est que les choses qui nous intéressent tous ici ne sont même pas enregistrées sur le radar de la grande majorité des programmeurs. Apprenez à accepter que vos modifications seront probablement minimes au début, mais chaque changement qui améliore les choses est significatif.
2. Apprenez à y penser à partir de leur PDV. Oui, cela semble bien en théorie de simplement réécrire les choses à partir de zéro pour utiliser un code de bonne qualité. Mais écrire du mauvais code est difficile , et vous leur demandez de se débarrasser des heures et des heures de travail. De plus, votre nouveau code ne sera pas exempt de bogues, il y a donc tout un processus de contrôle qualité qui va devoir être refait. Même si vous ne préconisez pas une réécriture complète, la nature du mauvais code est que tout ce que vous touchez dans une zone peut faire tomber tout le château de cartes, de sorte que même la refactorisation comporte un risque élevé. Leur expérience leur parle du risque d'essayer de réparer les choses, mais pas des récompenses.
3. Leur approche actuelle fonctionne déjà (de leur point de vue). Ils répondent déjà à toutes les attentes la direction en a sans utiliser vos idées nouvelles. Gardez à l'esprit que votre responsable n'a aucune idée de qui a raison et qui a tort. Il sait cependant qui a généré beaucoup de revenus et qui ne l'a pas fait. Je soupçonne que vous tombez dans cette dernière catégorie. De plus, gardez à l'esprit que pour que votre manager soutienne un changement, il doit se frayer un chemin autour de l'idée que les développeurs et les pratiques qu'il soutient tout ce temps sont faux. C'est difficile pour lui, car il a besoin de réévaluer sa propre histoire et d'avoir une vision plus négative de l'histoire des personnes qu'il aime probablement.

Voici quelques choses que vous pouvez faire pour construire faites confiance et améliorez votre propre situation.

1. Si possible, faites travailler votre propre application ou sous-système. Habituellement, cela ne les dérange pas si vous implémentez du code propre dans votre propre espace - ils ne sont tout simplement pas intéressés par ce que ils font. Mettez tous vos canards dans une rangée pour que votre bac à sable soit prêt à briller quand quelqu'un le regarde. Documentez tout, faites des tests si vous le pouvez, etc. La première fois que j'ai fait cela, je suis parti en vacances - c'était après ce qui était censé être la date de livraison mais avant une nouvelle date limite - et j'ai laissé un manuel à d'autres développeurs. utiliser mon système. Tout s'est passé sans accroc pendant mon absence. De plus, ce sous-système a la réputation d'être le plus fiable de toute l'application.
2. Trouvez des moyens polis de "faire" faire les choses de la bonne manière. C'est plus facile si vous disposez de votre propre sous-système ou application. Par exemple, une fois que mon patron a dit "nous devrions probablement commencer à penser à utiliser le contrôle de version", j'ai rapidement mis tous mes sites sous contrôle de version localement et sur le réseau, et les gens devaient utiliser le contrôle de version s'ils voulaient que leurs mises à jour soient propagées à tous les environnements. Si quelqu'un faisait remarquer que quelque chose qui aurait dû être dans le wiki n'était pas correct, je répondrais que je n'y ai pas trouvé les informations pertinentes - et je proposerais de l'ajouter.
3. Vous devez en fait être meilleur, plus rapide et plus exempt de bogues que vos collègues. J'ai réécrit tout notre framework dans un nouveau langage, et même pendant que je le faisais, j'étais toujours capable de respecter des délais agressifs et mon framework faisait des choses dont l'ancien n'avait jamais rêvé. Pourtant, à court terme, chaque fois qu'il y avait un bogue du nouveau framework que l'ancien framework n'avait pas, je devais répondre à des questions inconfortables sur pourquoi. À plus long terme, le framework s'est avéré être un développement rapide comme l'éclair et beaucoup plus exempt de bogues, mais le défi est pour vous et votre framework de survivre aussi longtemps.
4. Apprenez les cadres dans lesquels vous vous sentez faible. Si vous voulez agir en tant qu'architecte (et relever ce défi, c'est ce que vous devrez devenir), vous devez comprendre les concepts qui les sous-tendent. Vous pouvez ou non vouloir les utiliser «telles quelles», mais si vous comptez créer vos propres solutions architecturales, vous devez comprendre pourquoi celles qui existent déjà fonctionnent.
5. Réalisez que vous devrez probablement passer à autre chose pour profiter pleinement de ce que vous allez accomplir. Parce que vos coéquipiers ne se soucieront probablement jamais de la qualité du code en soi , il est peu probable que vous soyez apprécié ou rémunéré en fonction de vos réalisations dans ce domaine où vous vous trouvez. Ce que vous faites maintenant, c'est accumuler une expérience précieuse que vous avez eu la chance d'acquérir, puis cette expérience figurera sur votre CV pour vous faire gagner plus d'argent et, plus important encore, une place dans une équipe qui a les mêmes valeurs. vous le faites.

Veuillez également lire ma réponse dans Comment être constructif et résoudre des problèmes dans un environnement non constructif.

Il semble qu'en écrivant la question, vous vous êtes rendu compte que les choses que vous faisiez ne fonctionnaient pas. Donc, si vous ne l'avez pas déjà fait, arrêtez de les faire. Peu importe si vous aviez raison techniquement ou si ce que vous faisiez peut avoir fonctionné dans un environnement différent: ce n'était pas productif, alors arrêtez.

Re vos questions, à mon avis, indépendamment de les droits et les torts de la situation, vous devez garder le silence pendant un moment, écouter vos collègues et votre manager, et vous établir comme quelqu'un qui peut travailler avec succès sur ce qu'on leur demande et qui peut nouer des relations de travail productives avec les autres membres de l'équipe. S'il y a beaucoup de travail, on s'attend probablement à ce que les membres de l'équipe prennent la charge et ne bougent pas le bateau.

Comment puis-je soulever des préoccupations légitimes et faire des critiques? (et faites-les considérer, acceptés et / ou finalement traités)

Établissez-vous d'abord. Vous ne pouvez clairement pas faire passer vos idées techniques à vos collègues et influencer l'équipe dans son ensemble, mais les utiliser autant que vous le pouvez dans votre travail quotidien. Démontrer que vous faites votre travail plus rapidement et de manière plus fiable que vos collègues vous mettra dans une bonne position à l'avenir pour faire passer vos idées.

J'ai eu une expérience similaire récemment où je n'ai pas pu convaincre mon responsable d'adopter mes idées, mais je les ai utilisées moi-même et à la fin du projet, le responsable a remarqué que le projet s'était bien passé, et a commenté dessus (sans que je le demande). Si votre responsable ou vos collègues ne remarquent pas votre bon travail et ne sont pas disposés à en discuter, vous n'avez pas l'espoir de voir vos idées considérées comme négligeables.

Peut-être J'ai déjà gâché la chance d'avoir une relation de travail cordiale avec certains développeurs. Comment changer / réparer ça? (comment les autres me perçoivent, écoutez-moi à nouveau)

J'en doute. La plupart des gens veulent juste des collègues qui peuvent faire leur travail et avec qui ils peuvent s'entendre. S'il s'avère que vous êtes tous les deux de l'avis de vos collègues, je ne vois pas de problème. L'essentiel est de savoir si vous pouvez arrêter de parler et commencer à écouter. Encore une fois, je ne porte aucun jugement sur les droits et les torts techniques de la situation. Si vous avez raison sur vos idées techniques, vous pourriez bien vous épanouir dans d'autres entreprises.

En ce qui concerne l'avenir, à mon avis, une question clé est de savoir combien vous apprenez. Disons que vous vous établissez, arrêtez de parler et commencez à écouter davantage. Combien apprenez-vous alors de vos collègues plus expérimentés, techniquement et en termes de gestion des projets, de fonctionnement des affaires, etc.? Êtes-vous alors en mesure d'engager des discussions productives, aller-retour avec des collègues sur le travail que vous faites et, éventuellement autour du travail de l'équipe dans son ensemble, des discussions où vous tous apprenez quelque chose ?

Quelque chose qui m'a frappé comme significatif dans votre message a été lorsque vous avez dit que vos idées étaient contrées par "Ne faites pas confiance à Internet" et "expérience". Il semble que vous ayez beaucoup d'intérêts et d'idées et que vous vouliez faire partie d'une équipe performante. Si, après avoir ajusté votre équilibre conversation-écoute, vous n'êtes pas dans un environnement qui valorise une discussion honnête et ouverte d'idées au-dessus des années après, alors ce n'est peut-être pas le bon endroit pour vous. Bien sûr, en attendant, il est logique de continuer le travail en cours et avec vos collègues.

(J'ai délibérément essayé de ne pas rendre cette réponse spécifique au logiciel, au vu du commentaire de Pheonixblade9 sous la question.)

À deux reprises, un problème deviendrait trop chaud et conflictuel entre moi et un autre développeur. Je construis mes points de vue en recherchant les meilleures pratiques de codage en ligne et en leur écrivant des e-mails, invitant à la discussion , tout doit être contré par "Ne faites pas confiance à Internet" et "expérience".

Une des choses qu'une nouvelle personne entrant dans n'importe quel secteur doit apprendre est l'humilité. Les déclarations «ne faites pas confiance à Internet» et «expérience» sont en fait tout à fait valables, que vous le sachiez encore ou non. Plus précisément, vous semblez vous heurter à des gens qui ont beaucoup plus d'expérience que vous ... Ils n'aimeront tout simplement pas qu'une personne beaucoup plus jeune se mette en face.

À leurs yeux, vous N'ayez pas les «cicatrices de bataille» qui viennent de passer un nombre impie de nuits tardives à vous cogner la tête contre un mur en essayant de réparer quelque chose qui aurait juste dû marcher. Vous n'êtes probablement pas resté assis pendant des heures à regarder un morceau de code tel que var x = 1 + 1; et vous avez été déconcerté par la raison pour laquelle le programme insiste sur le fait que x est en fait égal à 3. Une fois que vous avez fait ce, pas seulement une fois mais sur une période de plusieurs années, alors vous commencez à comprendre que l'Internet est souvent faux. Que les idées et les concepts présentés peuvent être de bonnes solutions ... mais dans des situations très spécifiques.

Je sais que j'ai vu un grand nombre de juniors se précipiter pour mettre en œuvre la dernière chose qu'ils ont lu, souvent écrit par un autre jeune homme, sans vraiment comprendre les conséquences. J'ai également passé pas mal de nuits tardives à essayer de sauver un projet lorsque j'ai été appelé pour nettoyer leur désordre. À cette fin, j'ai développé une politique de "si vous ne pouvez pas l'expliquer dans un langage simple et me convaincre que cela résout le problème devant nous, alors vous ne le comprenez pas assez et donc cela n'appartient pas."

Cela dit, la clé ici est vraiment la façon dont vous abordez les choses. Dire à un développeur qui a fait le tour du bloc à plusieurs reprises qu'il a tort ne fonctionnera jamais. Essayer de justifier cela avec un lien vers un article ou même dire "Martin Fowler a dit ..." encore une fois ne fonctionne pas. Les gars expérimentés apprennent à juger un morceau de code ou une approche sur son mérite, pas sur qui est le messager.

Au lieu de cela, vous devez aborder cela dans une direction totalement différente. À savoir, demandez-leur de vous expliquer vous pourquoi votre idée est fausse. Il s'agit essentiellement de psychologie inversée et en leur demandant de signaler vos lacunes (ce qu'ils feront avec plaisir), l'une des deux choses se produira. Soit ils se rendront compte que leur approche est mauvaise et finissent donc par être d'accord avec vous, soit ils vous expliqueront pourquoi vous vous trompez. Les deux devraient être des situations bienvenues.

Regardez les conversations suivantes:

Mauvaise manière

Vous :: "Bob, vous devriez avoir utilisé le modèle d'inversion de contrôle
ici, Martin Fowler dans son article sur www.wherever.com dit que vous devriez. Ce que vous avez fait doit être complètement réécrit."
Bob :: "Cela fonctionne très bien. Vous n'avez pas de classe pour refactoriser? Peut-être CS 101?"
Vous :: "Mais il a dit. .. "
Bob ::" Va-t'en bien! " à part Jim: "Qu'est-ce qu'ils apprennent à ces enfants?"

Ce n'est pas vraiment une bonne approche car cela met immédiatement Bob sur la défensive. De plus, cela montre que vous manquez simplement d'expérience et donc de crédibilité en utilisant uniquement une référence à l'opinion de quelqu'un d'autre pour justifier votre déclaration. Cependant, si vous avez fait quelque chose comme ceci:

Meilleure façon

Vous :: "Bob, qu'est-ce que vous pensez utiliser un modèle IoC ici? Cela ne faciliterait-il pas les tests? Nous pourrions définir un paramètre de configuration afin de savoir dans quel environnement il se trouve et supprimer tout ce code. "
Bob :: "Peut-être ... Bien sûr, peu de gens comprennent comment bien faire l'IoC et se retrouvent généralement avec du code très difficile à lire. Dans ce cas, je préfère avoir quelque chose qui était plus facile à comprendre. "

Approche bien meilleure. Vous avez fait une suggestion et présenté une raison claire expliquant pourquoi cela s'applique tout en vous reportant à l'expérience de Bob. Plutôt que d'être sur la défensive, Bob est maintenant engagé et essaiera naturellement de vous «éduquer». Plus important encore, vous avez la possibilité de donner plus de détails afin de dissiper son inquiétude. Au cours de la discussion, il pourrait changer d'avis ou vous apprendrez certains des pièges avec ce que vous lisez. Dans tous les cas, vous devez apprendre quelque chose d'important.

Pour résoudre les problèmes à ce stade, vous devez faire trois choses. Tout d'abord, arrêtez de citer Internet. Deuxièmement, posez des questions, ne faites pas de déclarations. Troisièmement, sachez de quoi vous parlez avant d'en parler. Cela signifie jouer avec cette «pratique de codage» et l'utiliser dans un projet de test afin que vous sachiez ce qui ne va pas.

Essayez un autre point de vue. Lorsque vous n'êtes pas en mesure de gagner, ne créez pas de friction.

Vous ne pouvez pas changer votre âge. compétence. Cela vient en premier.

Peu importe ce que vous pensez de votre niveau de compétence ou de la qualité de votre travail. Parce que la communication est la réponse que vous obtenez. Ce qui compte, pour votre problème particulier, c'est ce qu'ils pensent de vous.

Résolvez-le d'abord. Et il sera beaucoup plus facile de défendre les améliorations que vous jugez appropriées.

Concernant vos questions:

1. Cela prend du temps, ne vous précipitez pas et restez calme.

   Il s'agit de trouver le bon moment et le le bon endroit pour soulever de telles questions. Personne n'aime une personne intelligente et les gens n'écoutent pas et ne tiennent pas compte de ce que vous dites parce qu'ils sentent que vous êtes un.

   Dans un environnement de travail, vous avez 2 emplois. Le travail que vous faites au quotidien et le second est celui où vous construisez des relations et de la confiance.

   Donc, si vous êtes bon dans votre travail et respectueusement, vous voulez soulever un problème sans le respect et le soutien de vos collègues de travail probablement personne n'écoutera et vous serez le plus étrange.

   Le meilleur conseil que je puisse dire est d'être patient. Vous avez essayé de soulever un problème et cela ne s'est pas déroulé comme prévu, alors prenez une pause et ne vous laissez pas déranger. Commencez lentement à travailler sur une autre approche tactique si vous avez vraiment envie de soulever le problème. Peut-être que d'autres personnes là-bas ressentent la même chose à propos de ce problème, il vous suffit de les trouver. Cela prend du temps.

2. Invitez ces développeurs à prendre un verre en soirée. Dites que c'est sur vous cette fois. La plupart des meilleures relations de type de travail se produisent en dehors du bureau. Prenez quelques verres et détendez-vous. Vous constatez que les gens écoutent mieux lorsqu'ils sont hors du bureau et détendus. Surtout dans un bar. Parlez de choses courantes comme le sport, les films, les animaux de compagnie ou autre. Les gens se rapporteront beaucoup mieux à vous.

   Peut-être qu'après un certain temps, lorsque vous sortez pour boire un verre du travail, vous parlez peut-être du problème de la norme de codage. D'après mon expérience, vous supporterez un meilleur changement pour que quelqu'un écoute ce que vous avez à dire.

Bonne chance

Peut-être que vous vous trompez sur vos préoccupations et que les problèmes de qualité du code que vous soulevez étaient des choix spécifiques faits par des ingénieurs informés et expérimentés.

Considérez le scénario suivant:

Une équipe a la pression de la direction pour précipiter un projet et en raison de cette pression, elle a réduit les délais de conception et de développement.
Ensuite, pour ajouter du sel sur la plaie, la direction embauche des membres de l'équipe inexpérimentés bon marché avec l'espoir que cela s'améliorera productivité de l'équipe mais tout ce que ce nouveau membre fait, c'est se plaindre de la qualité du code et des choix de conception.

Je ne dis pas que c'est votre histoire, mais ça pourrait l'être.

N'oubliez pas que ce sont des personnes avec lesquelles vous devez travailler tous les jours - soyez respectueux et prévenant, il peut y avoir plus à l'histoire - vous serez mieux servi et en apprendrez plus à long terme si vous êtes prompt à féliciter et pas prompt à critiquer.