Pages

lundi 13 décembre 2010

Le directeur technique

La sagesse populaire est que les gens font de mauvais gestionnaires techniques. Il ya toujours ce bras de fer entre les MBA et les techniques relatifs à la personne qui est moins désespérée. Pour les gens techniques, MBA signifie "Médiocre mais arrogant". Le MBA auraient leur propre liste de TLA (Trois Lettre acronymes) pour décrire un technocrate. Indépendamment de l'appréciation de chaque communauté par l'autre, c'est un fait que les gens techniques éventuellement devenir gérants à un moment ou un autre. Ce n'est que l'élite même que rester en tant que contributeurs individuels. Pour le reste, la vie professionnelle est un sport d'équipe, et nous sommes tenus de faire ce qu'il faut.

Qu'a donc le technocrate? Pourquoi ne peut-il pas être un bon gestionnaire? Je suis sûr que beaucoup d'entre eux sont des parents très, très sociable, et responsable en dehors de leur vie professionnelle. Qu'est-ce qui leur arrive quand ils entrent dans la sphère professionnelle? Il ya de nombreuses questions. Je tiens à enquêter sur deux d'entre eux: i) la portée du projet, et ii) l'analyse des forces et des faiblesses de son équipe.

Supposons un ingénieur est invité à portée d'un projet impliquant des algorithmes informatiques complexes. Supposons qu'il a quelques ingénieurs juniors en vertu de celui qui fera la mise en œuvre du projet. C'est ce qu'il va faire: «Le projet me demande de mettre en œuvre les caractéristiques A, B et C. Si je peux avoir ces trois caractéristiques, la fonction D, E et F doit être facile car ils ne sont que des extensions de A, B et C. Maintenant que je vais avoir un code de base solide possédant les caractéristiques A à F déjà mis en place, pourquoi ne pas ajouter G et H ainsi? Après tout ce ne sont que la réutilisation et un peu de re-conditionnement de A à H. Ce seront en . Ainsi, alors que l'exigence est pour A, B et C, il sera plan de A à Z. Quand les ingénieurs juniors voir cela, ils seront naturellement indignés. Lorsque la direction voit cela, il sera naturellement exalté à la perspective de dépassement des objectifs. A la fin de la journée, les ingénieurs juniors auront complètement dépassés, et le gestionnaire sont moins efficaces que l'ensemble AZ qu'il avait promis. Or, comme il n'a pas tenu sa promesse, il recevra la chaussure, même si il aurait rendu beaucoup plus que l'AC qui a été initialement demandé.

Que peut apporter un gérant, sans compétences techniques ne dans ce scénario? Compte tenu de la tâche de fournir des AC, il va aller négocier pour AB. Il demande à l'avance que le calendrier est trop serré pour AC. Il promettra AB, prendre la tâche de son équipe et obtenir son retour. L'équipe sera probablement se fait avec le temps dans la main. Le gestionnaire aura l'équipe à un dîner d'appréciation. En retour, son équipe de bénévoles pour compléter C ainsi. Maintenant, il va montrer qu'il a dépassé les attentes et de gagner une petite tape dans le dos.

La leçon ici est simple. L'objectif est de dépasser les attentes. Mais l'essentiel est que les attentes sont ce que vous définissez qu'ils soient. Si vous définissez des attentes élevées, et ne pas y arriver, vous êtes de retour à la case départ. Alternativement, vous pourrait abaisser les attentes et les dépasser constamment. Le gestionnaire intelligent sait cela. Le technocrate pauvres apprend cette fois plus.

L'autre problème, le technocrate doit faire face est qu'il portées du projet repose sur ses capacités, et non de son équipe capacités. Dans l'exemple ci-dessus, notre technocrate va comme ceci: "entité-A est une variante de l'algorithme de Dijkstra, devrait donc être fait en une demi-journée d'entité-B est une extension de A. Donc, il ne prendra pas plus d'un. heure. entité-C est juste un problème de dos. Nous pouvons mettre en œuvre l'algorithme glouton existants. Cela va prendre un jour. Nous mettons en œuvre des algorithmes bien connus, de sorte essais et de vérification devraient être minimes. Le projet ne devrait pas prendre plus d'une semaine "

