Comment comprendre que vous n'êtes pas le bienvenu ou discuter des méthodes de retrait des travailleurs de l'entreprise

Le développeur est une personne enthousiaste moyenne, il est inutile de discuter avec cela. Objectivement, étant donné que l'apprentissage de la programmation d'un jeune prend beaucoup de temps et d'efforts, de nombreux développeurs deviennent un peu des ours. Et maintenant je vais vous expliquer pourquoi.

Un ours est généralement un animal unique. L'hibernation hivernale seule est une question de respect. Ajoutez à cela la taille, l'omnivore et l'habitat, et nous obtenons le prédateur le plus élevé qui n'a pas d'ennemis naturels. Tout zoologiste vous dira que l'ours est une bête solitaire. Et juste dans le mode de vie des solitaires se trouve le principal problème d'interaction avec l'ours: il n'a pratiquement pas de système de signal mimique . Seul un autre ours peut nuire à un ours dans la nature, mais ils divergent simplement dans différentes directions, préférant une retraite tactique à une bataille sanglante. Autrement dit, le niveau d'émotivité de cette bête peut être comparé à l'émotivité de Chuck Norris, voyez par vous-même:



Parmi les développeurs, il existe de nombreux «ours» simples. Le problème est qu'avec une telle simplicité, «l'ours» perd toute chance de reconnaître des notes et des demi-teintes, du moins sans une longue expérience triste. Ainsi, dans cette publication, nous parlerons de plusieurs "méthodes" de base que les mauvaises personnes utilisent pour évincer un employé qui leur est répréhensible de la part de l'entreprise.

Mesures. Beaucoup et différent


La première façon de faire pression sur une personne est de revoir les métriques de son efficacité dans le sens des complications et d'augmenter leur nombre. Comme le dit un dicton: «Peu importe comment ils votent. L'essentiel, c'est ce qu'ils pensent. » En fait, le travail peut devenir plus grand, il sera simplement considéré différemment. Plus elles sont métriques et confuses, plus il est probable que le spécialiste commettra une erreur quelque part et ne comprendra pas les exigences de la direction.

Ces erreurs délient les mains de l'adversaire et l'adversaire commence à faire pression sur lui. Cela peut être de toute nature: de la traînée publique lors des rassemblements matinaux / pauses café à la dénigrement. L'essence de la complication des métriques est la suivante: sortir une personne d'un état d'équilibre professionnel.

Dans le même temps, l'arrière est couvert de manière fiable. Le malfaiteur peut préparer une vaste base de données sous la forme d'un flux de travail prescrit, effectuer une correspondance fastidieuse par courrier et utiliser d'autres méthodes de "papeterie sale et crochet" afin de compliquer la vie d'une personne. Le plus souvent, les victimes d'une telle fraude sont des personnes qui jouissent de l'autorité de l'équipe, mais en même temps, elles peuvent, à l'avenir, postuler à un poste de direction. En fait, c'est l'élimination des concurrents dans le style de l'épreuve de force des années 90.

Comment y faire face? Tout d'abord, absolument toutes les mesures ne peuvent pas être sans ambiguïté. Si le gestionnaire dit que l'interaction par courrier devrait être allouée à 10% du temps de travail, et que vous avez passé 12% ou 15%, puisque vous avez dû contacter, par exemple, avec le frontend, cela ne peut pas être une raison pour la procédure. De plus, le superviseur direct devrait être responsable de toutes les mesures exposées . Dans Crossover, en cas de divergence grave entre les métriques définies par la direction, les résultats des développeurs sont également demandés à la direction. Si le travail est terminé et que le processus de travail va dans la bonne direction, alors, une erreur a été commise par le gestionnaire qui a exposé des mesures irréalistes ou incorrectes.

Malheureusement, dans la plupart des entreprises, le principe de la responsabilité bilatérale pour la mise en œuvre des métriques n'est pas respecté et le développeur n'a pas la possibilité d'entamer le processus d'évaluation de leur adéquation, ce qui libère les mains de la direction et lui permet de s'engager dans une telle «agression». Le plus souvent, des mesures inadéquates sont de nature locale; si vous êtes confronté à la descente de «l'impossible» d'en haut, alors ce sont des problèmes structurels mondiaux, dont nous avons parlé dans le texte sur les managers «efficaces» .

L'introduction de la responsabilité collective pour la punition


De nombreux exemplaires ont déjà été cassés sur le thème de la responsabilité collective. Habituellement, cet outil est pratiqué pour la soi-disant construction de relations de confiance au sein de l'équipe. Le message clair est: "s'entraider, corriger et expliquer les erreurs à vos collègues et vous deviendrez une grande équipe."



Dans une exécution adéquate, cette approche vous permet de «tirer vers le haut» rapidement les nouveaux arrivants, élimine la nécessité de nommer des mentors «sous le bâton» et tous les autres mécanismes coercitifs.

En fait, la responsabilité collective se transforme souvent en un outil répressif pour exercer une pression sur l'équipe et ses membres individuels. Le postulat des primes collectives pour un travail réussi est omis et tous les exploits de travail de l'équipe sont dévalués avec la formulation «vous devez travailler à 100% de toute façon». D'un autre côté, toute erreur répréhensible à la direction d'une personne entraîne des sanctions collectives contre toute l'équipe.

En conséquence, le «coupable» des sanctions est évincé de l'équipe: qui est content de perdre des bonus et des bonus à cause des erreurs d'une autre personne? Si le département ne dispose pas d'une unité suffisante, très rapidement un employé répréhensible devient un paria, après quoi il commence à changer d'emploi.

