Business : Produit pour plates-formes internes – Camille Fournier

Depuis 3 ans, je dirige une organisation d’ingénierie de plateforme. Comme ce terme est vague, là où je travaille, cela signifie le côté logiciel de l’infrastructure. Les plates-formes de calcul telles que kubernetes, les systèmes de stockage, les outils de développement de logiciels et les cadres de services font partie du mandat. Nos clients sont d’autres ingénieurs de l’entreprise.

Je supervise également l’équipe produit de ce domaine. Maintenant, je ne suis pas un chef de produit (que je raccourcirai en PM pour le reste de cet article, à ne pas confondre avec projet manager), et je compte beaucoup sur mon équipe PM pour leur expertise. Mais cela ne signifie pas que je peux personnellement négliger le côté produit, et en effet je passe beaucoup de temps à réfléchir aux produits et à la stratégie de mon organisation dans le cadre de mon travail quotidien.

Ce sont des choses que j’ai observées et apprises dans ce processus. Je les partage avec vous parce que je pense que beaucoup de gens dans les équipes de type plate-forme, en particulier les ingénieurs et ceux d’entre vous dans les équipes de plate-forme sans chefs de produit formels, pourraient bénéficier de la compréhension de la façon d’aborder ces problèmes.

La prise de décision relative aux produits de plateforme est une discipline unique. Lorsque de nombreuses personnes pensent aux chefs de produit, l’image qui leur vient à l’esprit est celle d’un chef de produit pour les grands produits destinés aux consommateurs. Métriques, métriques, métriques! Tests A / B et études d’utilisateurs et KPI et conception de sprints et de modèles de revenus. Je suis sûr que chaque fois que vous créez des produits pour une large base d’utilisateurs, c’est un facteur, et les PM pour AWS ont probablement beaucoup de mesures pour les guider. Mais les tests A / B pour un public de centaines de personnes ne vous apprennent généralement pas grand-chose. Lorsque vous créez une plate-forme pour des clients internes dans une petite ou moyenne entreprise, une stratégie basée sur des métriques est plus difficile à appliquer.

Non seulement nous avons un petit groupe de clients, nous avons un public captif. D’autres équipes peuvent et décident parfois de partir seules et de construire leurs propres plates-formes, mais pour de nombreux types de produits, nous offrons la seule option. Vous pouvez demander aux clients ce qu’ils veulent ou comment ils aiment vos produits, mais ils peuvent ne pas vouloir se plaindre à leurs collègues. Bien sûr, les produits de plate-forme souffrent également du problème selon lequel certains ingénieurs pensent toujours qu’ils pourraient construire quelque chose de mieux, si seulement ils avaient le temps, de sorte que vous avez également un segment de clientèle qui semble ne jamais être satisfait, peu importe la difficulté de votre travail.

Un public captif nous porte à croire que les mesures de base pour l’adoption par les clients ne sont pas intéressantes, ce qui nous amène à leur tour à les ignorer, parfois à nos risques et périls. De nombreuses équipes de plate-forme se retrouvent avec plusieurs produits semi-finis qui se chevauchent car ils supposaient qu’un public captif conduirait au succès du produit.

Enfin, il y a le défi universel des plateformes. Les bons produits logiciels pour les ingénieurs ont tendance à provenir de quelqu’un avec un problème clair devant eux, qui a construit spécifiquement pour résoudre ce problème. Ils connaissent intimement le client car ils sont le client. Ils construisent pour une personne ou une équipe, et ils peuvent voir clairement ce qui doit être résolu. Mais l’équipe de la plateforme ne crée pas de solutions pour un seul utilisateur. Toute la valeur d’une équipe de plate-forme fournit des systèmes largement utiles, nous sommes donc rarement confrontés à un besoin bien spécifié de combler.

Lorsque vous faites partie d’une équipe de plate-forme, il est facile de perdre le sens de ce que c’est que d’utiliser vos propres produits, car vous êtes profondément dans les détails. Vous passez votre journée à vivre et à respirer les tenants et aboutissants de git, et vos utilisateurs connaissent les 3 commandes qu’ils doivent mémoriser et s’appuient autrement sur ohshitgit pour se sortir des ennuis. Dans un monde parfait, les chefs de produit de plate-forme utilisent régulièrement les produits qu’ils prennent en charge afin d’identifier les points faibles et les lacunes que les ingénieurs pourraient manquer et dont les utilisateurs pourraient ne pas se plaindre. Dans le monde réel, il est difficile de trouver du temps pour utiliser vos produits avec colère lorsque vous vous occupez également de toutes les autres parties du travail PM.

