La “Culture Produit” est axée vers ce que l’on vise, contrairement à la culture projet qui s’intéresse la manière dont on organise une mise en oeuvre. Cette notion est centrale dans toutes les méthodes Agile que nous croisons ces dernières années. Bien que nous en entendons parler que depuis peu de temps en France, cette approche de la production (quelque soit le domaine) est en exercice depuis plusieurs décennies dans d’autres pays, notamment outre-atlantique.

Créer de la valeur pour l’utilisateur et non se focaliser sur la gestion d’un projet prédéfini au détriment de l’expérience de nos clients.

En agile (xp, scrum, kanban, whatever…), nous organisons des backlogs, des itérations, des cycles courts comprenant tous les phases de conception, de développement, de tests et de retours utilisateurs, dans le but de limiter, d’éviter autant que possible le décrochage avec nos clients.

Une fois que nous avons acquis l’intérêt, et la conviction que nous avons besoin d’une méthode de travail nous permettant de rester au contact des utilisateurs et de penser – tous, développeur, PO, marketing, community managers, … – ce que nous faisons chaque jour par le biais du produit et non d’un process ou d’une méthode de gestion, il est utile de se donner un angle d’attaque. Il est existe plusieurs outils qui sont, à mon sens, complémentaires les uns avec les autres et non antagonistes. Par exemple, la définition d’une vision produit, des personas, la mise en place du Design Thinking en collaboration avec du Scrum / Kanban / Lean startup. Malheureusement, nous n’avons pas tous les moyens de nous permettre de tout mettre en place d’un seul coup.

Typiquement, j’adorerais pouvoir mettre en place pendant les phases de définition de concept du Design Thinking au sein de mon entreprise. Cependant, nous n’en sommes pas encore à ce degré d’acceptation de l’Agile, et je préfère commencer plus soft.

Une manière plus simple et plus rapide de remettre bien au centre du quotidien de l’équipe le produit qu’elle crée pour l’utilisateur, est de définir des utilisateurs types (personas), totalement fictifs, mais qu’on utilisera ensuite pour créer une vision produit orientée selon un angle de vue utilisateur, en prenant en compte ce que chacun de ces personas pourraient attendre.

 

A/ Préparation de la définition des personas et de la vision produit.

Pour se faire, il est important de préparer, en amont, un minimum l’atelier de définition de personas. Pour un développeur, se prêter à un tel exercice est loin des habitudes et peut se révéler complexe.

Il existe pas mal d’exemple de personas sur le net. Je me suis permis d’utiliser celui de Roman Pichler et de reprendre le canevas type.

persona canvas

Sachant que j’allais convier une petite dizaine de personnes, j’ai également préparé trois tableaux vides, que les membres de l’équipe n’auront plus qu’à remplir (je suis parti du principe d’inviter non seulement les développeurs, mais également les community managers et la personne s’occupant du marketing).

 

B/ Animation de l’atelier “Personas”.

b.1/ Présentation de l’exercice: 15 min.

Une rapide présentation des personas et de leur utilité est nécessaire, avant de laisser les membres de l’équipe appréhender par eux-mêmes l’exercice. Rappeler notamment:

  • En tant que membre d’une équipe, on oublie parfois de se mettre à la place de l’utilisateur, et on perd de vue ce qui pourrait avoir une véritable valeur ajoutée pour celui-ci.
  • Les personas sont là pour faciliter le changement de point de vue (développeur/CM/Marketing <-> utilisateur) afin de limiter la mise en place de fonctionnalités incompréhensibles, tortueuses, ce qui peut arriver de temps à autres lorsqu’on développe une User Story sans prendre le moindre recul. Ce n’est pas évident, sans une base un minimum définie, de changer de peau. Tout joueur de jeu de rôle sait à quel point le “background” de son personne est vital pour pouvoir s’imerger dans son univers.
  • L’empathie envers l’utilisateur est nécessaire pour ne pas créer un produit qui ne correspond pas à la cible. Les personas aident à ne pas mettre en oeuvre des solutions fonctionnelles qui nous plaisent en tant que développeurs, tout en étant désagréables pour nos utilisateurs. Typiquement, nous faisons du jeu dit “casual”, et une partie des développeurs est composée par des “hardcore gamer”. Il est déjà arrivé à plusieurs reprises que nous mettions en place des fonctionnalités que nous avons vues et appréciées sur des jeux “hardcode” et qui n’ont eu qu’un retour négatif, finalement, de la part de nos joueurs. Est-ce que la fonctionnalité est mauvaise? Est-ce que nos joueurs ne nous méritent pas? Ou plutôt, est-ce que nous avons oublié pour qui nous développions nos produits?

