Blog
Comment le produit peut (et ne peut pas) accélérer le développement |
- 17 janvier 2021
- Publié par : nicolas
- Catégorie : Non classifié(e)


La moitié des appels que je reçois des PDG incluent des demandes de gestion de produit pour augmenter la productivité en ingénierie (aka Development aka Makers). Pour expédier plus de choses, plus rapidement. Pour atteindre plus de dates de feuille de route. Pour réduire un objectif financier fictif au coût par fonctionnalité. Pour obtenir plus pour moins.
Cela reflète une confusion sur ce que font les chefs de produit (et comment nous ajoutons vraiment de la valeur), et souvent une mauvaise définition des rôles où les chefs de produit sont également des chefs de projet / programme ou des responsables de l’ingénierie. Cela signale également un manque de confiance entre l’équipe de direction et l’organisation de développement: “Comment puis-je savoir que j’en tire pour mon argent de ce mystérieux processus? À quel point peut-il être difficile de prévoir avec précision les deux prochains trimestres? » Et reflétant les plaintes fréquentes des parties prenantes internes selon lesquelles chacune de leurs demandes / priorités ne reçoit pas suffisamment d’attention. (Indice: la somme de ces éléments indispensables de toute urgence est Débit de développement 20x, donc les plaintes de priorisation ne disparaissent jamais.)
Mais ce n’est pas le rôle du produit d’extraire plus de code de l’équipe de création (développeurs + designers + CloudOps + ingénierie de test + documentation technique) ou pour restructurer le processus de développement. C’est le travail de Product de tirer le meilleur parti de ce processus pour le client et de promouvoir une économie de produit saine. Découvrons les choses que les chefs de produit ne devraient pas faire, peuvent faire pour offrir plus de valeur, et reconnaissons que nos équipes de fabricants sont des artisans plutôt que des robots.
Pas utile / pas notre rôle
Pousser plus de choses sur la feuille de route. Nous savons depuis le 1970 que surcharger une équipe de développement réduit sa production totale. En moyenne, engager une équipe à 110% de sa capacité signifie obtenir moins EN TOTAL que 85% ou 90% de chargement. Sans relâche, nous ne pouvons pas gérer les surprises inévitables qui surgissent (sans surprise) dans la plupart des sprints: pannes du système, bogues difficiles à éliminer, urgences familiales, API des partenaires qui se comportent mal, démos clients, réunions RH sur les nouveaux avantages. Lorsque nous sommes surchargés, nous coupons les coins ronds et accumulons des dettes de produits.
- Imposant des outils de développement, processus ou normes de codage. Après trois décennies de création de logiciels B2B, j’ai beaucoup d’opinions. Mais mes chefs de produit et moi n’avons pas la possibilité de nous opposer au choix de l’équipe de GitHub contre GitLab contre Bitbucket contre SourceForge contre CVS / SVN. Si l’équipe préfère espaces sur les onglets, c’est leur appel.
- Réduire les estimations. L’estimation – grossissement des histoires, des épopées ou des tickets – est l’évaluation interne par l’équipe de la taille et de la difficulté relatives. Les personnes qui font le travail sont les meilleures personnes pour dimensionner le travail. Les chefs de produit peuvent avoir des questions ou des suggestions… mais les équipes de fabricants abandonnent rapidement les estimations lorsque nous les annulons. Je sais que je suis en eau profonde quand j’entends «Dites-moi simplement combien de temps les dirigeants pensent que cela devrait prendre.»
- Spécifications de commande et de contrôle. Nous embauchons les meilleurs développeurs, concepteurs et ingénieurs de test, en les payant généreusement. Les équipes de fabricants (collectivement) ont plus de cerveaux que les chefs de produit. Ne supposons donc pas que nous pouvons écrire des histoires, des spécifications ou des exigences parfaites pour qu’elles soient mises en œuvre exactement. Nous accueillons les questions, les alternatives et les disputes passionnées occasionnelles.
Moyens d’augmenter le débit effectif (vue Processus)
Il existe de nombreuses façons dont les chefs de produit peuvent obtenir plus de bonnes choses, par opposition à simplement plus de choses. En regardant le processus, cela comprend:
- Priorité impitoyablement au travail, nous faisons donc plus de ce qui est important. Notre entreprise et nos clients ont une liste infinie de demandes et un appétit vorace pour les nouvelles fonctionnalités, ce qui peut conduire au chaos. Les chefs de produit doivent donc être les champions de OU exclusif, parfois emballé comme “Oui, bien sûr, nous pourrions le faire si nous reportons / annulons InitiativeA et CommitmentB et UpdateC et HotFixD.”
- Ralentir les interrompt un peu. S’il ne s’agit pas d’un système P1 en panne, nous n’avons pas besoin d’interrompre l’équipe cette minute pour dimensionner quelque chose de nouveau. La plupart des urgences disparaissent d’elles-mêmes un jour plus tard. Regroupez les demandes intéressantes à passer devant l’équipe toutes les deux semaines.
- Communication claire et fréquente des objectifs et de la stratégie. Lorsque notre équipe comprend le contexte d’un problème et comment les utilisateurs utilisent notre logiciel, ils sont habilités à imaginer des solutions alternatives. Certains seront meilleurs ou plus rapides ou auront un impact plus important sur les KPI. Plutôt que de commander et contrôler, les bons chefs de produit veulent les meilleures réponses. Humblement, vous pouvez demander «Si c’est ce que nous voulons accomplir, qu’ai-je manqué? Comment pourrions-nous l’aborder autrement?
Forcer un peu de mou dans le plan. La plupart des fabricants sont optimistes et les horaires sont généralement en retard. Les systèmes plantent, les partenaires changent d’API, des failles de sécurité sont découvertes, des bogues insidieux échappent à la correction, nous apprenons ce qui se passe quand AWS East est hors ligne. (Comme chaque épisode de chaque émission de rénovation domiciliaire, nous découvrons de la moisissure dans le sous-sol ou des ratons laveurs dans le grenier et devons nous adapter.)
- Définition collaborative DONE. Les fabricants et les chefs de produit doivent s’entendre sur une définition générale du fait. Cela peut inclure des notes de mise à jour, des tests automatisés, des prix, des tests de performances et une session de formation pour l’équipe d’assistance. Faire cela une fois, de manière réfléchie, évite des dizaines d’arguments quant à savoir si nous pouvons lancer des logiciels non testés aux clients payants.
- Ne pas tout estimer. Parfois, la mise sur le marché veut que nous estimions les 300 principaux éléments du backlog pour les aider à se concentrer sur ce qui pourrait être le plus simple. Mais c’est un gaspillage complet au-delà des 2-3 prochains sprint. Le produit doit donc faire un tri qualitatif rapide (basé sur une grande expérience avec cette équipe / ce produit, vue stratégique, urgence agrégée, impact) pour obtenir une liste de deux ou trois sprints.
- Entonnoir les demandes de développement dans un seul système. Le support utilise ZenDesk et attribue des tickets à l’ingénierie. Les ventes se font sur SalesForce et attribuent des tickets à l’ingénierie. Le marketing crée des Powerpoints de nouveaux produits potentiels et envoie des decks à l’ingénierie. Research a une page UserVoice pour voter sur les éléments du backlog. Le produit est sur la carte du produit ou Aha! ou Pendo ou Roadmunk ou autre, et synchroniser les demandes dans Jira. Nous ne pouvons pas nous attendre à ce que notre équipe de fabricants se concentre sur ce qui est le plus important si la gestion des produits ne consolide pas les entrées et ne réduit pas le bruit.
- Surveiller le placage à l’or et le surinvestissement. Quelles capacités sont essentielles et stimuleront la croissance de l’année prochaine? (Nous devons donc fournir quelque chose de formidable, avec des tonnes de tests automatisés et de validation UX.) Quels sont les éléments de case à cocher que peu de clients utiliseront? (Nous pouvons faire moins, éliminer les complexités, surveiller l’utilisation en direct, ne pas nous engager dans la v2 et la v3.) Sans une orientation claire du produit, tout doit être parfait.
- Poliment mais implacablement poser des questions sur la valeur du client final dans les grands travaux d’architecture. Chaque réimplémentation sur laquelle j’ai même travaillé s’est déroulée très tardivement et la plupart ont échoué. Existe-t-il une approche progressive ou à moindre risque? Un 80/20 avec l’essentiel de la valeur?
Défendre les besoins humains de l’équipe (vue des personnes)
Nos créateurs ne font généralement pas de rapports via la gestion des produits: ce sont nos pairs, pas nos subalternes. Mais nous avons un rôle important à jouer pour les garder motivés, heureux, engagés et productifs. En réduisant le taux de désabonnement du personnel.
Il est facile de considérer le développement comme une série d’étapes génériques bien définies: suivez la recette et nous obtiendrons des produits. Cérémonie X, modèle Y, mêlez ceci, Kanban cela. (Non SAFe, s’il vous plaît!) Mais un logiciel de construction ne ressemble pas du tout à la construction de clôtures ou au creusement de fossés. C’est un sport d’équipe complexe et créatif joué par certaines des personnes les plus intelligentes de la planète. Et les grandes équipes de créateurs sont axées sur la mission: si nous pouvons les attirer, leur donner une compréhension viscérale profonde de ce que font nos utilisateurs finaux (et de ce qui frustre ou bloque les utilisateurs), nous nourrissons un véritable amour pour les personnes qui utilisent nos applications. Donc, connecter soigneusement les développeurs et les concepteurs directement aux expériences utilisateur réelles clarifie leur réflexion et stimule également leur enthousiasme. Les équipes engagées émotionnellement peuvent offrir deux fois la valeur réelle de la passivité peinture-par-numéro / faire-juste-ce-que-le-livre-dit / produit-a-toutes-les-réponses.
Façons d’encourager la cohésion de l’équipe et la passion des utilisateurs:
- Lier les résultats de l’équipe aux résultats du client / de l’entreprise. Lorsque nous vous proposons une nouvelle fonctionnalité qui permet de conclure davantage d’accords, transférez le crédit. Lorsque nous corrigeons un bogue qui réduit considérablement les tickets d’assistance entrants, demandez à l’équipe d’assistance de nous remercier. Quand nous avons un bon trimestre, trouvez des moyens de partager la victoire et applaudissez.
- Marchandisez le bon travail de nos équipes. Les groupes de commercialisation connaissent rarement les noms des créateurs et ne savent souvent pas ce qu’ils font vraiment. Et nos équipes veulent désespérément se sentir nécessaires et appréciées. Offrez donc aux créateurs eux-mêmes l’occasion de faire des démonstrations de travail au reste de l’entreprise. Remerciez-les par leur nom lors des réunions de direction. Traduisez sans cesse “ce que nous avons expédié” en “pourquoi cela nous fera gagner de l’argent” et “pourquoi les utilisateurs se réjouiront de cela” et “comment l’excellent travail de l’ingénierie frustrera nos concurrents.”
- Gérer ou faire remonter les problèmes qui sont hors de portée des décideurs. J’essaie de participer aux rétrospectives d’équipe quand je le peux, non pas pour réparer leurs processus, mais pour détecter les problèmes qu’ils ne peuvent pas résoudre eux-mêmes. Vous rencontrez des difficultés pour que Finance approuve un nouvel outil d’enregistrement de code? Expliquez-moi la logique, et je peux joindre un pseudo-retour sur investissement et faire pression pour approbation. Des équipes entières passent des heures, ce sont de grandes réunions improductives? Nous pouvons plaider pour des ordres du jour plus serrés ou des listes d’invitations plus petites lorsque cela a du sens.
Repoussez HARD contre les systèmes de récompense d’entreprise individuels; pousser plutôt pour les récompenses et les objectifs de l’équipe. Le développement logiciel est un sport d’équipe, ce qui est le contraire des systèmes de récompense des ventes des entreprises. Combattez les classements individuels classés par force au sein des équipes. Trouvez des moyens d’applaudir les plus récents, les plus jeunes ou les moins similaires aux côtés des architectes et des responsables technologiques. Organisez un soirée pizza à distance.
- Développer la bonne volonté entre les départements. Lorsque les équipes de vente / marketing dénoncent les décideurs (comme elles le font souvent), soyez leur allié et leur défenseur. De même, lorsque les équipes de développement minimisent le défi de vendre, de commercialiser ou de lever des capitaux, partagez certains des défis. La plupart du temps, nous ne voulons pas que nos développeurs envient le marketing, mais un certain respect réduit les frictions. Augmente la joie. Ne pouvons-nous pas tous nous entendre?
Il y a des tonnes d’emplois dans d’autres entreprises, y compris nos concurrents. Le produit contribue à garder notre équipe heureuse, concentrée, productive et cohésive afin qu’elle soit moins susceptible de répondre au prochain appel de recrutement.
Octet sonore
Les chefs de produit ne sont pas chargés d’accélérer le développement. Nous sommes responsables de tirer le meilleur parti de leurs efforts. Pour les débloquer lorsqu’ils sont bloqués. Et pour susciter leur enthousiasme.