Bienvenue sur le podcast Artisan Developer,
l'émission qui combine technique et agilité pour partager la passion du code.
En tant que développeur, j'aime ce qui est technique.
Tu remarqueras que c'est le cas pour pas mal de développeurs.
Et le risque sur un projet, à un moment donné, c'est de perdre de vue pour qui on travaille.
On travaille pour un employeur bien entendu, que ce soit toi parce que tu es en frilante, que ce soit ta boîte,
que ce soit ton client, quelqu'un qui nous paye.
Mais la finalité de notre travail, c'est quand même l'utilisateur derrière.
Si on n'a pas l'utilisateur, à quoi sert ce qu'on fait ?
Et si les utilisateurs et les développeurs sont trop éloignés, tu as plusieurs risques.
Le premier c'est que les développeurs peuvent oublier les utilisateurs et réciproquement.
Les développeurs, on peut aussi faire des choses qui ne collent pas aux besoins.
On va faire des trucs qui ne correspondent pas au métier à ce que veut faire vraiment l'utilisateur
à une manière intelligente de le faire pour lui.
Et puis, dans le pire des cas, on peut même les percevoir comme des casse-pieds.
Il y a des fois, j'entends des développeurs, ça peut-être du maraillement aussi.
Ah, ces utilisateurs, qu'est-ce qui nous casse les pieds avec leur demande là ?
Ah bah oui, ce serait plus simple quand même si il n'y avait pas d'utilisateur.
Oui, effectivement, ce serait plus simple si il n'y avait pas d'utilisateur, mais à quoi servirait ce qu'on fait ?
Faire grandir, un logiciel, c'est déjà un challenge sur le plan technique.
Ça absorbe beaucoup d'énergie.
Donc si tu veux éviter ces écueils, le manifeste nous rappelle.
Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet.
Dans cette phrase, il y a quelques points qui sont importants, et sont presque tous importants d'ailleurs.
D'abord, on nous rappelle, les utilisateurs, on est vraiment centrés sur l'usage.
Si on veut apporter de la valeur en tant que développeur,
on doit se concentrer sur l'usage qui est fait de ce qu'on produit.
Alors soit les utilisateurs, soit les représentants.
Bah oui, tu ne peux pas forcément toujours parler à tous tes utilisateurs.
Tu imagines si tu as 2 000 utilisateurs dans l'osiciel,
il faut une grosse salle de réunion pour réunir tout le monde.
Donc à ce moment-là, il faut qu'il y ait quelqu'un qui prenne, qui fasse un peu l'utilisateur proxime.
C'est quand même mieux s'il est lui-même utilisateur.
Travailler ensemble, il y a bien cette idée de « on est dans le même bateau ».
Finalement, même si tu es payé par quelqu'un d'autre,
indirectement, c'est toujours pour l'utilisateur qu'on bosse.
Quotidiennement, il y a cette idée de faire un point tous les jours.
Il y a cette idée de se reconnecter tous les jours.
Tu vois, c'est un peu comme tes branches.
Si tu les laisses dériver pendant plusieurs jours,
le maire, je vais être difficile, tu le sais.
C'est pour ça qu'il faut au moins récupérer la branche principale,
au moins une fois par jour, minimum.
Et tout au long du projet, il y a cette idée que c'est pas juste au début
ou à la fin du projet.
C'est pas juste « les utilisateurs disent, ils veulent ça, ça, ça et ça ».
Salut les gars, rendez-vous dans 3 mois, vous nous livrez la version,
et on va utiliser, et ça va être nickel.
Non.
Tu vas pouvoir livrer des choses dès les premières releases,
dès les premières fin de sprints, c'est-à-dire dès les premiers 1 à 2 semaines,
tu peux commencer à livrer des choses.
Ce qui te permet de commencer à collecter du feedback de la part de l'utilisateur.
Ce qui te permet de mieux comprendre son métier.
Ce qui te permet d'éviter de construire sur des choses que tu vas complètement chambouler après.
Donc il faut garder à tout moment l'utilisateur en tête
et se synchroniser régulièrement avec lui.
Une astuce que tu peux faire, c'est créer un personnage.
Je vois des équipes qui font ça.
Tu peux créer un personnage de ton utilisateur idéal, te l'imprimer et l'avoir tout le temps sur ton bureau,
comme ça à chaque fois que tu te poses une question, à chaque fois que tu te doutes,
tu te demandes « OK, comment lui il ferait ? ».
Et tu verras que petit à petit tu vas nourrir ce personnage
et de mieux en mieux comprendre ton utilisateur.
Je t'ai remercié d'avoir écouté ce podcast jusqu'au bout
et si tu l'as apprécié, je t'invite à le partager avec un ami.
Ça fera connaître le podcast.
A demain !