Yammer : La structure traditionnelle des entreprises de développement est morte

Kris Gale, Vice-Président de l'Ingénierie chez Yammer, affirme que les petites équipes sont la clé du développement produit rapide dans les grandes entreprises. Il explore les subtilités de la construction d'organisations dans le développement produit et explique comment prendre des décisions conscientes pendant une phase de croissance peut garantir que les éléments qui rendent une start-up unique et spéciale ne se perdent pas. En fin de compte, c'est le rôle d'un directeur technique de réfléchir à la façon d'organiser et d'optimiser le développement logiciel.

Les petites équipes livrent plus vite

Au départ, l'équipe Yammer suivait une approche assez simple. On se concentrait principalement sur le produit lui-même sans trop se préoccuper du recrutement pendant la croissance de l'organisation. Cependant, à mesure que l'entreprise grandissait, ils ont remarqué que le gain marginal de productivité avec chaque nouveau développeur diminuait en raison d'efforts supplémentaires.

Parallèlement, le reste du monde a compris que Yammer était en train de créer quelque chose de grand. Partout, des start-ups essayaient de copier le produit, et même de grandes entreprises lançaient des produits concurrents. Chez Yammer, on savait qu'il ne pouvait y avoir qu'une seule entreprise dominante sur le marché et que ce serait une autre s'ils n'étaient pas assez agiles. Les applications web modernes doivent être agiles et adaptables.

Pour pouvoir livrer plus rapidement, Yammer a adopté l'approche de travailler avec de petites équipes. Mais cela signifie plus que simplement diviser une entreprise en petites équipes. Si ces équipes sont limitées de quelque manière que ce soit dans l'implémentation du code, elles sont inutiles. Elles doivent avoir la liberté d'accomplir des choses même en dehors de l'organisation.

La spécialisation dans les petites équipes

Tout au début, les nouvelles fonctionnalités chez Yammer étaient réparties entre les trois développeurs selon leur spécialisation. Ce n'était pas très strict. Donc s'il y avait beaucoup de travail avec Rails, Gale pouvait donner un coup de main, même si Rails n'était pas son point fort. L'objectif devrait être de créer des groupes similaires qui sont petits et spécialisés, mais qui ne représentent pas de purs silos, car différents problèmes nécessitent différentes compétences (et différentes expériences).

Processus séquentiels et grandes entreprises technologiques

Cette approche fonctionnait vraiment bien avec trois développeurs. Mais quand l'équipe Yammer s'est agrandie, on est passé à un modèle plus traditionnel pour les organisations de développement logiciel, avec une division selon les compétences techniques. Il y avait donc une équipe Back-end, une équipe Front-end, une équipe Mobile, etc. À la fin de l'année 2010, ce n'était plus seulement trois développeurs qui travaillaient sur les fonctionnalités, mais environ 30. Mais étaient-ils dix fois plus rapides ? Non.

Selon la loi d'Amdahl sur l'exécution parallèle des programmes, le gain de vitesse d'un programme utilisant plusieurs processeurs est principalement limité par la partie séquentielle du problème [car son temps d'exécution ne peut pas être réduit par la parallélisation]. Exemple : Si vous avez un programme dont vous ne pouvez paralléliser que la moitié, vous ne pourriez que doubler la vitesse même avec 100 processeurs. Même avec 100 processeurs supplémentaires, cela ne changerait pas grand-chose. Le temps pour la partie séquentielle de l'effort total reste donc toujours le même.

Les gens pensent à tort que dans le développement logiciel, le code est écrit à partir de spécifications – mais ce n'est pas vrai. Les décisions techniques sont aussi très importantes – et personne ne peut construire une entreprise de développement s'il croit cela.

Dans une organisation de développement logiciel typique de taille moyenne à grande, on a peut-être une équipe Front-end, une équipe Back-end et éventuellement une équipe Middleware. Ces équipes ont leur propre base de code et leur propre manager qui rend compte à un supérieur. L'idée est que l'organisation et l'architecture du code devraient correspondre.

