Gaspillage 2 : Fonctionnalités superflues - Développement logiciel Lean

1Le piège de la surproduction

En fabrication, la surproduction signifie produire plus que ce que les clients ont commandé. En logiciel, cela signifie construire des fonctionnalités que personne n'utilise.

Les études montrent systématiquement que 60 à 80 % des fonctionnalités sont rarement ou jamais utilisées. Pensez-y. La majeure partie de ce que les équipes logicielles construisent ne crée aucune valeur.

C'est le gaspillage le plus coûteux parce qu'il entraîne des coûts composés :

Coût de développement : Temps pour construire la fonctionnalité
Coût de maintenance : Chaque fonctionnalité ajoute de la complexité pour toujours
Coût d'opportunité : Qu'auriez-vous pu construire d'autre?
Coût pour l'utilisateur : Plus de fonctionnalités signifie des produits plus difficiles à utiliser

Une fonctionnalité qui n'est jamais utilisée n'est pas gratuite — elle vous coûte chaque jour en charge cognitive, fardeau de test, documentation et bogues potentiels.

Le coût de possession

Chaque fonctionnalité a un coût de possession. Elle nécessite des tests. Elle peut se briser. Elle complique la base de code. Elle confond les utilisateurs. Les fonctionnalités inutilisées ont une valeur négative — elles coûtent plus que rien.

2Pourquoi les fonctionnalités superflues sont construites

Les équipes construisent des fonctionnalités inutiles pour de nombreuses raisons :

« Tant qu'on y est » : Ajouter de la portée parce que cela semble efficace de regrouper. Ce n'est pas le cas — cela retarde le travail de valeur et ajoute du gaspillage.

Exigences imaginées : Construire pour des utilisateurs à qui vous n'avez pas parlé. Les hypothèses se composent en gaspillage.

Dorure : Les développeurs ajoutent une sophistication technique qui ne sert pas les utilisateurs. Des abstractions que personne ne réutilisera. L'optimisation de performance pour des fonctionnalités que personne n'utilise.

Fonctionnalités FOMO : « Le concurrent X a cette fonctionnalité! » Peut-être que leurs utilisateurs ne l'utilisent pas non plus.

Fonctionnalités politiques : Fonctionnalités construites parce que quelqu'un d'important les a demandées, pas parce que les utilisateurs en ont besoin.

Sur-ingénierie : Construire pour une échelle que vous n'atteindrez jamais. Concevoir pour une flexibilité que vous n'utiliserez jamais. « Mais si nous devons supporter un million d'utilisateurs? » Vous ne le ferez probablement pas.

Le contraire des fonctionnalités superflues n'est pas la pauvreté de fonctionnalités. C'est la concentration. Construisez exactement ce qui est nécessaire, rien de plus, et construisez-le bien.

L'exportation inutilisée

Une équipe a passé deux mois à construire l'exportation CSV/Excel/PDF pour une fonctionnalité de rapport. Les analytiques ont montré que 3 utilisateurs ont déjà utilisé l'exportation. La fonctionnalité reste dans la base de code, ajoutant un fardeau de test et un coût de maintenance pour toujours.

YAGNI appliqué

Une équipe devait supporter un fournisseur de paiement. Elle a construit exactement cela — aucune abstraction pour plusieurs fournisseurs. Plus tard, quand elle a réellement eu besoin d'un deuxième fournisseur, elle a refactorisé. Le coût total était inférieur à ce qu'aurait été l'abstraction initiale.

3Prévenir les fonctionnalités superflues

Valider avant de construire : Parlez aux utilisateurs. Menez des expériences. Utilisez des prototypes. La fonctionnalité la moins chère est celle que vous ne construisez pas.

YAGNI (You Ain't Gonna Need It) : Ne construisez pas pour des exigences futures imaginaires. Construisez ce dont vous avez besoin maintenant. Refactorisez plus tard si les exigences changent — et souvent elles ne changent pas.

Minimum viable pour tout : Quelle est la plus petite chose qui testerait cette hypothèse? Construisez cela. Apprenez. Itérez.

Dépréciation basée sur les données : Mesurez l'utilisation des fonctionnalités. Éliminez les fonctionnalités qui ne sont pas utilisées. Le courage de retirer est aussi important que la discipline de ne pas ajouter.

Dire non plus que oui : La réponse par défaut pour les nouvelles fonctionnalités devrait être « non ». Les fonctionnalités doivent se justifier. Dire non à une bonne idée est souvent juste parce que vous devriez travailler sur une excellente idée à la place.

Budgets de fonctionnalités : Pour chaque nouvelle fonctionnalité, retirez-en une ancienne. Cela force la priorisation et prévient l'enflure.

Les meilleures équipes ne sont pas fières de ce qu'elles ont construit — elles sont fières de ce qu'elles ont choisi de ne pas construire.

Chaque fonctionnalité que vous ne construisez pas représente des économies infinies : pas de développement, pas de tests, pas de maintenance, pas de documentation, pas de bogues, pas de confusion — pour toujours.