Pression sur l'estime de soi professionnelle


Une autre technique qu'une personne peut essayer de survivre de son lieu de travail s'exprime en exerçant une pression sur l'estime de soi professionnelle de l'employé. Quoi de plus important que l'estime de soi professionnelle? Pour de nombreux informaticiens, le niveau d'estime de soi personnelle est directement en corrélation avec le niveau de professionnel. Les réalisations dans le domaine professionnel nous donnent la force pour le développement personnel et la croissance, montrent que nous sommes capables d'être meilleurs que nous ne pouvions compter.

Bref, l'estime de soi professionnelle est un point très, très sensible sur lequel il ne faut pas faire pression. Mais comment est-il affecté exactement? Il existe quelques moyens simples: définir des tâches floues et le doute du public sur les compétences. En règle générale, ces «astuces» sont utilisées conjointement.

Le spécialiste qu'ils veulent évincer de l'entreprise se voit confier des tâches aussi vagues que possible, principalement oralement, afin de ne laisser aucune trace. Si la réglementation de l'entreprise vous oblige à correspondre et à définir des tâches détaillées - n'hésitez pas, pour comprendre ce qui est écrit, vous devrez ressusciter Turing et toute l'équipe qui a travaillé avec le décryptage des messages Enigma. Si le développeur n'est pas venu pour des explications - eh bien, cela signifie qu'il comprendra certainement tout ce qui ne va pas et qu'il pourra arranger un frein, au moins pour son initiative et le mauvais ordre de prise de décision.

Si le développeur considère qu'ils jouent à certains jeux avec lui et adopte le principe de "l'efficacité et la qualité du travail effectué dépend de la clarté de la tâche" et continue de clarifier la tâche, il tombe dans le prochain piège de cette chaîne.



L'essentiel est qu'au moment de poser la question "Quel genre de déchets est-ce dans ma tâche?" il y avait autant de spectateurs fidèles que possible. Ainsi, lorsque la question est posée, les yeux sont arrondis et la contre-question dans le style de la Terre promise est posée aussi fort que possible: «Eh bien, comment un développeur aussi expérimenté et habile ne peut-il pas faire face à la tâche la plus simple pour le mois de juin vert?!». Eh bien, le libellé de l'appel peut être n'importe quoi, le but est d'humilier publiquement une personne.

Le problème du développeur est qu'il perçoit des choses comme «Dieu, pourquoi dois-je travailler avec des idiots», c'est-à-dire, souvent, pour acquis. En fait, il tombe dans un piège dont le but est de l'humilier en tant que professionnel aux yeux de ses collègues et de porter atteinte à sa propre estime de soi. Parce que si ces situations se répètent systématiquement, même la personne «la plus forte» commencera à penser au moins à un changement d'emploi, et à tout le moins à se désintéresser du projet, c'est-à-dire qu'elle aura des problèmes de productivité réels plutôt que farfelus. Ce dont nos adversaires ont seulement besoin.

Comment faire face à une telle terreur


Le but de toutes les manipulations de ce genre est le même: détacher l'équipe et éliminer les personnes potentiellement dangereuses et / ou puissantes. Mais cela arrive quand vous "n'aimez pas le visage". Pourquoi nous le faisons, nous l'oublierons, car il s'agit déjà d'une question pour un article sur l'éthique des entreprises et elle recoupe directement le thème de la gestion «efficace». En fait, nous n'avons mentionné que quelques-uns des exemples les plus frappants de pression sur les développeurs, dont le but est de les forcer à partir. En fait, il y a beaucoup plus de trucs "sales", allant des potins dans la cuisine du bureau et se terminant par un sabotage direct du travail.

La première façon de se prémunir contre de telles actions est d'interagir en cas de litige avec la direction un peu plus loin. Dans les entreprises adéquates, un employé peut toujours s'adresser directement au "patron de son patron". Mais il y a deux gros "MAIS". Premièrement: si tout cela se produit avec la sanction de cadres supérieurs, alors se débarrasser de la pression ne fonctionnera pas. Deuxièmement: le leader doit être prêt à agir comme arbitre, ce qui n'est pas toujours le cas.

La deuxième façon consiste à fixer clairement chaque étape et chaque tâche du gestionnaire de tâches, afin d'éviter toute plainte formelle et d'entraîner le conflit dans un plan pratique, où les développeurs ont un avantage. Il s'agit d'une guerre de position - qui survivra et qui éclatera. Le problème avec cette méthode de contre-réaction est que des erreurs ne peuvent pas être commises ici et que le côté défenseur est dans une position sciemment perdante, car les «règles de guerre», c'est-à-dire les tâches, sont souvent déterminées par l'attaquant.

Il existe encore une troisième voie mythique, lorsqu'une équipe s'unit autour d'une victime de pression et ne permet pas à une personne de survivre de son lieu de travail. Dans ce cas, le conflit entre dans une phase prolongée de la confrontation et, très probablement, conduira à un changement de direction (car il est plus facile de moins cher que de laisser tomber toute l'équipe et d'en recruter une nouvelle). La principale condition est l'efficacité du plan de travail.

Mais c'est presque un scénario fantastique, car ce n'est pas pour rien que j'ai mentionné la nature émotionnelle «baissière» des informaticiens. Lorsque nous constatons qu'un collègue a besoin de notre aide, il a le plus souvent déjà signé des documents sur son propre licenciement et vous invite à un rendez-vous d'adieu dans un bar voisin.

Source: https://habr.com/ru/post/fr430398/


All Articles