J’ai également distribué les différents supports (exemple et canvas d’explications). Après un rapide tour de table afin de vérifier s’il n’y avait pas d’incompréhensions, j’ai laissé faire.

b.2/ Exécution et présentation des personas créés: 30 min.

Lorsque je mets une équipe devant un nouvel atelier / innovation game, j’ai appris qu’il est nécessaire de laisser les gens s’approprier le concept. Même si au début, la participation est mitigée et potentiellement, beaucoup regardent leurs voisins avec un air interrogateur, il ne faut pas presser les choses ni s’inquiéter d’un manque de réactivité au démarrage. C’est, souvent j’imagine, normal et naturel.

Faciliter l’atelier, c’est également laisser respirer les idées, non chercher à tout prix l’activité dès le démarrage. Celle-ci vient naturellement: il y a toujours un membre de l’équipe au moins qui se lève, pour voir les exemples, lire les supports, et tenter de se lancer. Du moins, il ne m’est pas encore arrivé de n’avoir vraiment aucune participation au bout de 5 minutes. Si c’était le cas, j’imagine qu’effectivement, il faudrait intervenir… Mais encore une fois, le fait d’attendre ne m’a pas encore fait défaut – alors qu’au début de ma mission de Scrum Master, je cherchais à avoir absolument la participation pleine de mon équipe, ce qui a eu pour résultat bien souvent d’épuiser les personnes présentes.

Quoiqu’il en soit je n’ai pas été déçu. Les personnes présentes se sont réparties en deux groupes de 5 personnes, ont pris leur temps avant de s’y mettre, plaisantant sur l’exercice, puis, au fur et à mesure, sont rentrés dans le jeu. J’ai laissé les équipes s’installer dans la définition de leurs personas, sans leur imposer plus que les supports avec lesquels je leur ai présentés le concept. D’ailleurs, chacune d’entre elles a créé des personnages avec une identité propre à chaque groupe. Une équipe en a fait un, l’autre en a fait 3. Pour l’anecdote, je n’avais préparé que trois feuilles de personas vierges, ils auraient pu rester dans le cadre fourni et se limiter à remplir les vides. Ils l’ont dépassé. Cela ne semble pas grand chose, mais c’est toujours plaisant lorsqu’on anime un atelier.

équipe personas
Equipes formées pour la création des personas

A la fin de l’exercice, les personas ont été présentés par une des personnes l’ayant créé. Un petit moment de fou-rire, parce que, forcément, un persona est toujours assez caricatural. Mais, d’une certaine manière, ils sont suffisamment cohérents pour pouvoir chercher à se mettre dans la peau d’un utilisateur fictif ayant une dénominateur commun avec une grande partie de nos véritables utilisateurs.

Présentation des personas
Présentation des personas

 

C/ Bilan

La création de personas n’est pas un exercice habituel pour une équipe de développement. Cependant, en travaillant ensemble, ceux-ci ont été définis rapidement et, malgré leur aspect caricatural, ils nous permettront, dans les futures réunions de définition de stories, de ne pas oublier nos utilisateurs et les raisons pour lesquelles nous mettrons en place telle ou telle fonctionnalité.