Management d'une équipe de programmeurs: comment et comment les motiver correctement? Deuxième partie

Épigraphe:
Le mari, en regardant les enfants crasseux, dit à sa femme: Eh bien, quoi, nous lavons ceux-ci ou les nouveaux?

Sous la coupe, la deuxième partie de l'article de notre chef d'équipe, ainsi que du directeur du développement des produits RAS - Igor Marnat sur les caractéristiques de la motivation des programmeurs. La première partie de l'article se trouve ici - habr.com/en/company/parallels/blog/452598




Dans la première partie de l'article, j'ai abordé les deux niveaux inférieurs de la pyramide de Maslow: les besoins physiologiques, la sécurité, le confort et les besoins de constance et passer au troisième niveau suivant, à savoir:

III - Le besoin d'affiliation et d'amour



Je savais que la mafia italienne s'appelait «Cosa Nostra», mais j'ai été très impressionnée quand j'ai appris à traduire «Cosa Nostra». «Cosa Nostra» en traduction de l'italien - «Notre entreprise». Le choix du nom est très réussi pour la motivation (laissons de côté la profession, dans ce cas nous ne nous intéressons qu'à la motivation). Une personne veut généralement faire partie d'une équipe, faire des affaires importantes et communes.

Une grande importance est accordée à la satisfaction du besoin d'appartenance et d'amour dans l'armée, dans la marine, dans toutes les grandes formations militarisées. Et, comme on le voit, dans la mafia. Cela est compréhensible, car vous devez forcer des personnes qui ont peu de choses en commun, qui ne constituaient pas initialement une équipe de personnes partageant les mêmes idées, réunies en appel (pas volontairement), ont différents niveaux d'éducation, différentes valeurs personnelles, consacrent littéralement leur vie, avec un risque mortel, à une cause commune , confiez la vie à un camarade d'armes.

C'est une motivation très forte, pour la plupart des gens, il est extrêmement important d'avoir l'impression d'appartenir à quelque chose de plus, de savoir que vous faites partie d'une famille, d'un pays, d'une équipe. Dans l'armée, ces objectifs sont la forme, divers rituels, défilés, marches, bannières, etc. Les mêmes facteurs sont importants pour toute équipe. Les symboles, une marque d'entreprise et les couleurs d'entreprise, les attributs et les souvenirs sont importants.

Il est important que les événements significatifs aient un mode de réalisation visible auquel ils pourraient être associés. Maintenant, l'entreprise a ses propres attributs, vestes, t-shirts, etc. - plutôt la norme. Mais il est également important de mettre en avant une équipe au sein de l'entreprise. Nous émettons souvent des T-shirts basés sur les résultats de la version, qui sont distribués à tous ceux impliqués dans cette version. Tous les événements, célébrations conjointes ou événements organisés par toute l'équipe sont un autre facteur de motivation important.

En plus des attributs externes, quelques facteurs supplémentaires influencent le sentiment d'appartenance à une équipe.
Premièrement, l'existence d'un objectif commun que tout le monde comprend est partagée par une évaluation de son importance. Les programmeurs veulent généralement comprendre ce qu'ils font de cool, et ils le font ensemble, en équipe.
Deuxièmement, une équipe devrait avoir un espace de communication dans lequel il y a une équipe entière, et qui n'appartient qu'à elle (par exemple, un chat dans le messager, des syncaps périodiques d'équipe). En plus des problèmes de travail, de la communication informelle, parfois des discussions sur des événements externes, un léger décollage - 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 adoptés par l'entreprise. La mise en œuvre des meilleures approches adopté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 avance sur les autres d'une certaine manière, va à la tête, cela crée un sentiment d'appartenance à une équipe cool.

La propriété d'équipe dans la planification et la gestion affecte également le sentiment d'appartenance. Lorsque les membres de l'équipe sont impliqués dans la discussion des objectifs du projet, du plan de travail, des normes et des pratiques d'ingénierie de l'équipe, en interviewant de nouveaux employés, ils ont un sentiment de participation, de copropriété 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 d'autres, même si elles sont pratiquement conformes.

Anniversaires, anniversaires, événements importants dans la vie des collègues - une pizza commune, un petit cadeau de l'équipe donnent un sentiment chaleureux d'implication et d'appréciation. Dans certaines entreprises, il est d'usage de donner de petites pancartes commémoratives pour 5, 10, 15 ans de travail dans l'entreprise. D'une part, je ne pense pas que ce soit aussi motivant pour de nouvelles réalisations. Mais, évidemment, presque tout le monde sera content de ne pas l'avoir oublié. C'est un de ces cas où l'absence d'un fait motive plutôt que sa présence ne motive. D'accord, il peut être plutôt dommage que le matin, linkedin vous rappelle et vous félicite pour votre 10e anniversaire sur le lieu de travail, et pas un seul collègue de l'entreprise félicité ou rappelé.

Bien sûr, 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'une personne de l'équipe est annoncé à l'avance (par exemple, dans une liste de diffusion pour une entreprise ou une équipe, ou lors d'une réunion d'équipe), cela ne motive pas particulièrement quiconque à faire de nouvelles réalisations. Mais si un jour vous voyez une nouvelle personne à côté de vous, ou si vous n'en voyez pas une ancienne, cela peut vous surprendre, et si vous partez, c'est vraiment 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 a soudainement repris et soudainement disparu. De tels moments valent clairement une communication séparée au sein de l'équipe à l'avance.

Un facteur important, qui est appelé propriété en anglais (la traduction littérale de «propriété» ne reflète pas pleinement sa signification). Ce n'est pas un sentiment d'appartenance, mais plutôt un sentiment de responsabilité pour votre projet, un sentiment lorsque vous vous associez émotionnellement avec le produit et le produit avec vous-même. Cela correspond à peu près à la prière de la Marine du film "Full Metal Shell": " Ceci est mon fusil. Il existe de nombreux fusils de ce type, mais celui-ci est à moi. Mon fusil est mon meilleur ami. C'est ma vie. Je dois apprendre à le posséder comme je possède ma vie. Mon fusil est inutile sans moi. Je suis inutile sans mon fusil. Je dois tirer correctement 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 sur un produit pendant une longue période, elle a la possibilité d'assumer l'entière responsabilité de sa création et de son développement, de voir comment une chose qui fonctionne naît de «rien», comment les gens l'utilisent, ce sentiment puissant surgit. Les équipes de produits qui travaillent ensemble depuis longtemps sur un projet sont généralement plus motivées et unies que les équipes réunies pendant une courte période et travaillant en mode chaîne de montage avec le passage d'un projet à un autre sans la pleine responsabilité de l'ensemble du produit, du début à la fin.

IV. Besoin de reconnaissance

Bonne parole et gentil avec le chat. Chacun est motivé par la reconnaissance de l'importance de son travail, son appréciation positive. Parlez avec les programmeurs, donnez-leur des commentaires périodiques, marquez le travail bien fait. Si vous avez une grande équipe répartie, les réunions périodiques (ce qu'on appelle une à une) sont parfaites pour cela, si l'équipe est très petite et travaille ensemble localement, cette fonctionnalité est généralement fournie sans rendez-vous de calendrier spéciaux (bien que les réunions périodiques individuelles soient toutes tout aussi nécessaire, vous pouvez simplement le dépenser moins souvent). Ce sujet est bien couvert dans les podcasts des gestionnaires sur manager-tools.com.

Dans le même temps, il convient de garder à l'esprit les différences culturelles. Certaines approches familières à des collègues américains ne fonctionneront pas toujours avec des approches russes. Le niveau de politesse accepté dans la communication quotidienne dans les équipes des pays occidentaux semble d'abord excessif pour les programmeurs russes. Une certaine franchise, caractéristique des collègues russes, peut être perçue comme impolie par leurs collègues d'autres pays. C'est très important dans la communication au sein d'une équipe internationale, beaucoup a été écrit sur ce sujet, le manager d'une telle équipe doit absolument s'en souvenir.

La démonstration des fonctionnalités sur lesquelles les programmeurs présentent les fonctionnalités développées pour le sprint est une bonne pratique pour répondre à ce besoin. Outre le fait qu'il s'agit d'une excellente opportunité de libérer les canaux de communication entre les équipes, de présenter aux chefs de produit et aux testeurs de nouvelles fonctionnalités, c'est également une bonne occasion pour les développeurs de montrer les résultats de leur travail, d'indiquer leur paternité. Eh bien, et polissez les compétences de prise de parole en public, bien sûr, ce qui n'est pas toujours nocif.

Ce serait une bonne idée de noter la contribution notable de collègues particulièrement distingués avec des lettres, des souvenirs (au moins avec un mot aimable) aux parties communes de l'équipe. Les gens apprécient généralement ces lettres et ces signes commémoratifs, les emportent avec eux lorsqu'ils se déplacent et prennent généralement soin d'eux de toutes les manières possibles.

Pour marquer une contribution plus importante et à long terme au travail de l'équipe, l'expérience et l'expertise accumulées, ils utilisent souvent un système de notation (vous pouvez à nouveau faire une analogie avec le système de grade militaire dans l'armée, qui, en plus d'assurer la subordination, sert également à cette fin). Souvent, les jeunes développeurs injectent une vengeance pour obtenir de nouvelles étoiles sur les bretelles (c'est-à-dire passer du développeur junior au développeur à temps plein, etc.).

