JH Rainwater «Comment faire paître les chats»: races de programmeurs et caractéristiques de leur élevage

On a déjà beaucoup parlé de la gestion des personnes dans leur ensemble (selon beaucoup, plus que suffisant). A propos de la gestion des programmeurs, en tenant compte des spécificités de leurs tâches, de l'organisation du travail et des relations internes en équipe, c'est beaucoup moins. Toute tentative de résumer et d'analyser votre expérience d'une personne qui a cuisiné dans l'environnement informatique et en tant que développeur et en tant que gestionnaire est particulièrement utile pour ceux qui se préparent à suivre le même chemin et à réfléchir à la manière d'appliquer les théories générales de la gestion aux réalités du programmeur.

J. Hank Rainwater, un programmeur de la vieille école, est l'une des personnes qui connaissent en vain tous les endroits difficiles dans le rôle de leader technique, car ils ont eux-mêmes flotté en eux. Son livre « How to Graze Cats » séduit par son objectivité: il décrit des situations spécifiques bien connues de tous, des différents composants et conditions de travail de l'équipe, comprend même les solutions technologiques de l'auteur (malheureusement déjà dépassées). Dans une courte série d'articles, nous prévoyons de mettre en évidence tout ce qui nous a semblé le plus utile et pertinent dans le livre - de la typologie des employés aux recommandations de communication avec les autres équipes.

Commencez par une question raisonnable: pourquoi, en fait, les chats? L'auteur lui-même, à titre d'explication, se réfère à une citation d'Helen Alman, qui tire cette analogie dans son livre Close to the Machine:

«Une de mes connaissances avec les chefs de projet a déjà comparé le processus de gestion des programmeurs au pâturage des chats. Il voulait dire que les chiens, en regardant fidèlement dans les yeux, nous n'en avons absolument pas besoin. Un bon programmeur doit être apprécié avec toutes ses bizarreries. D'un autre côté, tous ces bons programmeurs doivent être en quelque sorte amenés à se déplacer dans une direction. »

Tout d'abord, les programmeurs sont liés aux chats par le fait que ni l'un ni l'autre n'a tendance à s'égarer. Ils préfèrent marcher seuls, et la culture qui s'est développée dans le domaine informatique a longtemps encouragé ce type de comportement (ou, du moins, ne l'a pas empêché). En conséquence, le directeur technique est confronté à une tâche doublement difficile: organiser les célibataires en un groupe plus ou moins cohérent, sans violer leur individualité, vous devrez probablement affiner vos propres compétences en travaillant avec les gens.

The Rainwater définit son public cible comme suit: les nouveaux arrivants à la direction (les développeurs d'hier qui ont reçu une position de leadership), les dirigeants de petites équipes (jusqu'à dix personnes) travaillant sur plusieurs projets, de petites ou moyennes entreprises. À plus grande échelle, certaines techniques ne fonctionneront plus, et les dirigeants techniques plus expérimentés ont probablement déjà beaucoup appris par eux-mêmes. Le livre est conçu pour aider le leader dans la période de transition la plus aiguë et se préparer aux changements futurs.

Si vous regardez au sens large, un manager novice est confronté à deux problèmes majeurs: un nouveau poste transforme fondamentalement les mécanismes de son interaction, d'une part, avec les personnes, et d'autre part, avec les processus. Nous parlerons de la seconde en détail plus tard, mais une erreur courante doit être mentionnée tout de suite.

Beaucoup ne peuvent accepter qu'ils devront abandonner une partie de leurs tâches liées à l'écriture de code, et plus le programmeur est fort, plus ce sentiment de protestation est fort. La situation est aggravée par un nouveau sens des responsabilités pour tout le code que l'équipe produit. En conséquence, au lieu de redistribuer le temps et de consacrer des heures au travail administratif, le chef s'inquiète du côté technique des projets - il effectue lui-même toutes les révisions, vérifie méticuleusement la conception ou même réécrit les fragments infructueux. La plus persistante néglige toutes les autres responsabilités qui ne sont pas directement liées au code, et cela se termine par un désastre. Les plus sobres se transforment en loups-garous: pendant la journée, le chef, la nuit le programmeur, et cela se termine par l'épuisement professionnel.

Pour cette raison, la première chose qu'un chef technique doit faire est de reconnaître et d'accepter l'inévitabilité des changements dans la structure du travail et de se brancher pendant une assez longue période de «rupture». L'auteur estime la période d'adaptation à environ six mois - seulement à ce moment-là, la majorité s'habitue au nouveau rôle et commence à s'y sentir à l'aise. On peut être réconforté par le fait que la définition de «technique» n'est pas une expression vide de sens: celui qui dirige les développeurs ne peut tout simplement pas se permettre de s'éloigner complètement du travail avec les technologies, il n'y a donc pas lieu de craindre que l'activité managériale le supplante.

Passons maintenant à la deuxième source de changement - travailler avec les gens. Dans une position de leadership, un programmeur doit non seulement s'entendre avec les membres de l'équipe, mais, en gros, les utiliser comme ressource - identifier qui est capable de quoi et diriger ces compétences là où elles sont le plus nécessaires. Ainsi, la tâche se divise en deux parties: vous devez être en mesure de comprendre les gens et de pouvoir communiquer avec eux.

Pour aider le lecteur avec le premier paragraphe, Rainwater propose une classification des «races» de chats informatiques, qu'il a construite sur la base de sa propre expérience et de ses observations. Sa liste de races résume les types de développeurs qui se produisent régulièrement avec des caractéristiques, des forces et des faiblesses distinctives. Comme toute autre, cette classification ne doit pas être considérée comme un standard absolu - dans la nature, les types se mélangent et se croisent souvent, sont de plus en moins prononcés. Cependant, c'est un point de départ utile pour analyser les caractéristiques intellectuelles et personnelles de leurs programmeurs.

L'auteur divise les races en trois groupes: commun (pêché le plus souvent), rare (pêché de temps en temps) et bâtards (dans leur forme originale, porte moins de valeur que la masse totale).

Races communes

Architecte

Favori de la plupart des managers. Il se concentre sur la structure générale du code, va de l'analyse et des constructions abstraites à la mise en œuvre de solutions spécifiques pour eux dans le code. Force - elle génère de bonnes idées, parfois elle peut conduire un projet seul, du concept à la forme finale (bien que certaines personnes perdent de l'intérêt après que la structure générale soit définie et confient le travail «artisanal» aux développeurs de niveau inférieur). Faiblesse - il produit souvent un code obscur et déroutant avec des conceptions étranges qui n'obéit qu'au propriétaire et est très difficile à fournir un support externe.

