Quels problèmes de chef d'équipe peuvent être résolus avec l'aide du jeu

Bonjour à tous! Je m'appelle Yevgeny Rtishchev, à Sbertekh, je travaille en tant que responsable du développement des systèmes informatiques sur les projets du système frontal unifié. Le 24 septembre, j'ai pris la parole lors de la conférence Saint Teamlead Conf 2018 à Saint-Pétersbourg. Mon rapport portait sur le match organisé dans l'équipe, ce qui a grandement soulagé mes maux de tête en tant que leader, aidé à la motivation et à la discipline. Le public a très chaleureusement accepté le sujet et posé beaucoup de questions intéressantes et précieuses.

Il me semble que certains points du rapport ont été manqués. Par conséquent, dans l'article, j'ai décidé de parler à nouveau de mon expérience et de partager les résultats. Qui n'a pas assisté à la conférence et souhaite lire une histoire sur un outil alternatif pour une évaluation rapide des performances, la gestion d'une équipe à travers un jeu, une implication accrue dans le développement de produits et comment combiner les concepts de "gamification" et de bureaucratie dans les grandes entreprises - bienvenue .

Intro

Ensuite, il y aura une narration cohérente de mon devenir en tant que chef d'équipe, des problèmes conscients et des erreurs commises. Je ne le cacherai pas - la solution sera d'introduire un jeu d'équipe spécial, donc si vous n'avez pas le désir et l'intérêt de passer 10 à 15 minutes de votre temps précieux, vous pouvez passer à la section "Maintenant, tout le monde exploite MotC" et lire directement sur l'essence du jeu, les erreurs de calcul dans l'équilibre et l'ajustement , ainsi que ce qui en est ressorti.

Problèmes et douleur

