Geekly articles weekly

Personnes à problèmes parmi les chefs de projet



Pour ceux qui ne connaissent pas le développement logiciel, il peut sembler étrange qu'un projet ait à la fois un chef de produit et un chef de projet . La différence est que le premier est responsable de la détermination du produit, et le second est responsable de l'état du projet et de signaler aux parties intéressées si la date de livraison est à risque.

Les chefs de projet ont tendance à s'efforcer d'assurer la prévisibilité des délais grâce à la normalisation et aux processus cycliques. Ces processus se concentrent sur les rapports d'état pour suivre les progrès. Il est généralement admis que plus vous surveillez de près les processus, plus le calendrier du projet sera prévisible et plus la probabilité que le projet soit livré à temps est élevée.

La malédiction du chef de projet est la qualité des estimations du temps qu'il reçoit de l'équipe. Ces estimations peuvent varier énormément. Ils varient généralement d'une personne à l'autre et des mises à jour quotidiennes peuvent être nécessaires. Un tel tourbillon dans les estimations peut en fin de compte rendre impossible la détermination du calendrier du projet, mais une date ferme est attendue du gestionnaire. Lorsque ces échéances sont finalement manquées, le gestionnaire doit trouver un moyen d'expliquer pourquoi les échéances sont manquées, sans rendre les derniers employés directement responsables de l'échéance manquée. Une diplomatie inadéquate dans ce domaine conduit souvent le personnel à accuser le chef de projet de «les jeter sous le train», quelle que soit l'exactitude de leurs évaluations précédentes.

Les personnalités problématiques parmi les chefs de projet sont les suivantes:


Planificateur de réunions


Le chef de projet, qui estime que tous les problèmes du projet sont causés par un manque de communication et de coordination, et un nombre important de réunions sera la solution.

  • Peut muter en statistiques
  • Dangereux en combinaison avec le chef de produit tel que l' auteur du brevet
  • Probabilité de correction: élevée
  • Danger pour le projet: faible

Le problème


En théorie, les gens se réunissent en réunions pour discuter des options et prendre des décisions. En fait, cela arrive rarement. Le planificateur de réunions n'est pas conscient de ce phénomène et essaie de programmer des réunions aussi souvent que possible, avec autant de personnes que possible. Il croit sincèrement que cela améliorera la collaboration au sein de l'équipe: l'idée que la communication ne suffit pas pour la réussite du projet s'est fermement renforcée dans son esprit.

Ce type de manager exacerbe trois principaux problèmes inhérents à la grande majorité des réunions:

  1. En règle générale, la sélection des participants est mal effectuée, ce qui fait que certains écoutent des informations qui ne les intéressent pas et expriment une opinion sur des questions qui ne les concernent pas.
  2. L'organisation des réunions est également généralement mal réalisée, ce qui conduit souvent à des débats chaotiques qui ne sont pas pertinents pour le but de la réunion, ce qui à son tour ne conduit à aucune conclusion pratique.
  3. Les projets ne sont pas terminés lors de réunions, mais sur les lieux de travail. Si vous conduisez des employés à des réunions au lieu de travailler, ils passent un temps précieux.

Solution


Un planificateur de réunions ne constitue pas une menace sérieuse pour un projet car les employés n'assistent généralement pas aux réunions qui nuisent à leur productivité. Par conséquent, le travail se poursuit malgré les réunions en cours.

Ce chef de projet peut être corrigé avec une simple instruction:

  1. Classer tous les types de réunions qu'ils organisent habituellement: rapports d'étape, revues de projet, planification, etc.
  2. Déterminez quels résultats (le cas échéant) de ces réunions peuvent être obtenus par d'autres moyens, par exemple par courrier électronique, outils de suivi, conversations informelles.
  3. Pour les réunions obligatoires, déterminez à quelle fréquence elles doivent avoir lieu et qui doit être présent.
  4. Planifiez des réunions par blocs pour éviter les distractions multiples dues au changement de contexte.
  5. Laissez certains jours de la semaine libres des réunions.
  6. Exempté du montage quelques semaines dans son ensemble (vous serez aimé pour cela).
  7. Planifiez chaque réunion au moins une semaine à l'avance avec un ordre du jour publié et tous les documents qui doivent être examinés avant la réunion.
  8. Au début de la réunion, passez en revue l'ordre du jour, les objectifs de la réunion et aidez à atteindre ces objectifs.
  9. Mettez fin à la réunion immédiatement: ne la poursuivez pas si l'objectif initial est atteint.

