Sang, sueur et mini-équipes : pourquoi Belka Games a restructuré l’équipe Clockmaker et quels résultats cela a donné

Vitaliy Kuzmin

Presque deux ans se sont écoulés depuis que nous nous sommes lancés dans une expérience audacieuse de restructuration de l’équipe de Horlogerie. Nous sommes passés d’une structure fonctionnelle à la structure à la mode, quelque peu mystérieuse, pas complètement comprise, mais très séduisante, des mini-équipes.

Évidemment, chacune de ces configurations a ses avantages et ses inconvénients. L’une d’entre elles peut facilement prendre racine dans une entreprise mais pas dans une autre. Cet article est une tentative de revoir le chemin que nous avons parcouru, de rassembler toute notre expérience et de la présenter à nos collègues. Nous espérons que vous y trouverez quelque chose d’utile. Et si vous décidez de partager également votre expérience, ce serait fantastique.

Problèmes qui ont motivé cette décision

Il y a deux ans, nous avons changé Horlogerie à un nouveau moteur. Le cours de son développement a été documenté dans une feuille de route. Bien sûr, nous avons essayé de prévoir tous les résultats, mais le projet avait huit ans à l’époque et s’était construit un héritage décent, de sorte que nous nous sommes souvent heurtés à des défis imprévus. En conséquence, l’étendue de la version s’est accrue, les délais de publication n’ont pas été respectés et les chefs de projet sont devenus grisonnants sous nos yeux.

En conséquence, cerise sur ce gâteau de chaos, la fonctionnalité clé de la mise à jour a pris plus de temps à développer que prévu et, de plus, elle a été refaite plusieurs fois à la volée. Dans le domaine des jeux mobiles, ce rythme de développement est un luxe inabordable.

Avec une telle charge de travail, tous les défauts de la structure deviennent apparents. La nôtre a démontré deux inconvénients majeurs qui nous ont incités à nous transformer :

• Goulots d’étranglement. Au fil du temps, notre équipe a atteint plus de 60 personnes et sa taille a empêché les chefs de projet, le producteur et les responsables fonctionnels de travailler efficacement. Le nombre de tâches pour chaque responsable dépassait largement leur capacité, de sorte que certaines tâches restaient bloquées pendant longtemps lorsqu’elles devaient être approuvées par la direction ;
• Une équipe d’employés différente travaillait à chaque fois sur des fonctionnalités différentes. Ils n’avaient pas la cohésion des équipes soudées.

Étonnamment, même dans ces circonstances, les revenus du jeu ont continué à augmenter régulièrement. Dans une certaine mesure, le succès a affaibli notre vigilance et nous a fait fermer les yeux sur des problèmes graves et évidents (nous les reconnaissons maintenant, mais hélas, ils ne semblaient pas être un problème à l’époque).

Plus ces problèmes sont importants, plus la chute qu’ils provoquent est difficile. Pour nous, cela s’est produit lorsque nous avons atteint la fin de la première vague de la pandémie. Nos revenus ont commencé à s’ajuster, mais nos problèmes n’ont pas disparu. Les conditions émergentes nous ont donné des indices subtils que des changements étaient nécessaires.

La solution, ou vive la révolution !

À cette époque, nos concurrents sur le marché publiaient des mises à jour tous les mois et alimentaient la croissance des indicateurs financiers en bourrant les jeux de contenu frais. Nous avons décidé de nous joindre à ce rallye. Cet objectif était aussi clair que le fait que l’atteindre serait pratiquement impossible dans le cadre de notre structure actuelle.

Mais pourquoi des mini-équipes en particulier ?

Nous n’avions que peu ou pas d’expérience de travail en mini-équipes, nous avons donc décidé de nous tourner vers nos collègues du secteur. À bien des égards, bien sûr, nous avons été inspirés par l’approche très discutée de Spotify consistant à créer des « Squads », des équipes transversales autonomes responsables de leurs propres fonctionnalités et formant des « Tribus » plus importantes. Cependant, à l’époque, ses inconvénients étaient devenus évidents et nous nous en sommes éloignés. Considérant que Spotify lui-même n’utilisait pas sa propre structure, nous avons fait le bon choix.

Ainsi, nous avons eu un premier aperçu de notre future structure et l’avons documenté dans une présentation au PDG.

Voici comment le concept des mini-équipes a abordé nos problèmes point par point :

