Au fil de ses 17 années chez Akuiteo, Yvan Boissaux n’a cessé de voir son rôle évoluer au gré de la croissance de l’entreprise et des besoins de ses collaborateurs. Il revient sur le parcours qui a fait de lui un véritable facilitateur des évolutions produit, à l’interface entre consultants et développeurs – le fameux Product Owner des méthodes agiles.
La fin des consultants qui codent
Chez Akuiteo, nous avons fonctionné pendant longtemps selon un modèle un peu « à la start-up » : les consultants touchaient à tout, même au développement ! Mais l’entreprise grossissant et l’outil devenant de plus en plus technique au fil des évolutions, il a fallu distinguer clairement les rôles.
Cette séparation des fonctions a parfois créé des frictions entre chefs de projet et développeurs, les premiers voyant plutôt les besoins du client, les seconds plutôt les problématiques techniques. Si le consultant est un expert des enjeux d’utilisation quotidienne de l’outil, le développeur doit de son côté anticiper tous les impacts du moindre changement dans le code informatique.
Lorsqu’un client explique, par exemple, « qu’il manque juste un petit bouton » pour améliorer telle ou telle fonctionnalité, le chef de projet comprend son besoin et le restitue au développeur. Mais il ne prend pas toujours la mesure de ce que ce « petit bouton » peut impliquer en termes de règles comptables, éventuellement de programmes mutualisés...
Inversement, le développeur ne voit pas forcément les enjeux de gestion derrière les problèmes rencontrés par les utilisateurs – une TVA mal calculée sur une facture, un petit montant à expliquer qui retarde une opération de clôture…
Découvrez le témoignage d'un éditeur de logiciels, client d'Akuiteo.
Réconcilier consulting et développement dans l’édition de logiciels
Akuiteo ressentait le besoin de créer un pont entre les deux fonctions. Grâce à mon ancienneté dans l’entreprise, je connaissais l’outil et ses fonctionnalités sur le bout des doigts. J’ai commencé comme chef de projet chez Akuiteo en 2000 – pendant plus de dix ans, j’allais chez les clients pour déployer et paramétrer notre ERP et former les utilisateurs. Je suis ensuite devenu directeur de projets et j’encadrais une équipe de consultants.
Et, il y a deux ans, j’ai cédé ma place à un collègue pour endosser un rôle plus transversal, celui de Project Management Officer (PMO). L’objectif était de faciliter la communication entre les équipes consulting et les équipes de développement : assurer ce lien nécéssitait une bonne expérience à la fois de l’outil et des besoins utilisateur.
À lire aussi : Comment renforcer la collaboration entre fonctions finance et métier ?
Au bout d’un an à naviguer entre les deux, nous avons décidé qu’il était plus pertinent que je me consacre uniquement à l’aide aux développeurs, fonction mobilisant plus de compétences techniques que l’encadrement des consultants.
Comment je suis devenu Product Owner
Je ne le savais pas encore mais, en m’orientant côté produit, en traduisant les besoins des clients en questions fonctionnelles, je me positionnais sur un poste défini par la méthode Scrum comme celui de Product Owner (PO).
Ce rôle est absolument stratégique chez les éditeurs de logiciel qui ont adopté une démarche agile. Mais, chez Akuiteo, le poste s’est créé naturellement, sans que l’on prenne vraiment conscience que nous étions en plein dans les bases de l’agilité.
En somme, je suis devenu PO par la force des choses, sans y avoir été explicitement formé ! Je complète le travail du Product Manager, qui se concentre sur la vision produit, l’innovation et les nouveaux usages. Le PO, lui, s’assure que ces évolutions respectent la cohérence globale de l’outil et alimente l’équipe de développement avec des demandes bien qualifiées.
Tout le monde y a trouvé son compte dans l’entreprise ! Les développeurs apprécient que je sois présent physiquement dans leur bureau : je peux leur répondre immédiatement s’ils ont une question sur une règle de gestion un peu complexe. Et je peux aussi comprendre les besoins des chefs de projet, m’assurer que les délais peuvent être tenus si un client demande une évolution prioritaire dans un planning projet à respecter.
À lire aussi : Pourquoi Akuiteo a pris le chemin de l'holacratie.
Alors que développeurs et consultants géraient jusqu’à récemment leurs problématiques, leurs échéances et leur stress respectifs, le Product Owner est désormais là pour désamorcer les incompréhensions mutuelles, fluidifier les échanges et jouer le rôle de modérateur entre les exigences du client et les contraintes techniques existantes. Pas étonnant qu’une des plus grandes qualités du PO soit la diplomatie !
À propos de l'auteur :
Par Julien Costerg
Directeur des opérations - Akuiteo SAS