Avant que les dirigeants puissent répartir et déléguer le travail, ils doivent d'abord décider ce qui doit exactement être construit. Puis viennent des questions comme : « Sur quoi l'équipe Back-end va-t-elle travailler ? » et « Comment cela se connecte-t-il avec l'équipe Front-end ? »

Cependant, si les travaux sont répartis et délégués par les échelons supérieurs de la direction comme décrit, c'est qu'on fait fausse route. Réfléchissez-y. Car si celui qui doit implémenter le code trouve un problème dans les spécifications, il ou elle doit soumettre une proposition d'amélioration tout en haut au niveau de la direction, qui doit ensuite redescendre. Ce processus ralentit un produit et finit par l'arrêter complètement. De plus, les développeurs dans d'autres parties de l'organisation voient cela comme une perturbation, car ils ne travaillent pas étroitement avec le développeur qui a proposé le changement. Ils ne comprennent tout simplement pas la raison du changement.

Ce n'est pas ce qu'on voulait chez Yammer.

Le management ne devrait pas prendre de décisions de développement

On devrait toujours embaucher des personnes meilleures et plus intelligentes que soi. Si on suit ce conseil, ne devrait-on pas alors faire confiance à ces mêmes personnes pour prendre des décisions qu'on aurait autrement dû prendre soi-même ? En fin de compte, c'est le rôle du directeur technique de construire et de promouvoir une organisation. Vous devrez probablement plus vite que prévu ne plus vous concentrer uniquement sur l'écriture du code, mais porter votre attention sur l'organisation elle-même.

Je ne pense pas que vous devriez construire un produit. Je pense que vous devriez construire une organisation qui construit un produit.

Soyez extrêmement prudent en faisant confiance aux managers pour les décisions de développement. En fait, vous devriez déléguer toutes ces décisions aux personnes qui doivent les mettre en œuvre. C'est un signal d'alarme clair quand les managers sont les seuls à prendre des décisions pour plus de 30 à 40 personnes.

Comment devrait-on construire des fonctionnalités ?

Quand on construit une fonctionnalité chez Yammer, l'objectif est toujours d'améliorer l'une des trois métriques principales :

• Viralité
• Engagement
• Monétisation

Fondamentalement, chez Yammer on veut construire des fonctionnalités qui attirent les clients, les fidélisent et qu'ils achètent. Même si vos indicateurs clés sont différents, vous devriez définitivement commencer à communiquer quelques objectifs principaux dans toute l'organisation. Sinon, vous ne pouvez pas permettre à tous les employés de votre entreprise de prendre de bonnes décisions.

Dans les organisations traditionnelles, les chefs de projet rédigent les spécifications selon leurs idées. Chez Yammer, c'est différent. Au lieu d'écrire une spécification rigide sur ce qui doit être construit, une spécification est vue comme un point de départ pour une équipe transversale qui peut ensuite l'élaborer. Si la spécification est déjà trop longue ou prescrit trop de choses, vous devriez être prudent. Les développeurs concernés devraient pouvoir comprendre les décisions pour une fonctionnalité afin d'implémenter le code de la manière la plus efficace et efficiente.

La règle du « Deux et Dix »

La règle d'or la plus importante chez Yammer est : deux à dix personnes, deux à dix semaines. Il n'y a donc pas vraiment de projets plus grands ou plus compliqués. Il y a une relation non linéaire entre la complexité d'un projet et la phase d'intégration finale à la fin. Pour tout ce qui dure plus de dix semaines, la durée de la phase finale devient disproportionnée.

Se tenir à cette règle oblige également à livrer plus fréquemment, à tester des hypothèses et à ne pas trop s'attarder sur les erreurs. C'est similaire au Lean Startup et si vous voulez l'essayer, vous devez le codifier dans votre entreprise.

Vous devez développer un sens de l'urgence. Les projets très longs sont souvent responsables quand les développeurs perdent de vue l'objectif réel. C'est comme la randonnée. Quand vous partez, vous êtes encore plein d'énergie, vous vous réjouissez de la randonnée et vous avancez assez vite. Avec le temps, votre corps se fatigue et vous ne pouvez plus voir d'où vous êtes parti ou où vous allez. Quand vous atteignez ce point, vous avez besoin d'une forte volonté pour vous motiver à continuer. Malheureusement, beaucoup d'organisations ont mis leurs développeurs exactement dans cette phase intermédiaire pour la plupart de leurs tâches.

