Comment créer un produit que les utilisateurs détestent !

Conflits Product OwnerArticle librement traduit de l’anglais : Article d’origine chez Pichler (Merci à Romain pour le pointeur)

Voici une liste de comportements qui partent d’une bonne volonté mais qui sont en fait des erreurs assez classiques lors de l’application de Scrum et qui influencent négativement la réalisation du produit, et qui de plus, lorsqu’elles sont combinées peuvent conduire à un échec cuisant du produit.

  1. Etre trop pragmatique dans l’application du rôle de Product Owner : Pour essayer de répartir la charge de travail sur plusieurs individus ou un comité représentatif
  2. Viser à maximiser la diffusion du produit : Pour essayer d’avoir un produit qui contienne un maximum de fonctionnalités et qui puisse être distribué à un maximum d’utilisateurs différents
  3. Ne pas savoir dire NON : Pour essayer de ne pas désappointer les utilisateurs et mettre en péril le succès du produit
  4. Collecter et détailler tous les besoins dans le Product Backlog lors de l’itération 0 : Pour essayer d’être exhaustif afin de réduire les incertitudes et les risques, et permettre de planifier précisément la réalisation du produit
  5. Ne pas définir de priorités : Car de toutes façons, toutes les fonctionnalités doivent être dans le produit
  6. Ne pas demander très tôt du feedback aux utilisateurs : Car de toutes façons vous savez ce qui est le mieux pour eux puisque vous leur avez posé la question il y a quelques mois
  7. Planifier un livraison « Big Bang » : Pour essayer de surprendre vos compétiteurs, impressionner vos clients et dominer le marché en 1 seule nuit
  8. Lorsque l’on approche du jalon de livraison, mettre des fonctionnalités supplémentaire « à l’arrache » au détriment de la qualité : Car ce n’est pas important de s’occuper de la « dette technique » maintenant, et de plus les utilisateurs aiment bien les produits avec plein de fonctionnalités même si elles ne marchent pas très bien, et puis il sera toujours temps de corriger les problèmes dans une version ultérieure.
  9. Demander au Scrum Master d’agir comme un Chef de Projet : Car il est important que l’équipe soit dirigée pour donner son maximum et peu importe qu’elle explose en vol

Pour éviter ces erreurs, regardez vos projets à la loupe et cherchez ces comportements spécifiques, documentez vous en lisant des livres, des blogs et des articles, et participez à des conférences comme AGILE GRENOBLE 2010 🙂

4 réflexions sur « Comment créer un produit que les utilisateurs détestent ! »

  1. Bonjour Alexandre,

    Je ne comprends pas trop le premier comportement : « Etre trop pragmatique dans l’application du rôle de Product Owner ». Est-ce que tu pourrais donner un exemple ?

    Merci.

    Ma compréhension est qu’il ne faut pas considérer le rôle du PO comme un simple ensemble d’activités indépendantes que l’on peut répartir sur un groupe de personnes. Le pragmatisme est à rapprocher du bon sens qui pourrait faire répartir les tâches en fonction des compétences de chaque personne qui fait partie du groupe de PO. Par exemple : Toi tu écris les Stories car tu connais le méthode, moi je connais la technique alors j’assisterais aux démos de l’équipe, et toi tu es un ancien du métier alors tu définiras la valeur business
    Alex

  2. Bonjour Alexandre

    Comme Mathieu, je ne comprends pas le premier point.

    J’ai également un problème avec le point 4: Je suis d’accord pour ne pas « détailler » toutes les fonctionnalités lors du sprint 0 mais ne doivent elles pas toutes être listées? D’après moi, il faut 1. collecter toutes les fonctionnalités haut niveau, 2. les prioritiser 3.detailler en stories les fonctionnalités les plus prioritaires.

    Qu’en penses tu?

    Tres bien pour les autres points.
    Isa

    Le piège a éviter c’est de transformer la Spécification Fonctionnelle (ou Expression de Besoins) de l’ensemble du Produit en Product Backlog, et donc se retrouver par exemple avec plusieurs 100aines de Stories. Donc attention à ce que tu mets dans « lister toutes les Stories ».
    Et sinon, j’ai même expérimenté plusieurs fois avec succès le fait de démarrer une Release (3 mois) avec un périmètre réduit aux Stories de plus haute priorités (donc uniquement 60% de la vélocité prévue pour la Release) afin de se donner du temps et de la réserve en points pour prendre les feedbacks des utilisateurs lors des démos et réorienter si nécessaire la Release en cours.
    Alex

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *