Accueil Génie logiciel 5 erreurs courantes dans la collecte des exigences

5 erreurs courantes dans la collecte des exigences

0
5 erreurs courantes dans la collecte des exigences


Ceux d’entre nous qui vivaient aux États-Unis en 2013 se souviennent peut-être de l’époque où HealthCare.gov, un nouveau marché en ligne (et controversé à l’époque) pour l’assurance maladie, a été lancé par le gouvernement américain et s’est effondré. dans les deux heures. Une étude ultérieure menée par le Bureau de la responsabilité gouvernementale a constaté que le site Web avait été développé « sans planification efficace » et que « les principales exigences techniques étaient inconnues ». La demande des utilisateurs avait également été largement sous-estimée. Essentiellement, bon nombre des échecs du site étaient dus à une mauvaise planification des exigences du produit.

La collecte des exigences est une partie cruciale du développement de produits, et c’est aussi l’étape à laquelle les chefs de produit se trompent souvent. De nombreuses études soulignent l’inefficacité de la collecte d’exigences comme source de problèmes majeurs pour la productivité des développeurs. Dans un vaste enquête 2022 par CodinGame et Coderpad, par exemple, les principaux défis auxquels sont confrontés les développeurs de logiciels ont été cités comme étant « les retouches, les changements, le travail imprévu, les problèmes imprévus » et « une orientation peu claire ». Ces défis peuvent être atténués en mettant en œuvre un processus robuste de collecte des exigences.

Les principaux défis pour les développeurs sont les retouches, les changements, le travail imprévu, les problèmes imprévus (36 %) et l'orientation floue (34 %).
Les principaux défis auxquels les développeurs sont confrontés, comme le montre cette récente enquête, peuvent être atténués par une collecte appropriée des exigences.

En tant que programme, projet et chef de produit, J’ai été témoin d’un large éventail d’attitudes à l’égard de la collecte d’exigences de la part des entreprises et des équipes, dont certaines ont finalement abouti à un gaspillage de ressources, à une dérive du périmètre, à des clients déçus et à des produits sous-performants. Dans cet article, je vais présenter quelques-unes de ces erreurs et identifier les enseignements clés afin que vous puissiez éviter de commettre ces mêmes erreurs.

Biais courants à éviter lors de la collecte des exigences

L’un des principaux défis à chaque étape du processus de développement est de ne pas laisser les préjugés inhérents influencer notre travail. C’est pourquoi un processus de collecte d’exigences solide et objectif est essentiel.

Une étude menée par Bent Flyvbjerg, expert renommé en gestion de projet, révèle plusieurs préjugés courants qui surviennent souvent dans la gestion de projet. D’après mon expérience, ces mêmes préjugés peuvent également influencer premières étapes du développement du produit. Voici ceux auxquels vous devez faire attention :

Biais

Manifestation

Fausse déclaration stratégique

La tendance à déformer ou à déformer délibérément et systématiquement des informations à des fins stratégiques (également connue sous le nom de parti pris politique, de parti pris stratégique ou de parti pris de pouvoir)

Biais d’optimisme

La tendance à être trop optimiste quant aux résultats des actions planifiées, y compris la surestimation de la fréquence et de l’ampleur des événements positifs et la sous-estimation de la fréquence et de l’ampleur des événements négatifs.

Biais d’unicité

La tendance à voir votre projet comme plus singulier qu’il ne l’est en réalité

Erreur de planification

La tendance à sous-estimer les coûtsle calendrier et les risques, et surestimer les avantages et les opportunités

Biais d’excès de confiance

La tendance à avoir une confiance excessive dans vos propres réponses aux questions

Biais rétrospectif

La tendance à considérer les événements passés comme étant prévisibles au moment où ces événements se sont produits

Biais de disponibilité

La tendance à surestimer la probabilité d’événements avec une plus grande facilité de récupération (disponibilité) en mémoire

Erreur du taux de base

La tendance à ignorer les informations génériques sur les taux de base et à se concentrer sur des informations spécifiques relatives à un certain cas ou à un petit échantillon

Ancrage

La tendance à trop s’appuyer sur un trait ou un élément d’information lors de la prise de décision, généralement le premier élément d’information acquis sur le sujet concerné.

Escalade de l’engagement

La tendance à justifier un investissement accru dans une décision, sur la base de l’investissement antérieur cumulé, malgré de nouvelles preuves suggérant que la décision peut être erronée ; également connue sous le nom d’erreur des coûts irrécupérables

