De nombreuses équipes IT agiles sont organisées en sprints et animées par un product owner. Celles qui veulent aller plus loin grâce au Lean management, se posent parfois la question du contenu de ce rôle du product owner versus celui de chief engineer, bien connu dans l’univers de l’amélioration continue.

Comme le montre le tableau ci-dessous, la différence entre le chief engineer et le product owner porte sur le niveau de séniorité, sur l’étendue du champ d’expertise technique et sur la globalité des responsabilités.

L’évolution du product owner peut le porter, s’il le souhaite et s’il s’en donne les moyens, à endosser à terme le costume du chief engineer.

Depuis plus de quinze ans chez Operae Partners, nous prenons en charge ces deux rôles, nous vous accompagnons sur leur mise en pratique et sur le passage de l’un à l’autre.

La mission

Product owner	Points de passage d’un rôle à l’autre	Chief engineer
	Maximiser la valeur du produit créé en réponse à un besoin client (*)

Le produit

Product owner	Points de passage d’un rôle à l’autre	Chief engineer
Le Product Owner s’occupe de créer un produit dans un cadre déjà connu, voire rôdé. Si le produit / service est nouveau, ni la technologie, ni les langages, ni les méthodes, ni les outils ni les usages ne le sont. A part le produit à réaliser, tout le reste est déjà connu, documenté ou à choisir sur étagère, parmi les préconisations des experts qui fourniront l’architecture, la pile technique, les règles de cyber-sécurité… dans lesquelles s’inscrire. Ce cadre de réalisation reste stable sur plusieurs années, et se trouve régulièrement remis en cause par une innovation technique majeure. Dans cet intervalle de quelques dizaines d’années, il est possible de capitaliser sur les savoirs acquis.	Il est garant de l’adéquation de son produit au besoin, et du bon atterrissage de son projet de bout en bout	A contrario, le Chief Engineer dirige une expédition exploratoire sous lettre de mission. Cartographe, il fait construire, formaliser et documenter par les équipes qu’il anime la connaissance autour de l’inconnu. Inconnu qu’il cherche à réduire et décrire suffisamment pour aboutir progressivement à un nouveau produit viable, construit avec des outils ou technologies eux aussi nouveaux, mal documentés ou non-expérimentés. Il porte la responsabilité de la description fonctionnelle, technique, d’architecture et d’infrastructure du produit cible, ainsi que des différentes étapes qui y conduiront itérativement à partir de la toute première : le MVP.

L’animation d’équipe

Product owner	Points de passage d’un rôle à l’autre	Chief engineer
Équipe projet de 8 à 12 personnes Il rédige lui-même les user stories fonctionnelles et devrait rédiger les cas de tests, il priorise et alimente le backlog, encadre les sprints (sprint planning, revue..) Il évalue lui-même et devrait faire évaluer par son équipe l’avancement du produit et la performance des sprints.   Il délègue au tech lead toutes les activités qui relèvent des aspects techniques : paramétrage, développement, intégration, Infrastructure, cybersécurité, montées d’environnements et mises en production, (ce qui peut le mettre en difficulté lorsque l’organisation se tourne vers un fonctionnement en équipe produit). Il intervient et porte la responsabilité de la complexité technique, au-delà de l’UX, des composants du produit à construire.	Il formalise et partage une vision, anime les parties prenantes : client, key user, métier, développeurs, ops.   Il conçoit et partage une roadmap produit.   Il met en place la résolution de problèmes par l’équipe.   Il co-construit et partage la vision du produit : key user, métier, développeurs, ops.   Il s’implique aux cotés des Tech Leads dans le pilotage quotidien/hebdo des DEV, se rend sur le gemba DEV.	Équipe de 12 à 15 personnes, élargie entre 15 et 150 contributeurs.   Il co-construit des indicateurs de succès, animés par les équipes.   Il anime la coordination des domaines fonctionnel, technique et réseau et infrastructure par l’obeya.   Il coordonne les intervenants experts, dont architectes, DBA, cybersécurité, métier, marketing, contrôle de gestion et finance. Il organise l’exploration et l’arbitrage de solutions techniques concurrentes. Il co-construit le Minimum Viable Product (MVP) et chaque étape itérative suivante vers le produit final. Il arbitre en dernier ressort dans le cadre de son budget et de sa lettre de mission.

Les attentes client et la valeur produit

Product owner	Points de passage d’un rôle à l’autre	Chief engineer
	Il capte et comprend, par le gemba sur l’usage, et le recueil de la voix du client, les attentes informulées et indispensables ainsi que leur raison d’être (**)

Les outils et la méthodologie

Product owner	Points de passage d’un rôle à l’autre	Chief engineer
Les trois outils clés du product owner sont la user story, le backlog et le kanban.	Les KPI et le management visuel	Les trois outils clés du chief engineer sont le gemba, le MVP et l’obeya.

(*) Maximiser la valeur du produit créé itérativement en réponse à un besoin client : le fait est qu’il s’agit bien de la valeur du point de vue du client, et que la première étape consiste à la comprendre et la capter. Une erreur très fréquente dans le monde de l’IT consiste à croire que la principale attente du client concerne la livraison de nouveaux projets, alors que l’analyse de milliers de voix du client /utilisateur à travers le temps démontre que leur toute première attente est la disponibilité et la stabilité du SI. La pyramide des attentes utilisateurs se trouve souvent inversée dans les DSI, avec une disponibilité et des demandes d’évolution souvent placées derrière les projets dans les priorités IT.

(**) Dans le secteur automobile, il s’agira par exemple de chauffer le plancher du véhicule au Canada (hivers très rigoureux), de disposer les commandes radio, chauffage et climatisation à l’arrière des voitures de luxe en Chine (ça n’est pas le propriétaire de la voiture qui est au volant), de fournir des sièges et des portes de taille XXL aux USA (50 % de la population est en surpoids).

Dans l’IT, il peut s’agir de fournir : aux data scientists des méta données et une cartographie dynamique en plus de la donnée brute (se concentrer sur la production de modèles prédictifs plutôt que sur la pêche aux données)  ; aux équipes de Développement ou de Recette, des environnements à jour en moins de 15 minutes au lieu de 15 jours (accélérer les tests et montée en production en limitant les attentes et le changement de contexte/d’activité) ; aux commerciaux et responsables de comptes client, des reportings BI en temps réel mis en forme directement par les utilisateurs (chacun sa manière, au moment où son client l’appelle).

Par Christian Ignace et Marc Legru