309 lines
13 KiB
Markdown
309 lines
13 KiB
Markdown
|
# 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 ...
|