Comment faire fonctionner la gestion de produits pour les systèmes d’entreprise


J’adore créer des systèmes d’entreprise, car vous travaillez quotidiennement avec vos clients / utilisateurs et vous voyez littéralement leur vie changer à mesure que vous publiez de nouvelles fonctionnalités. Dans mon cas, chez Zalando, ce sont des systèmes d’achat de mode, de gestion de la chaîne d’approvisionnement, de gestion des stocks et de processus d’approvisionnement à payer (par exemple, payer nos fournisseurs pour les marchandises que nous leur avons achetées). Mais la construction de bons systèmes d’entreprise est sujette à l’échec, comme l’a récemment souligné l’auteur et consultant en produits Sam McAfee.

Bien que la plupart des articles et des blogs sur la gestion des produits parlent de la gestion des produits pour les produits SaaS destinés aux consommateurs ou aux entreprises, j’ai constaté que bon nombre des méthodes et des idées discutées dans ces derniers peuvent également être appliquées au développement de logiciels d’entreprise destinés aux utilisateurs internes de votre entreprise. .

Cet article est une tentative de partager certaines des leçons que nous avons apprises chez Zalando. Nous sommes l’une des principales plates-formes de mode en ligne en Europe et au cours des dernières années, nous sommes passés d’une «configuration informatique interne» plus traditionnelle à une culture axée sur les produits qui développe des solutions d’entreprise sur mesure de pointe.

Autorisez vos équipes de systèmes d’entreprise à gérer un problème

Comme pour toute décision concernant un produit, la première étape pour trouver la meilleure solution consiste à maîtriser et à comprendre le problème. Dans une configuration informatique interne traditionnelle, une personne du «côté commercial» a une idée de ce qu’il faut améliorer. Souvent, cette idée comprend une description détaillée de la solution qu’ils souhaiteraient que le «service informatique implémente».

C’est là que les problèmes commencent généralement. Beaucoup de ces idées ne créent qu’une valeur limitée et, ensemble, elles ne forment pas une vision de produit cohérente. Et ce n’est pas une surprise; ces collègues connaissent leur métier mais ne sont pas des chefs de produits formés. Malheureusement, le «chef de produit» (souvent appelé «analyste commercial» dans une telle configuration) n’a pas le pouvoir de repousser de telles exigences, mais se concentre plutôt sur la traduction des exigences commerciales en une conception détaillée que les ingénieurs logiciels peuvent ensuite mettre en œuvre.

Chez Zalando, nous avons changé cela. Nous avons créé des équipes multidisciplinaires qui possèdent des KPI commerciaux spécifiques, ainsi que leurs utilisateurs internes. Par exemple, notre Competence Center Inventory Management est copropriétaire de la disponibilité des marchandises (un KPI important pour chaque détaillant) avec les planificateurs de marchandises. L’équipe est composée d’ingénieurs logiciels, de chefs de produit, de concepteurs de produits, de contrôleurs et d’analystes, qui travaillent en étroite collaboration avec nos 250 planificateurs de marchandises (leurs utilisateurs internes) et nos plus de 1500 fournisseurs pour identifier les plus grands leviers pour améliorer la disponibilité des marchandises (et les indicateurs de performance clés associés) ). Certains de ces leviers peuvent nécessiter des améliorations du système, d’autres non. Ils sont libres de décider sur quoi travailler ensuite. Ils sont également libres de décider quels systèmes construire en interne et où tirer parti des solutions externes. Ils ont juste besoin de s’assurer que les KPI dont ils sont copropriétaires s’améliorent; et leurs progrès sont passés en revue chaque trimestre.

Combler le fossé entre «Tech» et «Business»

La configuration ci-dessus a rendu encore plus important pour nous de briser les silos fonctionnels, plus spécifiquement entre les équipes commerciales (c’est-à-dire «l’entreprise») et les équipes techniques (ingénieurs, chefs de produit). C’était un gros défi pour nous. Lorsque nous avons commencé, nos équipes commerciales n’avaient jamais entendu parler d’agile ou de MVP – et souvent voyaient simplement «MVP» comme une excuse pour réduire les fonctionnalités qu’elles voulaient, ou «agile» comme une excuse pour ne pas pouvoir s’engager à des dates de sortie . De même, nos équipes techniques n’ont pas compris les principales décisions commerciales et la nécessité de planifier à l’avance. Par exemple, lorsque votre entreprise croît de 20 à 25% par an, savoir si un problème clé, qui crée beaucoup d’efforts manuels, sera résolu en six mois ou non, a des implications importantes sur le nombre de personnes dont vous avez besoin pour démarrer embauche aujourd’hui. De même, lorsque vous prévoyez un nouveau lancement de ligne d’activité (comme Beauty as a new category sur Zalando), et que vous devez préparer une grande campagne de marketing et acheter les marchandises pertinentes, le tout pour être mis en ligne au début d’une nouvelle saison sur neuf Dans quelques mois, vous avez besoin d’une forme d’engagement pour que les fonctionnalités système requises soient disponibles d’ici là. Nous avons constaté que l’équipe technique rejetterait les délais, car selon eux, ils contredisaient une approche agile. Il nous fallait littéralement rapprocher deux mondes différents.

