[SCRUM WEEK] Dans la peau d'un Product Owner

[SCRUM WEEK] Dans la peau d'un Product Owner

Publié le : 22/08/2017 22 août Août 2017
RG System lance sa Scrum Week et met à l'honneur notre Team Scrum pendant 1 semaine ! Nous vous proposons de découvrir chaque jour un de nos acteurs Scrum au sein de RG System, et on continue en ce mardi avec Arnaud, notre Product Owner !
 

Bonjour Arnaud ! Qui es-tu ?

Je suis Arnaud LOPEZ, Product Owner chez RG System depuis décembre 2016. J’ai un double cursus : j’ai commencé par faire des études en électronique et ensuite j’ai poursuivi sur un Master en création d’entreprise innovante et management de projet innovant. Le management de projet innovant correspond bien au profil de Product Owner et grâce à mes différentes expériences professionnelles, j’ai développé un background développement web et applications. Ce qui m’a toujours intéressé c’est le produit. Pouvoir changer la vie des gens grâce au produit que tu crées et qui apporte une vraie plus-value aux gens qui l’utilisent, c’est vraiment génial ! Et aussi construire : manager la construction, construire un produit, le faire évoluer jour après jour, c’est ce qui me plait dans mon métier.
 

Être Product Owner chez RG System, ça consiste en quoi ?

Parfois on peut penser que je suis le secrétaire des développeurs parce que je suis en relation constante avec le client final, celui qui utilise le produit au quotidien, mais aussi Grégory, le Client RG au sens Scrum du terme, qui attend également de nouvelles fonctionnalités. J’échange aussi beaucoup avec le service commercial, qui remonte également les nouvelles fonctionnalités que nos clients et prospects souhaitent que nous développions, et bien sûr le support technique qui est plus axé sur la résolution des bugs. Je me considère un peu comme un chef d’orchestre et mon rôle est de prioriser au mieux les développements pour satisfaire nos clients et m’assurer que le ROI de chaque client orchestré soit positif. Et je ne parle pas que d’un ROI financier. Par exemple le ROI du support technique, ça va être le nombre d’appels qui diminue si un bug est résolu. Enfin, je dois aussi prendre en compte les besoins de l’équipe de dev’ qui doit réaliser des développements spécifiques pour débloquer la réalisation de nouvelles fonctionnalités, mais aussi des développements techniques pour éviter que le produit ne devienne obsolète.
 

De quoi est fait ton quotidien ?

Mon quotidien est fait de beaucoup d’interactions avec différentes parties donc, à commencer par le client final dont j’écoute les besoins et à qui je dois également expliquer certains éléments techniques, comme c’est le cas pour la mise en place d’un branding par exemple. Je fais aussi régulièrement le point avec l’équipe de développement, sur des maquettes, des fonctionnalités en cours de développement ou même en amont de création de story si j’ai besoin de comprendre les implications techniques avant de pouvoir bien la prioriser. Le service commercial me permet également de savoir quelles sont les attentes commerciales et je me tourne vers le support technique pour savoir quelles sont les remontées clients en termes de problèmes fonctionnels. Enfin je m’intéresse beaucoup aux solutions concurrentes pour voir quelles sont les tendances du marché et comprendre les choix effectués sur certaines solutions.
 

Quel est ton rôle dans l'organisation Scrum ?

Mon rôle principal est la définition des stories pour l’engagement du sprint. Suite aux échanges que j’ai eu avec le client final et les différents services au sein de RG, je peux définir les fonctionnalités prioritaires à développer. Je travaille ensuite avec le Scrum Master sur la planification de l’engagement et vient ensuite l’étape de conception. Les stories priorisées sont passées en revue une par une, on fait le point sur la manière de les développer et on évalue leur ROI : le temps pris par l’équipe de développement versus les ventes qui seront permises grâce à la réalisation de la story. Chez RG System on prend un jour complet de conception pour définir comment la story va être architecturée.

Une fois le sprint priorisé, je suis également en charge du Scrum Board que je mets à jour après l’engagement. Je prends les stories créées, je les imprime puis je découpe chaque story en tâches distinctes que je colle ensuite au Scrum Board. Après, au quotidien, chaque développeur met à jour ses stories sur le tableau afin que tout le monde ait une vue de l’état d’avancement du sprint. Le dernier jour du sprint, je dois valider les stories qui sont dans la colonne DONE. J’interviens quand même en amont pour évaluer l’avancement de la story afin d’éviter de tout refuser le dernier jour de sprint. Si une story n’est pas validée, elle retourne en WIP, puis en REVIEW, et de retour en DONE pour validation. C’est donc mon rôle de ne pas valider une story si, à mon sens, elle n’est pas assez développée ou pas fonctionnelle pour le client.