Constructiviste

Il prend un plaisir sincère du processus de programmation lui-même, s'efforce d'obtenir un bon résultat. La planification stratégique est généralement indifférente, le code est écrit sur une intuition, sans trop penser à la logique générale. À courte distance, cela ne fait pas beaucoup de mal et vous pouvez compter sur la qualité du travail du constructiviste. Lorsque le projet se développe, le manque de logique interne commence généralement à affecter et les décisions de «patch» sont utilisées - nous rappelons que le constructiviste est très concentré sur le résultat. Fonctionne très bien en collaboration avec un architecte. Documents à contrecœur ("tout est clair"), mais avec la persistance voulue de la tête - assez fort.

L'artiste

J'ai également connu la joie d'écrire du code, mais son élément est la recherche de solutions élégantes et inattendues pour mettre en œuvre les exigences données. Avec la logique et l'organisation, en règle générale, il n'y a pas de problèmes. Le principal inconvénient est un amour excessif de l'art et de l'expérimentation, qui encourage à étirer les tâches simples et à perturber les délais. Il a quelques similitudes avec l'architecte et le constructiviste, mais se distingue généralement par son style de programmation individuel brillant.

Ingénieur

Considère le développement logiciel comme un analogue virtuel de l'assemblage matériel avec toutes les conséquences qui en découlent. Il aime beaucoup s'adapter les uns aux autres, assembler des modules disparates en une structure complexe pour que tout fonctionne, trouver une place pour des solutions de tiers dans le système construit. Les compétences sont certes utiles, mais il y a un moyen de laisser l'ingénieur s'emballer, la complexité peut devenir une fin en soi pour lui. Une complexité excessive et un manque de flexibilité des produits sont deux vulnérabilités de cette race.

Scientifique

Contrairement aux artistes, il considère la programmation comme une science exacte - il essaie de suivre les principes fondamentaux en tout et d'éviter le «gag». Très pédant, s'efforçant de perfectionner le code et d'obtenir un fonctionnement correct dans toutes les conditions, souvent au détriment de considérations pratiques. Comme un ingénieur, il a tendance à tout compliquer inutilement. Mais quand il s'agit de tâches vraiment complexes nécessitant scrupuleusement et connaissances, il n'a pas de prix.

Lihach

