Cet article a été réalisé suite à notre meetup “Product Manager vs Tech : travail sous haute tension ?!” animé par Victor Billette de Villemeur, PM chez L’Oréal et Frédéric Arnal, Coach Agile chez Daveo, dont le replay est disponible ci-dessous.
Pour lire l’article, rendez-vous sous la vidéo.
« La roadmap n’est jamais respectée,
Mon projet n’est jamais priorisé,
Il y a trop de bugs,
La feature n’est pas telle qu’on l’attendait… »
On s’arrête là, mais la liste est longue.
Des retours que vous avez forcément déjà entendus si vous êtes Tech ou PM.
Tech VS PM ? Devons-nous les opposer ? Ou plutôt les réunir ?
Dans cet article, nous tenterons de comprendre les tensions entre ces deux rôles qui ont une parfaite complémentarité et que l’on a parfois tendance à oublier. Nous reviendrons sur la naissance du mouvement agile et nous tenterons d’apporter des solutions pour créer une bonne collaboration entre les équipes.
Retour aux sources sur le mouvement agile, la méthode Scrum et l’eXtreme Programming
À partir des années 1980, l’utilisation des ordinateurs fait son apparition dans le monde professionnel. Peu à peu, de nouvelles idées émergent, dont notamment Scrum (1993), l’eXtreme Programming (1996) et le Manifeste Agile (2001).
Scrum – 1993 – Le framework très processé
Scrum vise à fournir une structure claire et flexible pour la gestion de projet, qui peut facilement s’adapter aux changements et aux incertitudes fréquentes dans les projets de développement logiciel. Cette méthode est mieux alignée sur les systèmes de croyances permettant une division du travail.
Scrum est un cadre de travail très adapté à des environnements complexes. En le mettant en pratique, les équipes vont apprendre, grâce à l’empirisme et à la chasse aux gaspillages à s’adapter aux changements et à négocier les incertitudes.
Très procéssé, il est moins radical en apparence que d’autres approches agiles. Les structures traditionnelles, où la culture de la division du travail est présente, ont peut se projeter assez facilement. Les rôles de Product Owner, Scrum Master, développeur, sont assez proches de leur organisation initiale. Il est le cadre de travail agile le plus utilisé au monde. Cependant, sa force fait aussi sa faiblesse et il n’est pas rare d’observer des tensions non constructives entre les rôles de Product Owner et de développeur, comme il y en avait avant entre les fonctionnels et les développeurs.
Tentative de la pratique XP (eXtreme Programming) – 1996
L’eXtreme Programming (XP) est une approche de développement logiciel qui met l’accent sur des itérations courtes et fréquentes, la communication en face à face et des tests automatisés exhaustifs. L’objectif de l’XP est d’améliorer la qualité du logiciel en s’assurant que les exigences du client sont clairement définies et que le code produit répond à ces exigences. S’il est largement moins utilisé que Scrum, il a cependant donné des pratiques qui sont des références comme les User Stories ou le Craft coté développement.
Le concept de l’agilité – 2001
L’agilité est née dans le domaine du développement logiciel pour contrer les approches traditionnelles de gestion de projets qui étaient vues comme rigides et inadaptées aux imprévus. Un groupe de développeurs de logiciel s’est alors réuni pour discuter de ces problèmes et ont publié en 2001 les « Quatre valeurs fondamentales de l’agilité » et les « Douze principes de l’agilité » dans un manifeste appelé le « Manifeste pour l’agilité ». Depuis, l’agilité est devenue une approche populaire pour la gestion de projet dans de nombreux domaines dont principalement le domaine du développement de logiciel.
L’agilité est un modèle de développement de produits qui vise à maximiser la vitesse et la flexibilité en répondant rapidement aux changements des utilisateurs. Dans un environnement agile, les équipes de développement et les Product Managers travaillent ensemble de manière plus collaborative et plus flexible pour atteindre les objectifs commerciaux qui sont fixés et par conséquent offrir une expérience utilisateur exceptionnelle.
Pourquoi l’agile ne marche pas en général ?
Il est difficile de dire que l’agile ne fonctionne pas en général, car il s’agit d’une approche de gestion de projet qui a été adoptée avec succès par de nombreuses entreprises dans le monde entier. Cependant, il est vrai que l’adoption de l’agile peut être difficile et qu’elle peut ne pas toujours donner les résultats souhaités.
Voici quelques raisons pour lesquelles l’agile pourrait ne pas fonctionner dans certaines entreprises :
Culture de l’entreprise :
L’agile nécessite une culture de collaboration et de transparence, ce qui peut être difficile à instaurer dans certaines entreprises qui sont habituées à un mode de travail plus traditionnel.
Manque d’expertise technique :
Pour faire de l’agilité une réussite, il est important que les équipes soient composées de membres qualifiés et expérimentés. Si les équipes ne disposent pas des compétences techniques nécessaires, elles peuvent rencontrer des difficultés à mettre en œuvre le principe de manière efficace.
Manque de focus sur l’utilisateur :
L’agile met l’accent sur la création de valeur pour l’utilisateur final, mais si l’entreprise ne consacre pas suffisamment de temps et d’efforts à comprendre les besoins et les attentes de ses utilisateurs, elle peut ne pas être en mesure de créer des produits et des services qui répondent à leurs besoins.
Il est important de noter que ces problèmes ne sont pas exclusifs à l’agile et peuvent également affecter d’autres approches de gestion de projet.
Pour réussir, il est important de s’assurer que l’entreprise a une culture appropriée, dispose des compétences techniques nécessaires et se concentre sur la création de valeur pour les utilisateurs.
Comment faire de l’agilité une réussite ? Et quelles sont les pistes pour une meilleure collaboration entre le Product Manager et les Tech ?
Il est courant de constater que les équipes de développement et les Product Managers sont en tension, en raison de la nature de leurs rôles différents. Les équipes de développement sont souvent concentrées sur la création de produits techniques et fonctionnels, tandis que les Product Managers sont chargés de déterminer les fonctionnalités et les priorités en fonction des objectifs commerciaux et de l’expérience utilisateur.
Pour améliorer cela, il peut être utile de veiller à ce que les deux parties comprennent les objectifs et les priorités de l’autre, créer des opportunités de collaboration et de communication régulières, afin de résoudre les problèmes et les désaccords avant qu’ils ne deviennent trop importants.
De plus, il peut être bénéfique de veiller à ce que les membres des équipes de développement comprennent l’importance de l’expérience utilisateur et des objectifs commerciaux, et que les Product Managers comprennent les contraintes techniques et les délais de développement.
Quels sont les éléments à prendre en compte pour faire de l’agilité une réussite et favoriser une collaboration efficace entre les profils produit et les développeurs ?
Améliorer la communication et la collaboration :
Il est important de créer un environnement de travail qui encourage la communication ouverte et la collaboration. Cela peut inclure des réunions régulières de l’équipe, la mise en place de canaux de communication formels et informels et l’utilisation d’outils de collaboration en ligne pour faciliter la communication à distance.
Encourager la participation de tous les membres de l’équipe :
l’agile met l’accent sur la participation de tous les membres de l’équipe dans le processus de prise de décision. Il est donc important de s’assurer que les profils product et les développeurs sont impliqués dans les discussions et les décisions qui affectent leur travail.
Favoriser la transparence :
l’agile met l’accent sur la transparence et la visibilité. Il est donc important de s’assurer que tous les membres de l’équipe ont accès aux informations dont ils ont besoin pour travailler de manière efficace et de veiller à ce que les objectifs et les priorités de l’équipe soient clairement communiqués.
Mettre en place l’apprentissage continu :
l’agile est basé sur le principe de l’apprentissage continu et de l’amélioration continue. Il est donc important de s’assurer que les membres de l’équipe ont les ressources et le soutien nécessaires pour améliorer constamment leurs compétences et leur connaissance de l’agile.
Et le cloud dans tout ça ?
Le cloud amène à se poser de nombreuses questions : comment peut-on être toujours plus près de nos clients ? Dans un monde qui évolue très rapidement, où la transformation numérique guide nos actions : comment le cloud permet de décomplexifier la technologie en la rendant la plus simple possible ? Comment permet-il d’être réactif et de récupérer rapidement des données ? Comment le cloud permet-il de réduire drastiquement les coûts d’investissement dans une entreprise ? Et enfin, comment permet-il aux entreprises de répondre aux enjeux éco-responsables, notamment avec le cloud vert ?
Le cloud offre un panel de fonctionnalités ouvrant sur des innovations spectaculaires. Il donne accès à un nombre incalculable de documentation et de formation sur les providers par exemple, qui permet au Product de prendre conscience des éléments technique, et inversement avec les développeurs pour les éléments commerciaux. Le Cloud représente l’opportunité de prendre conscience des enjeux d’investissement techniques.
Dans un monde de plus en plus digitalisé, il devient impératif aux Product Managers de se former à la technique, surtout lorsqu’on constate que le Cloud est en train de prendre une place importante dans la culture d’entreprise. Dès lors, il est nécessaire de comprendre les nombreux enjeux qui se cache derrière ces aspects techniques dans le but de bien challenger son équipe et tirer le meilleur parti du Cloud.
Le rôle du Chief Product & Technology Officer permet-il de répondre à ces enjeux ?
Le Chief Product and Technology Officer (CPTO) est responsable de la stratégie produit et technologique. Il joue un rôle important dans la gestion des relations entre les profils product et techniques en veillant à ce que les objectifs et les priorités de l’équipe soient clairement communiqués et en encourageant la participation de tous les membres de l’équipe dans les discussions et les décisions qui affectent leur travail. En favorisant la communication et la collaboration et en encourageant l’apprentissage continu, le CPTO ou CTPO peut aider à renforcer la collaboration entre les profils.
Le Chief Product and Technology Officer s’assure de créer une bonne synergie permettant aux collectifs d’aller dans la bonne direction, en mettant toujours le client au centre des décisions.
Chief Technology & Product Officer (CTPO) ou Chief Product & Technology Officer (CPTO) ?
Quel est le terme le plus approprié quand on parle de cette fonction, à cheval entre le produit et la tech ? Il n’y en a pas réellement. Tout dépend de la nature de l’entreprise et de la stratégie qu’elle prend. Si elle est plus orientée tech ou plus orientée product, le CPTO ou CTPO sera issu d’un parcours différent (plutôt d’une formation dev ou d’une formation product) mais la finalité reste la même.
Par exemple, si une entreprise vend un produit, nous employons le terme de CPTO (Chief Product & Technology Offcier) mais à contrario, si l’entreprise vend des logiciels, nous parlons de CTPO (Chief Technology & Product Officer)
Pour aller plus loin, découvrez nos autres contenus sur le sujet :
- CPTO : un métier hybride entre la tech et le produit favorisé par le cloud ?
- Episode 2. Sans prise de Tech – [Future of Work] Naissance d’un nouveau rôle : le Chief Product and Technology Officer
