Devise:
Le mari, regardant les enfants crasseux, dit à sa femme : eh bien, allons-nous les laver ou en donner de nouveaux ?
Sous la coupe se trouve la deuxième partie d'un article de notre chef d'équipe, ainsi que du directeur du développement de produits RAS, Igor Marnat, sur les particularités de la motivation des programmeurs. La première partie de l'article peut être trouvée ici -
Dans la première partie de l’article, j’ai abordé les deux niveaux inférieurs de la pyramide de Maslow : les besoins physiologiques, les besoins de sécurité, de confort et de constance et je suis passé au troisième niveau suivant, à savoir :
III - Besoin d'appartenance et d'amour
Je savais que la mafia italienne s'appelait « Cosa Nostra », mais j'ai été très impressionné lorsque j'ai découvert comment se traduisait « Cosa Nostra ». « Cosa Nostra » traduit de l'italien signifie « Notre entreprise ». Le choix du nom est très réussi pour la motivation (laissons de côté le métier, dans ce cas on ne s’intéresse qu’à la motivation). Une personne veut généralement faire partie d’une équipe, s’occuper de certaines grandes affaires communes.
Une grande importance est accordée à la satisfaction du besoin d’appartenance et d’amour dans l’armée, la marine et toutes les grandes formations paramilitaires. Et, comme on le voit, dans la mafia. C'est compréhensible, car il faut forcer des gens qui ont peu de points communs, qui au départ ne forment pas une équipe de personnes partageant les mêmes idées, qui sont réunis par conscription (pas volontairement), qui ont des niveaux d'éducation différents, des valeurs personnelles différentes , pour consacrer littéralement leur vie, au péril de leur vie, à une cause commune , confiez votre vie à un compagnon d'armes.
C’est une motivation très forte ; pour la plupart des gens, il est extrêmement important de se sentir appartenir à quelque chose de plus grand, de savoir que l’on fait partie d’une famille, d’un pays, d’une équipe. Dans l'armée, les uniformes, divers rituels, défilés, marches, banderoles, etc. servent à ces fins. À peu près les mêmes facteurs sont importants pour n’importe quelle équipe. Les symboles, la marque et les couleurs de l'entreprise, l'attirail et les souvenirs sont importants.
Il est important que les événements significatifs aient leur propre incarnation visible à laquelle ils puissent être associés. De nos jours, c’est plutôt la norme pour une entreprise d’avoir sa propre marchandise, vestes, T-shirts, etc. Mais il est également important de mettre en valeur l’équipe au sein de l’entreprise. Nous publions souvent des T-shirts basés sur les résultats d'une sortie, qui sont remis à toutes les personnes impliquées dans la sortie. Certains événements, célébrations communes ou activités avec toute l’équipe sont un autre facteur de motivation important.
Outre les attributs externes, plusieurs autres facteurs influencent le sentiment d’appartenance à une équipe.
Premièrement, la présence d’un objectif commun que chacun comprend et partage une évaluation de son importance. Les programmeurs veulent généralement comprendre qu’ils font quelque chose de cool, et qu’ils le font ensemble, en équipe.
Deuxièmement, l'équipe doit disposer d'un espace de communication dans lequel toute l'équipe est présente et qui n'appartient qu'à elle (par exemple, un chat dans la messagerie, des syncaps périodiques de l'équipe). En plus des problèmes de travail, de la communication informelle, parfois des discussions sur des événements extérieurs, de la lumière offtop, tout cela crée un sentiment de communauté et d'équipe.
Troisièmement, je soulignerais l'introduction de bonnes pratiques d'ingénierie au sein de l'équipe, la volonté d'élever les standards par rapport à ceux acceptés dans l'entreprise. Mettre en œuvre les meilleures approches acceptées dans l'industrie, d'abord dans l'équipe, puis dans l'entreprise dans son ensemble, donne à l'équipe la possibilité de sentir qu'elle est en quelque sorte en avance sur les autres, ouvrant la voie, cela crée un sentiment d'appartenance. à une équipe sympa.
Le sentiment d'appartenance est également influencé par la participation de l'équipe à la planification et à la gestion. Lorsque les membres de l'équipe participent à la discussion des objectifs du projet, des plans de travail, des normes de l'équipe et des pratiques d'ingénierie, et qu'ils interrogent les nouveaux employés, ils développent un sentiment de participation, d'appropriation partagée et d'influence sur le travail. Les gens sont beaucoup plus disposés à exécuter les décisions prises et exprimées par eux-mêmes que celles proposées par les autres, même s'ils sont pratiquement en phase.
Anniversaires, anniversaires, événements marquants dans la vie des collègues - une pizza commune, un petit cadeau de l'équipe procurent un chaleureux sentiment d'implication et de gratitude. Dans certaines entreprises, il est d'usage de remettre de petites pancartes commémoratives pour 5, 10, 15 ans de travail dans l'entreprise. D’une part, je ne pense pas que cela me motive autant pour de nouvelles réalisations. Mais, évidemment, presque tout le monde sera heureux de ne pas l’avoir oublié. C'est un de ces cas où l'absence d'un fait démotive plutôt que sa présence ne motive. D'accord, cela peut être vraiment dommage si LinkedIn vous le rappelle le matin et vous félicite pour votre 10e anniversaire sur votre lieu de travail, mais pas un seul collègue de l'entreprise ne vous félicite ou ne se souvient de vous.
Bien entendu, un point important est le changement dans la composition de l’équipe. Il est clair que même si l'arrivée ou le départ d'un membre de l'équipe est annoncé à l'avance (par exemple, dans un bulletin d'information d'entreprise ou d'équipe, ou lors d'une réunion d'équipe), cela ne motive particulièrement personne pour de nouvelles réalisations. Mais si un beau jour vous voyez une nouvelle personne à côté de vous, ou si vous ne voyez pas une ancienne, cela peut être une surprise, et si vous partez, carrément désagréable. Les gens ne devraient pas disparaître tranquillement. Surtout dans une équipe distribuée. Surtout si votre travail dépend d'un collègue d'un autre bureau qui s'est soudainement levé et a disparu. De tels moments méritent certainement d'être informés séparément à l'avance de l'équipe.
Un facteur important, appelé en anglais possession (la traduction littérale de « possession » ne reflète pas pleinement sa signification). Il ne s’agit pas d’un sentiment d’appartenance, mais plutôt d’un sentiment de responsabilité envers votre projet, ce sentiment lorsque vous vous associez émotionnellement au produit et le produit à vous-même. Cela correspond à peu près à la prière du Marine dans le film « Full Metal Jacket » : «C'est mon fusil. Il existe de nombreux fusils de ce type, mais celui-ci est le mien. Mon fusil est mon meilleur ami. Elle est ma vie. Je dois apprendre à le posséder de la même manière que je possède ma vie. Sans moi, mon fusil est inutile. Je suis inutile sans mon fusil. Je dois tirer droit avec mon fusil. Je dois tirer avec plus de précision que l'ennemi qui essaie de me tuer. Je dois lui tirer dessus avant qu'il ne me tire dessus. Qu'il en soit ainsi… ».
Lorsqu'une personne travaille longtemps sur un produit, a la possibilité d'assumer l'entière responsabilité de sa création et de son développement, de voir comment un objet fonctionnel naît de « rien », comment les gens l'utilisent, ce sentiment puissant apparaît. Les équipes de produits qui travaillent ensemble pendant une longue période sur un projet sont généralement plus motivées et plus cohérentes que les équipes qui sont constituées sur une courte période et travaillent en mode chaîne d'assemblage, passant d'un projet à l'autre, sans l'entière responsabilité de l'ensemble du produit. , Du début à la fin.
IV. Besoin de reconnaissance
Un mot gentil plaît aussi au chat. Chacun est motivé par la reconnaissance de l’importance du travail accompli et de son évaluation positive. Parlez aux programmeurs, donnez-leur des commentaires périodiques, célébrez le travail bien fait. Si vous avez une équipe nombreuse et dispersée, les réunions périodiques (appelées en tête-à-tête) sont parfaites pour cela ; si l'équipe est très petite et travaille ensemble localement, cette opportunité est généralement offerte sans réunions spéciales sur le calendrier (bien qu'une réunion périodique soit un seul suffit (c’est toujours nécessaire, vous pouvez simplement le faire moins souvent). Ce sujet est bien traité dans les podcasts destinés aux managers sur manager-tools.com.
Il convient toutefois de garder à l’esprit les différences culturelles. Certaines approches familières aux collègues américains ne fonctionneront pas toujours avec les approches russes. Le niveau de politesse accepté dans la communication quotidienne au sein des équipes des pays occidentaux semble à première vue excessif aux programmeurs russes. Une certaine franchise caractéristique des collègues russes peut être perçue comme de l'impolitesse par leurs collègues d'autres pays. Ceci est très important dans la communication dans une équipe interethnique ; beaucoup a été écrit sur ce sujet ; le manager d'une telle équipe doit s'en souvenir.
Les démonstrations de fonctionnalités, où les programmeurs montrent les fonctionnalités développées au cours d'un sprint, sont une bonne pratique pour répondre à ce besoin. Outre le fait qu'il s'agit d'une excellente opportunité pour dégager les canaux de communication entre les équipes, faire découvrir les nouvelles fonctionnalités aux chefs de produits et aux testeurs, c'est aussi une bonne opportunité pour les développeurs de montrer les résultats de leur travail et d'indiquer leur paternité. Eh bien, et perfectionnez vos compétences en matière de prise de parole en public, bien sûr, ce qui n'est jamais nuisible.
Ce serait une bonne idée de célébrer la contribution significative de collègues particulièrement distingués avec des certificats, des panneaux commémoratifs (au moins un mot gentil) lors de réunions d'équipe communes. Les gens apprécient généralement beaucoup ces certificats et ces panneaux commémoratifs, les emportent avec eux lors d'un déménagement et en prennent généralement soin de toutes les manières possibles.
Pour marquer une contribution plus significative et à long terme au travail de l'équipe, à l'expérience et à l'expertise accumulées, un système de grades est souvent utilisé (encore une fois, une analogie peut être faite avec le système de grades militaires dans l'armée, qui, en plus assurer la subordination, sert également cet objectif). Souvent, les jeunes développeurs travaillent deux fois plus dur pour attirer de nouvelles étoiles sur leurs épaules (c'est-à-dire passer de développeur junior à développeur à temps plein, etc.).
Connaître les attentes de vos collaborateurs est essentiel. Certains sont plus susceptibles d'être motivés par un grade élevé, la possibilité d'être appelé, par exemple, architecte, tandis que d'autres, au contraire, sont indifférents aux grades et aux titres et considéreront une augmentation de salaire comme un signe de reconnaissance de la part de l'entreprise. . Communiquez avec les gens pour comprendre ce qu’ils veulent et quelles sont leurs attentes.
Une démonstration de reconnaissance, un niveau de confiance plus élevé de la part de l'équipe, peut être apporté en donnant plus de liberté d'action ou d'implication dans de nouveaux domaines de travail. Par exemple, après avoir acquis une certaine expérience et obtenu certains résultats, un programmeur, en plus d'implémenter ses fonctionnalités conformément à la spécification, peut travailler sur l'architecture de nouvelles choses. Ou impliquez-vous dans de nouveaux domaines qui peuvent ne pas être directement liés au développement : automatisation des tests, mise en œuvre des meilleures pratiques d'ingénierie, aide à la gestion des versions, prise de parole lors de conférences, etc.
V. Le besoin de cognition et de réalisation de soi.
De nombreux programmeurs se concentrent sur différents types d’activités de programmation à différentes étapes de leur vie. Certaines personnes aiment faire du machine learning, développer de nouveaux modèles de données, lire beaucoup de littérature scientifique pour leur travail et créer quelque chose de nouveau à partir de zéro. Un autre est plus proche du débogage et de la prise en charge d'une application existante, dans laquelle vous devez approfondir le code existant, étudier les journaux, empiler les traces et les captchas réseau pendant des jours et des semaines, et n'écrire presque aucun nouveau code.
Les deux processus nécessitent un effort intellectuel considérable, mais leurs résultats pratiques sont différents. On pense que les programmeurs sont réticents à soutenir les solutions existantes ; ils sont plutôt motivés à en développer de nouvelles. Il y a là une part de sagesse. D'un autre côté, l'équipe la plus motivée et la plus unie avec laquelle j'ai jamais travaillé se consacrait au support d'un produit existant, à la recherche et à la correction des bugs après que l'équipe d'assistance les ait contactés. Les gars vivaient littéralement pour ce travail et étaient prêts à sortir le samedi et le dimanche. Nous avons déjà traité avec empressement un autre problème urgent et complexe, soit dans la soirée du 31 décembre, soit dans l'après-midi du 1er janvier.
Plusieurs facteurs ont influencé cette forte motivation. Tout d’abord, il s’agissait d’une entreprise avec un grand nom du secteur, l’équipe s’y est associée (voir « Le besoin d’affiliation »). Deuxièmement, ils constituaient la dernière frontière, il n’y avait personne derrière eux, il n’y avait pas d’équipe produit à cette époque. Entre eux et les clients, il y avait deux niveaux de support, mais si le problème les touchait, il n'y avait nulle part où se retirer, personne n'était derrière eux, toute l'entreprise était sur eux (quatre jeunes programmeurs). Troisièmement, cette grande entreprise avait de très gros clients (gouvernements nationaux, entreprises automobiles et aéronautiques, etc.) et des installations de très grande envergure dans plusieurs pays. En conséquence, des problèmes toujours complexes et intéressants, des problèmes simples ont été résolus grâce au support des niveaux précédents. Quatrièmement, la motivation de l'équipe était grandement influencée par le niveau professionnel de l'équipe d'assistance avec laquelle elle interagissait (il y avait des ingénieurs très expérimentés et techniquement compétents), et nous étions toujours confiants dans la qualité des données qu'ils préparaient, de l'analyse qu'ils effectuaient. , etc. Cinquièmement, et je pense que c'est le point le plus important : l'équipe était très jeune, tous les gars étaient au début de leur carrière. Ils souhaitaient étudier un produit vaste et complexe, résoudre des problèmes sérieux qui étaient nouveaux pour eux dans un nouvel environnement, ils cherchaient à correspondre professionnellement au niveau des équipes, des problèmes et des clients environnants. Le projet s'est avéré être une excellente école, tout le monde a ensuite fait une bonne carrière dans l'entreprise et est devenu responsable technique et cadre supérieur, l'un des gars est maintenant directeur technique chez Amazon Web Services, l'autre a finalement rejoint Google, et tous d'entre eux se souviennent encore de ce projet avec chaleur.
Si cette équipe était composée de programmeurs ayant 15 à 20 ans d’expérience derrière eux, la motivation serait différente. L’âge et l’expérience ne sont bien entendu pas des facteurs déterminants à 100 %, tout dépend de la structure de la motivation. Dans ce cas particulier, le désir de connaissance et de croissance des jeunes programmeurs a donné d'excellents résultats.
De manière générale, comme nous l'avons déjà évoqué à plusieurs reprises, vous devez connaître les attentes de vos programmeurs, comprendre lesquels d'entre eux souhaiteraient élargir ou changer de domaine d'activité, et prendre en compte ces attentes.
Au-delà de la pyramide de Maslow : visibilité des résultats, gamification et compétition, pas de conneries
Il y a trois autres points importants concernant la motivation des programmeurs qui doivent absolument être mentionnés, mais les intégrer dans le modèle des besoins de Maslow serait trop artificiel.
Le premier est la visibilité et la proximité du résultat.
Le développement de logiciels est généralement un marathon. Les résultats des efforts de R&D deviennent visibles après des mois, parfois des années. Il est difficile d’atteindre un objectif qui dépasse l’horizon, la quantité de travail est terrifiante, le but est lointain, peu clair et invisible, « la nuit est sombre et pleine d’horreurs ». Il est préférable de diviser la route qui y mène en plusieurs parties, de tracer un chemin jusqu'à l'arbre le plus proche, visible, accessible, dont les contours sont clairs et qui n'est pas loin de nous - et d'aller vers ce but proche. Nous voulons faire un effort de plusieurs jours ou semaines, obtenir et évaluer le résultat, puis passer à autre chose. Par conséquent, cela vaut la peine de diviser le travail en petites parties (les sprints en agile remplissent bien cet objectif). Nous avons accompli une partie du travail - l'avons enregistré, expiré, discuté, puni les coupables, récompensé les innocents - nous pouvons commencer le cycle suivant.
Cette motivation est dans une certaine mesure similaire à ce que ressentent les joueurs lorsqu'ils terminent des jeux informatiques : ils reçoivent périodiquement des médailles, des points, des bonus à mesure qu'ils terminent chaque niveau ; cela peut être appelé « motivation dopaminergique ».
En même temps, la visibilité du résultat est littéralement importante. Une fonctionnalité fermée dans la liste doit devenir verte. Si le code est écrit, testé, publié, mais qu'il n'y a aucun changement dans l'état visuel visible pour le programmeur, il se sentira incomplet, il n'y aura aucun sentiment d'achèvement. Dans l'une des équipes de notre système de contrôle de version, chaque correctif est passé par trois étapes successives : la construction a été assemblée et les tests réussis, le correctif a réussi la révision du code, le correctif a été fusionné. Chaque étape était visuellement marquée par une coche verte ou une croix rouge. Une fois qu'un des développeurs s'est plaint que la révision du code prenait trop de temps, ses collègues ont dû accélérer et les correctifs sont restés suspendus pendant plusieurs jours. J'ai demandé, qu'est-ce que cela change réellement pour lui ? Après tout, lorsque le code est écrit, que la build est assemblée et que les tests sont réussis, il n'a pas besoin de prêter attention au patch envoyé s'il n'y a pas de commentaires. Les collègues eux-mêmes l’examineront et l’approuveront (si, encore une fois, il n’y a pas de commentaires). Il a répondu : « Igor, je veux recevoir mes trois coches vertes le plus tôt possible. »
Le deuxième point est la gamification et la compétition.
Lors du développement de l'un des produits, notre équipe d'ingénierie avait pour objectif de prendre une position de premier plan dans la communauté de l'un des produits open source, pour entrer dans le top 3. À cette époque, il n'existait aucun moyen objectif d'évaluer la visibilité d'une personne dans la communauté ; chacune des grandes entreprises participantes pouvait prétendre (et affirmait périodiquement) qu'elle était le premier contributeur, mais il n'existait aucun moyen réel de comparer les contributions des participants. entre eux, pour évaluer sa dynamique dans le temps. En conséquence, il n'y avait aucun moyen de fixer un objectif à l'équipe qui puisse être mesuré chez certains perroquets, évaluer le degré de sa réalisation, etc. Pour résoudre cette problématique, notre équipe a développé un outil de mesure et de visualisation de la contribution des entreprises et des contributeurs individuels. . D'un point de vue motivationnel, cela s'est avéré n'être qu'une bombe. Il n’y avait pas que les ingénieurs et les équipes qui surveillaient constamment leurs progrès et ceux de leurs collègues et concurrents. La haute direction de notre entreprise et tous les principaux concurrents ont également commencé leur journée avec Stackalytics. Tout est devenu très transparent et visuel, chacun pouvait suivre attentivement ses progrès, comparer avec ses collègues, etc. Il est devenu pratique et facile pour les ingénieurs, les managers et les équipes de fixer des objectifs.
Un point important qui se pose lors de la mise en œuvre de tout système de métriques quantitatives est que dès que vous les avez implémentées, le système s'efforce automatiquement de donner la priorité à la réalisation de ces métriques quantitatives, au détriment des métriques qualitatives. Par exemple, le nombre de révisions de code effectuées est utilisé comme l'une des mesures. Évidemment, la révision du code peut être effectuée de différentes manières, vous pouvez consacrer plusieurs heures à une révision et une vérification approfondies d'un correctif complexe en vérifiant les tests, en l'exécutant sur votre banc, en vérifiant avec la documentation et en obtenant plus une révision de votre karma, ou cliquez aveuglément sur quelques douzaines de patchs en quelques minutes, donnez à chacun +1 et obtenez plus vingt de karma. Il y a eu des cas comiques où les ingénieurs ont cliqué sur des correctifs si rapidement qu'ils ont donné +1 aux correctifs automatiques du système CI. Comme nous l'avons plaisanté plus tard, "vas-y, vas-y, Jenkins". Dans le cas des commits, de nombreuses personnes ont également parcouru le code avec des outils de formatage de code, modifié des commentaires, changé les points en virgules et ainsi gonflé leur karma. La solution est assez simple : nous faisons preuve de bon sens et, en plus des indicateurs quantitatifs, nous utilisons également des indicateurs qualitatifs essentiels. Le degré d'utilisation des résultats du travail de l'équipe, le nombre de contributeurs externes, le niveau de couverture des tests, la stabilité des modules et de l'ensemble du produit, les résultats des tests d'échelle et de performances, le nombre d'ingénieurs ayant reçu l'épaule d'un évaluateur principal les sangles, le fait que les projets ont été acceptés dans la communauté des projets principaux, le respect des critères des différentes étapes du processus d'ingénierie - tous ces facteurs et bien d'autres doivent être évalués avec des mesures quantitatives simples.
Et enfin, le troisième point : Pas de conneries.
Les développeurs sont des personnes très intelligentes et extrêmement logiques dans leur travail. Ils passent 8 à 10 heures par jour à construire des chaînes logiques longues et complexes, de sorte qu'ils y voient des vulnérabilités à la volée. Lorsqu'ils font quelque chose, ils veulent, comme tout le monde, comprendre pourquoi ils le font, ce qui va changer pour le mieux. Il est extrêmement important que les objectifs que vous fixez à votre équipe soient honnêtes et réalistes. Essayer de vendre une mauvaise idée à une équipe de programmation est une mauvaise idée. Une idée est mauvaise si vous n’y croyez pas vous-même ou, dans les cas extrêmes, si vous n’avez pas l’état interne de désaccord et d’engagement (je ne suis pas d’accord, mais je le ferai). Nous avons déjà mis en place un système de motivation dans une entreprise, dont l'un des éléments était un système électronique de feedback. Ils ont investi beaucoup d'argent, ont emmené des gens en Amérique pour se former, en général, ils ont investi au maximum. Un jour, lors d'une conversation après la formation, l'un des managers a dit à ses subordonnés : « L'idée n'est pas mauvaise, on dirait qu'elle fonctionnera. Je ne vous donnerai pas moi-même de feedback électronique, mais vous le donnez à vos collaborateurs et vous l’exigez de leur part. Ça y est, rien n'a pu être mis en œuvre davantage. L’idée, bien sûr, n’a abouti à rien.
Source: habr.com