Des réunions sont nécessaires pour mener à bien le projet, mais surtout:

  1. Rendez chaque réunion aussi efficace que possible.
  2. Minimisez l'impact négatif sur les performances.

Dès que le planificateur de réunion le comprendra, son comportement changera immédiatement pour le mieux.

Statisticien


Un chef de projet impliqué uniquement dans la création de listes et la vérification des éléments, quel que soit leur contenu.


Le problème


La réalisation de tout projet nécessite deux étapes essentielles:

  1. Faites une liste de choses à faire.
  2. Marquez les éléments de la liste qui sont créés.

Le chef de projet du type de statistiques est parvenu à la conclusion que le maintien de cette liste constitue l'intégralité de ses responsabilités professionnelles. Il n'est pas inquiet de ce qui est sur la liste. Seulement par le fait qu'il a des points et qu'ils sont contrôlés à un rythme prévisible. Le statisticien n'évalue pas et n'offre aucune approche critique de ce que sont les éléments de la liste, mais s'appuie plutôt sur d'autres, en leur indiquant le contenu de l'élément et la date limite.

La plus grande préoccupation pour un tel gestionnaire est que le logiciel de gestion de projet puisse faire son travail. Ainsi, cela devient inutile. Souvent, des statistiques sont fournies pour mener des projets dans un tel programme, et il tient très soigneusement à jour les informations. Le projet lui-même peut être en ruine, l'équipe peut sortir un produit complètement faux avec un retard de plusieurs mois et de mauvaise qualité, mais jusqu'à présent tout est correctement documenté, le statisticien ne voit aucun problème.

Heureusement, si un statisticien ne tient à jour que des listes et supprime des éléments, il ne nuit pas au projet s'il ne tient pas compte de son ignorance de la véritable situation. Le principal problème est que les statistiques peuvent rapidement se transformer en quelque chose de bien pire.

Solution


Les statistiques sont difficiles à fixer car son souci du détail est profondément enraciné dans la nature, très probablement dès l'enfance. Si quelqu'un considère les listes importantes, il ne changera pas soudainement son état d'esprit après vos mots. De plus, les listes sont vraiment importantes, mais ce ne sont qu'une carte, pas un paysage. Ce paradoxe déroutant des listes, qui sont importantes mais pas primordiales, rend les statistiques particulièrement difficiles à corriger.

Une compétence clé qui fait défaut aux statistiques est la capacité de travailler avec les gens. Le gestionnaire interagit avec la liste plutôt qu'avec les gens. Invitez-les à parler aux gens en direct de ce qu'ils font et pourquoi, et pas seulement à demander une liste d'articles. Cependant, en cas de mauvaise exécution, les statistiques peuvent glisser vers la micro-gestion (voir gestionnaire peu sûr ).

Enfin, demandez à rédiger un résumé d'un paragraphe sur l'état du projet et ne montrez pas le résultat sous forme de liste d'éléments. Cela leur permettra de présenter le projet de manière plus globale.

Trompé


Le gestionnaire est tellement séparé des réalités du projet qu'il donne de fausses informations aux parties intéressées.

  • Peut muter en optimiste ou pessimiste
  • Dangereux lorsqu'il est combiné avec un développeur optimiste
  • Probabilité de correction: élevée
  • Danger pour le projet: très élevé

Le problème


La principale responsabilité du gestionnaire est de rendre compte de l'état d'avancement du projet. C'est ce qu'on appelle «établir des attentes» et «répondre aux attentes» est la mesure par laquelle le succès d'un projet est déterminé. Un bon chef de projet établit des attentes basées sur une combinaison de données quantitatives et qualitatives, ainsi que sur sa propre expérience professionnelle. D'un autre côté, un manager errant est basé uniquement sur son instinct.

