Votre projet est en retard. Encore. La raison pourrait vous surprendre. Ce n’est probablement pas parce que votre équipe est mauvaise dans estimation avec des story points. Et ce n’est certainement pas parce que votre équipe est paresseuse. D’après mon expérience, la principale raison pour laquelle les projets sont en retard est simplement parce que votre produit est plus gros que vous ne le pensez.

Tu as une bonne idée de ce à quoi ressemblera le produit final, mais l’image complète est impossible à visualiser au début.

4 raisons pour lesquelles les produits se développent au-delà des estimations initiales

Examinons quatre raisons pour lesquelles les produits (et leurs retards de produits) finissent par être plus gros qu’on ne le pense.

1. Les produits évoluent avec le temps

La première est que les besoins évoluent. Ce dont vos utilisateurs ont besoin aujourd’hui ne sera pas ce dont ils auront besoin plus tard. Plus il faudra de temps pour passer de l’apprentissage de leurs besoins à leur satisfaction, plus ces besoins évolueront.

2. Les retards de produits ont des exigences émergentes

Deuxièmement, des exigences émergent. Certaines fonctionnalités d’un produit ne peuvent être découvertes qu’après avoir commencé à développer le produit. Ce faisant, vous fournissez les premières versions du produit aux utilisateurs. Ils jouent avec. Ils expérimentent. Et ils proposent de nouvelles idées.

Ces exigences émergentes sont des fonctionnalités auxquelles personne n’aurait pensé avant d’avoir expérimenté le produit ou le système partiel. Ils rendent votre produit plus grand que vous ne le pensiez parce qu’ils étaient imprévus.

3. Toutes les équipes négligent parfois certaines exigences

Troisièmement, certains les exigences sont négligées. Quels que soient vos efforts, il est probablement impossible d’identifier à l’avance tout ce dont vos utilisateurs auront besoin. Lorsque vous interviewez des utilisateurs, vous oublierez de poser une question, vous ne donnerez pas suite à quelque chose qu’un utilisateur mentionne ou vous manquerez de temps. Vous oublierez quelque chose.

4. Certains objectifs sont plus difficiles que prévu à atteindre

Quatrièmement, certains objectifs seront plus difficiles à atteindre que prévu. Les équipes ajoutent des fonctionnalités, des fonctions ou des capacités à un produit pour atteindre des objectifs définis.

Par exemple, une compagnie aérienne peut souhaiter améliorer le logiciel utilisé par ses représentants du service client afin que ces derniers puissent réacheminer plus rapidement les passagers concernés par les annulations de vol. Les développeurs de la compagnie aérienne prévoient d’atteindre cet objectif en utilisant un nouveau système d’IA pour suggérer un réacheminement des passagers.

Après avoir mis en œuvre cette nouvelle fonctionnalité, les membres de l’équipe mesurent l’impact et découvrent que l’organisation n’a atteint qu’à moitié le résultat souhaité.
Dans ce cas, des travaux supplémentaires seront nécessaires pour atteindre l’objectif. Et ainsi, le produit est devenu plus grand qu’on ne le pensait initialement.

Comment prendre en compte les produits inconnus

La première consiste à reconnaître que, quelle que soit la capacité des membres de l’équipe à comprendre les besoins des utilisateurs, ils ne penseront pas à tout.

Deuxièmement, ayez une conversation franche avec les parties prenantes (les deuxième équipe du propriétaire du produit) sur les réalités des produits inconnus. Faites-leur reconnaître qu’ils n’ont pas fini de réfléchir à ce qui est nécessaire, que les besoins vont évoluer et qu’il est impossible de penser à tout.

Troisièmement, évitez de faire des promesses sur le moment où l’ensemble du produit pourra être livré sans ajouter une certaine quantité de tampon pour tenir compte de la taille réelle du produit complet. Mais comment savoir quelle quantité de tampon ajouter ?

Comment calculer un tampon de taille de produit

Voici une technique que j’ai utilisée pour décider de la taille probable d’un produit.

1. Demandez aux membres de l’équipe quel pourcentage de la solution ultime ils pensent voir (50 % ? 80 % ? 25 % ?).
2. Le tampon du projet est de 1 divisé par le pourcentage connu.
3. En multipliant la taille du backlog de produit actuel par le tampon, vous obtenez une estimation de la taille réelle du produit.

Par exemple, si l’équipe dit qu’elle pense voir environ la moitié de la solution finale, cela signifie que la partie inconnue du backlog produit est de la même taille que les éléments connus du backlog. Si tel est le cas, le produit complet est le double de la taille que vous pensez actuellement.

La formule pour cela est simplement 1 divisé par le pourcentage que l’équipe pense connaître multiplié par la taille actuelle du backlog produit.

Je viens de donner l’exemple d’une équipe pensant voir actuellement la moitié de la solution ultime. En remplaçant 50 %, ou 0,5, dans la formule, vous pouvez voir que la taille réelle de ce produit est le double de la taille actuelle.

En regardant un autre exemple, supposons que l’équipe ait une série de conversations avec les utilisateurs et les parties prenantes. Sur la base de ces données supplémentaires, les membres de l’équipe estiment voir environ 80 % de ce dont les utilisateurs auront finalement besoin dans ce produit. Lorsque nous introduisons 80 % dans la formule, nous constatons que la taille totale de l’arriéré est 25 % supérieure à la taille actuelle.

Un calcul approximatif comme celui-ci peut vous donner une approximation de la taille de votre produit par rapport à ce que l’équipe pense qu’il est actuellement. Cette taille plus grande peut être utilisée pour établir des prévisions à long terme plus précises si nécessaire.

Qu’avez-vous vécu qui a rendu vos produits plus gros que prévu ? Veuillez partager votre expérience dans les commentaires.