Les équipes d’infrastructure ont-elles besoin de la gestion des produits? |

Je réfléchis à cela depuis un moment, récemment inspiré par les pensées de Josh Robb et Amy Nguyen.

De nombreuses équipes de développement d’infrastructure ne disposent pas d’un chef de produit ou d’un propriétaire / analyste de produit fractionné travaillant principalement sur les exigences techniques détaillées. Cela oblige un architecte ou un développeur senior à gérer un éventail de responsabilités qui ne les intéressent pas et qui ne sont peut-être pas qualifiés pour gérer: le tri des priorités commerciales conflictuelles; «vendre» en interne la valeur de l’architecture et des améliorations spécifiques; lier les décisions techniques aux métriques commerciales quantitatives; faire du lobbying pour augmenter les effectifs par rapport aux autres équipes; motiver les développeurs avec des exemples concrets de l’importance de leur travail pour les utilisateurs finaux.

Dit autrement, les grandes équipes de développement veulent travailler sur de gros problèmes techniques. Mais ceux-ci n’arrivent jamais dans un emballage cadeau ou entièrement définis ou sans conflit ou avec une valeur commerciale clairement articulée. Donc deux observations:

Les équipes de développement chevronnées et motivées sont le produit le plus rare de l’univers. Gardons-les concentrés sur ce qu’ils font le mieux. et

Les chefs de produit et les équipes de développement résolvent différents problèmes. Nous ne devons pas forcer les développeurs à être chefs de produit, ou vice versa.

Tout cela est très théorique, alors construisons un exemple…

Imaginez que nous sommes dans une entreprise de commerce électronique de taille moyenne / grande avec plus de 90 développeurs et une infrastructure back-end critique. Nous avons formé une équipe de développement d’infrastructure dédiée pour s’occuper des profils d’acheteurs (nom / adresse / PII, historique des commandes, informations de paiement, préférences marketing) et analyse des acheteurs (journalisation des transactions, statistiques d’engagement, données démographiques, valeur à vie, taux de réponse des campagnes). L’objectif général de l’équipe est de rationaliser et de normaliser les informations sur les acheteurs, en particulier pour l’évolutivité et la gestion cohérente des rapports et de la confidentialité. Nos «clients directs» sont d’autres groupes de produits / développement responsables des paniers d’achat, de l’état des commandes, des moteurs de recommandation, des campagnes de marketing et de la conformité légale.

Inévitablement, la plupart des situations suivantes surviendront:

• Conflits entre les groupes de consommateurs internes sur les priorités de cette équipe. L’équipe Recommandations et l’équipe Shopping Carts ont chacune un arriéré de deux ans pour l’infrastructure, et chacune (bien sûr) veut que sa liste soit traitée en premier.
• Où est la limite de l’infrastructure? Notre architecte a dessiné un diagramme magnifiquement symétrique des microservices RESTful, y compris uniquement les attributs de profil universels qui, selon elle, s’intègrent dans cette couche. Pendant ce temps, l’équipe de l’état des commandes a besoin d’un historique de livraison géographique qui, selon eux, sera d’une utilité générale pour toutes les équipes. Ainsi, les pistes techniques tombent dans un argument philosophique définissant l ‘«infrastructure» ou minimisant les diplômes académiques des uns et des autres. Le problème sous-jacent, cependant, est qu’aucune équipe n’a de bande passante, donc chacun construit des arguments techniques pour expliquer pourquoi l’autre équipe devrait faire le travail. (“C’est vraiment un problème au niveau de l’application, pas un problème d’infrastructure.”)
• Ce dont nos utilisateurs finaux communs ont besoin / veulentpar rapport à la façon dont chaque équipe d’application interprète les besoins des utilisateurs finaux. Par exemple, l’équipe du panier souhaite le moins de champs obligatoires pour le paiement (“Paiement plus rapide!”), tandis que l’équipe du moteur de recommandations souhaite plusieurs options de paiement par utilisateur pour ses accords en surbrillance («Remise sur les produits AmEx uniquement»). Objectifs potentiellement mal alignés, chaque équipe présentant ses demandes comme des spécifications techniques. L’équipe Infrastructure doit donc décider quand forcer la normalisation; quand brancher les lignes de code; quand forcer la collaboration de conception autour d’une expérience client unifiée; et quand laisser les équipes d’application suivre leur propre chemin. Si nous faisons simplement ce que chaque groupe exige de nous, nous créons plus de confusion et trop de représentations de données. Cela sent autant la politique que l’architecture.
• Interruptions exécutives. Une fois que nos dirigeants apprendront que nous avons formé une équipe Infrastructure, ils n’auront chacun que quelques idées que l’équipe pourra estimer et planifier. («Et si nous utilisons l’apprentissage automatique pour suggérer un mode de paiement basé sur l’adresse de livraison?») Et notre équipe d’infrastructure sera mise dans des situations de partenaire / client brûlantes. («Sephora utilisera notre plate-forme si nous pouvons prendre en charge leurs 460 000 SKU dans notre moteur de recommandations. Allez voir si nous pouvons le faire, ou ce qu’il faudrait.») Collectivement, l’équipe exécutive veut 200% de la capacité de chaque équipe.
• Alignement avec une stratégie plus large. La société souhaite se développer en Europe, ce qui nécessite une infrastructure GDPR essentielle. Mais notre équipe marketing actuelle (nord-américaine) pourrait stimuler l’engagement des fêtes avec quelques correctifs à notre API d’historique d’achat. Quelle est la bonne combinaison d’investissement à court terme et à long terme?
• Contexte / analyse économique lié au comportement des utilisateurs. Notre équipe se plaint du manque de contexte et d’une quantification de valeur peu claire. Des tickets non informatifs arrivent de la part de l’équipe du statut de la commande “Des temps de réponse plus rapides sur l’API des frais de port”, ce qui ne nous aide pas à comprendre les besoins réels, les seuils de réussite ou la valeur commerciale. Notre équipe Infrastructure a soif de plus de contexte, comme «Nos utilisateurs abandonnent les paniers d’achat car le temps d’attente pour afficher les frais d’expédition dépasse 3,5 secondes. Si nous pouvons raccourcir cela de 0,3 seconde, nous pouvons augmenter la conversion de 3 à 5%. Cela représente 6 à 10 millions de dollars par mois. “ Nous ne construirons pas exactement la bonne chose – ou nous ne serons pas ravis de le faire – à moins d’avoir une vue d’ensemble.
• Soutenir les initiatives multi-équipes. La plupart des gros efforts nécessitent une collaboration et des priorités partagées entre plusieurs équipes. Les chefs de produit de ces équipes font beaucoup de commerce de chevaux et de justification commerciale commune pour faire avancer les choses. Faute d’un chef de produit au sein de notre équipe Infrastructure, les décisions complexes sont prises sans représentation d’Infrastructure.