Les phrases clés suivantes vous permettent de reconnaître le chef de projet dans les nuages:

  • "J'ai un mauvais pressentiment."
  • "Je ne pense pas que nous serons dans le temps d'ici là."
  • "Je pense que tout ira bien pour nous."
  • "Je ne vois aucun problème."
  • "Cette décision m'embrouille."

Faites attention à l'utilisation du «je» et du «nous» - ce sont de bons marqueurs que la perception du manager est basée sur des impressions subjectives, et non sur les données collectées et analysées.

Il est important de noter la différence entre un manager égaré, un pessimiste et un optimiste :

  • Un pessimiste , basé sur son interprétation des informations quantitatives et qualitatives, estime que le projet échouera.
  • Un optimiste , basé sur son interprétation des informations quantitatives et qualitatives, estime que le projet sera couronné de succès.
  • Le gestionnaire erroné uniquement sur ses propres sentiments se fait une opinion sur le succès ou l'échec du projet, ce qui est complètement faux.

C'est l'une des rares personnalités qui peuvent ruiner un projet entier à lui tout seul. Si un tel gestionnaire rencontre souvent des parties prenantes, la vigilance doit être renforcée car les événements suivants peuvent se produire:

  1. Le gestionnaire informe les autorités que tout est perdu, le projet ne sera jamais mis en production, ce qui entraînera l'annulation du projet.
  2. Le gestionnaire dit que tout est en ordre et que tout sera à l'heure, ce qui fera que les autorités seront encore plus déçues si elles sont en retard, ce qui entraînera l'annulation du projet.

Solution


Heureusement, un tel gestionnaire peut être corrigé en deux actions:

  1. Demandez-lui pourquoi il ressent ce qu'il ressent.
  2. Montrez-lui des données quantitatives et qualitatives contraires à ses instincts.

Pourquoi demander à exprimer ce qu'il ressent? Cela l'aidera à comprendre que le jugement n'est pas basé sur quelque chose de matériel, mais sur une évaluation subjective, c'est-à-dire sur des sentiments. Il est essentiel qu'il arrive à cette conclusion par lui-même - pas besoin de dire qu'il a un mauvais instinct. Continuez à demander «Pourquoi pensez-vous ainsi?» Jusqu'à ce que vous atteigniez une percée.

Dès que le gestionnaire l'obtient, montrez-lui les faits solides sur le projet. Par exemple, s'il dit que «la qualité des produits n'est pas bonne», imaginez un graphique montrant une baisse constante du nombre de bogues au cours des derniers mois. S'il dit: «Nous serons prêts à temps», fournissez une liste des tâches incomplètes et le temps habituel d'achèvement des tâches, ce qui prouve le contraire. À ce stade, il devrait simplement appartenir à l'esprit et à la logique du gestionnaire de l'emporter. S'il reste dans l'illusion, répétez le processus autant de fois que nécessaire.

Pessimiste


Un manager qui parle avec confiance de l'échec du projet, et il est impossible de le convaincre du contraire.

  • Peut muter en errant
  • Il est dangereux en combinaison avec un testeur tel qu'un alarmiste
  • Probabilité de correction: non
  • Danger du projet: extrêmement élevé

Le problème


La plupart des projets de développement logiciel peuvent être considérés comme infructueux d'un côté:

  • Excédent budgétaire.
  • Dépassement des délais.
  • Manque de toutes les fonctionnalités nécessaires.
  • Problèmes de performances, de stabilité ou d'évolutivité.
  • Un grand nombre de bugs.

Dans le monde réel, cela peut être attendu et parfois perçu comme une réalité inévitable. Mais le pessimiste exige tellement que le projet ne puisse pas répondre, alors il annonce son échec bien avant l'échec réel du projet.

Un pessimiste est facilement identifié par deux caractéristiques clés:

  1. Il choisit spécifiquement des mesures négatives sur l'état du projet afin de se concentrer sur le négatif, en ignorant ou en dévaluant tout signe positif.
  2. Il est passionné par ses performances, souvent pleines de drames émotionnels.

