Pourquoi votre plateforme interne ressemble à un projet que personne ne veut utiliser

Quelques mois après le lancement, les plaintes commencent. « Le pipeline est trop rigide. » « Nous n'arrivons pas à obtenir l'accès à la base de données dont nous avons besoin. » « L'environnement de staging ne correspond pas à la production. » L'équipe qui a construit la plateforme se sent frustrée. Ils ont tout documenté. Ils ont fourni des pipelines standard. Ils pensaient que le travail était terminé. Mais les équipes produit trouvent des contournements, construisent leurs propres scripts et abandonnent silencieusement la plateforme.

Ce schéma se répète dans toutes les organisations. Une équipe plateforme construit quelque chose, le déclare terminé, puis passe à autre chose. La plateforme a été traitée comme un projet avec une date de livraison, et non comme un produit qui doit évoluer. Le résultat est une infrastructure coûteuse que personne n'utilise réellement.

Le piège de la mentalité de projet

Lorsqu'une plateforme est traitée comme un projet, l'équipe travaille vers un seul jalon : le jour du lancement. Ils conçoivent le portail, mettent en place les pipelines standard, rédigent la documentation et considèrent leur travail comme terminé. L'hypothèse est qu'une fois la plateforme existante, les équipes l'adopteront et tout fonctionnera sans accroc.

Cette hypothèse est presque toujours erronée.

Les besoins des développeurs évoluent au fil des projets. Une équipe qui n'avait besoin au départ que d'un pipeline de build et de déploiement de base aura éventuellement besoin d'un environnement de staging qui reflète la production. Elle aura besoin d'exécuter des migrations de base de données, de s'intégrer à des outils de monitoring ou d'accéder à des services spécifiques. Si la plateforme ne peut pas s'adapter à ces besoins changeants, les développeurs résoudront leurs propres problèmes. Ils créeront leurs propres pipelines, provisionneront leurs propres environnements et contourneront complètement la plateforme. L'investissement dans la construction de la plateforme devient un effort gaspillé.

Traiter la plateforme comme un produit interne

L'alternative est de traiter la plateforme comme un produit, et non comme un projet. Cela signifie que l'équipe plateforme fonctionne comme n'importe quelle équipe produit servant des clients externes, à la différence près que leurs clients sont les développeurs au sein de la même organisation.

Une équipe produit ne construit pas de fonctionnalités sur la base d'hypothèses. Elle parle aux utilisateurs, recueille des données et itère en fonction des retours. L'équipe plateforme doit faire de même. Elle doit comprendre ce qui ralentit les développeurs. Quelles parties du processus de développement causent le plus de douleur ? Quels pipelines échouent le plus souvent et pourquoi ? Quels environnements causent le plus de frictions ?

Cette mentalité de produit change la façon dont l'équipe plateforme travaille. Au lieu de construire des fonctionnalités basées sur ce qu'ils pensent que les développeurs veulent, ils prennent des décisions basées sur des conversations et des données. Ils mesurent les taux d'adoption : combien d'équipes utilisent réellement les pipelines standard ? Combien de temps s'écoule entre le commit et le déploiement ? Lorsqu'une équipe refuse d'utiliser la plateforme, l'équipe plateforme ne la blâme pas. Ils enquêtent sur ce qui manque ou ce qui est cassé dans l'expérience de la plateforme.

À quoi ressemble la pensée produit en pratique

Une équipe plateforme avec une mentalité de produit fait plusieurs choses différemment.

Ils maintiennent un backlog d'améliorations basé sur les retours des développeurs, et pas seulement sur leurs propres idées. Ils priorisent le travail en fonction de ce qui supprimera le plus de frictions pour le plus grand nombre d'équipes. Ils publient des mises à jour par cycles, comme n'importe quelle équipe produit, et ils mesurent si chaque changement aide réellement.