La première réaction de l'ingénieur junior sera "Qu'est-ce que cette algorithme de Dijkstra? En passant, comment est-elle prononcée?" Notre gestionnaire de technologie sera tout simplement perdre à ce point. "Saviez-vous que quand j'étais à votre place, j'ai proposé un algorithme probabiliste qui a été meilleur que Dijkstra? Les sots au comité de lecture a rejeté mon papier". L'ingénieur junior ira "Ok. C'est très impressionnant. Mais ce que le diable est ce truc Dijkstra?" Or, selon le tempérament de la techno-manager, il pourrait choisir d'enseigner le tout à l'ingénieur, ou d'un point à l'ingénieur d'un livre, ou dans le pire des cas, de recommander à la haute direction que ce gars-là est inutile. Quoi qu'il fasse, le résultat sera le même. Le projet ne sera pas respecter le calendrier.

Le gérant, sans expertise technique n'ont pas idée de l'algorithme de Dijkstra ou quelque chose de similaire. Sa portée sera d'abord impliquer ses ingénieurs. Le gérant utilisera leurs commentaires pour créer un calendrier, qui sera probablement avez un mois. Finalement, il va battre le calendrier et de prendre une maison de bonus à portée de main. Voici un cas où la prouesse technique du directeur technique de travaille contre lui. D'autre part, le gérant, sans l'expertise technique se sert de son manque de connaissances techniques à son avantage.

En résumé, la chose la plus important pour un manager est de respecter le calendrier. Il a soit à niveau son et la productivité de son équipe, ou de niveau bas des attentes pour atteindre cet objectif. Les responsables techniques n'avez probablement pas cette astuce. Ils sont mus uniquement par la stratégie de level-up et à l'automne court à chaque fois. Deuxièmement, le directeur technique doit comprendre que son équipe peut ne pas être aussi bon que lui. Cela peut souvent être une situation difficile. Il faut pour cela le gestionnaire de savoir qu'il est bien meilleur que les autres. Plus d'une fois, si vous êtes bon, vous ne réalisez pas que vous êtes bon. Les choses semblent tellement évident pour vous. Lorsque la personne d'autres ne l'obtient pas, vous marque lui aussi incompétent. Le gestionnaire doit avoir une mesure de la bonne est "assez bon" pour les membres de son équipe. Il doit aussi comprendre que certains membres de son équipe sera mieux au fil du temps. Ceux qui ne va pas mieux sont les vrais incompétents.

Les responsables techniques peuvent facilement tourner autour pour que tout fonctionne en leur faveur. Ils ont un énorme avantage de leurs connaissances techniques. Le jour cygne noir, c'est le technocrate qui sera en mesure de liberté sous caution à l'entreprise. Gérants sans l'expertise technique comptent beaucoup sur les compétences de leur équipe et la confiance pour faire le travail. Si l'une des deux (la compétence ou de confiance) prend un coup, ils n'auront pas une stratégie de sortie. En outre, les connaissances techniques peuvent être utilisés pour canaliser le processus de pensée pour qu'il y ait un équilibre entre l'innovation et le pragmatisme.

Principalement, un responsable technique doit faire un effort pour communiquer avec son équipe et de comprendre ses forces et ses faiblesses. Peut-être qu'il devrait passer un peu de temps à gérer une équipe qui n'est pas dans son domaine technique. Ce sera le forcer à se fier à ses compétences de gestion pour faire le travail. Il peut capter les nuances de la gestion, en particulier ceux liés à la compréhension des points forts de son équipe et ses faiblesses. Quand il revient, il ne peut pas être le monstre à son équipe qu'il était auparavant.

cet article est traduisé en francais
l'origine de cet article (en anglai): http://ezinearticles.com/?The-Technical-Manager&id=4755729

0 commentaires

Enregistrer un commentaire