• Nous avons éliminé les goulots d’étranglement des chefs de projet et des responsables fonctionnels en introduisant le rôle d’un chef d’équipe pour chaque équipe, qui a pris en charge toutes les opérations : gestion des plans hebdomadaires, création et répartition des tâches, et conduite de réunions individuelles avec les employés ;
• Pour éliminer les goulots d’étranglement au niveau des producteurs, nous avons introduit le rôle de propriétaire de fonctionnalité – en gros, un concepteur de jeux qui peut prendre des décisions concernant le produit et diriger une fonctionnalité du concept à la sortie ;
• Nous avons assigné des employés à une mini-équipe spécifique afin de créer quelques groupes cohésifs qui travaillent ensemble sur les nouvelles fonctionnalités ;
• Nous avons développé l’indépendance des mini-équipes, en encourageant la prise de décision et toute initiative en leur sein ;
• Nous avons fixé le rythme souhaité pour les mises à jour (au moins une fois par mois) afin de mieux comprendre la capacité d’une équipe, de prêter plus d’attention à la priorité des tâches et, par conséquent, de supprimer tout ce qui est inutile du périmètre.

Le principal piège était que les mini-équipes étaient conçues comme des unités commerciales autonomes et autosuffisantes. Elles étaient censées avoir exactement le même nombre de spécialistes dans tous les rôles afin de ne pas avoir à emprunter des spécialistes à d’autres équipes tout en travaillant sur leurs propres fonctionnalités. Et cela signifiait que nous devions sérieusement augmenter notre personnel.

Nous devions préparer des arguments étanches et déterminer comment nous pouvions adapter le modèle aux coûts les plus bas. Je vais m’avancer un peu et dire que toutes nos équipes ne sont pas dotées à 100 % du personnel prévu initialement. Mais nous sommes parvenus à une sorte de structure hybride où nous partageons les ressources sur Slack lorsque quelqu’un n’est pas surchargé de travail. Les chefs de mini-équipes y postent des demandes de spécialistes.

Après une courte présentation au PDG et une série de questions, le feu vert du patron était dans la poche. Il était temps d’agir.

Notre interprétation des mini-équipes et ce à quoi ressemble notre structure

Nous considérons les mini-équipes comme des unités commerciales autosuffisantes et (presque) autonomes, chacune ayant une spécialisation claire et la responsabilité d’une partie de la portée globale de la prochaine mise à jour. Elles sont autosuffisantes parce que leurs membres peuvent mener une fonctionnalité du stade de l’idée à sa mise en production.

En général, une équipe est composée des membres suivants :

• Le concepteur du jeu, alias le propriétaire de la fonctionnalité, qui est responsable de la documentation et s’assure que la vision de la fonctionnalité ne s’effondre pas pendant le développement ;
• Développeurs ;
• Artistes et concepteurs d’interface utilisateur ;
• Animateur ;
• Testeur.

Un chef d’équipe gère chaque équipe. Il facilite le processus de développement et est responsable de la gestion des personnes : entretiens individuels, objectifs et plans de développement. Les managers doivent également être gérés, c’est pourquoi notre structure place un chef de projet au-dessus des chefs d’équipe. Le chef de projet est chargé de coordonner les chefs d’équipe, d’assembler la mise à jour à l’aide des pièces du puzzle fournies par les mini-équipes et de contrôler les délais.

Nous avons divisé nos mini-équipes en trois domaines de responsabilité :

• Mise en œuvre de fonctionnalités clés riches. L’incrément majeur de notre produit est généralement constitué d’événements temporaires avec de nouvelles mécaniques de jeu ;
• Le fonctionnement de notre arsenal actuel d’événements avec des mécanismes de jeu anciens et éprouvés ;
• Travail technique. Généralement, il n’est pas lié à la logique commerciale et est caché sous le capot, mais il n’en est pas moins important pour le produit.

Nous avons toujours besoin d’équipes qui sont formées en fonction de la fonction. Par exemple, les concepteurs narratifs ne sont pas affectés à des mini-équipes de fonctionnalités et ne sont amenés à intervenir qu’en cas de besoin, car les mini-équipes n’ont pas de travail à plein temps pour eux.

Les gestionnaires fonctionnels n’ont pas disparu non plus. Ils ont acquis le fier titre d' »experts » et sont en dehors de la structure de la mini-équipe. Leur objectif principal est d’améliorer la qualité du travail des spécialistes dans leur domaine. En d’autres termes, le responsable technique examine le code des développeurs, le responsable du design de l’interface utilisateur examine les maquettes et propose des modifications, le responsable de l’assurance qualité s’assure que les scénarios de test couvrent tout, etc. Afin que les experts puissent développer des spécialistes à leur plein potentiel, nous avons essayé de libérer les experts des opérations autant que possible. C’est pourquoi les chefs d’équipe s’occupent des tâches dans le tracker de tâches et de leur attribution.

