Je m'appelle Maxim et je travaille depuis huit ans dans de grandes entreprises en tant qu'analyste d'affaires et propriétaire de produit. Aujourd'hui, je voudrais partager avec vous mes réflexions sur le développement de produits, organisé avec l'utilisation d'un grand nombre d'équipes de développement.
Ceux qui sont intéressés et désireux de parler de ce sujet - bienvenue sous cat.
Commençons par les grandes entreprises. Par grandes entreprises, j'entends des entreprises comptant des milliers de développeurs, testeurs, analystes, ingénieurs devops, propriétaires de produits et autres gestionnaires de personnel. Ce sont des dizaines de divisions, des centaines d'équipes, des hiérarchies complexes, des dépendances infinies et des domaines de responsabilité.
Entrer dans une telle entreprise, au début, il est difficile de s'y retrouver. Mais le temps passe, et maintenant vous pouvez tout à fait imaginer votre "île". En règle générale, ce sont:
- Un système ou un composant compréhensible qui est impliqué dans un processus métier très vaste et complexe;
- Le propriétaire du produit est une personne qui sait sans aucun doute où développer ce système;
- Un ensemble de documentation à divers degrés de pertinence;
- Une suite de tests, automatisés et pas très.
Semble familier?
Voici à quoi ressemble un système de développement logiciel typique et non le pire. Habituellement, les départements de développement des entreprises avec des produits à succès arrivent à cette forme dans 10-15 ans. Les produits à succès rapportent de l'argent, l'argent est investi dans le développement. Le développement se développe à pas de géant, il est mis à l'échelle de manière linéaire et arrive à une situation où les chefs de projet ne peuvent plus garder toutes les dépendances dans leur tête, de nombreuses équipes commencent à tirer la «couverture» sur elles-mêmes et, parfois, nuisent au produit plutôt que de le développer. Dans une telle situation, il est tout à fait normal qu'une équipe s'efforce d'atteindre son propre succès, ne craignant plus que ses collègues rencontrent des problèmes, et leur caractéristique commune ne sera pas livrée à cause de cela. Il est dans la nature des choses de développer la fonctionnalité que des parties prenantes infinies demandent le plus fort, et non celle dont les utilisateurs ont besoin.Le développement «sur la table» n'est pas rare. Le processus se poursuit - les exigences viennent, sont mises en œuvre, testées, livrées. Il est facile de cacher l'essentiel derrière un écran d'agitation - le développement de produits n'est pas aussi efficace qu'auparavant.
Pour comprendre cette perte d'efficacité, tournons-nous vers les classiques de la gestion de produit. Maintenant, il existe suffisamment d'écoles ou d'universités en ligne qui peuvent vous enseigner cette science pour un peu d'argent.
Ma petite liste si tu ne les connaissais pas
Donc, selon les "classiques", un produit est ce que les gens achètent. Les tâches d'un chef de produit sont de trouver le public cible, de déterminer le message de valeur, de sélectionner les canaux de vente appropriés, de réduire l'économie, de trouver des points de croissance, de trier toutes les hypothèses appropriées. Si nécessaire, modifiez l'idée, le public cible, les canaux, le message, le modèle commercial, le marché. Ou même tuer le produit s'il est clair qu'il n'a pas de perspectives prévisibles.
Cela ne ressemble pas à l'histoire ci-dessus, non?
Le fait est que, lorsque vous êtes une petite startup, tous les processus de développement de produits sont assez transparents et simples. Il est très facile de repérer le problème et de le résoudre. Il est facile de comprendre l'idée du produit. Il est facile de comprendre et de développer les fonctionnalités requises. Utilisateurs - les voici, à portée de main. Prod - le voici, avec toutes les métriques.
Cependant, le temps passe, le produit gagne des parts de marché, se développe en une ligne de produits, de plus en plus de développeurs sont embauchés, et avant que vous ne le sachiez, votre entreprise se transforme en un énorme fouillis de structures, d'intérêts et de responsabilités.
- Utilisateurs de produits personnalisés? Maintenant, vos propriétaires de produits ne s'en souviennent plus, ils se précipitent d'une partie prenante à une autre, essayant de comprendre quelles exigences saisir au début;
- L'économie de l'unité était-elle claire et transparente? Maintenant, les propriétaires du produit ne considèrent même pas PnL (Profit and Loss), chargeant toute l'équipe sur le plancher de sprint avec des côtés aux avantages douteux;
- Y avait-il une histoire de travail, une carte du parcours client et d'autres personnes? Maintenant, ils écrivent dans le magasin «En tant que product owner, je veux que cela se fasse parce que le service Opération et Maintenance en a besoin»;
- Y avait-il une compréhension de la responsabilité du résultat et des conditions? Maintenant, chaque équipe est pour elle-même, vos fonctionnalités seront livrées en production pour une version ou deux plus tard.
La complexité de la gestion du développement de produits à grande échelle augmente de façon exponentielle. Que faire?
La première chose qui vient à l'esprit pour la direction est que nous avons besoin d'un cadre magique qui fera fonctionner tout ce système complexe comme une montre suisse. Il y a une demande - il y a une offre. Je connais plusieurs de ces cadres qui, en théorie, peuvent faire face à la tâche à accomplir.
Sont-ils une «solution miracle»?
J'ai traversé plusieurs transformations commerciales où des coachs dorés ont été embauchés, les processus de gestion et de communication les plus modernes ont été introduits. Des milliers de personnes ont changé de poste du jour au lendemain et ont emménagé dans une nouvelle structure, une nouvelle équipe, de nouveaux processus, de nouveaux projets.
Et je peux dire ce qui suit:
- il est coûteux;
- ce n'est pas rapide;
- c'est très risqué;
- le succès ultime dépend fortement de la culture de l'entreprise. Si les gens comprennent et croient, le succès est probable.
Cette approche est-elle la seule correcte? Voyons ce que vous pouvez faire d'autre.
Je pense qu'il existe d'autres moyens de faire évoluer le développement de produits. Malheureusement, je n'ai pas d'instructions étape par étape pour vous, mais voici mes idées qui pourraient vous aider:
Produit . Le produit doit ajouter de la valeur. Considérez le zoo de vos systèmes et composants en termes de valeur. Mettez en évidence toutes les chaînes de valeur pour les clients finaux, les contreparties ou les tiers et divisez la carte du système par ces flux. Chaque propriétaire de produit doit avoir une chaîne complète de systèmes de valeur sous contrôle. Donnez-lui quelques analystes si la portée de la responsabilité est trop grande.
Métrique... Pour gérer, vous devez d'abord apprendre à mesurer. Chaque propriétaire de produit doit identifier des métriques pour son produit, sur la base desquelles il conduira le développement de ce produit.
Utilisateurs . Laissons de côté les parties prenantes. Seuls les utilisateurs peuvent donner une vraie idée de la valeur d'un produit. Le product owner doit être guidé par les résultats des entretiens et l'analyse des tickets de support dans leurs hypothèses.
Hypothèses . Finies les implémentations aveugles de la fonctionnalité. Chaque épopée ou fonctionnalité doit avoir des attentes quant à l'impact sur les métriques. Lors de la mise en œuvre des fonctionnalités et de leur test avec des tests A / B, les propriétaires de produits doivent comprendre si l'hypothèse a réussi ou non.
Coordination... Bien entendu, le travail de plusieurs produits doit être coordonné en fonction du cadre que vous choisissez. Cependant, vous ne devez pas transformer cette coordination en un conseil de responsabilité collective de chefs de produit.
Je pense que ce n'est qu'en maintenant les conditions décrites ci-dessus que vous pourrez faire évoluer la gestion des produits avec succès, et dans l'ensemble, peu importe le cadre que vous choisissez pour cette mise à l'échelle.