Source : Bent Flyvbjerg, « Les dix principaux biais comportementaux dans la gestion de projet : un aperçu » Journal de gestion de projet2021

5 approches inefficaces de collecte des exigences

Le processus de collecte des exigences sera différent pour chaque entreprise et chaque produit, et vous pouvez adopter plusieurs approches pour aboutir à un résultat positif. Plutôt que de parler de quoi à faire, il est plus efficace de décrire les faux pas courants qui auront un négatif impact sur les résultats des produits. Voici les cinq principales erreurs à éviter lors de la collecte des exigences :

1. Définir un produit par ce qu’il n’est pas

Il y a quelques années, je faisais partie d’une équipe chargée de la mise à niveau du portail intranet d’une entreprise. L’objectif du client était simple : concevoir un nouveau portail qui pas ressembler au produit défectueux précédent. (L’entreprise avait récemment tenté de mettre à jour le portail, mais la solution finale avait été rejetée par les utilisateurs finaux.) À première vue, « Pas comme X » peut sembler une exigence importante. Mais la réponse de l’équipe a été de se concentrer sur les visuels, en conservant les mêmes fonctionnalités et en rééditant le produit avec une nouvelle couleur et une nouvelle marque. Bien entendu, ce produit a rencontré les mêmes problèmes que le précédent car ses caractéristiques et fonctionnalités sont restées largement inchangées. Le problème n’était pas la couleur ou l’image de marque, mais plutôt le fait que les exigences du produit n’avaient pas été redéfinies.

Leçon: La collecte des exigences n’est pas facultative ; vous ne pouvez pas le piloter et il n’y a pas de raccourcis. Changer l’apparence d’un produit ne résoudra pas ses problèmes sous-jacents. Et il ne faut jamais définir un produit uniquement par ce qu’il ne devrait pas être.

2. Copier votre concurrent

Une entreprise de taille moyenne voit qu’un concurrent a profité d’une opportunité sur le marché et souhaite participer à l’action. La rapidité de mise sur le marché est essentielle, c’est pourquoi il ne faut pas perdre de temps pour répondre aux besoins. Au lieu de cela, l’équipe copie simplement les caractéristiques du produit de son concurrent. La réponse du client est la suivante : « Où se trouvent les fonctionnalités de support de ce produit que nous valorisons dans vos autres produits ? » et « Comment ce produit s’intègre-t-il aux autres produits que nous avons déjà achetés chez vous ? » L’absence de réponse cohérente à ces questions se traduit par une équipe produit frustrée et des clients insatisfaits.

Leçon: Vous n’êtes pas vos concurrents. Vous ne pouvez pas créer une réplique de produit et vous attendre à ce que vos clients emboîtent le pas. Lorsque vous recueillez les exigences des produits, pensez toujours aux besoins de vos clients spécifiques et aux raisons pour lesquelles ils aiment vos produits existants. Demandez-vous comment vous pouvez intégrer la valeur que vous offrez en tant qu’entreprise dans ce nouveau produit.

3. Ne pas interagir avec les clients

J’ai déjà fait partie d’une équipe dans une nouvelle entreprise qui avait créé un produit doté de fonctionnalités étonnantes qui surpassait la concurrence. Malheureusement, l’équipe a oublié un élément essentiel dans le processus de collecte des exigences : le client. En fait, ils avaient peur de s’engager avec eux, se méfiaient des commentaires négatifs et craignaient qu’une mauvaise adéquation produit-marché ne soit révélée. Ainsi, l’ensemble des exigences produit qu’ils avaient élaborées manquait de la contribution vitale des clients.

Leçon: Si vous ne travaillez pas dans un lieu de sécurité psychologique avec vos clients, c’est un gros signal d’alarme pour votre équipe. Il faut du courage et de la confiance pour montrer votre nouveau produit aux clients, et vous devez le faire pour une collecte efficace des exigences. Bien entendu, tous les clients ne sont pas disposés à essayer de nouvelles choses, mais environ 16 % des personnes seront des innovateurs ou des pionniers, selon le Courbe d’adoption de la technologie. Identifiez ces clients avant-gardistes et commencez à les utiliser dans votre processus de collecte de besoins.

4. Création de fonctionnalités inutiles

En tant que chefs de produit, nous devons être des experts dans notre domaine. les besoins des clients. Si les services fournis par votre entreprise sont B2B, vous devez même comprendre les clients de vos clients. Le succès, c’est le client qui veut ce qu’il obtient. Afin de savoir ce que veulent vos clients, vous pouvez analyser des rapports, lire des articles et assister à des conférences, mais pour obtenir une vision plus claire, vous devez leur demander ce qu’ils veulent.

J’ai moi-même appris cette leçon à mes dépens. Sur un projet, nous avons collaboré avec des clients et d’autres parties prenantes et élaboré une liste d’exigences en matière de produits. Cependant, lorsqu’il était temps pour moi de créer des user stories, je n’ai pas confirmé chacune d’entre elles auprès du client. Je pensais qu’ils ne se soucieraient pas d’une fonctionnalité de journalisation back-end ou d’un changement mineur de configuration du nœud d’infrastructure Kubernetes – en gros, tout ce qui n’était pas basé sur l’interface utilisateur ou l’UX. Mais je me trompais. Un client spécifique était obsédé par toutes les fonctionnalités de notre produit et souhaitait en savoir plus sur chaque couche de ses fonctionnalités, et avait même de nouvelles idées de fonctionnalités utiles.

Leçon: Ne présumez pas du niveau d’intérêt d’un client. Entrez dans les détails avec eux. Souvent, les clients sont plus curieux qu’on ne le pense. En tant que chef de produit, vous pourriez finir par proposer une fonctionnalité dont le client ne veut pas, et ne pas fournir correctement les fonctionnalités qu’il souhaite, parce que vous ne lui avez pas demandé ce qu’il en pensait.

5. Croire qu’Agile est le seul moyen

Récemment, je faisais partie d’une équipe dans une grande entreprise de services informatiques qui proposait un produit d’engagement client. La portée du produit était qu’une petite équipe de consultants visiterait le site du client, déploierait notre produit d’analyse logiciel exclusif et analyserait le réseau du client pour détecter les problèmes et opportunités de connectivité cloud. Une fois le service fourni, un rapport était envoyé au client. Il s’agissait d’une simple livraison de produit Waterfall avec des livrables fixes, Horaire, et les coûts. Quelques heures après la livraison sur site, le client a découvert d’autres problèmes de réseau qui n’impliquaient pas la technologie que nous avions convenu d’analyser. « Soyons agile« , ont-ils déclaré, et nous ont demandé de modifier notre produit pour analyser les problèmes d’imprimantes, de pare-feu et de connectivité client. Cependant, les exigences du produit avaient déjà été convenues et nous devions éviter toute dérive du périmètre. Nous avons choisi de livrer le produit actuel, puis de prendre en compte les nouvelles demandes des clients et de les utiliser comme exigences pour une version future.

Leçon: Agile est une façon de gérer un produit ou un service, mais pas la seule. À un moment donné, vous devez finaliser les exigences et passer à l’étape suivante. Comment savoir quand vous avez fini de rassembler les exigences ? C’est simple : lorsque les exigences ont été convenues avec le client, et pas plus tard. Vous pouvez utiliser Agile pour développer votre projet, mais vous devez utiliser une livraison de type Waterfall. Parfois, la meilleure réponse au client est : « Parlons-en lors de notre prochain engagement » ou « Nous voulons que vous réalisiez de la valeur le plus rapidement possible, alors ne nous laissons pas distraire par de nouvelles exigences pour le moment ».

Mettre en œuvre ces leçons pour une approche robuste

Le recueil des besoins est une étape essentielle dans développement de tout produit et ne doit pas être négligé. La base d’un produit ne peut pas être ce que vous ne voulez pas qu’il soit, ni simplement une réplication de quelque chose déjà sur le marché. Interagissez avec votre clientèle innovatrice et précoce pour obtenir leurs informations précieuses, et n’ayez pas peur de poser des questions pour vous assurer de ne pas perdre de temps à créer des fonctionnalités inutiles. Sachez quand finaliser les exigences et passer à autre chose, ou utiliser un Approche en cascade pour livraison. Mettez en œuvre ces leçons pour recueillir les exigences dès le début de vos projets afin d’obtenir des équipes productives, des clients satisfaits et des résultats positifs.

LAISSER UN COMMENTAIRE

S'il vous plaît entrez votre commentaire!
S'il vous plaît entrez votre nom ici