L’absence de découverte conduit à des outils de plateforme qui manquent leur cible
Construire quoi que ce soit, logiciel, matériel, infrastructure, sans comprendre ce dont les gens ont réellement besoin est une perte de temps et de talent. Dans de nombreuses équipes de plates-formes, en particulier dans les environnements de croissance rapide ou d’entreprise, il y a une tendance à l’exécution par défaut sans véritable découverte. Une équipe peut passer des mois à concevoir et à perfectionner des outils qui cochent toutes les cases d’une fiche technique, mais qui échouent au test le plus simple : les utilisateurs s’en servent-ils vraiment ?
Le problème n’est pas l’incompétence. C’est l’alignement qui n’est pas respecté. Les ingénieurs construisent souvent en fonction de problèmes perçus, des problèmes qui semblent importants à l’extérieur mais qui ne ralentissent personne dans la pratique. Sautez la découverte et vous commencez à résoudre des problèmes qui n’existent pas. C’est ainsi que les produits meurent à l’arrivée.
Les plateformes internes de développement ne doivent pas se contenter de fonctionner. Elles doivent s’intégrer directement dans le mode de fonctionnement des équipes logicielles, de manière silencieuse, efficace et sans friction. Lorsque ce n’est pas le cas, après quelques tentatives frustrantes, les gens reviennent à de vieux outils, à des flux de travail manuels ou à des bidouillages qui prennent du temps. L’adoption chute. La dette technique s’accumule. La valeur est perdue.
Vous n’avez pas le droit de créer un logiciel qui n’est pas utilisé. Découvrez d’abord. Comprenez le problème avec précision. Ensuite, construisez ce qui accélère vraiment les autres.
La découverte continue améliore la pertinence et l’adoption des outils de la plateforme
La découverte n’est pas quelque chose que l’on fait une fois, que l’on raye et que l’on retourne coder. Elle doit être continue, car les problèmes auxquels les gens sont confrontés évoluent constamment. C’est ce que nous avons fait chez Stack Overflow, en adoptant un processus de découverte continue comme partie intégrante du travail de la plateforme. Il ne s’agit pas d’un ajout. Une pratique de base.
L’idée vient de Teresa Torres, une chef de produit qui encourage les conversations hebdomadaires avec les clients pour valider les hypothèses et tester les orientations. Ce n’est pas de la bureaucratie. Les entretiens hebdomadaires avec les utilisateurs internes vous font gagner bien plus de temps qu’ils n’en font gagner aux réunions. Vous arrêtez de deviner ce dont les gens ont besoin. Vous arrêtez de construire sur la base d’opinions ou d’expériences passées. Vous construisez avec la précision du monde réel.
Cela fonctionne parce que les besoins des développeurs ne sont pas statiques. Les nouvelles décisions en matière d’architecture, les changements de chaîne d’outils ou l’évolution des priorités des produits créent de nouveaux points de friction que la solution d’hier n’est pas en mesure de résoudre. Si votre plateforme est basée sur le contexte du dernier trimestre, elle est déjà dépassée.
La découverte continue crée une boucle de rétroaction entre les constructeurs et les utilisateurs. Elle permet aux équipes de faire des paris ciblés avec confiance, et non avec espoir. Vous travaillez toujours vite, mais vous travaillez bien, et pas seulement vite. C’est ce qui compte lorsque le temps et les ressources sont limités.
Si vous ne faites pas de découverte en continu, vous ne construisez pas de plateformes. Vous ne faites qu’expédier du code.
Traiter les ingénieurs comme des clients améliore l’utilité et l’alignement de la plate-forme
Les ingénieurs internes ne sont pas des utilisateurs. Ils sont vos clients. Si votre plateforme existe pour les aider, votre première tâche est de comprendre leur environnement, leurs contraintes et leurs priorités. La plupart des équipes chargées des plateformes passent à côté de ce point. Elles traitent les ingénieurs comme des parties prenantes passives qui consomment tout ce qui est construit pour eux. Cet état d’esprit crée un désalignement et des outils à faible impact.
Chez Stack Overflow, l’équipe en charge de la plateforme a changé d’approche. Les équipes internes ne sont pas seulement consultées, elles sont impliquées très tôt, avant qu’une seule ligne de code ne soit écrite. Lors de la planification, l’équipe se concentre sur les résultats qui aideraient réellement les équipes partenaires à livrer mieux et plus vite. L’équipe ne se contente pas d’accepter les demandes de fonctionnalités et de fournir ce qui est demandé. Ils approfondissent les raisons pour lesquelles une fonctionnalité est demandée et le problème qu’elle est censée résoudre.
Cette méthode permet de se concentrer plus précisément sur les éléments à construire. Elle évite de perdre du temps avec des fonctionnalités populaires mais peu utiles. Pour Teresa Torres, il s’agit de se concentrer sur les « opportunités » au lieu de commencer par une proposition de solution. C’est plus difficile au départ, mais cela permet de clarifier les choses et de prendre de meilleures décisions.
Du point de vue des dirigeants, ce changement réduit la redondance et augmente le retour sur investissement du temps consacré à l’ingénierie. Vous financez moins de projets, mais ils aboutissent à une plus grande adoption et à moins de frictions. C’est ainsi que les équipes chargées des plates-formes internes parviennent à une véritable vélocité, non pas en livrant à temps, mais en livrant ce qui compte.
Les boucles de découverte légères et itératives favorisent la flexibilité et la confiance.
Les longs cycles de rétroaction ne fonctionnent pas dans les environnements dynamiques. Vous ne pouvez pas vous permettre de livrer quelque chose, d’attendre l’approbation, puis de réaliser qu’il a raté sa cible. L’équipe de la plateforme de Stack Overflow a choisi une voie différente, des cycles de retour d’information légers et continus qui permettent aux créateurs et aux utilisateurs de rester en contact étroit tout au long du processus.
Il s’agit ici d’hypothèses. Chaque projet repose sur ces hypothèses, mais peu d’équipes les valident réellement avant d’investir du temps et des ressources. Grâce à ce que Teresa Torres appelle la « cartographie des hypothèses », les équipes définissent ce qui doit être vrai pour qu’une solution fonctionne, puis testent ces hypothèses avec des utilisateurs réels le plus tôt possible.
Cette approche permet d’établir des relations plus saines entre les équipes. Les développeurs n’ont pas l’impression que les outils leur sont imposés. Ils voient leur contribution se refléter dans le produit avant même son lancement. Cela crée un climat de confiance, ce qui est essentiel lorsque vous optimisez les flux de travail des développeurs. Vous devez avoir la liberté de faire des compromis. Cette liberté est possible lorsque les équipes comprennent pourquoi les décisions sont prises, et pas seulement ce qu’elles obtiennent.
Pour les dirigeants, ce processus permet de corriger plus rapidement le tir. Si quelque chose ne fonctionne pas, vous vous en apercevez rapidement, avant que l’infrastructure ne soit trop complexe pour être modifiée. Il permet également aux équipes de pivoter sans perdre leur élan ou leur crédibilité. Tout cela se fait par le biais de cycles courts : écoutez, testez, ajustez. Pas de perturbation, pas de gonflement. Juste une itération intelligente avec un apprentissage rapide.
C’est à cela que ressemble l’agilité au niveau de la plateforme : des boucles de rétroaction concises fondées sur la transparence, de sorte que les décisions reflètent les environnements actuels, et non les hypothèses passées. Cela permet de gagner du temps, de réduire les frictions et d’obtenir des outils que les utilisateurs souhaitent réellement utiliser.
La mesure de l’adoption et des frictions permet d’obtenir des informations significatives sur l’impact.
L’expédition n’est pas la ligne d’arrivée. L’utilisation réelle vous permet de savoir si ce que vous avez construit fonctionne comme prévu. Mais les indicateurs qui ne suivent que l’adoption ne sont pas suffisants. Vous pouvez avoir un taux d’adoption élevé et échouer malgré tout, parce que les gens peuvent utiliser votre outil simplement parce qu’ils n’ont pas le choix, tout en construisant en privé des solutions de contournement pour accomplir leurs tâches réelles.
Chez Stack Overflow, l’équipe d’ingénierie de la plateforme s’intéresse à la fois à l’adoption et à la friction. L’adoption indique si un outil est utilisé. La friction indique dans quelle mesure l’outil s’intègre dans les flux de travail des développeurs. Ils examinent des indicateurs tels que la fréquence à laquelle les utilisateurs ont besoin d’aide pour les fonctionnalités de base, la fréquence à laquelle ils changent de contexte et s’ils demandent des améliorations ou s’ils se contentent de déposer des plaintes. Il s’agit de signaux pratiques qui révèlent dans quelle mesure une plateforme s’intègre de manière transparente dans le travail d’ingénierie quotidien.
Les données ne s’arrêtent pas aux indicateurs. Elles sont accompagnées d’entretiens avec les développeurs afin de mettre les chiffres en contexte. C’est ainsi qu’ils détectent les angles morts et découvrent si l’adoption est vraiment organique ou si elle est le fruit d’une utilisation forcée. Si un outil est invisible parce qu’il fonctionne, c’est un succès. S’il est largement utilisé mais qu’il fait l’objet de plaintes constantes, c’est du bruit qui couvre un dysfonctionnement.
Du point de vue de la direction, le suivi de l’adoption et de la friction des utilisateurs fournit une vue directe de l’efficacité des développeurs. Cela permet de prioriser l’investissement et l’itération, de sorte que vos équipes ne se contentent pas d’obtenir des outils, mais qu’elles deviennent plus productives grâce à eux. Cette boucle de rétroaction améliore le retour sur investissement de la plateforme et garantit que les heures d’ingénierie se traduisent par des gains de performance significatifs.
La découverte est permanente et s’adapte à l’évolution des besoins de l’équipe.
Les équipes de développement ne sont pas statiques, tout comme leurs problèmes. Une fois que vous avez résolu un problème, l’environnement change. Les priorités changent, les architectures évoluent et de nouvelles inefficacités apparaissent. Si votre compréhension des besoins de l’équipe est basée sur la dernière série de tickets ou sur les commentaires d’il y a six mois, vous n’êtes déjà plus à jour.
L’équipe de Stack Overflow traite la découverte comme un effort continu. Elle ne recueille pas de commentaires superficiels et ne s’en va pas. Elle procède à des vérifications régulières et utilise des entretiens basés sur des histoires, une méthode popularisée par Teresa Torres, pour aller plus loin que les demandes de fonctionnalités de base. Au lieu de demander aux gens ce qu’ils veulent qu’on construise, ils les interrogent sur la dernière fois qu’ils se sont heurtés à un obstacle. Cela leur permet de savoir ce qui s’est réellement passé, et pas seulement ce dont les gens pensent avoir besoin. Le contexte révèle des schémas réels et, souvent, le véritable problème n’est pas celui qui a été demandé à l’origine.
Les dirigeants qui investissent dans l’ingénierie des plateformes devraient exiger ce niveau de connaissance. Cela permet d’éviter l’erreur coûteuse de construire des outils pour résoudre les mauvais problèmes. Plus important encore, cela garantit que vos plateformes évoluent en même temps que vos utilisateurs, et non pas derrière eux.
Lorsque les plateformes s’adaptent en temps réel aux besoins de l’ingénierie, vous créez un effet de levier. Vous obtenez des cycles plus rapides, moins d’interruptions et une meilleure rétention de vos talents techniques parce qu’ils ne sont pas constamment en train de lutter contre des processus défaillants. Votre infrastructure devient dynamique sans être chaotique. C’est ainsi que vous empêchez l’innovation interne de s’enliser. La découverte vous donne le signal. L’itération vous donne la vitesse. Les deux doivent être constants.
L’équilibre entre la fiabilité et la découverte créative est un défi culturel mais nécessaire.
Les équipes chargées des plateformes sont généralement évaluées en fonction de la stabilité de leurs systèmes. Le temps de disponibilité, la latence, les taux de défaillance sont les paramètres qui attirent l’attention. Mais si ces équipes s’arrêtent à la fiabilité, vous ne progressez pas. On maintient. Et avec le temps, même les systèmes solides qui n’évoluent jamais ne répondent plus aux besoins des équipes. C’est là que la découverte intervient, non pas en remplacement mais en complément.
Ce n’est pas le processus qui est difficile, c’est le changement d’état d’esprit. La découverte est risquée. Elle introduit l’incertitude dans des environnements souvent formés pour l’éviter. Dans de nombreuses organisations, les équipes chargées des plateformes tombent dans la routine des « tickets et livraisons » : terminer ce qui est demandé, l’enregistrer et passer à la chose suivante. Cela donne l’impression que l’exploration créative des problèmes n’est pas possible. Mais si vous ne remettez jamais en question les demandes entrantes ou ne réévaluez jamais les problèmes en amont, vous renforcerez constamment les inefficacités existantes en les automatisant davantage.
Chez Stack Overflow, l’intégration de la découverte dans le travail de la plateforme a nécessité un changement culturel. La direction peut pousser dans ce sens, mais les progrès durables se produisent lorsque les cadres supérieurs et les cadres intermédiaires normalisent une nouvelle norme : demander « pourquoi », et pas seulement « quand ». Bloquer du temps pour l’exploration, faire de l’espace pour remettre en question les hypothèses et créer de la sécurité pour que les équipes d’ingénieurs puissent exprimer leur incertitude, voilà les véritables éléments constitutifs d’une meilleure culture.
Pour les dirigeants, ce compromis est stratégique. Lorsque vous prenez en charge à la fois un temps de fonctionnement élevé et une découverte réfléchie, vous construisez une plateforme qui ne se contente pas de rester opérationnelle, mais qui reste pertinente. Vous réduisez les problèmes d’intégration en aval. Vous réduisez la charge de travail. Et vous faites en sorte que les équipes se concentrent sur l’essentiel, en résolvant les goulets d’étranglement actuels et non en maintenant des hypothèses dépassées. La valeur à long terme de la plateforme dépend de cet équilibre.
Une mise en œuvre efficace commence à petite échelle et se développe de manière itérative
Stack Overflow n’a pas revu sa stratégie de plateforme du jour au lendemain. Tout a commencé simplement. Quelques conversations ciblées avec des utilisateurs internes. Pas de programmes de recherche formels. Pas d’enquêtes poussées. Juste de la curiosité et la volonté d’écouter. C’est à cela que devrait ressembler la découverte précoce : de petites étapes rapides qui vous aident à comprendre ce qui bloque les performances, ce qui fait perdre du temps et ce qui est réellement important.
Ces premiers entretiens n’ont pas été traités comme des sessions d’engagement. Ils servaient à recueillir le contexte. Au lieu d’accepter des demandes superficielles, les ingénieurs de la plateforme ont interrogé les équipes sur des situations récentes de friction. Ces discussions ouvertes ont permis de mettre en évidence des schémas méconnus qui n’étaient pas visibles à travers les seuls indicateurs. Au fil du temps, ces entretiens ont façonné la manière dont les feuilles de route étaient élaborées, non pas comme des listes de contrôle, mais comme des investissements stratégiques dans les problèmes réels rencontrés par les développeurs.
À partir de là, l’équipe ne s’est pas lancée immédiatement dans la réalisation de projets complets. Elle a testé les idées proposées avec de petits groupes : parfois une démonstration, parfois un prototype rapide. Les résultats ont dicté la décision de poursuivre ou non. Cette boucle légère de test, de rétroaction et d’ajustement a permis à l’équipe de rester en phase avec les utilisateurs réels. Elle a également permis aux parties prenantes de se sentir impliquées dans le processus, ce qui a rendu l’adoption plus rapide et plus naturelle.
Pour les décideurs, cela signifie que vous n’avez pas besoin de déploiements à l’échelle de l’entreprise pour prouver la valeur. Vous avez besoin de cycles d’apprentissage clairs, d’une collaboration honnête et d’un alignement étroit entre les équipes chargées des plateformes et les utilisateurs internes. Lorsque la découverte est intégrée à ce niveau, vos plateformes ne se contentent pas d’être construites, elles sont utilisées et évoluent. C’est à ce moment-là que les rendements des plateformes commencent à s’accroître.
Dernières réflexions
Si vous voulez que vos investissements dans les plates-formes soient rentables, il vous faut plus que de la fiabilité, il vous faut de la pertinence. Les outils qui ne s’intègrent pas dans les flux de travail réels sont ignorés, même s’ils sont très performants sur le papier. La découverte continue permet de résoudre ce problème. Elle permet à vos équipes de rester proches des besoins réels, de réduire le gaspillage et de renforcer l’alignement entre les ingénieurs des plateformes et les développeurs qu’ils servent.
La découverte n’est pas un luxe. C’est de la clarté opérationnelle. Lorsqu’elle est réalisée de manière cohérente, elle fait passer les équipes de la plateforme d’un rôle de support réactif à celui de facilitateur stratégique. Vous cessez de construire en fonction des demandes et commencez à construire en fonction des contraintes qui bloquent la vitesse. C’est de là que vient la valeur mesurable, non seulement de la vitesse, mais aussi de la précision.
Cela ne nécessite pas une réorganisation massive. Cela commence par une volonté de poser de meilleures questions, d’effectuer des tests plus petits et de rester proche des équipes que vous essayez de responsabiliser. Accompagnez cet état d’esprit d’un soutien culturel et de la cohérence de la direction, et vous obtiendrez des plateformes qui non seulement fonctionnent, mais font avancer les choses. Tel est l’objectif. Construisez des choses qui comptent et assurez-vous qu’elles continuent de compter.