Vous trouverez ci-dessous un schéma de notre structure organisationnelle.

Nous ne déployons pas de mini-équipes sur chaque projet. Le critère principal est le nombre d’employés. Pour nous, la création de mini-équipes a du sens si la taille totale de l’équipe dépasse 50-60 personnes. Dans les autres cas, nous conservons la structure fonctionnelle.

Gardez à l’esprit que vendre cette idée à votre équipe ne sera pas facile. Nous sommes humains, nous aimons donc résister au changement et rejeter activement tout ce qui va à l’encontre du statu quo. Nous avons organisé de nombreuses réunions pour expliquer en détail la valeur des nouvelles améliorations et annoncer les objectifs que nous poursuivons. Certaines personnes ont aimé l’idée, tandis que d’autres la traitent encore avec hostilité. Voici quelques mots de conseil :

• Obtenez d’abord le soutien des chefs d’équipe et des experts. Faites-en vos alliés. Il sera beaucoup plus facile de vendre l’idée aux employés hiérarchiques par l’intermédiaire des leaders d’opinion ;
• Soyez honnête avec votre équipe. Nous avons dit ouvertement qu’il s’agissait d’une expérience importante pour nous et qu’elle pourrait bien se solder par un échec. Nous n’avons pas exclu la possibilité de revenir à notre structure précédente et en avons discuté avec l’équipe ;
• Précisez que la structure n’est pas figée et que les spécialistes peuvent tourner entre les équipes. Ceci est important pour les employés qui ne veulent pas s’enliser dans des tâches répétitives.

Mise en garde importante

Il existe une mise en garde importante qui aide l’ensemble du plan de la mini-équipe à devenir pleinement opérationnel et à répondre à nos exigences en matière de fréquence de publication. Nous l’appelons « développement parallèle » ou « développement chevauchant ».

L’idée est que la mini-équipe Alpha travaille sur la mise à jour n°1 tandis que la mini-équipe Bravo travaille sur la mise à jour n°2. Par conséquent, elles ne sont pas en concurrence pour les ressources, et leurs tâches ne se chevauchent pas car chaque équipe développe sa propre fonctionnalité. Le cycle de développement complet d’une fonctionnalité prend en moyenne 2 à 3 mois. Ayant commencé le développement aux bons endroits, nous avons réussi à atteindre une fréquence de publication de 1,5 à 2 mois.

Faiblesses et problèmes des mini-équipes

Bien sûr, chaque système a ses défauts, et celui que nous avons construit ne fait pas exception. Passons en revue les principaux problèmes.

Des « coûts de transaction » importants. » Chaque mini-équipe devrait avoir des points de synchronisation pour coordonner le travail et comprendre à quoi il mène et à quel stade il se trouve. Nos équipes se synchronisent grâce aux chats sur Slack, au projet sur Asana et aux réunions sur Google Meet. C’est juste le nombre de ces réunions qui est un moment pénible. Nous avons commencé avec ce plan :

• Une conférence téléphonique avec tous les chefs d’équipe et les experts le lundi matin ;
• Des entretiens quotidiens de 15 minutes avec l’équipe chaque jour ouvrable (du lundi au vendredi) ;
• Revues et planification le vendredi après-midi.

Avec le temps, les mini-équipes sont devenues de plus en plus indépendantes, et nous avons commencé à faire des quotidiens trois fois par semaine : lundi, mercredi et vendredi. Certaines équipes ont essayé de combiner les quotidiens du vendredi et les sessions de planification en une seule réunion. Elles ont également donné aux experts la possibilité de se joindre à leurs quotidiens et à leurs séances de planification, à condition qu’ils soient personnellement invités ou qu’ils jugent nécessaire de soulever une question importante.

La nécessité de rédiger un énoncé de travail 2 ou 3 mises à jour à l’avance. Si cela n’est pas fait, l’équipe n’aura tout simplement rien à faire. Idéalement, l’équipe devrait produire les versions les unes après les autres de manière coopérative et transparente. Par exemple, lorsque les spécialistes de l’interface utilisateur ont terminé la conception de la fonction A, le producteur devrait avoir approuvé le cahier des charges de la fonction B.

