Comment planifier les risques produit ?

Bonne nouvelle, planifier les risques produit est une chose extrêmement simple car pour une fois cela ne vous demande pas de travailler dans l’urgence.

Mauvaise nouvelle, la plupart des product owners ne les anticipent pas.

Après les 2 récents articles sur la priorisation, je termine sur un point souvent oublié : planifier les risques.

Dans ce format court, je vous explique :

La définition d’un risque produit
Comment les planifier ?

C’est quoi un risque produit ?

Avant d’épiloguer sur la définition, voici en très bref ce qui n’est pas considéré comme un risque produit:

Un bug
Une fonctionnalité à développer

Maintenant que c’est clair, voici ce que j’entends par un risque produit

“Un risque produit est un danger externe qui va survenir à plus ou moins long terme et que vous devez prendre en compte pour continuer à opérer normalement”

Voici des exemples de risques :

Mise à jour d’un OS
Modification de la réglementation (un exemple récent : la loi RGPD)
Modification des termes d’un service dépendant à votre écosystème (changement des droits d’une API, SDK…)
Arrivée d’un concurrent
Etc…

Pourquoi s’en soucier ?

La question semble ridicule mais bien souvent, on gère les risques seulement quand il est trop tard (ce qui se déroule dans tous les domaines de la vie).
On pense que l’on a le temps et quand la date arrive on panique.

Cet état de panique à bien souvent un impact négatif sur l’ensemble du business et dans ce genre de situation on cherche un coupable.

Dans l’environnement produit, ne cherchez pas, le coupable désigné est tout trouvé : c’est vous.

Comment planifier les risques ?

La mobilisation de tous les acteurs

Un risque peut venir de toute part.

Parfois vous l’apprenez en lisant la presse, parfois un de vos collaborateurs vous en touchent un mot, parfois le signal vient de votre n+1.

Selon les cas, la prise de conscience dans votre organisation n’est pas la même.

Si le risque est amené par votre direction, vous n’aurez pas de problème à le planifier et le prioriser.

En revanche, si le risque est peu connu alors votre rôle va être de remonter l’information au plus haut de l’organisation

Le problème du risque est qu’il n’est pas tangible tant que l’on n’y est pas confronté.

Afin de le rendre plus concret, organisez un point avec tous les acteurs impliqués et présentez des chiffres et des faits.

Embarquez tout le monde.

L’estimation du temps de résolution

Une fois le risque pris en compte, il va falloir évaluer son temps de résolution.

A l’inverse d’un bug ou d’une fonctionnalité, vous allez devoir vous taper tout le boulot préparatoire (spécifications et estimations) mais une fois le chiffrage terminé, ce travail vegétera dans votre backlog pour un bon moment.

Dès qu’un risque intervient et que vous savez que vous allez devoir le faire, n’attendez pas la dernière minute pour faire le travail préparatoire.

Je vous conseille de vous en occuper le plus vite possible.
En plus de vous apporter de la tranquilité d’esprit, ce chiffrage vous permettra de planifier également vos autres priorités.

Planifiez vos risques entre 2 priorités afin de ne pas vous mettre sous l’eau.

Pour ma part je travaille en objectifs trimestriels. Selon les cas, je planifie souvent les risques au moins 1 trimestre en avance pour ne pas être pris de cours au moment venu.

Conclusion

Après les posts sur La priorisation et comment prioriser les bugs, vous l’avez compris, le product owner est un roi de l’organisation.

Certes votre responsabilité est de prioriser le backlog mais ne voyez pas le Backlog seulement comme une liste des tâches que vous avez prévus.

Le backlog c’est bien plus que ça.

Par moment 50% des choses qui y résident sont des tâches venant de l’extérieur (bugs, risques).

Avant de le prioriser, assurez vous d’avoir un backlog complet.

Enquêtez et prêtez attention à tous les facteurs externes qui ont un impact sur le produit.

Planifier les risques, c’est juste une histoire de bon sens.