Procédure de développement d'application
On me demande parfois comment je m'organise pour un développement d'application / site web. Comme ça peut toujours servir, j'ai décidé de vous faire part de la procédure que j'utilise. Bien que je ne développe quasiment que des applications web, je pense qu'elle peut s'appliquer à tout type de développement
Premier contact avec le client
Bon ben voilà, un client potentiel vient de vous contacter, c'est la fête, il veut vous faire développer une grosse application youpi. Bon. Mais pour ne pas faire n'importe quoi, il faut bétonner la chose. Non, rangez vos bétonneuses, on ne parle pas de la même chose. Le gros problème avec les clients, c'est qu'ils ne savent pas ce qu'ils veulent. Comme ils ne savent pas ce qu'ils veulent et que vous ne pouvez pas le deviner pour eux, si vous commencer le développement sans avoir toutes les informations en main, il arrivera un moment ou le client dira un truc du style oui mais heu c'est à dire que ça là je le voyais pas comme ça. Et là, ben vous serez bien emmerdé.
Pour éviter ce genre de désagréments, il convient d'établir un cahier des charges. Mais comme on veut bétonner, on va en faire deux.
Le cahier des charges commercial
C'est bien connu, les clients n'y connaissent rien en technique. C'est pour ça que pour commencer, on va tenter de parler leur langage. Le cahier des charges commercial est celui que le client comprend. Il doit être élaboré par ou avec le client. Il faudra a priori plusieurs rendez-vous commerciaux pour finir ce cahier des charges. Ces rendez-vous se dérouleront généralement avec le client, vous (le développeur) et un commercial de chez vous (on sait jamais ça peut servir). Laissez le client exprimer ses idées, puis reformulez les et complètez les, d'une manière compréhensible pour lui. Ne lui parlez pas de technique, ne lui dites pas que ce qu'il veut est très complexe, il s'en tape. Ne lui dites pas (encore) que ce qu'il veut est impossible, vous n'avez rien préparé pour le lui prouver.
Une fois ce cahier des charges établi, il doit être validé par les deux parties, on peut ensuite passer au deuxième cahier des charges.
Le cahier des charges technique
C'est celui que vous comprenez et que le client ne comprend pas. Reprenez le cahier des charges commercial point à point, et traduisez le en termes techniques. Si un point est complexe, détaillez le au maximum, si un point vous paraît impossible à gérer, préparer un argumentaire, il va falloir que le client comprenne. Une fois le cahier des charges terminés, étudiez les technologies à votre disposition, pesez bien le pour et le contre de chaque technologie avant de vous décider. Il faudra être en mesure de faire comprendre au client que non, 600ko de GIF/Flash par page c'est pas bien (dans le cadre d'un site web of course).
Une fois votre cahier des charges techniques betonné, vous pouvez le faire valider par le service technique du client, si il en a un. Si il n'en a pas, vous pouvez toujours essayer de le lui faire valider, mais bon, valider un cahier des charges auquel on ne comprend rien ne présente pas grand interêt.
Calendrier de développement
Une fois vos cahiers des charges bien en main, vous pouvez vous atteler au calendrier de développement. C'est ce qui planifiera votre développement et vous permettra de donner une estimation plus ou moins correct du temps de dévelopement recquis au client. N'hésitez pas à prévoir large, il vaut mieux surestimer le temps nécessaire que le sousestimer. Le temps de développement doit inclure le développement de l'application bien sur, mais aussi d'autres joyeusetées comme le recettage.
Dernière ligne droite
Voilà, vous avez vos cahiers des charges, votre calendrier de développement, et vous avez maintenant hâte de commencer le développement. Ca se comprend, mais il ne faut pas mettre la charrue avant les boeufs. Vous devez modéliser votre application avant toute vélléité de développement. La modélisation d'une architecture d'application robuste est ce qui vous évitera d'échouer dans les limbes du rustinage a outrance (vous avez vu comme je parles bien ?). Un projet mal pensé est un projet qui sera difficile à maintenir et à faire évoluer. Aidez vous de schémas, c'est très utile. Si vous connaissez UML, et bien faites en. N'hésitez pas à vous faire aider ou à faire valider votre architecture par une personne tierse si vous en ressentez le besoin.
Go Gi Joe.
Vous avez désormais tous les éléments en main pour développer sereinement:
- des cahiers des charges qui vous permettront de remettre le client à sa place en cas de feature request tardive
- un calendrier de développement qui vous permettra de remettre le client à sa place en cas de protestation sur le temps de développement
- une architecture qui devrait vous permettre de développer rapidement votre application relativement proprement
Elle est pas belle la vie ?
Comments
Article très intêressant en tout cas :) à mettre dans les marque-pages sans aucun doute !
à très bien mirmo ;)
PS: tu rox.
Bon, avec tout ça, je peux me remettre au développement :D
(et ouais, tu parles bien ;opp)
ya pas de PS qui tiennent ! TU ROX !
Ouais c net... quel bô gosse ce ash... c'est vraiment cool ses conseils !
c vrai que bien rase il est plutot pas mal ^^
Bonjour,
J'ai recu un cahier des charges pour effectuer un develloppement mais je suis en concurence, est ce que quelqu'un aurait un modele de "dossier de proposition".
Merci
Bonjour,
Je trouve la démarche très interessante et en effet un garde fou contre les dérives en cours de projet. Nous on ne le fait pas suffisamment et régulièrement on s'en mord les doigts.
Le manque de cahier des charges de la part du client est un vrai problème auquel nous sommes confrontés régulièrement. A la fois le client ne sait pas ce qu'il veut mais en plus il le veut tout de suite ....
J'aurai voulu savoir si tu chiffres ou si tu reportes les jours de rédaction du cahier des charges 'commercial' dans ton chiffrage final et si oui comment le présentes tu au client. Parce que tu dois passer rapidement 2/3 jours entre les phases de réunion et les phases de rédaction et cela a un coût non négligeable qui peut être un frein à l'application de la méthode.
Merci !
Très bonne question ! Ca fait longtemps que je ne suis plus impliqué dans ce genre de process mais je dirais que la rédaction du cahier des charges, si elle n'est pas effectuée par le client en amont, relève du domaine du "conseil" et peut donc être incluse dans le devis et la timeline. Après bien évidemment, toute la difficulté et de faire comprendre au client que c'est une étape nécessaire même si cela rajoute un cout et/ou du temps...