jouvenot.com

Méthodes agiles : 50 conseils pratiques (épisode IV)

Cet article est le quatrième d’une série de cinq épisodes intitulée Méthodes Agiles : 50 conseils pratiques.

31.      Ayez en tête un contre-exemple

S’assurer que tout le monde à en tête, un service, un produit, auquel ne doit surtout pas ressembler le vôtre, est impératif. Mieux il peut faire converger les équipes du projet en les fédérant autour d’un ennemi commun. Vous verrez, plus votre projet avancera dans le bon sens, plutôt votre contre-exemple passera dans l’esprit de vos développeurs du statut « d’homme à abattre », à celui de « vieux ringard », puis à celui de « l’aîné duquel on ne se moque plus car il est désormais âgé et qu’il a sommes toutes des qualités ».

32.      Actualisez scrupuleusement les demandes

Les développeurs ont parfois comme travers de considéré que si une demande n’a pas été formulé au moins quatre fois par le Product Owner, le client ou l’utilisateur, c’est que cela n’est pas réellement important et qu’il ne faut pas en tenir compte. Un bon moyen de palier à cela, est de mettre en place un système de barème des demandes à base de bâtons. Ces derniers étant ajouté à chaque fois que la demande est reformulée ou simplement reloguée. Exemple, la demande : « Intégrer le paiement par Bitcoin à la liste des moyens de paiement proposées|||||| » sera plus importante que celle-ci : « Traduire le message de confirmation de commande en Portugais Brésilien || ».

33.      Demandez au client ce qu’il ne veut pas

Vous serez surpris de voir combien la parole se libère lorsque l’on demande à certains utilisateurs ce qu’ils ne veulent pas, plutôt que ce qu’ils veulent. « Je ne veux pas être obligée de créer un compte, dès le début, avant même de pouvoir visiter le site ». « Je ne veux pas que le bon de commande ressemble à celui d’une entreprise de vente à distance ». « Je ne veux pas voir ce tuto à cet endroit ». « Je ne veux pas que le menu soit trop long, sinon il masque l’offre du mois, lorsqu’on le déroule complètement », etc. Autant de phrases que certain(e)s ont semble-t-il plus de faciliter à dire. Autant de phrases qui permettent à celles et ceux qui ne savent pas rédiger une expression de besoin, c’est-à-dire la plupart d’entre nous, d’en formuler quand même une, mais sans le savoir.

34.      Privilégiez l’epicenter design

Lors de la face de sketching, demander aux personnes associées au projet, de partir du centre de la page (de l’écran dessiné) et d’y mettre l’élément central de la fonctionnalité que la page web appellera, déclenchera ou utilisera. Exemple : une barre de saisie d’adresse e-mail s’il s’agit de la page d’inscription à la newsletter. Ou les produits également achetés par les clients ayant déjà acheté le produit que vous venez de mettre dans votre panier, s’il s’agit de la page destinée à faire du cross selling. Ensuite demandez-leur de mettre les éléments périphériques autour. Insistez pour qu’ils précisent si l’affichage de chacun de ces éléments est réellement indispensable ou non. L’utilisateur est ainsi focalisé sur l’expérience client et dessine un chemin débarrassé de tout élément perturbateur.

35.      N’oubliez pas les trois modes inhérents à tout service en ligne

Que vous le vouliez ou non, l’utilisateur pourra être confronté à trois modes d’utilisation : Blanck, Error, Regular.

Le premier mode correspond à ce qu’il verra alors que la fonctionnalité n’est pas active. C’est ici que l’on trouvera tous les formulaires à renseigner. Exemple : le formulaire de création d’un compte qui ouvrira les droits, une fois créé, d’accès à certaines fonctionnalités.

Le deuxième fait référence à ce que l’utilisateur verra lorsqu’un problème technique se produira (la créativité de manque pas dans ce domaine).

Le troisième désigne ce que l’utilisateur verra lorsqu’il utilise la fonctionnalité à proprement dite.

Ne sous estimez pas cette trilogie. Les modes blanck et error peuvent notamment donner plus de travail qu’on ne l’imagine et impacter les développeurs mais aussi des services externes à ceux de l’équipe projet. Exemple : un message d’erreur au moment de la finalisation d’une commande sur un site marchand, suivi par l’envoie automatique d’une notification à un opérateur téléphonique situé au Maroc, qui prendra le plus rapidement possible contact avec l’utilisateur pour l’aider à finaliser sa commande. Le non-envoie d’un e-mail de confirmation de commande, pourtant annoncé lors de l’inscription, donnera du travail au service support ou à celles et ceux qui se cachent derrière un chat bot.

36.      N’oubliez pas l’administrateur(s)

Trop souvent oublié, l’administrateur du site a souvent des besoins qu’il n’est pas possible d’ignorer. Ils touchent à la sécurité, à la gouvernance du site, à des process préalablement établis dans l’entreprise, au cœur de son activité première, à la culture d’entreprise, etc. Pire, l’administrateur est rarement seul. L’arrière du décor peut cacher différents administrateurs, distinguables selon leurs prérogatives ou leurs métiers. Les impliquer dans les séances de sketching est un bon moyen de spécifier plus efficacement le futur service.

37.      Alignez l’interface d’administration avec l’interface utilisateur

Cette précaution semble anodine mais elle a bien des mérites. Faire gagner du temps, permettre de plus facilement contrôler que ce qui est imaginé côté utilisateur est bien pris en compte côté back office, que les règles imposées par l’entreprise sont bien respectées, que le marketing produit n’a pas omis un service, une contrainte, une dépendance avec un système existent, que les règles de gestions du site (souvent logées côté back office) permettront bien d’afficher les pages imaginées en phase de sketching et offrir l’usage imaginé.

38.      Simplifiez le code au maximum

Bannissez ce que les développeurs appellent des spaghettis : quelques chose de compliqué, de long, de mélangé et d’indémêlable. N’oubliez pas, nous sommes dans une logique digitale ou le développement ne s’interrompt jamais. Si le site demeure, les développeurs vous quittent et les remplaçants seront plus rapidement opérationnels, efficaces et productifs s’ils trouvent un code simple en arrivant. La simplicité du code favorisera aussi son adaptation le moment venus, avec des nouveautés charriées par le déluge d’innovations et de mutations que le digital inflige à tous.

39.      Conserver un code aussi court que possible

Se donner un objectif relatif à la longueur du code peut être salutaire. Exemple : le code de tel module ne doivent pas dépasser tant de lignes. Cela permet de s’assurer que les développeurs et le scrum master font une chasse sans relâche aux feature loops (ces fonctionnalités qui ont l’air d’être uniques si l’on se place du point de vue de l’utilisateur, mais qui en réalité génèrent ou supposent la création de d’autres fonctionnalités pour simplement pouvoir fonctionner). Un cauchemar pour le respect du planning.

40.  Encouragez la pensée divergente

A chaque demande formulée, invitez les développeurs à imaginer comment s’y prendre autrement pour permettre à l’utilisateur d’effectuer ce qu’il souhaite. Les vertus de cette discipline consistant à instaurer le principe de la contre-offre systématique sont nombreuses : favoriser la créativité, trouver des voies moins coûteuses, gagner du temps, capitaliser sur les expériences passées de tous, resserrer les liens entre le marketing produit et la technique, éviter de tomber dans le piège consistant à penser qu’à un problème donné il n’y a qu’une seule solution.