Aller directement au contenu principal
3 min Boris Schapira

Réduire le suivi

Récemment, on m’a rapporté trois anecdotes d’avant-vente comportant des demandes du prospect de réduire la quantité de jours associés au suivi du projet. Je pense que ça mérite une discussion.

Demander à réduire un coût global, je comprends. Nous avons tous des objectifs financiers et il faut que le coût des prestations rentre dans le cadre d’un budget souvent voté en amont. Les prestataires, si tant est qu’ils ont des marges de manœuvres sur le périmètre ou les délais, peuvent souvent trouver des solutions alternatives pour mieux coller à une cible budgétaire.

Demander à réduire un coût au profil, cela me semble négociable dans la limite du raisonable. En dessous d’un certain coût, il est difficile d’assurer la qualité des compétences (notez que je n’ai pas dit que c’était impossible, on trouve des développeurs excellents et peu chers, notamment quand ils ne savent pas qu’ils sont excellents) mais à l’inverse, un coût élevé ne garantit pas non plus une compétence, donc je peux comprendre que cela se discute.

Réduire les exigences de qualité peut permettre de réduire le coût, au dépend de nouveaux risques. C’est un choix qui se discute et qui peut exclure un certain nombre de prestataires qui refuseront de participer à ce type de projets risqués pour leur réputation. Mais si on sait à l’avance que la durée de vie du projet est faible ou qu’il est destiné à une cible très identifiée, je peux entendre qu’on réduise volontairement son accessibilité, son respect de certaines bonnes pratiques ou sa résistance à la régression.

Demander à réduire arbitrairement le volume de suivi, c’est en revanche se tirer une balle dans le pied. C’est expliquer clairement qu’on souhaite sacrifier la qualité, mais ne pas préciser en quoi. C’est également nier le rôle de facilitateur du Chef de Projet (ou du Scrum Master) et penser que les développeurs sauront seuls trouver les réponses à leurs interrogations sans jamais perdre de temps. C’est supposer qu’une équipe est un endroit où les conflits n’arrivent jamais et qu’aucune résolution ne sera nécessaire. C’est imaginer qu’un projet n’est pas réalisé par des femmes et des hommes, mais par des ressources qui ne commettent pas d’erreurs, ne doutent pas et comprennent parfaitement le besoin, le projet, le planning et le budget. C’est une façon de faire que je déplore car elle aboutit souvent à une moins bonne expérience utilisateur (le produit est moins bien pensé), une maintenabilité dégradée et un coût final plus elevé mais caché, car composé d’enveloppes non-budgetisées et/ou de dépassements du côté du prestataire.

La plupart du temps, la décision de tailler s’appuie sur la finesse de rédaction des spécifications : « puisque nous savons ce que nous voulons, nous n’avons pas besoin d’une personne pour assurer la conduite du chantier ». Imaginez faire pareil avec une maison, ou prendre en main votre voiture chez un concessionnaire en ayant explicitement demander à ce qu’on ne contrôle pas les freins.

Si vous avez un doute, demandez des explications sur ce qui est inclus dans ce suivi, les engagements de vos potentiels partenaires et leurs méthodes de travail. Discutez sur les types de réunions, les types de livrable, intéressez-vous à la proposition et faites des commentaires. Il y a souvent des choses à apprendre pour l’ensemble des acteurs et le projet ne pourra s’en porter que mieux.

Mail Facebook Twitter Feed Flickr Github LinkedIn Search A loop Information git Clock Français English