JH Rainwater "Comment faire paître les chats" (deuxième partie): tout ce qui reste à maîtriser technique

Nous continuons de partager des extraits du guide de survie pour les techlides débutants de J.H. Rainwater. Dans la première série, nous avons parlé des races de développeurs avec lesquelles le gestionnaire doit généralement travailler; Essayons maintenant de comprendre quoi faire avec tout ce zoo. Les activités organisationnelles dans une équipe technique peuvent être divisées en deux parties - des choses plus ou moins natives (comme les revues de code et la gestion de l'architecture) et tout ce que la vie d'un programmeur n'a pas préparé - c'est-à-dire la gestion des personnes et des processus. Traitons d'abord un étranger.

Priorisation

La première chose qui fait généralement tomber un leader fraîchement sorti du four est une avalanche d'informations les plus diverses. Cet état de fait est assez logique: celui qui est à la tête de l'équipe est moins fermé dans son cadre et est impliqué dans plus de processus, mais cela ne devient pas plus facile. En conséquence, le leader technique commence souvent à se disperser - compte tenu de son devoir de répondre à chaque signal, il s'empare de tout à la fois, passe d'une tâche à l'autre et passe à côté de ce qui a le plus besoin d'attention.

Il n'y a qu'une seule issue: filtrer ce flux d'informations, séparer ce qui est directement lié à la tâche principale (publier un code qui répond aux exigences commerciales, avec un délai convenu) et envoyer le principal au backlog. Mais au début, les critères d'un tel tri peuvent ne pas être évidents. Pour les débutants, absolument tout semble important.

Pour compliquer les choses, de nombreux stimuli provoquent des émotions qui empêchent une évaluation sensible de l’importance et de l’urgence du problème. Les signaux entrants peuvent provoquer de l'intérêt (une curieuse anomalie a été trouvée dans le code), de la culpabilité (le concepteur rappelle qu'il a déjà demandé à plusieurs reprises d'implémenter la fonction qu'il souhaite implémenter), l'appréhension (l'utilisateur exprime son mécontentement vis-à-vis de la mise à jour).

Afin de systématiser plus efficacement toutes les demandes et informations, l'auteur suggère d'utiliser la matrice suivante pour les traiter:

• Comment les nouvelles données affectent-elles la portée du projet, la décision de conception et la date limite du projet?
• La source d'information est-elle fiable? Sinon, peut-il être ignoré?
• Dois-je réagir immédiatement à la réception d'informations ou puis-je attendre un peu?
• Où et comment enregistrer les informations afin que, si nécessaire, elles puissent être traitées rapidement?
• Quelle est la durée de validité des informations? Quand devient-il hors de propos?
• Comment ces informations se comparent-elles à ce que l'on sait déjà du projet?

Comme vous pouvez le voir, cette matrice permet de séparer les grains de l'ivraie à plusieurs égards: se débarrasser des informations franchement inutiles ou peu fiables, s'éloigner de ce qui peut être déplacé et évaluer l'importance des informations strictement pour le projet en cours. Cependant, des questions sur le calendrier et les méthodes de stockage suggèrent que les informations qui ne sont pas pertinentes pour le moment ne doivent pas être rejetées comme non pertinentes en principe - c'est un autre extrême qui conduira l'équipe à la stagnation à long terme. Nous en parlerons plus tard, lorsque nous discuterons des concepts de «leadership» et de «leadership».

Projets tentaculaires

Le prochain point douloureux est l'évaluation des volumes et des conditions de travail. Encore une fois, pendant un certain temps, la «natation» dans ce domaine est presque inévitable pour un technophile débutant - une expérience est nécessaire pour pouvoir examiner toutes les composantes du projet à la fois, sans rien manquer, et dès la première tentative de définir pour chaque type de travail, y compris des conditions adéquates inconnues. Mais même l'expérience acquise ne sauve pas d'une certaine erreur, et il n'est pas possible de la réduire à zéro. Une extrême précision dans la planification du travail est entravée par deux lois que Humphrey a judicieusement formulées:

Tout processus durera plus longtemps que prévu. Quelque chose apparaît toujours auquel vous n’avez pas pensé.

