Source : Benefits of Eating Your Own Dog Food (UXPin)
Ça commence par un utilisateur qui se plaint, qu’on imagine être un râleur patenté et à qui on prête de multiples défauts (dont celui de ne pas savoir se servir de la magnifique solution que vous avez développée dans votre projet)… jusqu’à ce qu’un deuxième se manifeste, puis un troisième... Il faut alors accepter l’évidence : votre produit a un défaut !
Sachant que le coût engendré par ce défaut sur votre produit/service/livrable de projet augmentera au fur et à mesure que ce défaut demeurera, vous vous dites :
- « J’ai du travail »
- « Si seulement j’avais pu identifier et éradiquer ce défaut plus tôt ».
Alors, qu’attendez-vous pour vous mettre au dogfooding (également appelé « Eating your own dog food », que vous pouvez traduire littéralement par « manger sa propre nourriture pour chien ») ?
Qu’est-ce que le dogfooding ?
Rassurez-vous, il n’est pas question pour vous de partager l’écuelle de votre fidèle compagnon afin de réussir votre projet.
Le dogfooding est en fait une expression utilisée en entreprise (particulièrement sur les projets informatique), qui désigne l'utilisation de ses propres produits et services afin de se confronter directement à leurs qualités et défauts.
Vous développez un service de livraison de fruits de mer à domicile ? Une cravate mangeable dans l’avion ? Une application de géolocalisation des machines à café dans l’entreprise ? Essayez-les vous-même avant de les soumettre au jugement de vos futurs clients !
Cette méthode permet de montrer la confiance de l’équipe projet (et parfois de l’ensemble de l’entreprise) vis-à-vis de ses propres produits et de détecter très tôt des anomalies liées à ses produits.
C’est aussi le moyen d’assurer le marketing et la diffusion internes d’un produit, et de le faire connaitre de toute l’entreprise. Cette démarche contribue donc à une appropriation progressive du produit par tous ceux qui contribueront ultérieurement à son succès (les commerciaux, la production, la logistique… ).
Quelques exemples de dogfooding
En 1981, lorsque Michael Scott rédige une notice appelant son entreprise (Apple) à ne plus acheter de machines à écrire afin de privilégier les ordinateurs de la société, il est en plein Dogfooding ! Son objectif : montrer aux clients d’Apple la fiabilité des produits de l'entreprise (tellement fiables que l’entreprise elle-même les utilise).
Microsoft a développé l’Operating System Windows NT en travaillant sur des versions de développement de ce dernier. Cela permettait aux équipes d'utiliser le produit dans de réelles conditions et détecter les bugs encore plus rapidement.
Et lorsqu’il n’y a pas assez de dogfooding ? Une partie de l’échec de Facebook Home était liée au fait que l’équipe de développement de ce projet disposait d’iPhones, alors que l’application était développée principalement pour Androïd. De ce fait, l’équipe a délaissé des widgets et autres dossiers applicatifs dont les utilisateurs d’Android avaient besoin.
Les défis du dogfooding
Tout d’abord, il convient de noter que tous les projets ne se prêtent pas à la pratique du dogfooding (ex : construction d’une centrale électrique, projets pharmaceutiques…). S’il est possible de vérifier que le produit correspond bien à un cahier des charges fixé à l’avance, il est parfois impossible de le tester en interne.
D’autre part, le défi est d’identifier en interne des utilisateurs suffisamment représentatifs de la cible visée par le projet. Si je lance un produit destiné au 3ème âge et que je le fais tester à des collègues de la génération Y, je prends un risque que certaines fonctionnalités soient considérées comme des bugs par les uns alors qu’elles sont valorisées par les autres.
Enfin, au-delà du fait de faire goûter, il faut réussir à capter les retours des testeurs internes de façon suffisamment formelle pour qu’ils soient exploitables.
Un « journal utilisateur » peut par exemple être mis à disposition sur un dossier partagé et alimenté progressivement et librement. Il peut intégrer les questions suivantes :
- Où étiez-vous lorsque vous avez utilisé le produit ?
- Que souhaitiez-vous faire ? Combien de temps cela vous-t-il pris ?
- Décrivez quelque chose que le produit a fait pour vous faciliter la vie
- Déposez une image/photo/copie d’écran de quelque chose qui vous a frustré
Un questionnaire « Alpha-test » (nommé ainsi car c’est un test interne, pas encore ouvert au public comme le sera par la suite le « Bêta-test ») réalisé sur un outil comme SurveyMonkey peut également vous permettre de collecter des informations qualitatives et quantitatives (surtout si vous avez la possibilité de solliciter l’ensemble des collaborateurs de votre entreprise). Il permet en règle générale d’identifier des bugs mineurs et majeurs, et des fonctionnalités manquantes, et il donnera des bases solides pour un test avec des vrais utilisateurs externes.
Et vous, êtes-vous adepte du dogfooding sur vos projets ?