Il est impératif de connaître les attentes de vos collaborateurs. Quelqu'un est plutôt motivé par un grade élevé, la possibilité d'être appelé, par exemple, un architecte, tandis que quelqu'un, au contraire, est indifférent aux grades et aux titres et considérera une augmentation de salaire comme un signe de reconnaissance par l'entreprise. Communiquez avec les gens pour comprendre ce qu'ils veulent, quelles sont leurs attentes.

Une démonstration de reconnaissance, une manifestation d'un niveau de confiance plus élevé de la part de l'équipe peut permettre une plus grande liberté d'action ou d'implication dans de nouveaux domaines de travail. Par exemple, avec l'accumulation de certaines expériences, la réalisation de certains résultats, le programmeur, en plus d'implémenter ses fonctionnalités conformément aux spécifications, peut travailler sur l'architecture de nouvelles choses. Ou impliquez-vous dans des travaux sur 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, assistance dans la gestion des versions, intervention lors de conférences, etc.

V. Le besoin de connaissance et de réalisation de soi.

De nombreux programmeurs sont orientés à différentes étapes de leur vie vers différents types d'activités de programmation. Quelqu'un aime s'engager dans l'apprentissage automatique, développer de nouveaux modèles de données, tout en lisant beaucoup de littérature scientifique pour le travail, en créant de nouveaux à partir de zéro. Le débogage et la prise en charge d'une application existante sont plus proches les uns des autres, dans lesquels vous devez approfondir le code existant, étudier les journaux, empiler les pistes et les captchas du réseau pendant des jours et des semaines, et écrire à peine du nouveau code.