Vous pouvez observer cette dilution de concentration et de qualité dans de nombreux produits de plate-forme open source créés par de grandes entreprises afin de vous vendre sur leur solution cloud ou de créer une norme de l’industrie. Cela commence à ressembler à un logiciel qui est en train d’être construit. Et vous le voyez absolument dans les projets de plates-formes internes dans les grandes et petites entreprises. Lorsque les équipes de plate-forme construisent pour être en train de construire, en particulier lorsqu’elles ont de grandes visions d’objectifs finaux complexes avec peu d’états intermédiaires, vous vous retrouvez avec des produits déroutants, sur-conçus et loin d’être appréciés.

Si les défis peuvent être résumés comme suit: un petit public captif, avec lequel il est difficile de vraiment sympathiser et une tendance à construire sans réfléchir, que pouvez-vous faire? Voici quelques approches que j’ai trouvées pour vous aider:

Vous n’avez pas une énorme base de clients pour tester les choses, alors comment trouver un produit réussi? N’ayez pas honte de reprendre un système d’une équipe qui l’a construit en pensant à eux-mêmes, si ce système semble être le bon concept général pour l’entreprise au sens large. Beaucoup d’équipes de plate-forme n’aiment pas faire cela, car elles pensent que cela signifie qu’elles devront vivre avec des décisions avec lesquelles elles ne sont pas d’accord. Ils oublient que lorsque vous prenez un produit d’une équipe qui l’a construit, vous avez déjà un client raisonnablement satisfait pour commencer! Pour le meilleur ou pour le pire, quelqu’un a montré qu’il avait un problème, et il l’a résolu, et vous ne le reprendriez pas si vous ne pensiez pas que ce problème valait la peine d’être résolu de manière holistique, non?

Je l’ai fait lorsque j’ai créé une solution globale de découverte de services il y a longtemps. Une autre équipe avait d’abord identifié le problème et créé sa propre version d’une solution à l’aide de ZooKeeper. La solution répondait bien à leurs besoins, mais n’a pas répondu aux besoins généraux de tous les employés de l’entreprise en matière de mise à l’échelle mondiale. J’ai donc repris l’idée du projet et l’ai transformé en une véritable infrastructure de plate-forme, conçue pour une grande entreprise et pas seulement une équipe. Il y avait beaucoup de décisions sur les produits à prendre dans le cadre de ce travail, mais l’identification de base du problème comme méritant d’être résolu a été faite pour moi. Il y a beaucoup de travail intéressant pour prendre une solution optimisée localement et la transformer en quelque chose qui peut être utilisé par un ensemble diversifié d’applications.

Une autre façon d’identifier de nouvelles opportunités prometteuses est de travailler en partenariat avec une autre équipe, et même d’intégrer quelqu’un dans cette équipe, pour mieux comprendre un problème. Les équipes partenaires viendront probablement vous demander si vous prévoyez de construire quelque chose pour résoudre leurs différents problèmes. Lorsque vous pensez que c’est un bon exemple spécifique de quelque chose qui deviendra un modèle général, profitez de cette demande pour en savoir plus! En accord avec l’objectif de vraiment comprendre la sensation d’un problème, demander aux ingénieurs de la plate-forme de créer une application avec une idée de prototype pour une plate-forme, puis d’utiliser les leçons de ce projet pour extraire un système plus général, est un moyen productif de rapidement itérer une idée en quelque chose qui est utilisable. Après tout, la partie la plus difficile du côté produit de l’ingénierie de plate-forme consiste à déterminer l’utilisabilité. Vous voulez savoir comment les gens vont réellement écrire du code autour de cette offre? Eh bien, écrire du code autour de l’offre vous-même est un bon moyen de le comprendre.

Dans les équipes de plate-forme, une grande partie du travail sur les produits consiste à déterminer comment faire fonctionner les produits open source ou les stratégies populaires pour votre entreprise. Prenez des kubernetes. Les défis du produit autour des kubernetes internes résident dans les décisions que vous prenez sur la façon de l’intégrer dans l’écosystème existant afin d’amener les gens à l’adopter sans trop d’argument. Si vous êtes une entreprise d’un certain âge, vous disposez peut-être déjà d’une ancienne solution de cloud privé. Tout le monde a l’habitude de fonctionner sur des machines virtuelles, mais vous pensez que kubernetes vous apportera des améliorations opérationnelles et encouragera également la société à repenser ses pratiques logicielles pour être un peu plus modernes.

