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 ?