Le champ de lit à l'heure, ou 5 signes de problèmes cachés dans l'équipe

Il y a beaucoup de problèmes de communication et leur solution est toujours très spécifique à chaque cas. La difficulté de certains problèmes réside dans le fait qu'ils sont cachés et se font sentir clairement quand il est déjà trop difficile ou trop tard pour réparer quelque chose. Je me suis souvenu de cinq cas que j'ai personnellement rencontrés. Tout n'a pas été résolu, tout n'a pas été décidé consciemment. Sous la coupe, vous trouverez cinq histoires illustrant les cinq signes de problèmes. J'ai complété chaque histoire avec un indice très sec sur la correction car la vraie solution est très subjective.

Le début de février est un bon moment pour penser au printemps, à l'été, au chalet d'été, aux lits, aux grands lits longs ... C'est bien que ce soit février, alors parlons du travail d'équipe. Comment est le livre de Tolstoï dans Anna Karenina? «Toutes les familles heureuses se ressemblent, chaque famille malheureuse est malheureuse à sa manière.» Chacun a sa propre compréhension du bien et du mal. À mon avis, chaque équipe ou entreprise a certaines caractéristiques de la relation au sein de l'équipe et du leadership avec ses employés, qui sont le résultat des caractéristiques du comportement inconscient des gens. C'est le facteur d'inconscience qui cache ces problèmes, car souvent, si une personne ne voit pas le problème, alors le problème, pour ainsi dire, ne l'est pas. En réalité, il s'avère que le comportement est différent de ce qui est déclaré par l'équipe ou l'entreprise, mais implicitement. Vous ne pouvez les remarquer qu'après plusieurs mois de travail dans l'entreprise. Rappelant des problèmes similaires dans différentes sociétés informatiques, j'ai dressé une liste de ces traits qui pourraient rapidement comprendre la nature des problèmes existants et la manière de trouver des solutions.

1. Les développeurs ne sont qu'une autre ressource

Type de problème: entreprise vs employé

Un gestionnaire m'a dit: «Je relève des PDG et des parties prenantes. Et vous n'êtes qu'un développeur. " Cela signifiait qu'il avait une grande responsabilité, et pour moi, en tant que développeur, il n'y avait pas une telle responsabilité. Plus tard, il s'est avéré qu'il n'avait pas sa propre opinion sur les personnes sous son commandement et il a simplement diffusé les idées de son patron. Et son patron n'a pas communiqué très étroitement avec les développeurs. Par conséquent, la gestion était minime et seuls les rapports étaient une priorité. Pour cette raison, l'attitude envers les gens était comme s'ils étaient des rouages ​​du mécanisme. Personne ne pouvait le dire directement en vertu de normes acceptées, mais les choses parlaient d'elles-mêmes. Personne ne vous dira que vos objectifs ne sont pas importants car ils perdront la face. Mais, en même temps, personne ne tiendra compte de vos intérêts, comme Votre manager sait exactement ce que vous devez faire, comment penser et ce que vous ressentez. Lorsque vous discutez des perspectives, on peut vous dire des choses agréables que vous voulez entendre. Mais l'action réelle ne suit pas cela, et il y a toujours une raison pour laquelle quelque chose d'autre est plus important. Et si vous commencez à être en désaccord, vous serez accusé de ne pas écouter, de ne pas communiquer ou, pire encore, d'introduire de gros risques dans le projet. De toute évidence, votre patron refuse de trouver une solution qui serait bénéfique pour les deux. La solution la plus simple pour lui, c'est vous, ne faisant que ce que vous avez dit. Dans l'entreprise, cette attitude envers les salariés s'est maintenue à un niveau élevé. En conséquence, le roulement du personnel a augmenté. Et un certain nombre de personnes clés ( développeurs et partenaires produits (ing.: Propriétaire du produit) ) ont quitté l'entreprise.

Astuce: recherchez la synergie

Il est normal que les gens aient leurs propres objectifs personnels et que l’entreprise ait les leurs. En particulier, ils ne coïncident pas, mais il est important de comprendre à quel point les gens et l'entreprise divergent en termes d'objectifs. En trouvant des synergies avec les employés, vous augmentez le gain par rapport au cas où les gens font juste ce qu'on leur dit.

2. Quelqu'un surveille constamment vos erreurs

Type de problème: manager vs employé