Sur la base de tout cela, l'auteur appelle à traiter le problème philosophiquement. Très probablement, en première approximation, vous ne pourrez pas prendre en compte des fonctions moins évidentes ou des complications imprévisibles, et elles nécessiteront une ressource supplémentaire que vous n'avez pas hypothéquée. Pour de telles surprises, vous devez être préparé et préparer une équipe - apprendre aux gens à reconstruire rapidement afin de "colmater les trous", leur laisser un peu de temps en réserve pour des circonstances imprévues. Ce qui ne peut en aucun cas être fait est de considérer la croissance naturelle comme une urgence et de rechercher les coupables, en particulier dans les autres départements (et cela semble toujours particulièrement tentant). Vous ne semez donc que l'inimitié entre les équipes et ne faites rien pour résoudre le problème.

Néanmoins, il ne faut pas tomber dans un fatalisme complet: la croissance du projet est néanmoins le résultat de défauts de planification. Vous ne pourrez pas vous en débarrasser complètement, mais vous pouvez et devez réduire la concentration.

Si nous transférons les lois de Humphrey aux réalités du programmeur, il devient clair que la planification s'affaisse pour deux raisons: une analyse insuffisante des détails et des estimations inutilement optimistes de la durée de conception du produit logiciel. L'optimisme parmi les managers s'évanouit généralement de manière naturelle: plusieurs fois en dépassant les délais, vous commencerez forcément à jouer avec prudence. En ce qui concerne les détails, cette compétence vient également avec l'expérience, mais cela vaut la peine dès le début d'avoir une idée générale de ce à quoi la feuille de route devrait ressembler.

Par exemple, si vous vous lancez dans un projet armé d'un tel document, de nombreuses catastrophes naturelles et tracas vous attendent:



Si la feuille de route est plus similaire à l'exemple ci-dessous, les chances d'un résultat heureux sont considérablement augmentées:



En plus de ces deux raisons, Rainwater énumère quelques facteurs de risque supplémentaires que Robert Glass, l'auteur d'un triste livre sur les projets de catastrophe dans le domaine informatique, a souligné:

• Spécification inadéquate des objectifs du projet
• Application d'une technologie nouvelle pour cette entreprise
• Méthodologie de gestion de projet annuelle / manquante
• Manque d'experts de premier plan dans le groupe
• Perturbation des accords par les fabricants de matériel / logiciels

Recherche de langue commune

Vous pourriez penser que nous parlons de compétences en communication de talents communicatifs - mais non, le sens du titre est beaucoup plus littéral. Dans différentes entreprises, des équipes de programmeurs sont constituées pour différents motifs. Si vous êtes chanceux, vous pourriez être en charge de personnes travaillant avec votre pile de technologies natives. Mais très souvent, des équipes mixtes se rencontrent, où différents employés parlent différentes langues. Une telle confusion rend parfois la vie difficile au leader.

L'une des tâches du responsable est de superviser toutes les activités de l'équipe, de s'assurer que tout le code qui va dans le monde fonctionne, de haute qualité et sans complexité excessive. Si vous n'êtes pas familier avec les outils que vos subordonnés utilisent lors du développement, alors vos mains sont liées. Vous ne pouvez pas procéder à des examens de code de manière indépendante, vous ne découvrirez les erreurs graves qu'au stade des tests, ce qui ralentit tout le rythme de travail et, en gros, il est beaucoup plus facile de conduire par le nez.

Que faire dans cette situation? En général, il y a deux façons. Si l'ensemble des langages et technologies n'est pas trop vaste et modifiable, vous ne pouvez pas perdre de temps et essayer de les maîtriser au moins au niveau de base. C'est peut-être le meilleur moyen de sortir - vous n'avez donc à dépendre de personne, vous recevrez directement des informations, ce qui signifie que vous pouvez éviter le «téléphone mort» lorsque vous discutez des fonctionnalités, des exigences et des délais.

S'il n'est pas possible d'apprendre vous-même les langues nécessaires, vous devrez chercher des moyens de déléguer cette responsabilité. Formez le noyau d'assistants qui peuvent vous fournir une rétroaction objective et honnête sur chaque technologie inconnue (si un seul employé en est propriétaire, cette méthode ne fonctionnera naturellement pas).