Ils acceptent également que la première version de la plateforme ne sera pas parfaite. Les modèles de pipeline initiaux pourraient être trop rigides. La documentation pourrait manquer des cas limites importants. Le processus d'onboarding pourrait être déroutant. Ce ne sont pas des échecs. Ce sont des signaux que la plateforme a besoin d'itérations. Ce qui compte, c'est d'avoir un mécanisme pour recueillir ces retours et agir en conséquence.

La partie difficile : changer la mentalité organisationnelle

Passer d'une mentalité de projet à une mentalité de produit n'est pas facile, en particulier dans les organisations qui ont toujours traité les outils internes comme des projets d'infrastructure. Les projets d'infrastructure ont des périmètres fixes et des dates de livraison. Les produits ont des cycles de développement continus et des exigences évolutives.

Le changement nécessite que l'équipe plateforme repense son rôle. Ils ne sont pas des constructeurs qui livrent un système fini. Ils sont des fournisseurs de services qui améliorent continuellement l'expérience développeur. Leur succès est mesuré par la capacité des développeurs à apporter de la valeur, et non par le nombre de fonctionnalités de la plateforme.

Cela nécessite également un soutien organisationnel. L'équipe plateforme doit avoir la permission de passer du temps sur la recherche, la collecte de retours et l'itération. Ils doivent être évalués sur des résultats comme la vélocité des développeurs et l'adoption de la plateforme, et pas seulement sur le fait d'avoir livré un portail dans les délais.

Quand la plateforme échoue à s'adapter

Sans une mentalité de produit, la plateforme devient un goulot d'étranglement. Les développeurs se sentent contraints par des processus rigides qui ne correspondent pas à leurs besoins spécifiques. Ils commencent à contourner la plateforme, ce qui crée des incohérences entre les équipes. Certaines équipes utilisent le pipeline standard, d'autres utilisent des scripts personnalisés, et quelques-unes n'utilisent aucune automatisation. La charge cognitive que la plateforme était censée réduire augmente en réalité, car les développeurs doivent désormais apprendre à la fois la plateforme et les contournements.

Le pire résultat est lorsque l'équipe plateforme blâme les développeurs de ne pas adopter leurs outils. « Nous l'avons construite, pourquoi ne l'utilisent-ils pas ? » La réponse est généralement simple : la plateforme ne résout pas leurs problèmes réels. L'équipe plateforme a construit ce qu'elle pensait être nécessaire, et non ce qui était réellement nécessaire.

Une checklist pratique pour les équipes plateforme

Si vous construisez ou maintenez une plateforme interne, voici une courte checklist pour rester honnête avec vous-même :

• Savez-vous quelles équipes utilisent votre plateforme et quelles équipes l'évitent ?
• Pouvez-vous nommer les trois principaux points de friction auxquels les développeurs sont confrontés lorsqu'ils utilisent votre plateforme ?
• Avez-vous un cycle de feedback régulier avec vos utilisateurs, et pas seulement une boîte à suggestions ?
• Mesurez-vous l'adoption et la vélocité des développeurs, et pas seulement la disponibilité et le nombre de fonctionnalités ?
• Avez-vous un backlog qui priorise les améliorations en fonction de l'impact utilisateur ?
• Lorsqu'une équipe contourne votre plateforme, enquêtez-vous sur les raisons ou la blâmez-vous ?

Si vous ne pouvez pas répondre « oui » à la plupart de ces questions, vous gérez probablement un projet, pas un produit.

L'essentiel à retenir

Une plateforme qui n'évolue pas avec ses utilisateurs sera abandonnée. Traiter la plateforme comme un produit interne signifie accepter que le travail n'est jamais terminé. Le travail de l'équipe plateforme est de réduire continuellement les frictions pour les développeurs, de répondre aux besoins changeants et de mesurer si leurs changements aident réellement. Le moment où une équipe plateforme déclare son travail terminé est le moment où la plateforme commence à mourir.