C'est normal lorsque les gens au travail essaient d'aider leurs coéquipiers en discutant ouvertement et respectueusement des problèmes. Cette atmosphère de soutien se brise si elle est mal utilisée par les rôles de gestion (chefs d'équipe ou gestionnaires). La situation peut se développer involontairement et peut être plus visible avec la participation du gestionnaire que du chef d'équipe. Par exemple, un manager vous demande ce que vous aimeriez améliorer en équipe. Vous, bien intentionné, dites, dans un tas avec le reste, que ce serait bien si Vasya écrivait plus de tests unitaires. Le manager, lors de sa rencontre avec Vasya, lui dit, comme s'il faisait un reproche, qu'il n'écrit pas de tests unitaires. Ce paragraphe peut être un paragraphe, par exemple, sur une évaluation des performances. Vasya, voyant les affirmations du manager, va essayer de découvrir auprès de ses collègues ce qui ne va pas, mais tout le monde dit que tout va bien. Parce que pour les collègues, le problème des tests unitaires, en tant que tel, ne l'est pas. Mais à ce moment, la confiance commence à se détériorer. Pour Vasya, tout semble comme si quelqu'un derrière lui le noircissait aux yeux du manager, mais ne le lui a pas dit dans les yeux. La situation est mauvaise en ce que personne ne la noircit spécifiquement. Ensuite, cela empire, car si le manager ne peut pas résoudre ce problème, alors dans une telle atmosphère l'insécurité des personnes dans l'équipe s'intensifie et les oblige à constamment prouver quelque chose aux autres.

Astuce: insister sur une discussion ouverte

Ici, le manager doit être tendu. Premièrement, toutes les plaintes ne sont pas vraiment un problème. Deuxièmement, vous devez écouter l'employé, car il peut donner des indices d'une situation similaire. Et troisièmement, le gestionnaire devrait encourager les gens à parler des problèmes uniquement en présence d'une autre personne. Les raisons et les faits des deux parties doivent être pris en compte.

3. Il y a toujours quelqu'un à blâmer pour l'erreur

Type de problème: équipe vs employé

Bien que l'analyse des erreurs soit la norme, un rappel constant des erreurs passées n'est pas normal. Un échec peut survenir en raison d'un manque d'exigences ou d'un manque de connaissances, ou en raison d'échecs successifs à différents stades de développement, tels que le code de révision, l'AQ, l'UAT. Dans ce cas, une attention prolongée à une personne qui a fait une erreur en se moquant de lui aura un mauvais effet. Si ce comportement est la norme dans l'équipe, des parias peuvent apparaître dans l'équipe. Ce comportement est généralement pris en charge par l'un des rôles principaux. Les autres membres de l'équipe s'ajustent et suivent simplement le style du leader. En l'absence de soutien par le haut, ce comportement ne sera pas long et se terminera rapidement. Bien sûr, la personne qui a fait l'erreur doit le savoir et comprendre comment l'éviter afin de ne pas remonter sur le râteau. Mais ne vous y accrochez pas.

Astuce: arrêtez de vous concentrer sur les bugs

La discussion des échecs devrait se terminer immédiatement après que toutes les conclusions ont été tirées. Les coéquipiers devraient se sentir soutenus dans une telle situation.

4. L'équipe commence les tâches sans description ni planification

Type de problème: équipe vs client

La phase de planification est importante et personne ne vous dira que vous ne devez pas le faire. Dans le même temps, l'équipe peut manquer d'autorité ou de soutien de la part de la direction pour repousser des tâches qui n'ont pas de description. La direction peut dire qu'elle est très désolée et reconnaître les erreurs de planification qui lui ont fait accepter des accords qui ne peuvent être retardés. Dans de telles circonstances, les développeurs sont ceux qui paient le prix final. La direction répétera les mêmes erreurs encore et encore, car les développeurs font simplement ce qu'on leur a dit. En même temps, tout le monde garde son visage, car il y a une reconnaissance formelle du problème et une promesse de le résoudre ... un jour. Au cours du travail, les développeurs sont constamment confrontés à une situation où quelque chose n'est pas décrit dans les tâches. Ils commencent à prendre du retard, se précipitent et ressentent une pression constante de la part des dirigeants. En conséquence, les développeurs sont toujours extrêmes.

Astuce: protégez l'équipe, pas vous-même

Le chef d'équipe, ou le manager, doit prendre la responsabilité de protéger l'équipe des autres managers et clients, résister à leur assaut et ne pas abandonner la responsabilité au niveau de l'équipe. La définition de Prêt pour les tâches devrait aider les gestionnaires à bien préparer les tâches. Dans ce cas, cela devrait devenir une règle stricte.

5. Solution

Type de problème: processus vs employés

Sous une forme vivante, j'ai rencontré cette fonctionnalité dans une jeune entreprise, où les processus se sont développés à un rythme très rapide. Dans une conversation personnelle, le patron m'a dit: "Nous avons un processus, mais vous devez comprendre quand cela vaut la peine de se déplacer pour terminer la tâche plus rapidement." C'est vrai: parfois contourner le processus aide à atteindre les objectifs plus rapidement, et c'est même nécessaire. Mais lorsqu'il est nécessaire de contourner le processus dans 50% des cas, le processus lui-même commence à être perçu comme une certaine formalité. Dans ce cas, il est évident que le processus est plus un obstacle. En revanche, sans processus, la direction se sent précaire en raison d'un mauvais contrôle et d'un manque de confiance envers les développeurs. En conséquence, tout le monde comprend le problème, mais changer le processus est difficile en raison de la bureaucratie (tout le monde a besoin du consentement, c'est un tas de rassemblements, etc., etc.). Par conséquent, certains gestionnaires peuvent suggérer aux développeurs de contourner le processus en fonction des meilleurs motifs. Mais en offrant cela, ils mettent les développeurs dans une position vulnérable où une telle étape peut être considérée différemment selon les personnes et les occasions.

Astuce: suivez le processus plus facilement

Vous n'avez peut-être pas besoin d'un processus ou de règles. Au lieu de cela, vous n'aurez peut-être besoin que de recommandations sur la façon de faire quelque chose avec la possibilité d'une exécution différente. Eh bien, ou vous pouvez penser au processus officiel de contournement du processus standard, dans certains cas. Mais dans ce cas, avez-vous besoin d'un processus plus lent?

Avez-vous vu quelque chose de similaire? Ajoutez vos commentaires de cas.