Comment avons-nous procédé? D’un point de vue organisationnel, nous avons complètement fusionné le «business» avec les équipes «IT» (nous avons utilisé la terminologie «la technologie est partout»). Nous n’avons plus aujourd’hui une seule grande organisation informatique monolithique, mais nous avons formé de plus petites unités, où les équipes commerciales et technologiques relèvent des mêmes hauts dirigeants. Dans le même temps, nous avons beaucoup investi dans le renforcement de la communauté technologique globale en créant des guildes ou des groupes d’intérêt spécifiques à un sujet, et d’autres moyens, tels que des discussions techniques inter-équipes. Nous avons également investi dans la formation de nos leaders commerciaux aux concepts technologiques de base, tels que le développement agile, les MVP et l’importance de ne pas accumuler de dette technique.

À un niveau plus opérationnel, nous visons à ce que tous les collègues de nos équipes de systèmes d’entreprise (ingénieurs, concepteurs de produits, analystes, chefs de produit) effectuent régulièrement des stages avec leurs utilisateurs. Cela aide grandement à créer un réseau et améliore la compréhension des problèmes commerciaux. Nous avons construit des communautés d’utilisateurs clés très actives autour de tous nos systèmes, et utilisons ces communautés pour nous aider à aligner régulièrement notre arriéré de fonctionnalités et nos priorités, généralement tous les mois. Nous veillons également à ce que les utilisateurs soient toujours présents dans les revues de sprint. De plus, nous organisons régulièrement des échanges informels entre disciplines à travers des déjeuners aléatoires et d’autres événements.

Recrutez et formez les bons chefs de produit

Vous pensez peut-être que tout cela est évident et vous avez raison. Cependant, recruter et former le bon type de chef de produit pour ce type de rôle interne n’est pas simple, et je dirais même plus difficile que de recruter et de former des chefs de produit pour d’autres rôles de gestion de produit.

Premièrement, ils doivent être intéressés par la refonte et l’amélioration des processus d’affaires internes et des KPI, un ensemble de compétences et d’intérêt que tous les chefs de produits n’apportent pas. Deuxièmement, ils doivent être excellents dans la gestion du changement. Lorsque vous créez des applications destinées aux consommateurs, le consommateur les obtient ou les quitte. Avec les systèmes internes (et un public captif), vous pouvez obtenir plus d’impact lorsque vous combinez un changement de système avec un changement de processus, c’est-à-dire un changement de «comment nous faisons les choses» (mais cela nécessite nécessairement de rechercher et d’obtenir l’adhésion de nombreuses parties prenantes ). Cela signifie que les chefs de produit pour les systèmes d’entreprise internes passeront beaucoup de temps avec les utilisateurs, les accompagnant tout au long du voyage, organisant une formation système et obtenant l’adhésion de leurs utilisateurs pour la nouvelle solution.

Enfin, nos chefs de produits doivent prendre des décisions de faire ou acheter et basculer entre le développement d’un système en interne au sein d’une équipe agile et la mise en œuvre d’une solution externe aux côtés d’un intégrateur de systèmes. Traditionnellement, ces deux rôles sont différents avec des ensembles de compétences différents. Chez Zalando, nous voulons que nos chefs de produit soient responsables du problème et le résolvent de la meilleure façon possible, et ils ne peuvent le faire que s’ils savent utiliser des solutions internes et externes pour résoudre ce problème.

Bien sûr, chacun de nos chefs de produits doit également maîtriser les principales méthodologies de gestion de produits pour découvrir, définir, concevoir et fournir les bonnes solutions pour nos utilisateurs et problèmes. Pour ce faire, nous travaillons régulièrement avec des outils, tels que des communiqués de presse, des pré-mortems, des user story maps, des sprints de conception (que nous avons légèrement modifiés), des MVP et différentes manières de hiérarchiser les problèmes et les solutions.

Alors, où trouvons-nous ces chefs de produit uniques? Eh bien, il semble (encore) qu’il n’y ait qu’un petit nombre de chefs de produit qui apportent l’ensemble des compétences que nous recherchons. Par conséquent, nous recrutons des personnes dans une équipe commerciale et leur enseignons la gestion des produits, ou recrutons des chefs de produit (destinés aux consommateurs) et leur permettons d’acquérir les compétences supplémentaires requises. Heureusement, nous avons maintenant une assez grande communauté de gestion de produits où les collègues peuvent échanger leurs meilleures pratiques et s’entraider. Si vous partez de zéro, je vous suggère de faire ce que nous avons fait il y a quelques années: réunir une poignée de personnes intelligentes avec des profils différents et les faire apprendre les unes des autres, soutenues par un programme de gestion de produits plus formel.

Nous apprenons encore

Bien sûr, je pourrais entrer dans beaucoup plus de détails, mais je vais le laisser ici pour l’instant. J’aimerais entendre les commentaires de la communauté des produits de systèmes internes. Si vous avez des enseignements à partager, veuillez également rédiger un article; nous ne faisons que commencer!





Source

  • Partager cet article

Laisser un commentaire