Quand je suis arrivé à Sberteh, un nouveau programme interne a commencé et il a fallu rapidement constituer une équipe de développement mobile. Un mois après mon départ, mon manager (qui m'engageait) a démissionné et toutes ses tâches et ses problèmes sont devenus les miens. Honnêtement, avant cela, j'avais peu d'expérience dans la gestion d'une équipe de deux personnes pendant un an. C'était plutôt comme du mentorat technique et du mentorat de nouveaux développeurs. L'équipe s'est rapidement étendue à 11 personnes, j'ai complètement évité d'écrire du code, de développer une architecture et d'autres tâches difficiles. Je suis devenu sensible aux émotions et mes principes de gestion correspondaient à la gestion de la situation, et je devais chercher à plus long terme, développer des personnes dans l'équipe, former de nouveaux leaders, marquer et encourager ceux qui savent bien tirer, mais aussi identifier et punir les «méchants» et les paresseux.

J'ai vu une issue dans l'introduction d'éléments de gestion régulière. C'est-à-dire besoin d'un système avec des règles transparentes pour les récompenses et les punitions. En même temps, je ne voulais vraiment pas tout réduire à
des méthodes banales, dont la réaction s'avère toujours être le contraire.



Tout d'abord, j'ai décidé de faire une liste de problèmes conditionnels, ou plutôt, ces choses que je voudrais
voulait s'améliorer en équipe. Par exemple, je voulais que les gars ne soient pas en retard pour le stand-up, pour s'y préparer, s'écouter attentivement et aider à résoudre les problèmes. Beaucoup de gens n'aiment pas les stand-ups ou tous les jours, car considérer cela comme une perte de temps de travail.

La première étape a été de changer la langue que nous parlions lors de la cérémonie agile - nous avons commencé à tenir un stand-up en anglais. La décision a pris un coup: beaucoup ont préparé le texte à l'avance, la durée a été réduite (l'anglais était laconique et tout le monde a essayé de se concentrer uniquement sur l'essence).

Et puis j'ai réalisé que je devais expérimenter

Nous formulons les zones à problèmes

La tendance à la pensée systémique m'a dit que pour faire quelque chose, il faut d'abord formuler des problèmes ou, plus précisément, des choses que j'aimerais améliorer. Alors je
décrit les principaux domaines.

Classement des membres de l'équipe

Notre entreprise a une gamme de grades - ce sont certains niveaux qui ont leurs responsabilités formelles, leurs privilèges et leurs fourchettes de salaire. Le véritable alignement des forces diffère souvent du formel pour des raisons évidentes: le nombre de postes vacants et leurs grades sont limités, tous les gars sont venus dans l'équipe à des moments différents et dans des conditions différentes, quelqu'un a montré une forte croissance en peu de temps, etc. La procédure de mise à niveau est complexe, assez rare et vous devez y être bien préparé, c'est-à-dire nommez objectivement les personnes qui le méritent. Dans la première procédure de ce type, je me suis très trompé: comme il m'était difficile de me souvenir de tous les mérites ou échecs de certains gars, je suis parti de mon opinion subjective, peut-être à certains endroits en raison de ma propre disposition. Et c'est faux.

Les erreurs dans de telles situations sont très difficiles à corriger. Et je me suis trompé pour la première fois (une minute de confession). Mais les expériences négatives sont un bon professeur. J'ai réalisé que nous avons besoin d'un outil clair - un indicateur simple pour voir toutes les réalisations et les échecs d'une personne, dans quels domaines elle se développe. Les informations doivent toujours être accessibles et pertinentes, et il est normal qu'elles soient publiques - alors tous les membres de l'équipe auront moins de questions avec les prochains changements.

Aide au développement de produits

À mon arrivée, l'entreprise fonctionnait selon le modèle de la cascade - en fait, la banque était le client et l'équipe de Sberbank-Technologies était l'entrepreneur interne. Un an plus tard, la société est passée à la grande Agile - les équipes sont devenues décentralisées, concentrées sur le développement de leurs propres produits (qui pourraient être des sous-modules d'une grande
systèmes). Sur les épaules du propriétaire du produit d'une telle équipe, en plus de la gestion linéaire et de l'architecte de service (dans le cas d'un produit technique), il y avait aussi une nouvelle fonction - la gestion des produits, c'est-à-dire la formation de sa vision, une carte stratégique du développement, le détail et la hiérarchisation des tâches, ainsi que la responsabilité du calendrier de mise en œuvre.

Et moi, en tant que propriétaire du produit, je voulais vraiment que les membres de l'équipe accomplissent non seulement leurs tâches, mais aussi aident le produit à grandir, apportent de nouvelles idées, enlèvent une partie de mes responsabilités et des maux de tête. Par exemple, beaucoup de temps a été consacré à la collecte des exigences, à leur développement et à leur décomposition en tâches logiques et séquentielles spécifiques. Un autre problème était le support produit et la communication avec les utilisateurs. Notre produit est une bibliothèque interne pour développer des applications iOS mobiles (il y a déjà toute une série d'articles sur Habr à ce sujet). Et nos consommateurs sont d'autres équipes d'application. À un moment donné, le nombre de nos utilisateurs a atteint environ 120 développeurs, concepteurs et gestionnaires. Et je n'avais même pas 12 heures par jour pour communiquer avec tout le monde. Je voulais vraiment que l'équipe aide activement dans ce domaine.

Planification de la précision et détermination du temps

Pendant longtemps, nos indicateurs Story Points (ci-après dénommés SP) ont fortement bondi de sprint en sprint. À chaque fois, une situation similaire s'est produite soit en raison de l'arrivée de défauts de la PROM, soit
certaines tâches super importantes imprévues directement de la direction. Les gars se plaignaient régulièrement et étaient mécontents eux-mêmes, car ils ne pouvaient pas comprendre où le temps était passé, si la tâche nouvellement reçue était plus importante que le sprint, quelle valeur cela apporterait au produit. Complexité accrue et approche généralement acceptée pour évaluer les défauts dans 0 SP - J'ai toujours ajouté au sprint
un certain nombre de défauts afin qu'ils puissent être échangés avec des défauts critiques arrivés en plein sprint.

Quelque chose de frais et de nouveau

Après deux ans de travail sur un produit et au sein de la même équipe, les gens commencent à se fatiguer, leurs yeux perdent leur éclat fou et les baisses de productivité.
La solution qui devait être inventée était de rallumer la lumière et un peu
égayer l'équipe.

Un peu sur l'équipe

J'aimerais parler un peu plus de l'équipe: le propriétaire du produit, l'analyste (alias Scrum Master) et 9 développeurs iOS. Comprenez-vous maintenant pourquoi je voulais tellement comprendre l'équilibre des pouvoirs dans une équipe aussi homogène?



Quelques données sociales: nous avions deux filles et l'âge des participants était
allant de 22 à 33. Les domaines d'intérêt étaient différents, mais nous avons essayé de
activités générales de l'équipe: jeux de société réguliers, mini-événements d'entreprise,
voyages communs à des conférences, etc.

Maintenant, tout le monde exploite MotC

J'ai toujours eu un énorme intérêt pour l'industrie du jeu. Enfant, j'ai construit des mondes entiers à partir de lego-cubes, dessiné de simples jeux de société sur un morceau de papier, je suis devenu accro à 3D Max, puis j'ai commencé à apprendre des outils simples pour créer des jeux informatiques - tels que Dark Basic ou Game Factory. J'ai passé beaucoup de temps dans MMO, et du plus étrange - j'ai fait ma propre version du jeu Diablo 2 dans l'éditeur de carte pour Warcraft 3 (il a même eu du succès sur le réseau local de la ville).

Comme vous le comprenez, encore une fois, je voulais créer un monde de jeu et plonger
membres de l'équipe dans un défi en temps réel



Les jeux, en eux-mêmes, contiennent une base très utile, à savoir: la compétition, les points et les notes, les règles et les violations, les réalisations individuelles et par équipes. Les jeux infectent l'excitation (qui dans notre cas est similaire à l'implication), et enseignent également l'amertume de la défaite et les joies de la victoire.

La seule chose qui reste est de choisir un paramètre, de trouver des mécanismes et des règles, d'équilibrer l'équilibre et de travailler également sur la viralité conditionnelle.


La part du lion de mon rapport sur Saint Teamlead Conf a été consacrée uniquement à la création du jeu et à l'achèvement de tous les points nécessaires (gameplay, problèmes d'équilibre, psychologie de 4 types de joueurs, etc.). Je ne traduirai pas toutes ces informations en texte - j'espère que les lecteurs intéressés attendront six mois quand olegbunin rendra les entrées publiques (ou m'écrira en privé). Vous pouvez également venir écouter la conférence des chefs d'équipe le 2 novembre .

Comment obtenir MotC?

En bref, vous pouvez obtenir des pièces virtuelles pour effectuer certaines actions:
1. Clôture des tâches de sprint. Ceci est important et doit être encouragé, car c'est ce qui apporte de la valeur commerciale. 1 Story Point a apporté 1,2 MotC. Pourquoi la valeur n'est-elle pas égale? Oui, c'est simple: premièrement, le nombre magique dit déjà qu'il y a une sorte de coefficient, et après avoir indiqué sa présence, vous pouvez toujours le changer soigneusement (pour ajuster la balance). Plus MotC - entier, c'est-à-dire c'est aussi une incitation supplémentaire pour fermer un plus grand nombre de points d'histoire. Pour 3, vous obtenez 3 Motc, et pour 5 déjà 6.

2. Correction des défauts. Puisqu'il n'y a pas d'évaluation dans SP, alors que ce soit dans MotC. Différents niveaux de criticité avaient un poids différent en termes de MotC. Mais encore une fois, afin d'encourager la correction des défauts (ce que tous les développeurs ne souhaiteraient pas), un bogue fermé apporte toujours un nombre fractionnaire de pièces, qui pourrait être arrondi si un autre défaut n'est pas corrigé.