Il met la vitesse avant tout, y compris la qualité du code. Néglige des bagatelles comme des commentaires, une conception correcte, en suivant les règlements acceptés. À première vue, cela donne un bon résultat tout à fait fonctionnel, mais des tests approfondis révèlent de nombreux problèmes. Malheureusement, cette race est cultivée par les dirigeants eux-mêmes: les scorchers sont le plus souvent obtenus de jeunes programmeurs inculqués à de fausses priorités et qui ont peur de ne pas répondre aux attentes.

Races rares

L'assistant

Dans la terminologie moderne, un sorcier est généralement appelé une rock star. Prend en charge les tâches les plus difficiles et les gère, trouve des moyens révolutionnaires de résoudre les problèmes, fait tout à temps et efficacement. Même avec le maintien de son code, des difficultés particulières ne se posent généralement pas. En général, tout semble merveilleux, mais le leader technique doit garder les yeux ouverts à deux égards. Premièrement, il ne faut pas permettre une dépendance excessive à l'égard de l'assistant - toute l'équipe, y compris le chef, risque de se transformer en danse pour un employé. Deuxièmement, vous devez être préparé au fait qu'un jour, l'assistant vous décevra tout de même - personne ne pourra toujours faire des miracles. Une telle opportunité doit être saisie avec calme et avoir un plan de sauvegarde.

Minimaliste

Il écrit un code étonnamment fonctionnel de quantités très modestes. Tout semble harmonieusement, clairement construit et annonce sans ambiguïté sa nomination. Cette race est très morose dans le choix des tâches et des projets; minimaliste se battra plus que d'autres pour le droit d'établir le champ d'application de ses capacités. Point faible - escorte. Il se bat de toutes ses forces pour apporter des modifications à son code (sans parler de celui de quelqu'un d'autre) - il n'est tout simplement pas intéressé à jouer avec les détails lorsque l'essentiel est fait.

Analogique

Il diffère dans une pensée spécifique, compense ses difficultés d'abstraction par un amour des analogies. Lors des réunions, il est difficile d’attraper son courant de pensée, mais il saisit rapidement le point. En règle générale, ils écrivent un bon code facile à prendre en charge, mais dans certains cas, une mauvaise compréhension d'une abstraction peut la ralentir. Il arrive aussi que les analogies échouent, surtout si l'analyste distingue l'un de ses proches de tout ce qu'elle essaie de tirer sur tout. Vous pouvez équilibrer les défauts de l'analyste en le mettant en tandem avec l'architecte - ils s'entretuent ou créent quelque chose d'exceptionnel.

Cascadeur

Il aime les tours spectaculaires et est constamment à la recherche des innovations technologiques qui les livrent. En fait, il n'y a pas de réel retour sur ce passe-temps: le cascadeur ne peut pas penser de manière pragmatique, la valeur réelle de telle ou telle technologie pour le produit final et l'utilisateur reste cachée pour lui. Cet employé devra constamment surveiller et rediriger son enthousiasme vers les tâches prioritaires.

Mutts

L'eau de pluie distingue les bâtards dans une catégorie distincte en tant que chats avec des défauts évidents, un avantage sur les faiblesses par rapport aux forces. Mais il n'appelle pas pour s'en débarrasser sans regarder. Beaucoup de bâtards sont tout à fait aptes à la formation et peuvent progressivement être recyclés dans d'autres races. Ci-dessous, nous fournissons des prévisions et des recommandations pour différents types.

Slobber

Le principal fournisseur de code bâclé et bâclé. Saute souvent de style en style. Comme un scorcher, il sacrifie la conception et le respect des accords adoptés par l'équipe, mais, contrairement au scorcher, il ne peut pas être justifié même par la grande vitesse de travail. C'est son code qui doit parfois être réécrit à partir de zéro - si épuisant et gourmand en ressources pour le comprendre.

La négligence est aiguë et chronique. Si elle a soudainement attaqué un employé, cela peut être dû à des problèmes personnels. S'il s'agit d'une condition habituelle pour lui, il convient de déterminer s'il est judicieux de consacrer du temps à la reconversion. Le critère principal ici est le désir et la volonté du sloven de faire des efforts. Le misérable, qui apprécie généralement son travail, avec l'attention du chef ou du mentor, pourrait bien être réadapté et apprendre des méthodes de travail plus efficaces.

Frein

