Bon, derrière ce titre un peu éxagéré se cache une réalité que je découvre depuis que je me suis lancé comme prestataire freelance dans le monde du web en général et dans le monde de Drupal en particulier...

On me l'avait dit plusieurs fois, mais j'avais toujours cru à une certaine éxagération de la part des collègues un peu blasés, mais non... les clients sont... ne sont pas... enfin...

Avec la mise en place de quelques projets récemment je me rends compte que les clients réfléchissent rarement très longtemps à leurs besoins! Ils ont des idées très claires dans leur esprit, mais c'est le travail du prestastaire de leur sortir les vers du nez, faute de quoi tensions et déceptions sont au rendez vous!

Un exemple au hasard : un client pour un gros intranet que je suis en train de développer me demande de créer un « annuaire de contacts » pour gérer les contacts de son organisation. Je décide de ne pas utiliser de solution toute fait comme CIVICRM qui me semble un peu trop lourde pour ses besoins... Une fois la base de la solution mise en place (en suivant à la lettre son cahier des charges ainsi que notre « Use Case » bien défini, il me sort entre deux cafés la phrase choc

 

Client : « Quoi? Je ne peux pas utiliser ce système pour envoyer et reçevoir des mails? »

Moi : «  Je ne vois pas le rapport... »

Client : «  Ben, Alexis, il me semble que c'est évident que si on centralise nos contacts, on veut s'en servir pour nos mails..

Moi (qui commence à sortir les fichiers du Use Case et le Cahier des Charges signé par le client) : hummmm.....

Client: (qui me voit venir) : Ouiiiiiiiiii je sais qu'on en a pas parlé! Mais il me semble que c'est tellement évident que je ne pensais pas qu'on avait à en parler..

Moi: Hummmmmmmmmmmm

Client : Bon.. hé merde... combien de plus pour un webmail intégré à l'intranet

Moi: Ahhhhhh ok on peut discuter ;)

Bon ce dialogue est un peu romancé et que je suis chanceux d'avoir un client avec un certain budget, mais considérez cet autre exemple :

Autre client : Salut, le site est super, par contre je pense qu'on devrait tout réorgaaniser les sections

Moi : Pardon? Je croyais que le projet était complété ?

Autre client : ah oui mais tu sais, c'est en utilisant qu'on se rends compte des failles

Moi: Ouais, mais les rencontres ou je « t'emmerdais » avec les détails, elles servaient à ça!

Autre client : c'est beaucoup plus logique avec la nouvelle structure, je suis certain que c'est simple pour toi...

Moi : Hummmmmmm

Bref, j'en tire quelques conclusions que voici:

  • Les clients écoutent rarement quand vous préparez un Use case

  • Idéalement, il faut facturer du temps pour créer un prototype entre la phase « Use Case » (définition des besoins) et la phase de ralisation concrète.

  • Une planification obséssive représente au moins 50% d'un projet

  • Facturez toujours une marge d'au moins 15% du projet total à la fin pour les « nouveaux besoins »

  • Faites leur signer un document de définition des besoins très précis. Une fois cela fait vous pourrez facturer tous les ajouts conséquents sans discussion possible.

  • Définissez avec le client ce qui sera flexible et ce qui ne le sera pas

  • Développez en étapes, en ayant toujours le plus de retours possibles de la part du client à chacune de ces étapes

J'en oublie sûrement, je vous invite à ajouter ici votre liste de conclusions acquises avec votre propre expérience!

Technorati Tags: