La fonction de trop

Il y a une question dangereuse lorsqu'on développe un produit.

« Et si on ajoutait aussi... ? »

Elle semble innocente.

Et si on ajoutait des statistiques ?

Et des notifications personnalisées ?

Et un export PDF ?

Et une interface d'administration plus complète ?

Et pourquoi pas un mode sombre avec trois thèmes ?

Quelques semaines plus tard, l'application possède un menu impressionnant.

Mais le problème initial est-il mieux résolu ?

Pas forcément.

Une idée intéressante n'est pas forcément une bonne priorité

Je comprends très bien l'attrait d'une nouvelle fonctionnalité.

Côté développeur, c'est stimulant. On peut imaginer une meilleure interface, découvrir une bibliothèque et résoudre un défi technique.

Mais du côté de l'utilisateur, l'intérêt est souvent beaucoup plus terre à terre.

Il veut terminer une tâche.

Réserver. Payer. Suivre une demande. Trouver une information.

Si une fonction ne l'aide pas à faire cela, elle risque surtout de compliquer son parcours.

Le produit n'est pas une collection de possibilités. C'est une réponse à un besoin.

Le coût invisible de chaque ajout

Une fonctionnalité demande davantage que les heures nécessaires à sa première version.

Elle ajoute parfois des champs en base, des droits d'accès, de nouvelles erreurs possibles, des textes d'aide, des traductions, des tests et du support.

Elle peut modifier les règles d'autres parties de l'application.

Même si personne ne l'utilise, il faut souvent continuer à la maintenir.

C'est un peu comme acheter un meuble parce qu'il est joli : on oublie qu'il faudra désormais trouver où le mettre, le nettoyer et tourner autour. 😄

Comment décider ?

Avant de commencer une nouvelle fonction, je préfère poser quelques questions :

• Qui en a réellement besoin ?
• Quelle difficulté cette fonction supprimera-t-elle ?
• Combien de personnes ont demandé quelque chose de similaire ?
• Peut-on résoudre le problème en simplifiant ce qui existe ?
• Comment saura-t-on que l'ajout a été utile ?

Un souhait exprimé par une seule personne n'est pas automatiquement mauvais.

Mais ce n'est pas non plus une preuve que tout le monde en aura besoin.

Il faut comprendre ce qu'elle cherche à accomplir derrière sa demande.

Simplifier peut être plus difficile qu'ajouter

Ajouter un bouton donne une preuve visible de travail.

Le supprimer demande parfois davantage de courage.

Parce qu'il faut accepter qu'une idée à laquelle on tenait n'apporte pas la valeur espérée.

Parce qu'il faut expliquer pourquoi l'application change.

Et parce que les utilisateurs n'ont pas tous les mêmes habitudes.

Une suppression doit donc être réfléchie : regarder l'usage, préserver les données si nécessaire, prévoir des alternatives et communiquer.

Mais garder indéfiniment tout ce qui a été créé n'est pas une stratégie non plus.

Le piège de la feuille de route infinie

Une liste de tâches peut donner l'impression d'avancer à mesure qu'on ajoute des tickets.

Pourtant, une bonne feuille de route doit aussi dire ce qu'on ne fera pas maintenant.

J'essaie de distinguer les corrections indispensables, les améliorations demandées par les utilisateurs et les expérimentations plus incertaines.

Une petite équipe ne peut pas tout construire.

Et essayer de le faire peut l'empêcher de réussir ce qui compte vraiment.

La question à garder

Je ne suis pas contre les nouvelles fonctionnalités.

Je suis développeur. C'est littéralement l'une des choses que j'aime faire. 😂

Mais un produit devient meilleur quand il aide davantage ses utilisateurs, pas simplement quand son menu s'allonge.

La prochaine grande amélioration n'est peut-être pas ce qu'on va ajouter.

C'est parfois ce qu'on aura le courage de retirer.