Une telle position peut convaincre les autorités que le projet est sans espoir et qu'il est vraiment annulé.

Solution


Le directeur pessimiste ne peut pas être fixé, car il est souvent malheureux dans sa vie personnelle, insatisfait du travail, de la carrière ou de l'entreprise elle-même. Ainsi, son négatif n'a rien à voir avec le projet lui-même, mais représente un problème personnel. La meilleure chose que vous puissiez faire est d'offrir des conseils psychologiques, ce que peu d'entreprises proposent. Cela conduit au résultat souvent inévitable: le manager part ou l'entreprise le licencie.

Optimist


Un chef de projet qui s'est convaincu de la réussite du projet, malgré toute preuve du contraire.

  • Peut muter en capitaine d'équipe ou se tromper
  • Dangereux lorsqu'il est combiné avec un développeur optimiste
  • Probabilité de correction: faible
  • Danger du projet: extrêmement élevé

Le problème


En règle générale, les gens aiment travailler avec des gens positifs. L'inconvénient d'un gestionnaire optimiste est que sa vision du monde positive ne fait pas clairement apparaître les signes avant-coureurs du projet . Au lieu de prendre des mesures pour résoudre les problèmes, il préfère ignorer ces signes, les considérant comme négatifs pour la santé, et préférant plutôt ne signaler que le bien. Cela crée une culture de complaisance ou de découragement parmi les membres de l'équipe, tandis que les patrons ont l'illusion que tout va bien.

Dans toute position de leadership, l'optimisme face à l'adversité est un avantage important. Pour distinguer un gestionnaire optimiste d'un leader audacieux, utilisez les tests suivants:

  • Se sent-il reconnaissant des mauvaises nouvelles?
  • À quelle fréquence fait-il des compliments infondés?
  • Est-il toujours de bonne humeur, peu importe le moral de l'équipe?
  • Évite-t-il la confrontation, même si elle est justifiée?
  • Ne semble-t-il pas que les gens l'aiment plus que le succès du projet?

Un gestionnaire optimiste fait souvent échouer un projet, car il ignore les problèmes qui peuvent conduire à l'échec. Plus le projet prend de temps, plus l'effet est mauvais.

Solution


Un optimiste est facilement confondu avec un leader audacieux, c'est pourquoi ils sont rarement identifiés, et donc rarement corrigés. Au moment où la forme optimiste apparaît, il est souvent trop tard car le projet a déjà échoué.

Les organisations s'efforcent de promouvoir des leaders courageux. En conséquence, un gestionnaire optimiste a plus de chances de promotion s'il peut convaincre ses supérieurs que le projet a échoué pour des raisons indépendantes de leur volonté.

Quelle que soit la raison pour laquelle le gestionnaire se comporte de cette façon - pour la croissance de sa carrière personnelle, ne voulant pas faire face à une vérité inconfortable ou simplement à la naïveté - les dommages causés au projet sont les mêmes. La seule différence est de savoir s'il est promu ou renvoyé.

Capitaine d'équipe


Un chef de projet qui se concentre sur la satisfaction de tous les programmeurs et non sur la réussite du projet.

  • Peut muter en optimiste
  • Dangereux lorsqu'il est combiné avec un responsable du développement des Casques bleus
  • Probabilité de correction: élevée
  • Danger pour le projet: faible

Le problème


Un moral élevé est important pour tout projet: les développeurs sont généralement plus créatifs et productifs lorsque le moral est élevé. Quand un projet va mal, naturellement, le moral baisse jusqu'à ce que la situation s'améliore. À l'heure actuelle, au lieu de résoudre les problèmes du projet, le capitaine de l'équipe s'attache à améliorer le moral.

Le capitaine de l'équipe et l' optimiste ont en commun une attitude positive, mais sa manifestation est fondamentalement différente:

  • L'optimiste ignore tous les problèmes rencontrés par le projet et signale des informations incorrectes aux autorités.
  • Le capitaine d'équipe considère le succès du projet uniquement en termes de moral: un moral bas est un projet infructueux; un moral élevé est un projet réussi. Il pense aux intérêts des clients et des supérieurs plus tard, voire pas du tout.

