SAND-framework/data/doc-prince-book-generation/doc/tome1/Contents/func-le-besoin-metier.md

# 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](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 ...