L’un des plus grands défis auxquels les équipes de développement de produits sont confrontées est simplement de savoir comment décider quel produit construire. Dans le cas des équipes qui travaillent à partir d’une spécification de produit, en particulier dans le développement de matériel, les ingénieurs ne sont généralement pas autorisés à commencer à travailler avant qu’elle ne soit terminée et approuvée. Et étant donné que la plupart des délais de développement sont incroyablement courts, il n’y a souvent pas assez de temps pour envisager des solutions alternatives une fois que de nouvelles informations apparaissent.
Une façon d’envisager ce défi est représentée ici. Vous pouvez imaginer que le cercle représente toutes les façons possibles pour l’équipe de construire le produit. Et ce minuscule point bleu est la spécification d’un produit particulier. Cette spécification de produit définit exactement le produit sur lequel les développeurs doivent se concentrer et construire.
Dans ce post, je vais d’abord décrire certaines des méthodes courantes utilisées pour se mettre d’accord sur une spécification de produit. Ensuite, j’explorerai les problèmes liés à ces méthodes et comment ils peuvent conduire à la construction de produits à partir d’une spécification qui ne résout pas réellement les problèmes de votre client.
Je dois dire que ma perspective provient de 10 ans d’expérience de travail dans l’industrie des semi-conducteurs analogiques et à signaux mixtes, d’abord en tant qu’ingénieur d’applications, puis en tant que définisseur de produits. Maintenant, je suis consultant ici à Jama.
Les pires façons de créer une spécification de produit:
Demander à votre client ce qu’il veut que vous construisiez
Une façon de commencer est de demander à vos clients ce dont ils ont besoin. Cela peut se faire en attendant une demande de devis (RFQ) émise par le client, ou de manière moins formelle, par des réunions et des discussions. En général, cette approche vous permet d’apprendre quelle solution ou quel produit ils utilisent aujourd’hui et ce qu’ils aimeraient voir changer dans un avenir très proche. D’une certaine manière, vous agissez en tant qu’entrepreneur et votre client est responsable de tous les détails de la spécification.
Du fait que ce scénario demande d’itérer sur un produit existant, il y a une forte probabilité que vous vous retrouviez avec une idée très spécifique que vous pouvez définitivement mettre en œuvre.
Cependant, il y a plusieurs problèmes avec cette approche :
- Ce que votre client vous dit sur sa stratégie de produit, il le dit probablement aussi à votre concurrence, et un objectif clé du projet est probablement de faire quelque chose de moins cher que la solution existante. Vous allez vous retrouver dans une guerre des prix.
- Votre client est déjà fixé sur un type de solution, en fonction de ce qu’il avait acheté auparavant, ce qui rend difficile de suggérer quoi que ce soit qui puisse mieux répondre à ses besoins.
- Le calendrier est probablement extrêmement agressif, laissant peu d’opportunités pour construire quelque chose de nouveau, ou permettant une véritable innovation.
- Votre client peut ne pas être au courant des nouvelles technologies, ou il peut simplement ne pas savoir ce dont il a besoin.
Dans ce cas, vous comptez sur votre client pour traduire ses exigences internes en une spécification pour vous, plutôt que de rédiger des exigences pour un produit dont le marché plus large a besoin et qu’il achètera.
Alors que vous développez le produit, votre équipe devra inévitablement faire des compromis pour diverses raisons. La seule façon d’être sûr que le meilleur choix est fait est de revoir les modifications apportées à la spécification du produit résultant avec votre client. Si vous ne le faites pas, vous courez le risque de construire un produit qu’il n’acceptera pas. Mais comme l’équipe de conception sera soumise à une pression extrême pour exécuter un programme agressif, il y a de fortes chances qu’elle fasse des compromis sur le produit sans disposer de toutes les meilleures informations. Cela augmente encore le risque de construire le mauvais produit.
Cette approche fonctionne dans la mesure où un produit est livré. Si vous êtes dans le domaine de la livraison de composants de commodité, alors c’est parfait. Si vous recherchez une solution unique qui défend la marge brute, alors ce n’est pas la meilleure approche.
POSTE LIÉ : Comment réaliser une meilleure analyse d’impact sur les relations en amont et en aval
2. Demander à un ingénieur de rédiger l’intégralité de la spécification
Un autre scénario courant est celui où un ingénieur, ou un autre membre de l’équipe en contact avec le client, envisage une solution en fonction des conversations qu’il a eues avec un ou quelques clients. L’équipe se rallie à cette idée, et avec une poussée d’élan interne, les exigences sont rapidement documentées et les efforts de l’équipe se tournent rapidement vers la rédaction des spécifications du produit et le développement de la solution.
Une fois qu’une solution est complète et prête à être commercialisée, certaines équipes valideront leur idée avec les clients, mais puisque l’équipe présente une solution – et non l’exploration d’un besoin – la discussion tend à porter sur les détails de la spécification du produit. Ces équipes n’auront pas l’occasion de découvrir si la solution résout un problème.
Typiquement, dans ce scénario, les exigences du produit sortent directement de la tête d’un individu et sont ensuite capturées dans une longue fiche technique, et le reste de l’équipe transige en utilisant la spécification documentée. Chaque fois que l’équipe rencontre un conflit où un compromis doit être fait, la personne qui a rédigé les exigences doit décider des compromis corrects de manière indépendante, avec peu ou pas d’informations nouvelles. De plus, si cette personne n’a pas recherché ni validé les exigences, alors l’équipe construira le mauvais produit.
Pourquoi ces approches ne mènent pas au succès
Ce que les deux approches précédentes ont en commun, c’est que l’accent est mis sur l’obtention d’une spécification de produit fini aussi rapidement que possible. Les équipes sont tellement pressées de commencer à construire quelque chose et de respecter le délai du client qu’elles ne s’assurent pas d’abord que ce quelque chose est le bon quelque chose.
De plus, la connaissance des exigences existe chez un seul individu de l’équipe. Cet individu est soit la personne en interface avec le client commanditaire, soit la personne qui a eu l’idée du produit. Dans un cas comme dans l’autre, le reste de l’équipe est dépourvu de tout contexte pour la solution, la raison pour laquelle ils construisent ce produit, et ne peut donc pas faire de recommandations.
Le résultat est souvent que les produits sont tués plus tard qu’ils n’auraient dû, après que beaucoup de temps et d’argent aient été gaspillés, ou que les équipes créent des produits qui ne sont pas réussis ou des produits me-too qui rivalisent largement sur le prix. Aucune de ces situations n’est bonne pour les affaires.
POSTE LIÉ : 8 choses à faire et à ne pas faire pour rédiger des exigences
Les meilleures façons de créer une spécification de produit :
La meilleure façon de construire des produits que vos clients achèteront est de sortir et de parler à votre marché cible bien avant de commencer à rédiger votre spécification. Tout d’abord, vous devez articuler votre énoncé de problème.
Un énoncé de problème de produit est constitué de quelques phrases ou paragraphes qui décrivent un besoin du marché. Ils sont écrits du point de vue du persona qui a le problème et – c’est critique – ne disent rien sur la façon de résoudre réellement le problème. L’objectif de cette étape de l’exploration est de transmettre une compréhension du problème et un sens de la valeur associée à sa résolution.
Un énoncé de problème est généralement composé de trois parties :
- La première est le persona, ou une description de qui a le problème. Il est utile de décrire le persona de façon très détaillée séparément, puis de faire référence à un persona particulier dans l’énoncé du problème pour éviter de répéter la même description du persona.
- Vient ensuite la description du problème. Plus il y a de détails, mieux c’est ici. Vous voulez vous assurer que le besoin est clair comme de l’eau de roche. Donnez également un nom au problème. Cela permet aux équipes de s’y référer plus facilement au cours du projet.
- Enfin, écrivez une description de la fréquence à laquelle le problème se produit. Si le problème se produit rarement et a un faible impact, alors sa résolution est de faible valeur. Si le problème se produit fréquemment et a un impact élevé, alors la valeur de sa résolution sera élevée.
Vous pouvez commencer par demander aux clients quels sont les problèmes qu’ils ont et qu’ils pensent que vous pouvez résoudre, mais vous devez creuser plus profondément pour arriver aux énoncés de problèmes vraiment précieux ou aux pépites d’or. Ces pépites d’or proviennent généralement du développement d’une compréhension profonde du marché et du rassemblement d’informations provenant d’un large éventail de sources.
Si vous y parvenez, vous finirez par identifier un problème que vous pouvez résoudre et pour lequel votre client paiera.
Pendant le processus, veillez à ne pas vous heurter à des faux positifs ou négatifs. Écouter trop de personnes à l’intérieur de votre entreprise ou seulement un petit nombre de clients peut vous conduire à valider ou abandonner un problème à tort. Parlez à autant de clients que possible et recueillez autant de données que possible.
Revenons à notre diagramme de tous les produits possibles que nous pouvons construire.
Cette fois, nous avons ajouté des lignes qui se croisent et qui représentent des contraintes. Si nous pensons aux énoncés de problèmes comme des lignes traversant le cercle, alors un bon énoncé de problème fondé sur la compréhension du marché délimitera une zone dans le cercle qui représente toutes les solutions acceptables. Tout ce qui se trouve dans cette zone résout le problème et serait acceptable pour le client.
Vous remarquerez que la taille de cette zone est bien plus grande que les cercles précédents de RFQ et d’idées de produits. Cela s’explique par le fait que ces énoncés de problèmes et ce contexte délimitent intentionnellement la solution de manière aussi lâche que possible pour permettre à de nouvelles idées de se manifester.
L’idée est de donner à l’équipe de conception un maximum de flexibilité pour créer la solution la plus innovante possible dans le cadre des contraintes.
POSTE LIÉ : Liste de contrôle : Sélectionner un outil de gestion des exigences
Comment arriver à un énoncé final du problème ?
Voici mes recommandations :
- Débutez en assignant à quelqu’un pour chaque projet la responsabilité d’être la voix du client.
- Puis, chargez cette personne d’identifier les problèmes du marché uniquement à partir des informations recueillies sur le marché.
- Assurez-vous que ces problèmes du marché sont documentés et partagés dans un endroit auquel toute l’équipe a accès.
- Ecrire une justification pour chaque énoncé de problème de marché qui explique pourquoi c’est un problème et combien il est important de le résoudre
- Ajouter un jalon dans le plan de projet où les énoncés de problèmes doivent être examinés et approuvés par l’équipe avec une analyse de rentabilité.
- Alors que l’équipe commence à développer une solution, revenez périodiquement à la liste des énoncés de problèmes pour rappeler à chacun quelle est la cible.
- Pour chaque problème, saisissez une liste des caractéristiques du produit qui résoudront le problème.
- Si un problème ne peut pas être entièrement résolu, réexaminez l’analyse de rentabilité pour vous assurer que le produit est toujours viable.
De l’énoncé de problème à la spécification
Maintenant que vous avez vos énoncés de problèmes et que l’équipe s’est familiarisée avec eux, commencez à développer en collaboration une spécification de produit. Puisque tous les membres de l’équipe comprennent le problème à résoudre, chacun peut contribuer à la spécification.
Parce que vous avez fait le travail initial d’identification du problème que vous résolvez, dans les contraintes identifiées, et que votre équipe a envisagé plusieurs façons de livrer la solution, vous avez suffisamment d’informations pour rédiger la spécification du produit.
Libérer la spécification du produit par petits lots
La meilleure approche ici est de libérer de petits morceaux de la spécification à l’équipe dès que possible pour obtenir un retour rapide. Cela permettra d’éviter de perdre du temps en empruntant la mauvaise voie et facilitera grandement la tâche de l’équipe pour fournir un feedback de haute qualité.
Non convaincu ? Considérez ceci : Que se passe-t-il si vous recevez une fiche technique de 200 pages à examiner ? Vous regardez probablement les premières pages, puis survolez le reste.
Maintenant, que se passe-t-il si vous recevez un document d’une page ? Vous l’examinez probablement en entier. Deux cents documents d’une page donneront lieu à un bien meilleur retour qu’un seul document de 200 pages.
Référez-vous à l’énoncé du problème pour vous assurer que vous êtes sur la bonne voie
Aussi, au fur et à mesure que vous développez la spécification, vérifiez que le produit est toujours une solution valide au problème. Il est facile d’être pris dans le compromis inhérent au développement d’un produit et d’oublier de vérifier si vous êtes toujours sur la cible.
Cette approche gère également les attentes de vos parties prenantes. Comme le processus est contrôlé, il existe un cadre et une transparence qui empêchent quiconque d’outrepasser les décisions. À tout moment du projet, vous serez en mesure d’expliquer exactement quelle valeur votre produit offre et pourquoi il doit avoir les caractéristiques que l’équipe a spécifiées.
Concevoir des produits en fonction des besoins du marché est essentiel pour réussir
Je reconnais que dans certaines industries, c’est un grand changement par rapport à la façon dont les produits ont été conçus et construits. Mais à mesure que les marchés deviennent plus compétitifs et que les produits deviennent de plus en plus complexes, se contenter de livrer une autre itération de quelque chose que vous avez déjà construit ne vous permettra pas de rester longtemps en activité.
Pour en savoir plus sur la façon de rédiger les exigences de manière à ce que toutes les parties prenantes aient une compréhension claire des besoins de développement, téléchargez notre eBook, Best Practices for Writing Requirements.
LIRE L’EBOOK
.