Le capitaine de l'équipe est très facile à repérer:

  • Il vient spontanément avec des friandises comme le café et les beignets.
  • Il considère qu'il est important de s'entretenir en privé avec chaque employé, "afin de connaître leurs besoins".
  • En règle générale, elle aime parler de choses personnelles, de la vie d'un employé en dehors du travail (pensant que cela peut être une source d'insatisfaction).
  • Il envoie des lettres positives, met en place des motivations dans tout le bureau et est généralement trop positif.
  • Il représente le meilleur mobilier de bureau, le meilleur éclairage et, en règle générale, le meilleur environnement de travail.
  • Lutte avec acharnement contre les mauvaises conditions de travail, telles que le manque de développement de carrière pour les employés, la formation insuffisante et les heures supplémentaires.
  • Organise des réunions parascolaires avec l'équipe, sans lien avec les étapes importantes du projet.
  • Très inquiet que tous les participants au projet l'aiment.


Une telle personne semble être un gestionnaire de projet idéal, mais il y a deux raisons de s'inquiéter:

  1. Tous ces événements n'augmentent que temporairement le moral, qui s'estompe rapidement lorsque les gens se souviennent des réalités du projet.
  2. Ils n'éliminent pas les causes fondamentales de la moralité faible, préférant les incitations à court terme.

Ainsi, le capitaine d'équipe finit par plaire à tout le monde, mais en réalité ne fait pas le travail de chef de projet.

Solution


Le principal problème est que le capitaine d'équipe n'a généralement pas beaucoup d'expérience en tant que chef de projet. Par conséquent, la solution est de le former. Heureusement, il existe une énorme quantité de ressources de formation pour les chefs de projet.

En fournissant au manager les outils nécessaires, il est nécessaire de l'encourager à identifier les causes profondes d'un moral bas, puis à les corriger. Compte tenu de la tendance naturelle du capitaine d'équipe à améliorer l'humeur des employés, il tentera sûrement de trouver et de corriger les causes profondes du déclin moral dès qu'il comprendra ce qu'il faut rechercher.

À ce stade, vous obtenez un chef de projet avec un mélange très puissant de motivations: premièrement, il utilise la moralité comme mesure des problèmes dans le projet, et deuxièmement, il trouve ces problèmes et les résout. Puisque sa motivation vient de la compassion pour son prochain, les problèmes sous-jacents à la moralité faible seront rapidement éradiqués.

Soit dit en passant, dans leur caractère d'être gentil avec les autres, il est donc peu probable de les «guérir» de cette composante, et leur «correction» ne devrait pas impliquer l'élimination des parties positives du caractère. Au final, s'il est possible d'améliorer le niveau du chef de projet, il est difficile de trouver une meilleure option pour de tels investissements que le capitaine d'équipe.

Tyran


Un gestionnaire qui traite les membres du projet avec mépris au nom de leur motivation à travailler plus dur.


Le problème


De nombreuses personnalités fortes sont généralement impliquées dans les projets de développement de logiciels, mais chacun doit être subordonné à un seul objectif et concentré sur la mise en œuvre du projet. Par conséquent, les chefs de projet ont le pouvoir de diriger les participants au projet pour assurer la réussite du projet. Le tyran abuse de ces pouvoirs en utilisant un renforcement négatif pour obtenir des résultats.

Bien que les tyrans puissent ne pas être appréciés, les patrons croient souvent que leur «main ferme» est exactement ce qu'il faut pour la réussite d'un projet, surtout s'il est en retard. Les menaces et les punitions agissent en fait comme une motivation pour de nombreux types de personnalité (voir un développeur comme un soldat ), ce qui aide à propager les tyrans.

Les problèmes réels avec les tyrans sont difficiles à détecter, mais ils sont incroyablement nuisibles au projet.

  • , , , .
  • , , , .