3. Correction des tâches non imprimables. En plus des défauts, il y avait d'autres tâches urgentes: le serveur de construction est tombé en panne, les tests d'interface utilisateur sont tombés, une tâche urgente et importante est arrivée de la direction, et bien plus encore. Maintenant, pour eux, la personne a reçu MotC et ainsi compensé la pénurie de SP dans le sprint.

4. Notes et classements. Déjà 4 catégories ont été inventées: champion SP, maximiseur de contribution (nombre maximum de MotC), héros de sprint et prix d'équipe. Le principe des deux premiers, je pense, devrait être clair d'après le nom, avec le reste - plus intéressant. Le héros du sprint a été choisi par l'équipe votant sur le rétro, et ce fut l'une des récompenses les plus honorables de l'équipe tant en termes de nombre de Mot qu'en termes de prestige et d'importance. La présence d'un prix d'équipe est essentielle car Cela montre que non seulement le résultat personnel est important, mais aussi le résultat global de toute l'équipe. Trois gradations ont été inventées: sprint régulier, sprint supérieur et sprint échoué. Le sprint était considéré comme normal, si plus de 78% de l'arriéré de sprint était fermé, s'il était de 100%, alors c'est le sprint supérieur. Dans le cas du sprint, toute l'équipe a reçu une généreuse augmentation. Mais il y avait un revers à la médaille - c'est un sprint raté.

Exploitation minière MotC négatif

Les MotCs comptent. Par conséquent, il était possible d'obtenir des pièces avec une valeur négative. Quel anti-mérite a conduit à ceci:

1. Échec du sprint. Dans le cas de l'exécution de moins de 78% de l'arriéré de sprint, toute l'équipe a reçu un minage négatif.
2. Ouverture du défaut. S'il y avait un défaut sans équivoque dans la tâche de perfusion, le MotC négatif a été obtenu par le développeur qui a injecté la demande de traction, ainsi que ses examinateurs.
3. 3. Un système de financement supplémentaire a également été inventé pour être en retard pour un stand-up ou une inattention à des collègues. Elle a agi selon le principe «3 d'affilée». 3 icônes identiques se sont effondrées en une nouvelle, dans laquelle il y avait une extraction négative. Il y avait une règle d'amnistie: lors de la réception de plus de 25 MotC au sprint, l'effondrement n'a pas conduit à une exploitation minière négative, mais les badges n'ont pas été réinitialisés.

Comment dépenser MotC?

Oui oui Le sens des pièces de monnaie n'est pas seulement dans les évaluations personnelles, mais aussi dans le fait qu'elles pourraient être dépensées. Pour cela, une fonction d'activation a été inventée. Seules les pièces positives pouvaient être activées. Il y avait tout un magasin dans lequel il y avait des marchandises et leur valeur. Pour le contrôle, leur nombre était limité.

Qu'y avait-il dans le magasin?

1. La possibilité de quitter le travail plus tôt ou de revenir plus tard. Le hodovichok le plus important.
2. Journée de travail à distance.
3. Possibilité de sélection des tâches prioritaires lors de la planification.
4. Recommandation LinkedIn.
5. Choisir un module à développer sur Swift. Tout le code était en Objective-C, et les gars aimeraient vraiment se développer en Swift.
6. Billets de conférence (si disponibles).

Il y avait d'autres positions, mais ici la règle la plus importante est de garantir la possibilité de leur achat, sinon la confiance sera ébranlée.

Corrections pendant le jeu

Au cours de l'expérience, à certains moments, des problèmes d'équilibre primaire sont devenus perceptibles.
Lesquels?

1. Joueurs modèles. En plus des développeurs, il y avait un analyste dans l'équipe, et sa capacité à obtenir MotC était très limitée, car la part du lion des tâches pour les points de stockage a été affinée pour le développement. De plus, les fonctions de l'analyste comprenaient une partie des tâches administratives, qui étaient coûteuses à surveiller en permanence. La solution a été d'introduire le concept de «minage privilégié», c'est-à-dire un certain nombre de MotC sont automatiquement crédités pour l'accomplissement des tâches quotidiennes. Il est intéressant de constater qu'à l'avenir un autre déséquilibre a été constaté: en l'absence d'un analyste (par exemple, des vacances), quelqu'un a repris ses tâches et, ainsi, a pris part à la production pour une exploitation minière privilégiée.

2. Amortissement des tâches. Au fil du temps, certaines tâches répétitives deviennent plus faciles à réaliser. Par exemple, nous avions une procédure pour publier une nouvelle version du framework (notre produit) - ce qui prenait environ 1,5 à 2 heures de temps pur. Avec le développement de DevOps, son temps passé a été réduit à 30 minutes. En conséquence, la rémunération dans MotC a également diminué. Ou périodiquement, il y avait des tâches pour préparer de nouvelles formes de rapports ou de statuts. Il est difficile de le faire pour la première fois, mais il est plus facile de le répéter - par conséquent, l'estimation en pièces a diminué. L'équipe a perçu ces ajustements de manière appropriée.

3. Double point pour les défauts. Un exemple pour montrer que dans chaque équipe, il y aura des situations imprévues et que les règles doivent être «ajustées». Nous sommes restés longtemps sur la fusion automatique en cascade (c'est-à-dire que lors de l'injection de correctifs, les fusions automatiques sont apparues dans les versions précédentes et se sont développées). À un moment donné, nous avons décidé d'arrêter cette pratique vicieuse en raison des conflits de fusion constamment suspendus sur develop-e et nous sommes passés à l'idée de dupliquer les tâches pour toutes les versions où vous souhaitez télécharger les modifications. Cela a conduit à l'émergence de multiples tâches similaires dans JIRA:



En conséquence, officiellement selon les règles, le joueur peut rapidement effectuer et effectuer 2-3 tâches et obtenir 2-3x pièces. J'ai dû introduire des corrections pour ces tâches, car leur complexité a diminué (mais certainement pas à zéro en raison de conflits potentiels dus à des changements dans les branches individuelles).

4. L'idée de récompenser le travail avec les utilisateurs. Je voulais vraiment «forcer» les gars à aider nos consommateurs (et c'est environ 100 développeurs d'applications, pleins de questions stupides et répétitives). Nous avons essayé différentes approches: nommer des assistants, maintenir une base de connaissances détaillée, développer une communauté d'utilisateurs experts et les encourager. Mais une solution simple est apparue: 1 fois par jour, j'ai rapidement parcouru le chat de support dans Slack et donné aux consultants les plus actifs de l'équipe une petite mais agréable récompense sous la forme de MotC. Les gars ont évalué

En général, un jeu est un processus vivant qui doit changer en cours de route. L'essentiel est de vous assurer dès le départ et de laisser de la place aux manœuvres organiques. Changer les mécanismes du jeu peut provoquer du ressentiment chez les joueurs. Au départ, j'avais peur de ne pas pouvoir calculer correctement l'équilibre entre l'exploitation minière et le coût des «prix» - j'ai donc immédiatement indiqué que leur nombre dans le magasin est limité et sera réapprovisionné autant que possible. De plus, comme vous le savez, le marché de l'offre est contrôlé par un monopole, qui peut toujours déclarer un déficit ou une inflation!

Résultats et observations

L'expérience a duré 9 sprints (4 mois). 968 MotC, 262. 3 -, 4 , MotC :

	MotC	MotC+
1	104	86
2	203	203
3	148	128
4	65	47
5	172	92
6	58	40
7	68	68
8	95	77
9	55	55

– , .

Numbers (xls MacOS) ( MotC ). 5 : , , , .

– .
– . , JIRA
,
. «»
, ,
. :

MotC
1
1
2	boilerplate ( )
2	XSD- , boilerplate
3
16	14 SP
4	SP

, – , .


Win-Win. , . , . .

, – «» . , , , . Performance Review .

!

PS Facebook LinkedIn , - 2 .