La recette arrivant en bout de course d'un projet, elle est souvent sacrifiée pour compenser les retards de développements pour des bonnes et/ou mauvaises raisons. Il arrive donc souvent que la version livrée en recette a peu été testée (voir pas du tout ou pas de façon suffisamment significative).
Cela conduit à différentes choses :
- Les jours payés par le client ne sont pas utilisés à cet effet,
- L'effort de recette coté client explose puisqu'il doit assurer la recette en lieu et place du prestataire
- L'effort de recette coté presta va également exploser coté prestataire et non être réduit comme escompté car il aura (souvent) tendance à :
- multiplier les livraisons correctives partielles
- générer de nombreux aller/retour pour cause de non-correction voir régression
- exploser le cout de livraison (packaging, documentation, etc)
- Désorganise tant le prestataire que le client du fait de cette charge à absorber dans des plannings qui ne le permettent pas forcément
- Au final, une tension croissante va pourrir les relations entre le client et le prestataire, sans compter la démotivation croissante de part et d'autres pour faire avancer le projet. Sans compter que cela ternit l'image de marque du prestataire et peut mettre fin à tout travail potentiel entre le prestataire et le client.
Au final, tout le monde est clairement perdant.
Quelques pistes d'amélioration :
- Mieux estimer les périodes de recette (structurellement sous estimée) et qu'elle fasse partie du budget du projet. A croire qu'annoncer une période de recette est une honte en matière de programmation... Attention, il faut quand même que cette durée reste cohérente avec la taille/complexité de l'application.
- Etre transparent/honnête avec son client en disant qu'il y aura un retard de livraison le temps de faire la recette. Après tout, c'est logique, le temps perdu au niveau du développement ne se rattrappe jamais par magie...
- Mieux résister à la pression interne de livrer "à tout prix et/ou au plus vite" au client
- Prendre le temps de faire cette recette
- Coté presta, prévoir des zones tampons si des projets doivent se succéder afin qu'un retard sur un projet n'en condamne pas un autre. Cela suppose aussi que le chef de projet remonte les infos à temps à sa hiérarchie.
- Dans le cas de plusieurs itérations, faire en sorte d'en avoir le moins possible pour ne pas se démotiver dans les phases de recette,
- S'il y a des applications auxquelles se connecte le projet, soit vous êtes en mesure de mettre en place réellement cette plateforme chez le prestataire, soit il faut venir faire des tests d'intégration chez le client
- Faire venir le prestataire sur site pour pouvoir travailler de concert et éviter les parties de ping-pong par mail ou téléphone,
- Se dire que ce retard sera compensé par le fait que tout ce qui a été dit dans le paragraphe précédent ne se produira pas... ou dans une moindre mesure
Enfin, si le jour de la livraison il y a un retard de dernière minute ou une opération plus longue que prévue, prévenir le plus tôt possible le client et le tenir informé des éventuels reports de livraison. Ou alors se donner une vraie marge pour tenir les horaires. Cela évite en outre que le client excédé vous appelle pour savoir où vous en êtes et à quelle heure vous allez livrer.
Tout cela suppose également que le chef de projet ait une visibilité suffisamment bonne sur le travail de ces développeurs et qu'il connaisse suffisamment bien le produit sur lequel il travaille pour que ces estimations soient les plus justes possibles. Faute de quoi, il risque de se trouver dans une fort mauvaise posture (vécu inside).
A ce jour, une telle méthode m'aurait épargné un gros nombre des 100 bugs trouvés juste en cliquant à droite et à gauche (sans prendre en compte les specs fonctionnelles d'un projet) et les 5 livraisons que j'ai réduit à 3 intégrations. Je tairais le nom de la SSII, vu que ce n'est pas propre à cette SSII et que j'espère que d'autres équipes projets de cette SSII travaillent de façon plus satisfaisante. Pour avoir de l'autre coté, j'en garde également des mauvais souvenirs et des conditions de travail déplorables, se retrouvant entre le marteau (le client) et l'enclume (sa hierarchie).