Plus un tyran travaille longtemps, plus cette lente fuite de talents sera dramatique. En fin de compte, une fois que tous les participants compétents au projet seront expulsés, il deviendra impossible d'inviter des participants talentueux et expérimentés au projet, car les employés potentiels ne voudront pas travailler avec une équipe incompétente (le fait apparaît facilement lors de l'entretien).

Il est important de noter que le tyran est généralement présenté au projet au moment le plus inopportun: lorsque le projet est en difficulté. Les projets à risque d'échec devraient vider les membres de l'équipe incompétents, tout en restant compétents, mais le tyran provoque exactement l'effet inverse.

Solution


Pour corriger un tyran, il faut lui faire prendre conscience qu'un tel comportement affecte négativement le projet. Il existe deux approches générales pour cela:

premièrement, fournissez des données quantitatives qui reflètent leur style de gestion de projet:

  • Combien d'employés précieux ont quitté l'État.
  • Réussir à attirer des talents.
  • Combien de fonctionnalités ont été publiées.
  • Combien de bogues sont enregistrés.
  • Combien de dates manquantes.

Lorsque l'on compare ces informations, les délais sont particulièrement efficaces.

Deuxièmement, faites-leur savoir à quels indicateurs vous vous attendez dans un avenir proche. Très probablement, ils montreront de l'irritation et du désespoir, car ils ne savent pas comment améliorer ces indicateurs. Mais c'est une opportunité idéale pour leur offrir des conseils et une formation sur la façon de devenir un meilleur manager. La formation devrait couvrir les éléments suivants:

  • Comment ils se comportent avec les employés.
  • Comment ils discutent des échecs et des succès des projets.
  • Comment identifier et éliminer les participants au projet incompétents.
  • Comment attirer et retenir des participants compétents.

À condition qu'il y ait un spécialiste approprié pour une telle formation, le manager-tyran peut être complètement corrigé, car les caractéristiques suivantes sont naturellement inhérentes à une personne:

  • Les gens ne veulent pas être méchants.
  • Les gens aiment être aimés.
  • Les gens aiment être efficaces.

L'essentiel est que l'équipe adopte une nouvelle approche, malgré la réputation du tyran dans le passé. Le problème peut être résolu très simplement, par exemple, pour convoquer une réunion sur le thème "Je suis désolé" et "J'ai changé pour le mieux".

Obsédé par le processus


Le gestionnaire est tellement obsédé par le processus qu'il oublie sa tâche - pour aider le projet à réussir.

  • Peut muter en tyran
  • Dangereux lorsqu'il est combiné avec un chef de produit de type dictateur
  • Probabilité de correction: élevée
  • Danger pour le projet: faible

Le problème


A l'issue de toute formation ou lecture d'un livre sur le management, chaque manager court le risque de devenir obsédé par le processus. Cela peut arriver même avec les meilleurs, donc la patience est importante lors de leur correction.

Il existe deux grandes catégories de processus qui sont obsédés par:

  1. Obsession de la cascade
  2. Obsession du développement agile (Agile)

Peut-être que le cours ou le livre de formation a appelé ces processus différemment, mais vous pouvez facilement les mettre dans la bonne catégorie en appliquant le test suivant:

  • Les obsédés par la cascade pensent que tous les problèmes peuvent être résolus à l'aide d'une documentation supplémentaire, par exemple, «à partir de maintenant, nous écrirons la configuration système requise pour chaque document ayant des exigences commerciales».
  • Ceux qui sont obsédés par le développement agile croient que tous les problèmes peuvent être résolus à l'aide de réunions courtes et fréquentes, par exemple, «à partir de maintenant, nous organiserons des réunions quotidiennes le matin pas plus de 15 minutes».

L'objectif de tout gestionnaire est de livrer le projet dans les délais et dans les limites du budget. Le processus que nous utilisons facilite cela. Lorsque le chef de projet devient obsédé, il peut ignorer l'objectif principal et se concentrer plutôt sur la question «Le processus se déroule-t-il correctement?» au détriment d'autres fonctions officielles.

Solution


