Peut-on réussir un forfait ?

Plus je travaille avec des SSII et plus je trouve que les projets gérés au forfait se passent mal. Les torts sont souvent partagés, mais je constate plusieurs causes d’échec :

Le client est incapable de rédiger un cahier des charges

Là je sais de quoi je parle, j’ai souvent le rôle de client en ce moment

Le besoin évolue, n’est pas forcément clair et donc il est très dur de rédiger un cahier des charges exhaustif. Le client est obsédé par la garantie de réalisation qu’apporte le forfait, alors qu’il est incapable d’exprimer correctement son besoin. Pire je vois de plus en plus de forfait où on demande au prestataire de rédiger le cahier des charges : on rêve.

Les acheteurs : price killer

Oui c’est une bonne chose de tirer les prix vers le bas, mais il faut aussi rester raisonnable. Comment voulez-vous travailler sereinement avec des prestataires à qui on a mis le couteau sous la gorge.  Pourquoi pas des enchères inversées pendant qu’on y est ? -souvenir-

Le réflexe « perdant – perdant »

J’ai l’impression d’être le seul à demander aux SSII d’augmenter leur chiffrage quand j’ai l’impression que c’est un peu juste. Une fois j’en parlais à un chef de projet, il m’a même répondu : « Ne leur dis rien, s’ils se plantent c’est pour leur pomme ! ». On sait très bien que ça ne se passe pas comme cela. A un moment si le prestataire s’est vraiment planté, c’est le projet qui va en pâtir (qualité de code, test unitaire, bug..)

L’inter-contrat

Même si les commerciaux sont les spécialistes pour vous faire de beaux discours sur leur « cellule forfait » avec des personnes dédiées. Il ne faut pas se leurrer, le forfait c’est l’idéal pour occuper une personne en inter-contrat. Le problème pour le projet c’est que l’on n’a jamais les mêmes développeurs en face. C’est dur d’assurer une continuité des développements.

Junior en solo

C’est un peu lié au problème des prix tirés vers le bas mais je vois de plus en plus de débutants seuls sur des projets. J’ai absolument rien contre les débutants mais il faut les encadrer. Le problème c’est qu’en SSII des développeurs avec 10 ans d’expérience c’est super rare. Et oui, on vend plus cher un mauvais chef de projet qu’un bon développeur avec de l’expérience.

Le Mythe du forfait de service

Depuis un certain temps on nous a mis en place des « forfaits de services ». Alors ça c’est encore une belle invention d’acheteur qui n’a pas du travailler dans le monde du développement. En gros le principe c’est d’envoyer une demande par email et d’attendre le livrable 2 mois plus tard. Vous ne savez pas qui travaille sur le projet, c’est une boite noire. Et donc on retombe dans les travers des deux précédents points et on va avoir des développeurs Flex juniors qui vont coder du J2EE.

Des solutions ?

Je sors justement d’une expérience forfait un peu difficile. A la signature du contrat tout est beau, c’est une société avec qui je travaille souvent, ils mettent en avant le fait qu’il sont CMMI niveau 3, on parle même d’intégration continue avec Hudson. Bref on est en confiance. Au final on nous livre du code Java d’une qualité affligeante (si si c’est le bon mot quand je trouve des noms de variable avec des accents), zéro test unitaire et cerise sur le gâteau le livrable ne compile pas car il manque des sources.

Malgré tout ça je vais continuer à travailler avec cette société. Car déjà elle n’est pas la seule responsable de cet « échec » mais surtout je pense que c’est avant tout un problème de mauvaise personne au mauvais endroit.

Mais comment faire en sorte que la future prestation se passe bien :

Travailler gagnant – gagnant

Partager les risques avec le prestataire, s’impliquer dans le chiffrage, travailler ensemble.

Choisir les intervenants

Il faut vraiment intégrer que la réussite d’un projet n’est pas lié à la société mais bien aux personnes qui réalisent. Faire passer des entretiens est donc primordial pour sélectionner son équipe. C’est le seul moyen d’être sûr que l’on va pas mettre un Flexeur à gérer des transactions JTA ( oui oui c’est du vécu…).

Faire des revues de code périodiquement

Les chefs de projets qui regardent la qualité du code livré sont rares, mais le faire à la livraison c’est surtout trop tard. Il est très important de bien suivre la qualité du code tout au long de la vie du projet pour s’assurer que ça ne diverge pas.

Et non coder un « proto » n’autorise pas à faire n’importe quoi ! (si je retrouve le gars qui a codé la gestion des transactions à la main dans un filtre HTTP je l’étripe

Conclusion

C’est bête à dire mais pour réussir il faut juste travailler en bonne intelligence avec le prestataire. Arrêter ce rapport maitre/esclave qui ne peut que mal finir et discuter d’égal à égal.

Le client devrait passer plus de temps sur son expression de besoins que sur les petites lignes du contrat cadre. Arrêtez d’être obsédé par la garantie de résultat et de date de livraison complètement illusoire pour vous reconcentrer sur l’essentiel : le produit.

Le développement agile permet de résoudre beaucoup de problèmes. Mais quand je vois que l’on demande à des prestataires de travailler de façon Agile mais en gardant un cadre type forfait avec engagement de résultat, c’est complètement antinomique !