L'équipe d'ingénierie de Compass a rencontré un problème. Nos fonctionnalités étaient solides sur le plan technique, mais il manquait quelque chose : une véritable attention envers les clients. Nous codions efficacement, mais est-ce que nous résolvions les bons problèmes ?
En tant que Senior Engineering Manager chez Atlassian pour Compass, j'ai passé des années à relever ce défi. Mon équipe et moi-même sommes chargés de créer des outils qui aident les équipes de développement à gérer leurs composants logiciels et leurs ressources à grande échelle. Quand j'ai intégré l'équipe, j'ai remarqué une tendance à laquelle sont confrontées de nombreuses organisations d'ingénierie : nos fonctionnalités sont excellentes, mais nous n'arrivons pas toujours à apporter de la valeur.
J'ai pu directement constater que la culture de l'ingénierie peut contribuer ou nuire au succès d'un produit. Chez Atlassian, nous ne nous contentons pas de créer des outils pour les équipes chargées des logiciels, nous connaissons parfaitement les défis auxquels nos clients sont confrontés au quotidien. Cet aspect nous donne un point de vue unique sur la transformation de la culture de l'ingénierie, et c'est pourquoi je tiens particulièrement à partager ce que nous avons appris.
Les obstacles liés à l'ingénierie traditionnelle
Prenons l'exemple d'une équipe produit, dont l'histoire peut vous sembler familière.
Tina, développeuse senior, est réputée pour ses connaissances techniques hors pair. Bien que son code soit irréprochable, elle s'est retrouvée piégée dans un cycle que nous connaissons tous : recevoir des exigences, coder et déployer des fonctionnalités. « Je codais dans le vide, admet Tina. Je ne savais pas si ce que j'étais en train de construire résolvait réellement les problèmes des clients. » Elle souhaitait davantage de contexte client. Mais le fait de se concentrer uniquement sur la mise en œuvre l'en empêchait.
Rita, la conceptrice produit de l'équipe, a dû faire face à ses propres difficultés. Elle passait des semaines à créer des designs au pixel près pour, au bout du compte, recevoir un feedback crucial pendant le développement et devoir apporter des révisions majeures. « Lorsque les développeurs signalent des contraintes techniques, il est souvent trop tard pour conserver la vision originale du design », explique-t-elle. Rita avait besoin d'une meilleure intégration avec le processus de développement et d'un moyen de valider les designs plus tôt.
De son côté, Paul, le responsable produit, essayait de mener la barque. Il a passé d'innombrables heures à rédiger des cahiers des charges détaillés, mais il y avait toujours des erreurs de traduction. « C'est comme le jeu du téléphone sans fil », explique Paul. « Au moment où nous mettons les fonctionnalités à la disposition des clients, elles changent par rapport à ce que nous avions initialement imaginé. » Le responsable produit recherchait désespérément une meilleure collaboration entre les équipes d'ingénierie et de conception, mais le processus de transfert traditionnel ne cessait de créer des obstacles.
Rick, le responsable de programme, a peut-être eu la position la plus difficile de toutes. Son rôle ? Coordonner les dépendances entre les différentes équipes, tout en trouvant un équilibre entre rapidité de livraison et qualité. Il n'en dormait plus la nuit. « Lorsque les équipes travaillent en vase clos, de simples changements peuvent entraîner des semaines de retard », observe Rick. Il avait besoin d'un moyen d'améliorer la collaboration et la visibilité entre les équipes.
Anna, responsable de l'ingénierie, qui avait du mal à transformer le mode de fonctionnement de ses équipes, supervisait le tout. Même si elle accordait une grande importance à la technicité, elle savait qu'il manquait quelque chose. « Nous avons une équipe d'ingénierie incroyablement talentueuse », souligne-t-elle, « mais nous n'offrons pas toujours à nos clients la valeur dont ils ont besoin. » Anna voulait changer la culture de l'équipe, mais à cause du modèle de développement traditionnel, il lui était difficile de trouver un équilibre entre excellence technique et valeur client.
L'expérience de cette équipe reflète une tendance générale dans le développement de logiciels. Bien qu'elle soit organisée et prévisible, l'approche séquentielle traditionnelle crée naturellement un décalage entre les personnes en charge de la conception du produit et les utilisateurs.
La culture : la clé de la transformation
« La culture mange la stratégie au petit-déjeuner. » Bien que cette citation soit souvent attribuée à Peter Drucker, expert en management, elle a pris de l'importance avec Mark Fields, lorsque celui-ci l'exposa de manière permanente dans la salle de crise de Ford, en 2006. Ce n'est pas qu'une phrase accrocheuse. Ce message reflète une vérité fondamentale que nous avons constatée à plusieurs reprises dans le secteur de la technologie : une stratégie, aussi brillante soit-elle, échouera si elle entre en conflit avec la culture de l'organisation.
Lorsque nous avons décidé de transformer la culture de l'ingénierie chez Compass, nous avons découvert quelque chose de crucial : l'excellence technique à elle seule ne suffisait pas. Nous devions créer un lien entre nos ingénieurs et nos clients. Les chiffres le confirment : les entreprises dotées d'une culture bien ancrée enregistrent une croissance de leurs revenus 4 fois supérieure à celle de leurs concurrents.
Notre parcours de transformation chez Compass l'illustre parfaitement. Nous sommes passées d'un processus traditionnel du cycle de vie des fonctionnalités, qui prenait généralement entre 6 et 8 semaines, à un processus de découverte itératif qui nous a permis de mieux comprendre les problèmes des clients. Il ne s'agissait pas simplement d'un changement de processus. C'était un changement fondamental. Avant, nous pensions tout savoir, maintenant nous en apprenons tous les jours ; chaque fonctionnalité est devenue une occasion d'en apprendre plus sur nos clients.
L'évolution de l'ingénierie de produits
Depuis toujours, l'ingénierie logicielle consiste à créer un code fonctionnel grâce à une conception, un développement et des tests systématiques, tout en respectant les exigences. Les ingénieurs se concentrent principalement sur l'exécution technique, à savoir un codage efficace, la maintenance des systèmes et la garantie de la qualité.
L'ingénierie de produits représente toutefois un changement fondamental dans notre façon de concevoir des logiciels. Elle inclut deux éléments cruciaux : une compréhension approfondie des clients et un apprentissage continu, tout en préservant la rigueur technique du génie logiciel. Les ingénieurs produits ne se contentent pas de coder ; ils participent à la découverte et à la résolution des problèmes des clients, car ils fournissent des informations techniques aux décisions en lien avec les produits et assument l'entière responsabilité des résultats de leur travail.
Le modèle d'ingénierie logicielle traditionnel
Dans le modèle traditionnel, le développement suit une trajectoire linéaire. Le cahier des charges passe d'abord entre les mains de la gestion de produit, pour aller ensuite à l'équipe conception, puis à l'équipe d'ingénierie, qui le met en œuvre. Imaginons qu'il s'agit d'une course de relais. Chaque équipe passe le témoin à la suivante.
L'ancien flux de travail de notre équipe reflétait cette approche linéaire :
- L'approbation des cahiers des charges prend plusieurs mois.
- Les architectes et concepteurs travaillent de manière isolée.
- Les ingénieurs codent en respectant des spécifications précises.
- Les tests et le déploiement arrivent en dernier.
- Le feedback du client passe par plusieurs intermédiaires.
Cette approche fonctionnait lorsque les exigences étaient stables et que les modifications coûtaient cher. Mais compte tenu de l'évolution rapide des marchés d'aujourd'hui, nous avions besoin de quelque chose de plus adaptatif et qui place le client au cœur du processus.
La boucle continue de l'ingénierie de produits
Notre transformation a consisté à remplacer ce processus linéaire par une boucle d'apprentissage continue. Au lieu de voir le développement comme une course de relais, nous fonctionnons désormais comme une équipe de football : tout le monde bouge ensemble, s'adapte à l'évolution des conditions et garde un œil sur l'objectif, à savoir créer de la valeur pour le client.
Dans ce nouveau modèle :
- Les ingénieurs participent aux entretiens avec les clients et aux sessions de découverte.
- Le développement et la conception se font en collaboration, avec un prototypage et des tests rapides.
- Les décisions techniques sont validées par rapport aux besoins du client.
- Le déploiement devient une opportunité d'apprentissage, et pas simplement une étape.
- Les équipes mesurent leur succès en fonction de l'impact sur les clients, et pas seulement en fonction d'indicateurs techniques.
De la mise en œuvre à la responsabilisation
Pour des ingénieurs comme Tina, cette transformation lui a permis de passer d'une simple implémentation à une véritable responsabilisation. Désormais, les ingénieurs :
- participent à la définition des problèmes et à l'exploration des solutions
- apportent des points de vue techniques aux premières discussions
- valident les hypothèses directement avec les clients
- assument l'entière responsabilité des résultats des fonctionnalités, pas simplement la qualité du code
- suivent les indicateurs commerciaux et l'impact sur le marché
Les résultats parlent d'eux-mêmes : les organisations qui adoptent ce modèle enregistrent des délais de commercialisation plus rapides et des taux d'adoption des fonctionnalités plus élevés que celles qui utilisent des approches d'ingénierie traditionnelles. Plus important encore, nous avons constaté une meilleure implication de l'équipe, une meilleure prise de décisions techniques et un meilleur alignement entre les solutions techniques et les besoins des clients.
Comment nous avons rendu notre transformation possible
Pour transformer le mode de travail des ingénieurs, il fallait plus qu'un simple changement d'état d'esprit, il fallait poser les bonnes bases. Pour notre équipe, un élément crucial de cette base était l'outil Jira Product Discovery, qui a naturellement intégré le contexte client à notre flux de travail quotidien.
Le premier défi que nous devions relever était de rendre les informations sur les clients accessibles à tous. Avant, le feedback des clients et les exigences relatives aux produits figuraient dans les documents Confluence, les fils de discussion Slack et les tickets Jira. Jira Product Discovery a intégré tout ce contexte directement à notre flux de développement. Les ingénieurs peuvent désormais suivre les entretiens client, les sessions de feedback et les modèles d'utilisation tout au long de leur travail de développement, afin de rendre les besoins des clients tangibles et immédiats plutôt qu'abstraits et vagues.
Cette accessibilité a fondamentalement changé la façon dont nos équipes collaboraient. Lorsqu'une personne en charge de la conception, comme Rita, créait des designs, elle pouvait les relier directement aux problèmes des clients, visibles et compréhensibles par les ingénieurs. Lorsque Paul privilégiait les fonctionnalités, il pouvait facilement relier l'impact sur les clients à la complexité technique, afin de prendre des décisions plus éclairées. Plus important encore, notre équipe d'ingénierie a enfin pu bénéficier d'une vue d'ensemble sur les projets en cours, mais pas seulement. Elle peut désormais connaître l'importance de ces projets pour nos clients et l'impact que cala a sur leur travail.
Pour les équipes qui envisagent une transformation similaire, n'oubliez pas qu'il n'est pas question de choisir entre l'excellence technique et l'orientation client, mais de réunir ces deux aspects pour créer des produits que les clients adorent vraiment. Lorsque les ingénieurs comprennent parfaitement les besoins des clients, ils prennent de meilleures décisions techniques, élaborent des solutions plus sophistiquées et trouvent plus de sens dans leur travail, car ils peuvent en constater l'impact direct.
Vous voulez en savoir plus sur la façon dont nous avons mené cette transformation ? Visionnez notre webinaire : The Magic Behind Product Engineering : Turning Customer Problems into Features They Love (La magie derrière l'ingénierie produit : transformer les problématiques des clients en fonctionnalités plébiscitées), où j'évoquerai en détail notre parcours, et je partagerai des stratégies et des rituels pratiques que vous pouvez mettre en œuvre avec votre propre équipe.