C’est bien beau, mais le travail du produit n’est pas «dites à tout le monde que vous avez des kubernetes maintenant et qu’ils doivent l’utiliser». Au lieu de cela, le travail du produit consiste à identifier différents types de clients et à déterminer ce qui leur facilitera la migration. Quelles carottes pouvez-vous fournir pour inciter les gens à faire un travail qu’ils ne veulent pas faire? Peut-être que les carottes sont efficaces pour accéder au calcul ou au stockage. Vous pouvez peut-être offrir un SLO plus élevé avec le nouveau produit. C’est peut-être plus rapide, plus sûr. Mais ces choses ne se produisent pas simplement. Vous devez choisir les fonctionnalités que vous présentez à vos clients, vous devez les aider à comprendre l’offre et les avantages, et vous devez tenir ces promesses.

Malgré leur audience captive, les équipes de la plate-forme sont réputées pour créer des offres de produits semi-finis qui ne parviennent pas à être adoptées. Lorsque votre organisation de plate-forme exécute trois générations différentes de solutions au même problème sans plan clair pour supprimer l’une d’entre elles, et que vos clients sont à la fois confus par les offres et insatisfaits d’eux, vous avez une grave défaillance du produit entre vos mains. La stratégie de migration doit être un élément principal de la planification du produit.

Mon dernier conseil produit aux équipes de la plate-forme est de se rappeler que vous n’êtes pas Google (sauf si vous êtes, dans ce cas, salut!). Lorsque vous avez une équipe de plate-forme de 7, voire 100, vous devez être extrêmement réfléchi à ce que vous choisissez de construire. Les équipes de plates-formes de toutes tailles peuvent s’enliser en essayant d’imiter des systèmes qui ont été construits au fil des ans dans les grandes entreprises. Même lorsque ces grandes entreprises fournissent leurs solutions en tant que logiciel open source, elles codent souvent toutes sortes d’hypothèses sur l’écosystème environnant des produits disponibles et la culture et les besoins des ingénieurs utilisant le produit qui peuvent ne pas bien fonctionner dans votre entreprise. Ce n’est pas une bonne gestion de produit de dire « Google le fait, donc nous devrions. »

Au lieu de cela, commencez par une compréhension claire du problème et une comptabilité de votre écosystème et de votre culture existants, avant de plonger dans une solution technique. Votre volume de données est hors de contrôle. Vous devrez peut-être résoudre ce problème avec une meilleure solution de stockage, ou vous devrez peut-être le résoudre en identifiant les principaux producteurs de données et en vous demandant si les données qu’ils stockent sont réellement utiles. Vous constaterez souvent que les données sont des ordures, ou que les développeurs peuvent modifier leur flux de travail, ou un peu de réglage des performances des requêtes rend cette échelle d’application très bien dans un SGBDR normal. Construisez uniquement lorsque vous avez épuisé les alternatives.

Les grandes équipes de plate-forme peuvent raconter ce qu’elles ont construit, ce qu’elles construisent et pourquoi ces produits rendent l’équipe d’ingénierie globale plus efficace. Ils ont de solides relations avec les partenaires qui conduisent l’évolution de la plateforme avec des offres ciblées qui répondent et anticipent les besoins futurs du reste de l’entreprise. Ils sont admirés comme des ingénieurs solides qui construisent ce qui est nécessaire, selon des normes élevées, et ils sont en mesure d’investir du temps pour le faire parce qu’ils ne construisent pas trop.

Que vous soyez un ingénieur de plate-forme, un responsable de l’ingénierie ou un gestionnaire de projet, il est utile de se rappeler que vous devez toujours être axé sur le client et stratégique sur vos offres de plate-forme. Sans stratégie claire pour montrer l’impact et la valeur, vous finissez par être négligé et en sous-effectif, et aucune quantité de nouvelles technologies intéressantes ne résoudra ce problème.

Merci à mes amis produits et plateformes pour leurs commentaires sur les versions préliminaires, en particulier Renee et Pete.

Vous aimez ce post? Vous pourriez aimer mon livre, Chemin du gestionnaire, disponible sur Amazon et Safari en ligne!