Approfondir vos connaissances sur les questions liées aux technologies et aux outils est également utile pour une autre raison - c'est le seul moyen de devenir un leader technique au sens plein du terme. Dans son système terminologique, l'auteur divise les notions de «manager» et de «leader». Un gestionnaire est celui qui organise le travail, résout les problèmes quotidiens et s'assure que les tâches en cours sont terminées à temps et correctement. Un leader est un stratège qui pense en dehors des délais de contrôle, fixe la direction générale du mouvement de son équipe, relève la barre, repense et optimise les processus. Bien sûr, dans l'équipe de développement, un tel travail visionnaire nécessite une bonne connaissance du marché de la technologie. En arrière-plan, le leader technique estime constamment que la boîte à outils actuelle est obsolète et doit être remplacée, surveille les nouveaux produits et a en même temps une perspective suffisamment large pour évaluer leurs véritables mérites (et ne pas tomber dans le syndrome de Stunt).

Dans la première partie de l'article, nous avons parlé du fait que le leader n'a pas à s'inquiéter qu'il abandonnera le travail avec la technologie - et pour ceux qui marquent les leaders, c'est effectivement le cas. Mais ici, il est logique de répéter l'avertissement au même endroit: n'espérez pas en même temps échapper aux responsabilités du manager. La gestion implique un équilibre entre les deux rôles, qui sont parfois conflictuels, mais restent presque également (la gestion est quelque peu inférieure) nécessaires à la survie de l'équipe. Perfectionnez les compétences organisationnelles à votre avantage - moins une routine mange de temps, plus vous progresserez rapidement en tant qu'expert technique. Si les tâches quotidiennes sont laissées au hasard, le chaos régnera dans lequel il n'y aura plus de stratégie.

Cueillette du troupeau

Nous passons maintenant au deuxième bloc de problèmes - le travail notoire avec les gens. Commençons par le tout début: avant de parler de la façon de gérer une ressource humaine, vous devez savoir où l'obtenir. Même si vous avez l'équipe établie, tôt ou tard, la question se posera de recruter des employés. Plus tôt, nous avons analysé les types de programmeurs et indiqué ceux qui devraient être pourchassés en premier lieu. Vous devez maintenant comprendre comment agir afin d'identifier les qualités nécessaires chez les candidats et ne pas être déçu de leur choix.

L'auteur propose les recommandations suivantes pour les entretiens:

• Donnez au candidat une tâche de test. Attribuez à un employé potentiel une tâche qu'il devra soit résoudre immédiatement, soit l'emmener chez lui et la résoudre avant la date d'échéance.
• Assurez-vous de passer un test oral des compétences du candidat - afin que vous puissiez évaluer à la fois ses connaissances et sa capacité à penser clairement dans une situation stressante.
• Dans la mesure du possible, notez les fonctions de l'employé souhaité, toutes les tâches qu'il doit effectuer et remettez cette liste au candidat pour examen. La conversation deviendra donc immédiatement plus objective et, en règle générale, plus franche.
• Ne vous limitez pas à une seule réunion. Ce sera très bien si le candidat communique non seulement avec vous, mais aussi avec le «noyau» susmentionné - vos assistants, adjoints, principaux développeurs de l'équipe. Mais organiser un spectacle avec toute l'équipe n'en vaut pas la peine, c'est déjà trop.
• La vérification des qualités personnelles, les tests typologiques et similaires sont une étape possible mais facultative. N'y recourir que si le candidat ne s'y oppose pas et que vous disposez d'outils d'évaluation fiables.

En parlant d'embauche, on ne peut que mentionner le revers de la médaille - le licenciement des travailleurs qui ont démoli l'équipe. Ici, Rainwater prend une position plutôt difficile et conseille sans hésitation de se débarrasser de ceux qui se sont montrés incompétents ou problématiques. La meilleure position est la politique d'un avertissement: elle donne à une personne la possibilité de s'améliorer, mais ne permet pas d'abuser de ce droit. Si un employé fait partie de la «liste noire» et que vous avez eu une conversation avec lui, vous devez superviser ses succès ultérieurs avec une attention particulière. Cela nécessite des efforts supplémentaires, donc donner une troisième chance est déjà un gaspillage injustifié.

