* * * * *

Abonnez-vous !

Innovablog, Le Web où l’Innovation ordinaire : design, ergonomie, interfaces riches, web 2.0, eCommerce,…

  • A propos de l’auteur
  • Archives
  • Contacts
  • 12
    nov 07
    Catégorie : Web application

    Ne publiez pas la feuille de route de vos produits !



    37signalsCe billet se veut être une traduction libre d’un article de 37signals intitulé You don’t need a product road map. Il peut s’adresser à tous les développeurs et concepteurs d’applications sur l’utilité de publier sa feuille de route (road map). Pour information, voici la Roadmap du navigateur Firefox.

    Résumé / abstract

    Le message que veut faire passer l’article est que la publication d’une feuille de route est une mauvaise idée. Une feuille de route n’est pas une prédiction, c’est une promesse. C’est une promesse liée à une vision eue hier, pas aujourd’hui ni non plus demain. Elle définit des attentes et conduit à la déception lorsque les idées d’une personne à propos d’une future fonctionnalité ne sont pas conformes à ce qu’il a été promis de délivrer.

    Source : http://www.endhomelessness.org.uk

    La roadmap comme l’achat à crédit

    Il est extrêmement tentant de se lancer dans une feuille de route lorsque vous développez un logiciel. Vous récoltez la gloire en annonçant des caractéristiques souhaitées du produit sans même une version de démonstration. Cela ne nécessite aucune conception, aucune réflexion, ni même discipline pour répondre aux demandes de nouvelles fonctionnalités en écrivant des bullet points sur une feuille de route. C’est un peu comme l’achat à crédit, ce que vous ne payez pas sur l’instant est de toute façon à payer plus tard mais avec intérêt.

    Des promesses qui engendrent la déception

    Comme les spécifications fonctionnelles plus tôt dans la phase de développement, les feuilles de routes sont pleines de difficultés. Le processus habituel se révèle deux fois plus long, ce qui signifie que vous ferez inévitablement la promesse d’accords de principe. Lorsque tout ce sur quoi il faut trancher se résume en un slogan, à l’instar de “Onglet réunions, 4ème trimestre” (« Meetings Tab, 4th Quarter »), la promesse devient une boîte vide qui va cristalliser des attentes totalement différentes. Ce qui en résulte est la déception, lorsqu’une part seulement des attentes peuvent effectivement être satisfaites.

    Encore pire que les attentes déçues, est la pente glissante de vendre de l’espoir. Les clients doivent prendre de véritables décisions quant à savoir si votre logiciel convient à leurs attentes. Quelques fois, ce n’est pas le cas. C’est normal.

    Il est préférable de ne pas faire l’affaire avec certains clients plutôt que de tempérer leurs demandes et de les appâter avec de vagues promesses. Il est extrêmement rare qu’un seul élément soit réellement déterminant pour conclure avec un client. Si votre logiciel est suffisamment performant, la plupart des clients pourront se passer d’une ou de deux fonctionnalités qu’ils attendaient.

    Si ce n’est pas le cas, il est très facile pour les clients de se convaincre que le produit le deviendra, surtout si vous les confortez avec quelques illusions en acceptant quelques bons accords pour eux. Mais lorsque vous devez finalement délivrer, vous allez faire voler en miettes cette illusion et vous vous retrouverez avec des clients désabusés qui penseront que vous leur avez fait passer des vessies pour des lanternes.

    Dire oui aujourd’hui et pénaliser le futur

    Et le pire, s’il pourrait sembler à première vue gratuit de gagner des clients en leur promettant la Lune au terme de la fabuleuse feuille de route, ce n’est vraiment pas le cas. En acceptant de nouvelles entrées dans la feuille de route du produit vous pénalisez réellement le développement futur. Cette « dette » va en effet rétrécir votre degré de liberté. Votre capacité à poursuivre de nouvelles grandes idées à mesure qu’elles se présentent sera sérieusement atténuée si vous vous êtes déjà engagé sur de nombreuses demandes dont l’implémentation s’avère urgente.

    Les développeurs liés par les tâtonnements d’hier ne vont pas être libérés dans leur travail. C’est démoralisant d’être contraint de travailler sur quelque chose non pas parce que c’est la bonne chose à faire à ce moment-là, mais simplement parce qu’une promesse arrive à terme.

    Conclusion

    Les clients n’oublient pas vos promesses, surtout pas celles qui ont été faites en raison d’une feuille de route.

    Pour certains, la feuille de route peut donc s’envisager comme des oeillères aux mouvements du marché et aux attentes des clients, guidant le développement vers des objectifs définis parfois des mois (voire des années pour les projets énormes) en amont et non plus vers les tendances du marché tel qu’il l’est.

    Et vous, partagez-vous ce point de vue ? Est-ce qu’une feuille de route (ou raod map) peut s’envisager confrontée aux modes de développement “agile” ?

    Ressources :

    Cet article vous a plu ? Ne perdez plus aucune info : abonnez-vous gratuitement !

    A vous de jouer ! Laissez un commentaire :

    XHTML: Vous pouvez utiliser ces tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>

    Innovablog motorisé par WordPress
    Theme Wordpress par Olivier Favre
    Site Map
    RSS Feed
    Contenu intégralement sous licence Creative Commons