La loi de Pareto est plus communément connue sous la règle du 80/20. Cette distribution des probabilités suit une loi des puissances. L’idée qui est régie par cette loi est que la majorité de vos résultats peuvent être réalisés avec un minimum d’effort.

Cette loi est un outil fondamental en gestion de la qualité. Elle est aussi utilisée en réassurance. Cette loi dit que « généralement » 80 % de résultat peuvent provenir de seulement 20% d’efforts !

Par exemple : En fiscalité : 20% des citoyens imposables génèrent 80% de la trésorerie publique, En sport: 20 % de l’effort à l’entraînement permet d’atteindre 80% de la performance, en service après-vente: 80% des réclamations proviennent de 20% des clients.

Cette loi est bien connue des managers : En préparant leurs ambitions, les managers expérimentés savent que seuls quelques éléments majeurs sont décisifs. Le reste sera traité par la même occasion en tant que parties de ces éléments — Juran, 1964

Ainsi, un bon directeur de produits est une personne qui peut voir (à l’avance sans l’avantage du travail déjà accompli) les 20% sur lesquelles se concentrer. En développement Agile, nous devons essayer d’appliquer la règle des 80/20, qui cherche à se concentrer sur l’importance des 20% qui engendre la majorité des résultats.

Si la qualité de votre application n’est pas la première exigence, si vous avez le contrôle sur son périmètre et si la mise à disposition de votre application est votre première priorité, pourquoi ne pas fournir 80 % de votre produit en seulement 20% du temps. En fait, dans ce scénario particulier, vous pourriez vous demander pourquoi faire les derniers 20% restant.

Maintenant, cela ne signifie pas que votre produit doit être fondamentalement bugé, laisser une mauvaise expérience à l’utilisateur, etc. Cela signifie simplement que le développement de certaines fonctionnalités, ou la richesse de certaines caractéristiques, va plus loin et a une diminution de rendement pourrait ne servir à rien.

Cette affirmation n’est elle pas en conflit avec le précédent billet: « terminer » signifie « TERMINER! ». Pas réellement, parce qu’à l’intérieur de chaque itération ou Sprint, ce que vous décidez ou ne décidez pas de « de développer » peut ne pas être réalisé à 100%.

Pour exemple, sur la règle des 80/20, Microsoft lui-même a montré que l’utilisateur moyen de Word utilise seulement 8% des fonctionnalités. 8% Et nous pouvons penser que moins de 80% d’entre eux n’utilisent même pas 8%. Si Microsoft n’avait développé que les 8% importante de Word, pourraient ils encore avoir pris la même part de marché? Peut-être, peut-être pas, malheureusement nous ne le saurons jamais.

Il est également utile d’examiner l’impact sur l’expérience de l’utilisateur. Google nous a montré que les utilisateurs préfèrent souvent des applications qui font au plus près du besoin. Seulement ce que vous voulez. Et pas plus. Le reste est sans doute encombrant et en fait, interfère avec l’expérience de l’utilisateur et apporte seulement un intérêt réduit pour un nombre limité d’utilisateurs.

Nous pouvons donc inverser le 80/20, pour dire que seulement 20% des fonctions d’une application seront nécessaires à 80% des utilisateurs. Dans un développement agile, lorsque vous développez un nouveau produit, concentrez-vous sur ce que votre logiciel doit faire avant tous. Pourriez-vous prendre le marché avec toutes les caractéristiques importantes, ou seulement avec des fonctions qui sont moins riches fonctionnellement, en seulement peu de temps ?

En dehors de la réduction des coûts, réduction des risques et des prestations plus élevées en étant plus rapide sur le marché, vous pouvez également vous appuyer sur la première version du produit basé sur le retour du client réel.

Donc, tout cela est réellement du bon sens (cf. MMM notre DGA).

A la finalité, ce n’est pas aussi simple, car il faut être un très bon visionnaire pour découvrir les 20% qui fourniront 80% des résultats. Par expérience et dans de très nombreux cas, les responsables n’ont pas cette vision.