Pendant longtemps, il ne peut pas assumer la tâche, ne sait pas par où commencer, poursuit les spécifications dans l'espoir désespéré qu'elles apporteront une sorte de clarté. Comme il n'est pas difficile à deviner, l'indécision du frein vient du doute de soi. Il faut agir ici en fonction de l'origine de cette incertitude. Si un développeur a lamentablement échoué dans le passé et qu'il a maintenant peur des échecs, panique, laissez-lui l'opportunité de faire ses preuves, même dans les petites tâches simples, afin que cette peur disparaisse progressivement. Si c'est l'inexpérience, alors avec le temps et le soutien bien connu de l'équipe, tout est susceptible de se normaliser par lui-même. Si une telle indécision n'est qu'un trait de caractère, il est plus facile de donner au pauvre garçon un modèle qui l'aidera à choisir un style et à se mettre au travail.

Amant

L'amant manque de connaissances, mais il y a généralement plus que suffisamment de motivation. Cette espèce de bâtards est plus susceptible de pénétrer dans de bons développeurs. Cependant, leurs progrès doivent être étroitement surveillés - pour évaluer les capacités, pour enregistrer les réalisations qui donnent raison de les envoyer à des tâches plus responsables. Il ne faut pas trop exagérer les attentes: beaucoup sont épuisés face à des difficultés ou à une routine inévitable dans le travail d'un programmeur. De manière générale, les amateurs ont leurs atouts - tout d'abord, le look frais et non caché notoire, bien qu'il puisse être fatigant d'attendre de marcher sur tous les râteaux et de comprendre les vérités communes.

Profan

Cela semble simplement terne. Habituellement, le nouveau chef hérite de ceux de l'ancien; l'histoire de leur placement dans l'équipe reste un mystère. Faire quelque chose pour ces personnes est difficile - le développement nécessite une auto-amélioration constante, ce qu'ils ne tireront tout simplement pas. Si un profane lui-même est conscient de son niveau et ne se distingue pas par des ambitions inadéquates, vous pouvez essayer de le rattacher au service de test - parfois de faibles capacités n'empêchent pas les gens de trouver correctement les bogues. Ceux qui ne sont même pas conscients de leur proximité feraient mieux de ne pas avoir à s'en occuper.

Éclectique

Un mélange nucléaire d'un ingénieur, d'un artiste bâclé et pas trop talentueux. Le code qu'il écrit est une vinaigrette indigeste de différents styles et modules. Contrairement aux produits de négligence, il s'agit d'un code qui revendique le talent - en apparence, il peut sembler qu'il contient même quelque chose jusqu'à ce que vous essayiez de l'exécuter. La question principale de la personne lisant le code éclectique: "Que voulait-il dire?" Afin de rectifier la situation, vous devez d'abord comprendre si cette confusion est vraiment le résultat d'une sorte de recherche, ou y a-t-il une tentative devant vous de slobbery sur les pistes. L'éclectisme bénin bénéficie grandement des revues systématiques de code.

Enfin, il existe une autre race qui se démarque des autres dans tous les sens - c'est un cow - boy ou un loup solitaire. Les habitudes félines l'atteignent au plus haut degré. Dans son métier, un cow-boy, en règle générale, est très bon (sinon il ne peut tout simplement pas rester en place), dans le travail d'équipe - est absolument sans espoir. Il se distingue par sa détermination à jouer uniquement selon ses propres règles: entreprendre des projets qui l'intéressent, et pas d'autre, utiliser les moyens qu'il veut, compter exclusivement avec ses plans, etc. Il n'y a qu'une seule façon avec les cowboys: comprendre une fois pour toutes qu'ils ne feront pas partie de l'équipe et décider si vous les appréciez suffisamment pour accepter leurs habitudes particulières. En général, les cowboys sont indispensables dans deux cas: des situations critiques, apparemment sans espoir et des projets isolés qui seront accompagnés par des experts extérieurs.

Nous avons donc répertorié les races que l'auteur a rencontrées le plus souvent. Cependant, quelques remarques doivent être apportées à cette classification:

• Le leader ne doit pas se considérer comme une exception à la règle: il a une expérience en programmation, ce qui signifie qu'il appartient lui-même à l'une des races. C'est une circonstance importante - son approche individuelle de l'écriture de code affectera la culture de l'équipe dans son ensemble. Par exemple, dans un groupe de dirigeants minimalistes, la documentation peut glisser, car il ne lui a jamais prêté l'attention voulue, même dans son propre travail.
• : , , . , , , – .
• , , – ( ), ( ) ( ). , , – .
• , – , .

, . , .

№1

: , , -, . , – , : . Que faire

: . , – , . . , , – , .

№2

: . , - , .

: – , . , , . , , – -. , , . , , – , , .

. , , , , .