Je suis aussi en charge d’organiser les événements liés à l’organisation Scrum : les planifications de sprint donc, les revues de sprint et la rétrospective. J’anime la revue de sprint avec le Scrum Master, j’essaie de démocratiser un maximum les fonctionnalités présentées quand le Scrum Master va lui faire un focus plus fonctionnel et au besoin technique. C’est l’occasion de valider avec l’équipe RG System que la story répond bien aux attentes de chaque client orchestré. Une fois les stories validées, j’intègre au sprint prochain une story de mise en production qui permet de rendre les fonctionnalités développées disponible à l’utilisateur final sur le Dashboard. Enfin, je participe également à la rétrospective, l’occasion de faire un point avec l’équipe Scrum sur les deux semaines de sprint écoulées pour parler du ressenti de chacun et essayer de comprendre ce qui n’a pas fonctionné, toujours dans le but d’améliorer un peu plus le process Scrum mis en place. Globalement, le but du Scrum c’est d’orchestrer les visions de chacun et échanger ensemble afin de trouver une vision commune, et c’est mon rôle d’orchestrer cette vision.
 

Quels sont les challenges que tu rencontres chez RG System aujourd’hui ?

Mon premier challenge c’est d’arriver à prendre assez de recul pour me positionner sur le futur et définir la vision à adopter : quelles seront les prochains thèmes à aborder, quels seront les prochains défis etc. Je dois être en mesure de justifier chaque choix en sachant ce qu’il implique. En tant que Product Owner, c’est important d’avoir une vision complète, de tous les enjeux de la société et des problématiques de chacun. Comme je suis au cœur des stories et de la production de l’entreprise, je dois connaître les attentes de chacun et estimer le poids de ces attentes. Je dois suivre la stratégie globale de l’entreprise pour rester en phase avec les autres processus et adapter mes ressources, notamment humaines, pour fournir des développements plus poussés et ainsi suivre la cadence imposée par notre croissance actuelle.
 

Pour toi, quelles sont les compétences nécessaires sur ce poste ?

Pour être un bon PO, il est nécessaire d’avoir un certain background technique, surtout chez RG System où les technologies utilisées sont très poussées. Il faut avoir des connaissances réseaux d’administrateur système, mais aussi des compétences en développement pour comprendre comment le projet se structure et savoir de quoi on parle : fonctionnement des API, comment fonctionne un serveur, comment une application web est structurée, comment elle communique, comment fonctionne le web en général etc. En relation constante avec les clients, de bonnes compétences en communication sont aussi nécessaires.
 

Qu’est-ce que tu préfères sur ton poste de Product Owner ?

Le point numéro un c’est l’équipe ! Nous avons tous le même état d’esprit, nous avons tous à cœur d’apporter notre pierre à l’édifice dans un but commun, je me sens vraiment dans mon milieu. On a tous cette culture d’avoir envie de faire, de fouiller pour faire du mieux possible et de comprendre pourquoi on le fait. C’est super d’être avec des gens qui veulent toujours aller au bout des choses !
Le deuxième point c’est le niveau d’expertise de chacun. Côté développement on est expert sur chaque sujet, mais il en va de même avec les équipes support et commerce qui sont vraiment à l’aise avec le produit.
Et le dernier point c’est la liberté dont nous bénéficions tous. On se structure soit même, et j’ai la chance sur mon poste de pouvoir par exemple passer du temps sur une thématique très spécifique si j’ai besoin de bien la comprendre pour aller plus loin, même si le ROI n’est pas évident de prime abord. A mon niveau, je ne fais pas partie d’un processus spécifique ce qui me confère plus de liberté.


Cet article vous a plu ? Découvrez les autres posts dédiés aux autres rôles Scrum au sein de RG System !

Historique

<< < 1 2 3 4 5 6 7 ... > >>
Information sur les cookies
Nous avons recours à des cookies techniques pour assurer le bon fonctionnement du site, nous utilisons également des cookies soumis à votre consentement pour collecter des statistiques de visite.
Cliquez ci-dessous sur « ACCEPTER » pour accepter le dépôt de l'ensemble des cookies ou sur « CONFIGURER » pour choisir quels cookies nécessitant votre consentement seront déposés (cookies statistiques), avant de continuer votre visite du site. Plus d'informations
 
ACCEPTER CONFIGURER REFUSER
Gestion des cookies

Les cookies sont des fichiers textes stockés par votre navigateur et utilisés à des fins statistiques ou pour le fonctionnement de certains modules d'identification par exemple.
Ces fichiers ne sont pas dangereux pour votre périphérique et ne sont pas utilisés pour collecter des données personnelles.
Le présent site utilise des cookies d'identification, d'authentification ou de load-balancing ne nécessitant pas de consentement préalable, et des cookies d'analyse de mesure d'audience nécessitant votre consentement en application des textes régissant la protection des données personnelles.
Vous pouvez configurer la mise en place de ces cookies en utilisant les paramètres ci-dessous.
Nous vous informons qu'en cas de blocage de ces cookies certaines fonctionnalités du site peuvent devenir indisponibles.
Google Analytics est un outil de mesure d'audience.
Les cookies déposés par ce service sont utilisés pour recueillir des statistiques de visites anonymes à fin de mesurer, par exemple, le nombre de visistes et de pages vues.
Ces données permettent notamment de suivre la popularité du site, de détecter d'éventuels problèmes de navigation, d'améliorer son ergonomie et donc l'expérience des utilisateurs.