3 discussions que vous devez être prêt à avoir avec votre équipe technique en tant que Product Owner

Être product owner ou manager au sein d’une équipe produit c’est essayer de prendre les bonnes décisions au quotidien pour construire un produit viable, qui apporte de la valeur aux utilisateurs. Dans le logiciel, cela implique d’une façon ou d’une autre de prendre en compte l’aspect technique du produit. Il y a toujours un débat autour du type du profil qui doit être recruté : issu de la tech? Venu d’une business school? Ou ayant un passé de designer? Ce n’est pas le débat que je veux ouvrir ici.

La seule chose dont je suis intimement persuadé, c’est que quelque soit l’origine du PO/PM, il est un outil de communication au service du client, du produit, de l’entreprise et de l’équipe. De fait, il est obligatoirement amené à échanger avec les équipes techniques. Si vous êtes PO/PM et que vous n’avez jamais d’échanges directs avec les développeurs et le tech lead de votre équipe, vous ratez quelque chose.

Les décisions techniques deviennent forcément stratégiques dans la vie de votre produit, et doivent être en adéquation avec les enjeux de votre entreprise. Ci-dessous, j’essaie de décrire quelques discussions que je considère importantes voir indispensables à avoir avec votre équipe technique. (Attention, les scénarios présentés sont simplifiés au possible et pas toujours exhaustifs)

Faisabilité Technique : « Tout est faisable, si vous avez le temps »

Fréquence : Souvent

Un scénario: «

PO : Yo la team ! On travaille sur une nouvelle fonctionnalité avec les UXs. Elle doit permettre à l’utilisateur de transformer les abeilles en papillons (Désolé pour cette feature). Vous auriez 10 min cet aprem ou demain pour en discuter?

TL : On a qu’à faire ça directement après le stand up, comme ça on est plus interrompu de la journée.

PO : Ok! Cool. … Donc je disais, on a cette nouvelle fonctionnalité, on a fait quelques maquettes avec les utilisateurs. Donc l’utilisateur, il sélectionne son abeille, choisit son type de papillon et ensuite il clique et la BIM, abeille transformée en papillon instantanément.

TL : Houla, on se calme. Instantanément, ca ne va pas être possible. En fait on a [insérer ici l’explication de la contrainte technique lambda] qui fait qu’on doit absolument attendre 3 min avant que l’abeille soit transformée.

PO : Ah mince? 3 minutes! C’est chaud. Il y a vraiment pas moyen?

DEV : Bah la franchement, non. Il faudrait faire ça autrement.

PO : Ok, cool. Merci la team. Est ce que l’un d’entre vous aurait 30min dans la semaine, pour voir si on peut construire une solution un peu différente? »

Discuter de la faisabilité technique d’une fonctionnalité devrait être régulier. En résumé, à chaque feature, il est important de discuter et d’échanger avec l’équipe pour comprendre les blocages qui peuvent naitre d’une évolution. D’une façon générale, il est rare qu’une fonctionnalité ne soit pas réalisable. C’est plus souvent une question de temps et de moyen que l’on souhaite accorder à cette fonctionnalité.

De plus, discuter de la faisabilité technique c’est un peu comme présenter des maquettes à des utilisateurs. Le plus tôt c’est fait, le mieux c’est.

Plusieurs raisons à ça:

• Tous les sujets ne sont pas traitables en 10 minutes (la majorité en fait ne le sont pas :D). Souvent votre équipe aura besoin de temps pour se plonger dans le code avant de vous donner une réponse. Alors au plus tôt ils pourront être au courant au mieux ce sera.

• Pouvoir changer votre fonctionnalité si elle est trop coûteuse. En effet, une fonctionnalité est créée si il y a une douleur ou un besoin chez les utilisateurs. Il existe des solutions différentes pour répondre à un besoin ou une douleur. Au plus tôt vous serez au courant, au mieux vous trouverez une réponse.

• Adapter votre roadmap. Disons que vous ne trouvez pas d’autres solutions, cette nouveauté vous allez devoir l’implémenter. Il est donc important d’être au courant le plus tôt possible pour prévenir le reste des parties prenantes. Et toutes celles des fonctionnalités à venir.