De plus, non seulement la «cause commune» abstraite souffre généralement de la négligence d'un membre de l'équipe, mais aussi de personnes très spécifiques qui doivent corriger ses erreurs ou accepter de gâcher les résultats de leur travail. Une indulgence excessive est donc payée à leurs frais et ne renforcera probablement pas votre position de leader.

Organisation du travail des salariés

Milieu de vie confortable

Le livre accorde beaucoup d'attention à cet aspect. Pour atteindre une productivité maximale de vos employés est une responsabilité directe du leader, mais une productivité élevée nécessite une concentration élevée, et la concentration est impossible si le programmeur est entouré d'irritants de tous côtés. Par conséquent, le leader doit faire tout ce qui est en son pouvoir pour offrir à l'équipe de bonnes conditions de travail.

Les recommandations spécifiques pour la conception d'un bureau que Rainwater donne dans des endroits semblent quelque peu idylliques (par exemple, dans un bureau séparé pour un frère), et dans des endroits comme des échos d'un passé lointain et difficile (chaque développeur doit avoir son propre ordinateur). Mais le principe général reste raisonnable et applicable: pour que les programmeurs réussissent dans leurs activités, ils doivent avoir la possibilité, d'une part, de travailler en équipe pendant un certain temps, et d'autre part, de se laver le cerveau seul. Pour les premiers, vous avez besoin de lieux de formation convenablement équipés: des salles de réunion avec des projecteurs, des équipes de loisirs (idéalement) avec des tables de tennis ou des consoles de jeu notoires. Pour le second, il est nécessaire d'organiser l'espace disponible de manière à ce que les gens soient le moins possible distraits par le bruit, le scintillement, les odeurs et d'autres facteurs distrayants. Si les conditions sont mauvaises, laissez les employés, en particulier ceux qui sont précieux et fiables, travailler à domicile.

Un minimum obligatoire d'équipements comprend également un équipement moderne et de haute qualité, que le développeur peut, dans des limites raisonnables, configurer à sa discrétion. Si les voitures sont faibles et obsolètes, il n'est pas nécessaire de parler de percées technologiques, et vous n'avez pas seulement un fonctionnement silencieux et sans problème. Pour les programmes de test, des dispositifs spéciaux doivent être alloués qui reproduisent les caractéristiques standard de l'utilisateur.

Heures de travail

Le tas de tâches du conseiller technique, que nous avons décrit, suggère que la durée de sa journée de travail devrait presque doubler. Mais ici, vous devez être prudent. Le problème est qu'avec son régime de travail, le manager lui-même, à contrecœur, donne le ton à l'ensemble du département. Si vous vous asseyez tard, les travailleurs supposeront que quelque chose de similaire est également attendu d'eux. En conséquence, le traitement peut pénétrer la chair et le sang de votre culture locale - et cela est semé d'embûches.

Premièrement, tout le monde ne sera pas satisfait de cet état de fait. Tout d'abord, le traitement frappera ceux qui sont accablés par des obligations supplémentaires, par exemple familiales. S'il y en a beaucoup, la situation dans l'équipe sera tendue. Eh bien, et deuxièmement, l'auteur, comme beaucoup après lui, souligne que les heures de travail supplémentaires sont plus susceptibles de nuire à la productivité - à la fois à cause de la fatigue et à cause d'une diminution de la motivation. Il est plus sage d'exiger un travail efficace de l'école en cours plutôt que d'inculquer des habitudes qui conduiront à l'épuisement professionnel.

Répartition et supervision des tâches

Soyons honnêtes: même des conditions idéales et un horaire doux en eux-mêmes n'encourageront pas les gens à s'auto-organiser et à travailler avec diligence. Entre autres, un patron est nécessaire pour répartir le travail et s'assurer qu'il est exécuté. Une partie de votre temps devrait être occupée par le contrôle - en passant, cela contribue également à la concentration.

L'auteur conseille de ne pas trop diviser les «périodes de reporting» pour les subordonnés, de ne pas les étouffer par une observation constante avec une demande quotidienne de résultats. Il est plus sage de déterminer une liste de tâches pour chaque semaine et d'évaluer la quantité de travail effectuée pour la même période. Dans les périodes particulièrement chaudes, les listes devront être ajustées même à ce petit intervalle en raison de problèmes urgents et de changements de priorités. Le leader doit garder à l'esprit tous ces changements (et dans les réalités modernes - et les faire dans les systèmes comptables appropriés).