Quoi que vous fassiez, n'essayez pas de leur voler le processus ou de le contester. Vous avez affaire à un fanatique religieux plutôt qu'à une personne rationnelle. Il s'est convaincu que son processus «fixerait» le projet. S'ils pensent que le projet est «interrompu» et que vous essayez de dire «cela ne nous aidera pas», ils considéreront simplement que vous faites partie de la raison pour laquelle le projet est interrompu.

Il est facile de résoudre le processus obsédé: il suffit de se contenter de tout ce qu'il dit, en rappelant doucement que «il faut du temps pour transformer un grand navire» et «Rome n'a pas été construite en un jour». Il s'agit de le forcer à accepter la mise en œuvre d'un nouveau processus à travers une série de petites innovations, plutôt qu'un changement majeur. Cela leur permettra d'apprendre de leur propre expérience quelles méthodes sont efficaces et lesquelles ne le sont pas. En acquérant cette expérience, ils apprendront à adapter le processus à la situation sur le terrain. Il y a de l'espoir qu'ils comprennent: le processus est un moyen pour une fin, pas une fin en soi.

Je ne sais pas


Un chef de projet qui demande constamment le statut actuel des employés, jugeant nécessaire qu'ils se concentrent sur l'accomplissement de leurs tâches.


Le problème


Lorsqu'un gestionnaire est assis à son bureau, loin des participants au projet qui effectuent le travail, il peut facilement ressentir un sentiment d'inutilité. Cela leur fait faire tout ce qui est nécessaire pour se sentir nécessaire et utile. Pour un manager incertain, le moyen le plus évident de paraître productif est de vérifier le travail actuel des salariés. Ceci est souvent réalisé en utilisant les méthodes suivantes:

  • Distribution d'e-mails demandant l'état du projet.
  • Planifiez des réunions pour discuter du statut.
  • L'obligation de remplir les feuilles de temps en détail.
  • L'obligation de diviser les objectifs en petites tâches.
  • Organiser des réunions face à face spontanées pour interroger les membres de l'équipe sur leur statut.

Un gestionnaire peu sûr est largement connu sous un autre nom: micro-gestionnaire. Ses méthodes de gestion de projet sont interprétées par les membres de l'équipe de projet comme l'une ou l'ensemble des éléments suivants:

  • Nitpicking
  • Harcèlement
  • Préoccupation
  • La distraction
  • Interruption
  • Ennuyeux

Souvent, les employés développent un ressentiment profond envers un chef de projet incertain, car à leur avis:
  • Le gestionnaire ne fait pas confiance à ses compétences en gestion du temps.
  • Le manager ne croit pas à leur appréciation des délais.
  • Le gestionnaire ne comprend pas la nécessité d'être seul pour résoudre les problèmes.
  • Le gestionnaire n'a rien d'autre à faire que de demander et de signaler les statuts.

Cette perception crée une confrontation entre le gestionnaire de projet et les développeurs, supprime une communication utile que le gestionnaire pourrait utiliser pour résoudre de vrais problèmes. Au lieu d'interagir avec un tel gestionnaire pour la coopération et la coopération, les développeurs évitent tout contact supplémentaire avec lui, craignant qu'on leur demande (encore une fois) un statut.

Solution


Un manager peu sûr est tellement courant qu'un tel comportement est considéré comme le travail principal du manager. En supposant l'inévitable, la plupart des développeurs forment un certain seuil, à quelle fréquence leur statut actuel leur sera demandé. Étant donné que la plupart ont appris à s'adapter à la poursuite constante du statut, un gestionnaire peu sûr ne représente pas un risque élevé pour le projet, même s'il prive l'équipe de la possibilité de communications utiles qui auraient pu autrement avoir lieu.

Un tel manager est né du fait que la performance de l'équipe n'est pas bien visible pour lui. La solution est donc de placer ce manager à côté de l'équipe. Sinon, ce gestionnaire est dépassé par le désir de demander directement le statut de chaque développeur. S'ils sont à proximité, le gestionnaire peut comprendre l'état actuel du projet, simplement en écoutant les conversations des développeurs entre eux. Dans ce mode, le manager est le plus efficace, car il n'a besoin d'intervenir que lorsque la productivité est vraiment difficile.

Voir aussi:

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

More articles:


All Articles