13 KiB
Le besoin métier
Ayez une vision de votre produit
Votre idée est peut-être géniale, révolutionnaire, utile ou juste rentable (aucun mal à cela). Elle va peut-être changer le monde, ou plus modestement faciliter le quotidien de pas mal de monde.
Pensez au premier téléphone portable : en voilà un produit qui a changé bien des choses; impossible aujourd'hui d'imaginer vivre sans : sans accès à votre boîte mail, sans appareil photo, sans sms, sans carnet de contacts... Mais, attendez, le premier téléphone, il ne faisait pas tout ça ! Non, rappelez-vous, un téléphone portable, à la base, ça sert à pouvoir téléphoner n'importe où.
Tout le reste, c'est utile, pratique, génial, sans doute indispensable au quotidien, bref, c'est tout autant révolutionnaire. Mais si on doit définir le téléphone portable en quelques mots, c'est "juste" un moyen d'échanger vocalement et instantanément de l'information entre deux intervenants, où qu'ils soient dans le monde.
Votre produit est pareil : il doit pouvoir se définir en une courte phrase, et en réalité ne sert qu'à une chose. Si si, tout le reste est utile commercialement, esthétiquement, fonctionnellement... Mais votre produit possède un coeur, et la première chose à faire est de l'identifier.
Cela vous permettra de savoir vraiment ce dont vous avez besoin. Si vous demandez au père de famille, dont nous parlions plus haut, de décrire sa voiture, il va peut-être dire qu'il veut un break Citroen de 120 chevaux gris métallisé, avec 5 portes. Il sait ce qu'il veut... Pourtant il oublie l'essentiel : la voiture doit lui permettre de se rendre d'un point A à un point B.
Oui, c'est évident : une voiture permet de se déplacer. Mais pourtant, évident ou pas, une voiture, ce n'est rien d'autre ; c'est ce qui reste une fois qu'on a enlevé tout le reste : retirez la climatisation, la peinture métallisée, le cuir... Il nous reste le coeur de la voiture, ni plus ni moyen qu'un moyen de locomotion.
Allez même plus loin, et imaginez une voiture sans moteur ; est-ce toujours une voiture ? Oui, sans aucun doute, le moteur n'est qu'un moyen pour cette fin, ultime, de permettre aux gens de se déplacer : une voiture à cheval n'en reste pas moins une voiture. Certes, elle n'est peut-être pas optimale, pas rapide, pas jolie, tout ce que vous voudrez... Mais C'EST UNE VOITURE. Et peut-être moins cher en plus !
Pour votre logiciel, votre intranet, votre application mobile, c'est pareil : identifiez le coeur de votre produit, ce qui fait son essence même, ce sans quoi votre produit n'est plus votre produit, et là vous aurez de bonnes bases pour commencer.
Comme le dit Liz Keogh, chaque projet informatique doit poursuivre une vision. Cette vision répond souvent à un besoin économique (réduire des coûts, améliorer la productivité), voire parfois à des souhaits différents (améliorer le quotidien des gens, changer les mentalités...). Dans tous les cas, tout ce que vous allez mettre dans votre produit doit poursuivre cette vision.
Tout ce que vous mettez dans votre produit doit poursuivre une vision
Le bon produit est celui qui répond à votre vision
Quand ils ont conçu Basecamp, un logiciel de gestion de projets aujourd'hui reconnu et plébiscité, Jason Fried et David Heinemer avaient une vision : faciliter la vie des différents intervenants lors de leurs créations de projets. Cette vision est visible partout dans Basecamp : simple, facile d'accès, rapide et ergonomique, il facilite réellement la vie de celui qui l'utilise.
Ils auraient pu choisir de concevoir un logiciel riche, multi-fonction et polyvalent ; ils ne l'ont pas fait. Pourquoi ? Tout simplement parce que cela n'aurait pas servi leur vision. On pourrait vouloir un CRM dans Basecamp, ou un intranet, ou tout ce que vous voudrez. Tous ces modules pourraient être forts agréables, utiles et d'excellents arguments commerciaux. Mais ils ne servent pas la vision du produit. Et c'est justement pour ça que Basecamp plaît autant : il ne fait qu'une chose, mais il le fait bien !
Pensez également à ceci : certes Basecamp n'est pas riche fonctionnellement, mais
- Il est largement suffisant dans 90% des cas
- Il a été d'autant moins coûteux à concevoir
- Il a été d'autant plus rapide à développer
- Chaque fonctionnalité a pu être testée en profondeur et est fiable
- Il ne souffre d'aucune complexité inutile et est rapide
- Les équipes de développement se sont focalisés sur un domaine fonctionnel simple
- Tout changement ou évolution est simple à mettre en place
Tout cela serait impossible si Jason Fried et David Heinemer ne s'étaient pas focalisés sur leur vision du produit et n'avaient pas refusé systématiquement d'ajouter des fonctionnalités qui ne répondent pas à cette vision initiale.
Rappelez-vous : vous êtes le seul maître à bord. C'est à vous de vous servir de votre vision du produit pour limiter le superflu et focaliser toute l'énergie disponible (développeurs, serveurs, graphistes, ergonomes...) sur ce qui répond à cette vision, autrement dit sur ce qui est vraiment utile.
Retirez de votre Produit tout ce qui ne sert pas votre Vision
Vous attendez des résultats métiers
Vous avez probablement souvent entendu cette expression : ce qui compte, ce sont les résultats !
Bon, je ne vais pas vous dire que la fin justifie les moyens, pas du tout. Non, ce que je veux dire, c'est qu'en investissant du temps et de l'argent dans votre projet, vous ne devez jamais oublier que ce qui compte ce sont les résultats métiers (ou fonctionnels) de votre projet. Ces résultats qui justement servent votre vision.
Pensez-y : chaque fonctionnalité, chaque élément d'interface, chaque bouton, chaque champ de saisie... tout cela doit fournir un bénéfice à l'utilisateur de votre produit !
Ça peut paraître évident... Mais alors pourquoi consacrer autant d'énergie sur des choses inutiles fonctionnellement ? Si si, ça arrive tout le temps ! En tant que développeur j'ai souvent eu l'occasion de le voir : une grosse partie de mon temps était consacré à du superflu (gestion des profils utilisateurs hyper poussée, interfaces graphique à la iGoogle, optimisation prématurée des performances...), alors même que les fonctionnalités métier n'étaient pas encore finies, voire même pas spécifiées !
L'énergie dépensée sur un projet doit être corrélée aux bénéfices que votre produit en tirera pour satisfaire votre vision. Si, alors que les fonctionnalités métiers ne sont pas pleinement finies, testées, fiables, éprouvées et ouvertes aux changements, l'énergie dépensée ne sert qu'à "vendre du rêve", vous risquez la catastrophe.
Concevez votre produit, non pas pour le vendre, mais pour qu'il réponde à un but (votre vision). Si vous y arrivez, vous aurez à ce moment là en main les meilleurs atouts pour le vendre.
Le bénéfice sera d'autant plus grand que, au lieu de perdre du temps sur des choses moins utiles, vos développeurs, prestataires ou la société qui a en charge votre projet, vont mieux comprendre votre besoin, sans se perdre en détails inutiles pour le moment.
En vous focalisant sur les fonctionnalités métiers, vous allez aussi pouvoir plus rapidement vous confronter au feedback de vos futurs utilisateurs. Les changements fonctionnels de votre produit seront ainsi réalisés plus tôt, et donc moins coûteux.
Ne concevez pas votre produit pour le vendre, mais pour qu'il réponde à un but. Vous aurez alors en main les meilleurs atouts pour le vendre
Re-priorisez souvent, changez souvent
Vous l'avez vu : votre produit doit se focaliser sur ce qui apporte à un métier, sur ce qui répond à votre vision.
C'est bien beau, mais on en est tous conscients : un aspect métier peut être essentiel aujourd'hui, mais totalement inutile ou différent demain ! Comment gérer ces changements dans votre projet ?
Vous vous en doutez, de nombreuses personnes ont tenté de répondre à cette question. Parmi elles, les (nombreux) auteurs du Manifeste Agile. Voici certains des principes de ce Manifeste tel qu'ils sont présentés sur http://agilemanifesto.org, qui nous intéressent particulièrement :
"Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée.
Accueillez positivement les changements de besoins, même tard dans le projet. Les processus Agiles exploitent le changement pour donner un avantage compétitif au client.
Livrez fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts."
C'est assez clair : si l'on suit ces principes, largement reconnus aujourd'hui dans le monde de l'édition logicielle, le produit doit être confronté le plus tôt possible au monde réel pour obtenir un feedback régulier des potentiels utilisateurs.
Ce feedback régulier va vous permettre de réorienter votre produit afin de supprimer, modifier ou ajouter des comportements dans celui-ci. Vous avez donc besoin de pouvoir re-prioriser certains éléments, de changer en cours de route le parcours de développement de votre site, logiciel, application ou intranet.
En un mot : vous avez besoin de confronter votre produit aux utilisateurs. Plus vous le confronterez souvent, plus votre produit sera compétitif, et plus vous aurez besoin de faire évoluer votre produit.
Vous l'avez compris : vous avez besoin de changements tout au long de la phase de conception de votre produit. Cependant, vous l'avez sans doute déjà vécu, tout changement dans un produit informatique est généralement :
- long
- coûteux
- source d'erreurs et de bugs
- difficile et démoralisant pour les équipes
L'idée pour résoudre ces difficultés est assez simple, mais parfois difficile à mettre en place, comme nous allons le voir.
Vous devez trouver une solution pour faciliter le changement
Gérez votre besoin de changements
L'idée du Manifeste Agile pour gérer le changement peut paraître simple parce qu'il "suffit" (entre autres) de modifier les cycles de développement de votre produit. Généralement, un produit est conçu d'un seul bloc : on développe un produit non fini pendant une période assez longue, et on livre un produit fini (enfin, ça c'est qu'on espère !) à la fin. Cette méthode implique un effet tunnel assez long et souvent dévastateur.
Qui ne connaît pas le célèbre tableau de Léonard de Vinci : La Joconde ? Que se serait-il passé si Léonard de Vinci avait dû peindre Mona Lisa comme on travaille généralement sur un projet informatique ? Cela donnerait à peu près ceci :
![ Méthodologie classique : le travail et découpé en lots, chaque lot est totalement réalisé avant de passer à la suite. Le changement fonctionnel en cours de route est difficile. ] (mona-lisa-incremential.jpg)
Le travail est tout de suite très fin, et on ne peut le livrer qu'à la fin... Difficile dans ces conditions d'accepter le changement !
Maintenant examinez la méthode proposée par les fondateurs du Manifeste Agile. Les équipes techniques vont travailler en cycles, itérativement, de manière à livrer régulièrement un produit, certes moins complet, mais exploitable et sur lequel il est possible de fournir un feedback.
Le rythme de ces itérations, et leurs objectifs, sont fixés en accord avec tous (équipes techniques, fonctionnels...), et chacun s'engage à faire le maximum pour livrer un produit exploitable. Voici ce que cela donnerait cette fois-ci pour notre cher Léonard :
![ Méthodologie agile : le tableau s'affine petit à petit. Le changement fonctionnel est facile, même en cours de route] (mona-lisa-iterative.jpg)
Bien sûr, un logiciel qui prendra un an à être développé ne sera pas exploitable commercialement au bout de trois itérations de deux semaines ! Par contre vous aurez moyen d'obtenir des premiers retours utilisateurs, et surtout vous allez pouvoir reprioriser et changer certains éléments en cours de route : la forme du visage ne vous convient pas ? Faites la changer lors d'une prochaine itération ! Les couleurs sont trop ternes ? Priorisez un changement des couleurs pour voir ce qu'en pensent vos futurs utilisateurs. Bref, vous avez compris l'idée !
Les principes agiles sont simples et évidents, mais ils peuvent être étrangement contre-intuitifs à mettre en place : souvent, les équipes (techniques et fonctionnels) ont du mal à se détacher de leurs anciennes pratiques, quant bien même elles adhèrent aux concepts agiles.
J'ai à plusieurs reprises eu l'occasion de voir des entreprises adopter des méthodologies agiles trop brusquement, ou d'une manière inadaptée. Les méthodes agiles ne sont pas un remède miracle à tous les maux, il serait faux de croire que du jour au lendemain des équipes peuvent oublier toutes leurs anciennes pratiques et que par magie vous serez livré à temps et avec un produit fini.
Mais le changement vers l'agilité peut être simple et rapide, sous deux conditions :
- vous DEVEZ vous impliquer dans votre projet ! C'est à vous de prioriser, de dire ce qui va, ne va pas, régulièrement.
- Vous devez accepter de vous faire aider : les changements à adopter ne sont pas que méthodologiques, ils sont aussi conceptuels. De nombreuses sociétés agiles sauront vous guider et vous conseiller. Et croyez moi, l'investissement en vaut la peine, largement !
Itération, feedback; itération, feedback; itération ...