Avons-nous réussi à le faire ? Encore une fois, pas entièrement. Mais nous pensons avoir fait de grands progrès à cet égard. Notre horizon de planification actuel pour un projet est de six mois. Cela signifie que nous savons quelles fonctionnalités nous allons réaliser au cours des six prochains mois et qu’un cahier des charges est prêt pour chacune d’entre elles.

Un manque de flexibilité. Tout d’abord, il est difficile de réorganiser les plans au cours d’une production continue lorsque les fonctionnalités sont réalisées les unes après les autres. Le jeu mobile est un environnement instable, et il faut parfois abandonner une fonctionnalité à moitié terminée si la foi en elle a disparu et qu’une idée pour une meilleure fonctionnalité est apparue.

Deuxièmement, certaines fonctionnalités ont été détruites plus d’une fois et ont nécessité des révisions majeures. Nous avons essayé de donner ces révisions à l’équipe qui a initialement créé la fonctionnalité, car elle avait le plus d’expertise et la plus faible barrière à l’entrée. Comme les équipes alternent les versions, les révisions ont parfois dû attendre 2 à 3 mois, et un producteur quelque part était triste pendant tout ce temps.

Parlons des points positifs

Nous avons déjà souligné les défauts de l’ancienne structure fonctionnelle : les responsables, les chefs de projet et les producteurs étaient surchargés de tâches, les équipes ne travaillaient pas en harmonie et les processus étaient ralentis. Dans la nouvelle structure, nous espérions rassembler les équipes, atteindre un rythme de publication régulier et décharger les responsables et la direction dans la mesure du possible. Voyons ce que nous avons réalisé, un par un.

Coopération. Les membres de nos mini-équipes sont constants, ce qui signifie que les processus internes ont été affinés. L’animateur connaît toujours la meilleure façon d’envoyer les animations au programmeur. Le programmeur, à son tour, établit à l’avance une base de données pour l’animateur. Grâce à cette coopération, il est beaucoup moins fréquent que les membres de l’équipe aient à clarifier quelque chose et soient détournés du sujet. L’intégration se fait à la volée.

L’engagement. Lorsque les grandes entreprises augmentent leurs effectifs, il est beaucoup plus difficile pour les employés de comprendre leur impact sur le produit et leur contribution à un objectif commun. Lorsque vous avez 20 testeurs dans un département, il est plus difficile de reconnaître que vous faites quelque chose d’important et d’utile en vue d’un objectif global, et beaucoup de personnes commencent à simplement « faire leur travail ». Dans une mini-équipe, le sens de l’objectif revient : l’unité a des KPI clairs devant elle, le travail d’une personne a un impact direct sur celui des autres et, par conséquent, chaque personne est aussi engagée que possible dans le processus.

Moins de goulots d’étranglement. Désormais, les chefs d’équipe répartissent toutes les tâches opérationnelles entre les équipes. Les responsables fonctionnels ne sont plus des goulots d’étranglement et, de plus, ils ont plus de temps pour affiner les processus et aider les employés dans leur domaine à se développer.

Les sorties sont plus fréquentes. Chaque équipe travaille sur sa liste de choses à faire indépendamment les unes des autres. Leurs domaines de responsabilité ne se chevauchent pas. Chaque équipe soumet ses fonctionnalités dans les délais impartis et, grâce à cela, les builds sont publiés dans les temps.

Résultats

Avons-nous atteint nos objectifs ? Sans aucun doute. Le passage à une nouvelle structure, ainsi que d’autres changements, ont aidé le jeu, vieux de huit ans… Clockmaker découvrir de nouveaux potentiels financiers. Cela est dû en grande partie au fait que le nouveau contenu est plus fréquemment mis en production. Rappelez-vous que nous sommes passés d’un cycle de développement plus long à des mises à jour tous les 1,5 à 2 mois. En conséquence, nous avons établi deux fois des records historiques de revenus quotidiens.

Les mini-équipes sont-elles une panacée, une solution à tous vos problèmes ? Certainement pas. Pour les équipes matures, le changement sera certainement douloureux. Et, bien sûr, il doit être justifié : vous devez comprendre clairement à quels problèmes vous vous attaquez. Si vous disposez d’une structure organisationnelle bien établie qui vous permet de relever vos défis commerciaux, réfléchissez dix fois avant de tout bouleverser.

En ce qui nous concerne, nous avons décidé que la structure fonctionne, et nous essayons actuellement de la mettre en œuvre dans un autre projet en tirant les leçons de l’expérience de nos pionniers et en adoptant les meilleures pratiques, mais en les affinant et en les adaptant à la réalité actuelle.