Les deux processus nécessitent de grands efforts intellectuels, mais la solution pratique est différente. On pense que les programmeurs hésitent à prendre en charge les solutions existantes, ils sont plus susceptibles d'être motivés à en développer de nouvelles. Il contient un grain sain. D'un autre côté, l'équipe la plus motivée et la plus soudée avec laquelle j'ai jamais travaillé soutenait spécifiquement le produit existant, trouvant et corrigeant des bogues après avoir contacté l'équipe d'assistance. Les gars ont littéralement vécu ce travail, étaient prêts à partir les samedis et dimanches. Nous avons une fois résolu de plein gré 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.

Cette forte motivation a été influencée par plusieurs facteurs. Premièrement, c'était une entreprise avec un grand nom dans l'industrie, l'équipe s'y est associée (voir «Besoin d'affiliation»). Deuxièmement, ils étaient la dernière frontière, il n'y avait personne derrière eux, l'équipe produit était déjà partie à cette époque. Entre eux et les clients, il y avait deux niveaux de support, mais si le problème les atteignait, il n'y a nulle part où se retirer, derrière personne, toute la société est 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 à très grande échelle dans plusieurs pays. En conséquence, des problèmes toujours complexes et intéressants, des problèmes simples ont été résolus en supportant les niveaux précédents. Quatrièmement, la motivation de l'équipe a été très influencée par le niveau professionnel de l'équipe de support avec laquelle elle a interagi (il y avait des ingénieurs très expérimentés et techniquement cool), et nous avons toujours été sûrs de la qualité des données qu'ils ont préparées, de l'analyse qu'ils ont effectuée, etc. Cinquièmement, et je pense que c'est le moment le plus important - l'équipe était très jeune, tous les gars étaient au début de leur carrière. Il était intéressant pour eux d'étudier un produit vaste et complexe, de résoudre de nouveaux problèmes graves pour eux dans un nouvel environnement pour eux, ils cherchaient à répondre professionnellement au niveau des équipes, des problèmes et des clients environnants. Le projet s'est avéré être une excellente école, puis tout le monde a fait une bonne carrière dans l'entreprise et est devenu chef technique et cadre supérieur, l'un des gars est maintenant directeur technique chez Amazon Web Services, l'autre est passé à Google au fil du temps, et tous se souviennent toujours de ce projet avec chaleur .

Si cette équipe était composée de programmeurs avec 15 à 20 ans d'expérience derrière eux, la motivation serait différente. L'âge et l'expérience ne sont bien sûr 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é un excellent résultat.

En général, comme nous l'avons mentionné à plusieurs reprises, vous devez connaître les attentes de vos programmeurs, comprendre lesquels d'entre eux souhaiteraient étendre ou modifier la portée des activités et prendre en compte ces attentes.

En dehors de la pyramide de Maslow: visibilité, ludification et compétition, pas de conneries

Il y a trois autres points importants concernant la motivation des programmeurs qui devraient être mentionnés, mais les attirer vers 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 bien au-delà de l'horizon, la quantité de travail est terrifiante, l'objectif est loin, pas clair et invisible, "la nuit est sombre et pleine d'horreurs". Il est préférable de diviser la route en plusieurs parties, d'ouvrir la voie à l'arbre le plus proche, qui est visible, réalisable, la forme est claire et ce n'est pas loin de nous - et allez à cet objectif proche. Nous voulons faire un effort de quelques jours ou semaines, obtenir et évaluer le résultat, puis continuer. Par conséquent, le travail doit être divisé en petites parties (les sprints en agile servent bien cet objectif). Ils ont fait une partie du travail - enregistré, exhalé, discuté, puni les coupables, récompensé les non invités - vous pouvez commencer le cycle suivant.

Cette motivation est dans une certaine mesure similaire à celle vécue par les joueurs lorsqu'ils jouent à des jeux informatiques: ils reçoivent périodiquement des médailles, des points, des bonus lors du passage de chaque niveau, cela peut être appelé «motivation dopaminergique».

De plus, la visibilité du résultat est littéralement importante. Une fonction fermée dans la liste doit devenir verte. Si le code est écrit, testé, contaminé, 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 ont réussi, le correctif a passé le code de révision et le correctif a été épuisé. Chaque étape était visuellement marquée d'une coche verte ou d'une croix rouge. Une fois, l'un des développeurs s'est plaint que le code de révision dure trop longtemps, les collègues doivent accélérer, les correctifs se bloquent pendant plusieurs jours. J'ai demandé ce qui, en substance, est en train de changer pour lui? Après tout, lorsque le code est écrit, la construction est assemblée et les tests réussis, il n'a pas besoin de faire attention au patch envoyé s'il n'y a pas de commentaires. Les collègues procéderont eux-mêmes à l'examen et les garderont en mémoire (si, là encore, il n'y a pas de commentaires). Il a répondu - "Igor, je veux obtenir mes trois coches vertes dès que 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, en entrant 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 déclarer (et affirmait périodiquement) qu'elle était le premier contributeur, mais il n'existait pas de véritable moyen de comparer la contribution des participants les uns aux autres, d'évaluer sa dynamique dans le temps. En conséquence, il n'y avait aucun moyen de fixer un objectif pour l'équipe, qui pourrait être mesuré chez certains perroquets, évaluer le degré de réussite, etc. www.stackalytics.com . , . . - stackalytics. , , , .. , .

, — , , . , . , -, , , , , , +1 . , , +1 CI . , “go, go, jenkins”. , , , . : , . , , , , scale performance , , core reviewer, core projects , — .

, — No bullshit.

— , . 8-10 , . -, , , , , . , , , . — . , , , , disagree and commit ( , ). - , . , , , . - : « , , . , , ». , . , , .