Si un leader rejoint une équipe «étrangère» avec un rythme de travail déjà établi, il vaut la peine de demander à chaque employé de peindre ses tâches habituelles de la même manière. Une telle documentation peut révéler beaucoup de choses intéressantes - non seulement qui et quoi est impliqué et comment la gestion a été effectuée auparavant, mais aussi ce que les gens pensent généralement de leurs responsabilités.

Quant au contenu de ces listes, bien entendu, à bien des égards, il sera déterminé par les compétences des employés et les exigences de l'entreprise. Mais avec tout cela, le livre avance l'idée qu'il est nécessaire de faire pivoter les tâches autant que possible - le développeur ne devrait pas faire la même chose de semaine en semaine. Il y a plusieurs raisons à cela. Tout d'abord, cela aide à maintenir un climat sain dans l'équipe: pas d'offense car quelqu'un obtient constamment les choses les plus désagréables ou, au contraire, les plus intéressantes, moins de sensation de routine et de monotonie au travail. Deuxièmement, les programmeurs doivent rester en bonne forme intellectuelle - une variété de tâches y contribuera. Enfin, avec une telle alternance, un minimum d'effort sera nécessaire pour former un banc.

Le Reinwater attache une grande importance au banc. L'idée principale ici est qu'en cas de maladie, vacances, licenciement, décès prématuré de l'un des développeurs, l'équipe devrait inclure des personnes qui seront en mesure de remplir ses fonctions - au moins pour cette période, jusqu'à ce qu'elles embauchent un remplaçant. Cela garantit non seulement le bon fonctionnement du département, mais évite également d'autres problèmes (par exemple, la forte dépendance de l'entreprise à l'égard des assistants). En conséquence, il est nécessaire de maintenir l'intérêt des employés pour les technologies pertinentes, de toutes les manières possibles pour encourager la coopération et la participation à des projets "étrangers".

Soit dit en passant, le patron lui-même n'est pas protégé contre le facteur de chute de briques. Par conséquent, dès que vous vous y habituez un peu, commencez à penser à qui vous feriez de votre successeur. Ce n'est pas seulement de la réassurance, mais aussi un bon exercice pour déléguer des tâches - lors de la préparation d'un successeur, vous devez sans le savoir réfléchir au travail le plus facile et le plus sûr à confier à d'autres. Pendant les fouilles, cette connaissance sera très utile.

Et le dernier: jusqu'à présent, il s'agissait principalement des intérêts de l'équipe et des supérieurs, mais ne perdons pas de vue que nous travaillons toujours avec les gens. Les préférences et les caractéristiques personnelles des employés doivent être prises en compte dans la mesure du possible. Vous ne devez pas vous attendre à une mobilité spéciale de la part de quelqu'un qui a du mal à passer de l'un à l'autre, vous ne devez pas, pour des raisons de justice, envoyer les freins à une tâche qu'il a peur de ne pas assumer, etc. Ici encore, nous nous appuyons sur la thèse selon laquelle nous devons surveiller attentivement nos employés et bien les connaître.

Motivation et encouragement

Mais assez sur les fouets, parlons des plus agréables - ces cookies de pain d'épice que les programmeurs devraient obtenir du travail. Rainwater nomme les types de pain d'épices suivants (par ordre de priorité): salaire, avancement professionnel, mot aimable et, enfin, insignes corporatifs abstraits.

En termes de rémunération, les managers qui ont quitté le développement ne sont pas trop enclins à la pioche, mais tombent souvent dans l'extrême opposé et surestiment les attentes des salariés. Lorsque vous décidez des taux, gardez à l'esprit les facteurs suivants: productivité, expérience, efficacité, rapidité des tâches, taux moyen actuel, conditions du marché et normes d'entreprise. Une erreur courante est d'augmenter les salaires à l'avance, en espérant que cela encourage les travailleurs à tout donner. , – , .

, , , . , , .

– . , , , (, , «»). . – , . , , , .

, . – , -, , , , . : , . « » , . ( – ) – .