En fonction de votre équipe, il peut être nécessaire de ritualiser ces discussions. Par exemple, sur ma précédente mission, nous nous accordions 1h30 par sprint pour échanger à propos de la faisabilité technique des sujets à venir. Cependant, dans d’autres équipe, cela est fait par opportunisme. A chaque équipe de choisir ce qui lui convient.

Architecture Technique : Les décisions d’architecture sont des décisions business. Soyez en convaincu.

Fréquence : assez aléatoire

Un scénario: «

PO : Salut l’équipe, comme vous le savez on va lancer 2 nouveaux pays dans 4 mois, et il faut qu’on soit prêt au niveau du produit. Vous le sentez comment?

TL : Euh bah, ça dépend. On lance la Suisse et la Belgique? ou genre on lance l’Inde et la Chine?

PO : Plutôt l’Inde et la Belgique.

TL : Ah oui ça va pas le faire. Notre batch là il galère déjà à traiter nos données. Alors un pays comme l’Inde c’est mort. Si on veut lancer ces pays là, il faut modifier en profondeur ce traitement.

PO: C’est ce que je me disais aussi. En fait, on mise sur 200 000 nouveaux utilisateurs en plus dans les 3 mois qui suivent l’ouverture du pays. Et on table sur 2 millions dans un an. C’est un marché de ouf !

TL: Ok, alors ça va pas le faire du tout. On est encore sur notre architecture de bootstrapping. Là, c’est beaucoup plus sérieux. Il faut changer de paradigme. On va réfléchir à une nouvelle architecture et te faire une proposition, mais il faut qu’on se voit avant pour mieux considérer les enjeux.

PO : Ok, on peut essayer de se voir une 1h cette semaine et avoir une proposition pour la semaine prochaine?

TL : Euh je peux rien te promettre. On aura les premiers principes directeurs, mais ça risque de prendre un peu plus de temps pour avoir la version finale.

PO : Ca roule, je t’envoie une invite pour qu’on en parle. »

L’architecture technique est un terme qui peut parfois faire peur au gens pas ou peu technique mais ces décisions sont importantes pour votre produit.

Ce qu’il faut comprendre et retenir c’est que l’architecture est principalement une question de patterns et de paradigmes qui viennent répondre à des enjeux business comme par exemple la performance, la scalabilité, l’utilisabilité ou le traitement des données.

En fonction des changements de paradigmes business ou métiers auxquels est exposée votre entreprise et donc votre application, les bonnes décisions d’architectures doivent être prises.

Attention, ça ne veut pas dire que c’est à vous de prendre ces décisions, mais encore une fois votre rôle est celui de la communication. Il est important de vous assurer que l’équipe technique est au courant de ces enjeux suffisamment tôt, qu’elle les a bien assimilés, pour qu’elle puisse proposer et mettre en place les solutions adaptées.

Dette technique : « Tu te souviens quand tu nous a dit de faire ça rapidement? »

Fréquence: Espérez le moins souvent possible

Un scenario: «

PO : Ouuahh les gars, on est un peu à la bourre là. On avait dit au marketing et aux clients que cette fonctionnalité sortait cette semaine. Mais on n’aura pas fini en fait.

DEV: Nope, on a fait ce qu’on a pu mais là franchement, on livrera pas avant lundi. On avait plutôt bien estimé le travail au départ mais il y a eu l’incident de production et le bug qu’on a du corriger en urgence.

PO : Oui, je sais bien. J’en ai discuté avec le client déjà. Il n’y a pas un truc qu’on peut faire?

TL : Si, repousser la date de livraison, Normal. On fait ça proprement, comme d’hab. On est des craftsmen, pas des bouchers.

PO : Hum, c’est chaud. Sérieux, y’a pas moyen de livrer un truc plus rapidement?

TL : … Si si … on peut faire [insérer ici toute pratique de développement douteuse], ça va marcher mais ce sera crado. C’est de la dette qu’il va falloir traiter après la livraison

PO: Hum…genre, c’est dangereux à quel niveau?

TL : «C'est dangereux, car si on fait un truc sale et qu'on ne répare pas rapidement, la prochaine fois qu'on devra intervenir sur ce code on devra y passer beaucoup plus de temps, et ça peut engendrer des bugs dans les semaines à venir.

PO : OK. Bah faisons comme ça. Mais par contre la première chose qu’on fait après la livraison, c’est remettre le truc d’équerre. Est ce que ça vous va?

TL : Ok ok. On faisons comme ça. »

Dans ce cas, c’est ce que l’on peut appeler de la dette tactique. Dans d’autres situations ce sera de la dette tout simplement liée au vieillissement du logiciel, à des évolutions de manières de faire, à un changement de langage ou à une montée de version (Attention du coup c'est plutôt des problèmes de qualité. Je vous encourage à lire "Culture Code" - le dernier livre blanc d'OCTO. Le sujet y est abordé.).

Bref, la dette, ça fait aussi partie de votre produit. Et il est important de comprendre que l’équipe a parfois besoins de s’en occuper et de faire le ménage.

Quelques indices peuvent parfois sonner l’alerte : beaucoup de temps à sortir des fonctionnalités à priori simples , une augmentation de la fréquence d’apparition des bugs ou un TechLead qui fait la gueule ^^ . Votre rôle est aussi d’aider l’équipe à traiter cette dette et donc d’échanger avec eux régulièrement pour identifier ce qui doit être priorisé.

En conclusion : “ Communiquez avec votre équipe technique, transmettez leurs vos enjeux, écoutez leurs recommandations et donnez leur le temps de bien faire les choses.”

Quand je parle de discussion technique, je ne parle pas de ligne de code. Savoir comment le logiciel est implémenté à la ligne près n’a aucun intérêt pour le PO. Si vous avez la chance, comme moi, de travailler avec des personnes passionnées et avec l’envie de bien faire : faites confiance. Vous pouvez peut être influencer le processus (revue de code, pair programming, binômage peuvent être initiés grâce à vous) mais les propositions technologiques et le développement sont le travail de l’équipe technique, pas le vôtre.

Vous devez donc d’une part comprendre les contraintes et les limites des technologies de votre application pour anticiper certaines prises de décisions.

D’autre part, faire preuve de pédagogie pour transférer à votre équipe les contraintes UX et business auxquels ils doivent apporter des solutions technologiques.

Enfin faire en sorte de leur dégager l’espace et le temps pour vous assurez qu’ils puissent réaliser proprement ce pourquoi votre équipe est missionnée.

BONUS : Un vrai challenge pour l’équipe technique.

Il y a un dernier sujet à aborder, mais qui s’adresse avant tout au techlead et à l’équipe technique d’une façon générale. Comment se rendre compréhensible auprès du PO?

Les sujets techniques ont leur importance dans une équipe produit, comme je viens d’essayer de l’expliquer. Il est donc important que votre product owner puisse s’en imprégner, mais s’il vous plait … faites un petit effort. Mettez vous à niveau (c'est à dire tout en bas) et essayez d’être pédagogue lors de vos échanges, promis, on vous le rendra ^^.

Quelques exemples qui me viennent en tête:

• éviter de parler des outils ou des technologies, mais plutôt de ce qu’ils apportent au produit. (ex: parler de swagger au lieu de la documentation des APIs)
• éviter de parler des termes utilisés dans le code, mais utiliser les termes métiers (notamment lorsque vous codez en anglais)
• accepter que le PO vous dise « je comprends rien à ce que tu me racontes » et reformuler jusqu’à obtention d’un « AHHHHHH. C’est bon, j’ai compris »

Parlez en à votre PO, je suis sur qu’il a plein d’autre exemples à vous donner ! ^^

Si vous vous posez des questions à ce sujet, souhaitez proposer des alternatives ou si vous recherchez un Product Owner pour votre projet, n’hésitez pas à me contacter : aichane@octo.com ou sur twitter @AnaelIchane.

Enfin si vous avez apprécié cet article: likez, tweetez, commentez ou partagez sans états d’âmes.