Etc.

Notez que les équipes techniques ont tendance à penser à ces conflits inévitables en termes purement techniques: si nous pouvions simplement définir plus précisément «infrastructure» et amener nos équipes consommatrices à attribuer une valeur économique exacte à chaque demande, nous pourrions calculer avec précision la priorité de tout et travailler uniquement sur les choses les plus précieuses. (Indice: des différences d’opinion honnêtes, des biais inconscients, des personnalités, la pression des ventes, des incitations mal alignées, l’optimisme des développeurs et des estimations de valeur extrêmement inexactes signifient que les feuilles de calcul sont insuffisantes.)

Et n’oubliez pas que nous n’avons embauché personne dans l’équipe de développement pour l’expertise nécessaire pour traiter ce type de questions. (Vous ne le croyez pas? Consultez vos descriptions de poste en ingénierie et votre processus d’entrevue pour avoir de l’expérience dans la négociation des priorités de produits entre équipes.) Les développeurs qui doivent résoudre ces problèmes (une) le faire mal par rapport à quelqu’un qui est chargé / formé / affecté / préparé à faire de la gestion des produits; b) ne veulent pas le faire; et (c) dépensera beaucoup plus de temps / d’énergie. Nous nous plaignons constamment de la pénurie de talents et réduisons la productivité du développement – annulant des réunions périodiques pour économiser 30 minutes / semaine – mais nous jetons des pistes d’ingénierie non formées / réticentes dans des eaux organisationnelles saccadées.

Mais c’est en grande partie ce que font les chefs de produit dans les grandes entreprises. Il est donc facile de voir comment un PM compétent rend immédiatement son équipe 10% plus productive. Qui, soit dit en passant, paie son salaire. Avec les avantages secondaires d’une équipe de développement plus heureuse, plus concentrée, avec moins d’interruptions et un contexte plus clair pour son travail. (Écoutez attentivement, et vous entendrez «une baisse du roulement du personnel clé de l’ingénierie».)

Un chef de produit solide aura l’équipe travaillant sur plus de choses les plus importantes. Ainsi, les objectifs de l’entreprise et les stratégies plus larges se réalisent mieux / plus tôt. Je dirais qu’une bonne gestion de produit offre 35% + de valeur stratégique et de résultats réels en plus à chaque équipe, par opposition à forcer les responsables techniques à faire leur propre politique et à hiérarchiser les équipes. Ergo: un chef de produit affecté à chaque équipe d’infrastructure vaut 2 à 4 développeurs.

Octet sonore

Les équipes de développement et leurs chefs de produit résolvent des problèmes adjacents mais différents. Si un flux de travail est suffisamment important pour mériter sa propre équipe de développement, il est suffisamment important pour désigner un chef de produit. Ensemble, nous résolvons ce qui doit être fait et comment le faire gracieusement.