Cependant, vers la fin de la randonnée, vous pouvez à nouveau voir votre destination et la motivation revient. À chaque pas, l'objectif se rapproche un peu. Il est important que vos développeurs soient dans cette phase où ils peuvent mesurer et visualiser leurs progrès. C'est la seule façon de maintenir l'urgence et le moral.

Code Ownership

Attention au Code Ownership – quand les gens ont leur propre base de code, cela peut créer beaucoup de mauvaises incitations qu'on devrait éviter. Chez Yammer, l'organisation est divisée en domaines d'expertise. Les développeurs sont finalement vraiment intelligents et motivés et s'ils peuvent s'orienter vers l'objectif de l'entreprise, ils peuvent accomplir des choses étonnantes (et ce même de manière complètement autonome).

Définir à quoi ressemble une équipe qui travaille

Avant qu'une équipe produit soit créée pour une fonctionnalité, on examine attentivement la spécification. Plus précisément, on essaie d'estimer l'effort pour la fonctionnalité.

Prenons le Produit X. C'est une fonctionnalité imaginaire qui augmente la viralité en permettant d'inviter des amis pendant le processus d'inscription. Dans cet exemple, l'accent est mis sur le Front-End, ce qui signifie qu'on a peut-être besoin de deux personnes pour l'interface utilisateur. Et comme on doit probablement aussi changer quelque chose dans le processus d'inscription, on a certainement besoin de quelqu'un de l'équipe Rails pour écrire le code correspondant.

Une fois que l'équipe produit s'est mise d'accord sur une priorité pour le projet, il suffit d'attendre que les développeurs soient disponibles (dans ce cas deux pour le Front-End et un pour Rails). Chez Yammer, il y a un grand tableau blanc quadrillé appelé « Big Board ». D'un côté sont listés les projets, de l'autre tous les développeurs qui travaillent sur des fonctionnalités. Bien sûr, un développeur ne peut travailler que sur un seul projet à la fois. Le Big Board crée également une bonne transparence des priorités. Tout ce qui est accompli pendant le développement y est mentionné et ainsi le directeur général peut y jeter un coup d'œil à tout moment et constater : « Voilà sur quoi les développeurs travaillent en ce moment. »

Si vous réussissez à garantir le focus pour un seul projet, votre entreprise deviendra déjà nettement plus rapide. C'est étonnant que personne n'en fasse une condition dans son organisation – alors que tout le monde sait au fond combien coûte un changement de contexte. Avec un focus absolu, on construit une chose, on la livre et ensuite on peut se consacrer à autre chose.

Mais qui s'occupe alors des bugs ?

Si tout le monde travaille sur des fonctionnalités, qui s'occupe des bugs ? Chez Yammer, il y a simplement plusieurs équipes transversales. On prend quelques personnes de l'équipe Rails, de l'équipe Front-end et de l'équipe Mobile, etc. et on leur dit : « Votre travail est de corriger les bugs et de traiter notre liste. » C'est seulement une affaire temporaire (comme tous les groupes orientés projet) et les gens alternent. Cette structure organisationnelle permet de s'occuper du support sans affecter le développement des fonctionnalités.

De plus, cela ne crée pas de seconde classe de développeurs. On ne met pas simplement quelques développeurs juniors de côté pour corriger les bugs ; les développeurs seniors sont également impliqués. Et c'est voulu, car quand des bugs doivent être corrigés, on ne veut pas les masquer, mais traiter la cause. Les personnes plus expérimentées devraient être autorisées à refactorer le code si nécessaire. Ce système crée également une boucle de feedback entre ceux qui construisent les fonctionnalités et ceux qui corrigent les bugs. Quand on connaît la fréquence et le type de bugs, ce sont des informations importantes pour les décisions qui peuvent faire avancer le développement produit.

Ce texte provient du blog de First Round et a été traduit par nous en allemand.