Je cherche des informations sur la manière d’aborder la négociation de contrat avec des clients pour aborder les choses avec une approche Agile/Scrum.
Comment définir une approche financière acceptable avec le client, sans tomber dans une proposition de forfait un peu forcée par le client (Le fameux devis) ?
Bien souvent, il est demandé de faire un devis et d’estimer globalement les coûts avant de démarrer une mission ou un projet. Proposer une approche financière fixe avec un scope flexible et des deadlines souvent fixées à l’avance reste hyper casse gueule.
On présente souvent un graphique time/scope, mais comment orienter les discussions budgétaires pour quand même décrocher un projet sans se sentir coincé après.
Avez-vous des pistes de réflexion à ce sujet ?
Comment faire au mieux pour que tout le monde s’y retrouve ?
Faire de la régie pure. C’est clairement ce qui marche le mieux de mon expérience.
Faire un contrat agile : commencer sur par exemple 3 ou 4 sprints avec un périmètre co-créé (un produit minimal), puis ensuite passer en régie par sprint, où l’on paye au sprint avec des revues de sprint toujours avec le client.
C’est mon premier messages sur la communauté : alors j’en profite pour dire merci à Scrum Life
Par rapport à la question du contrat, je suis bien d’accord avec Benjamin.
Et cette question est vraiment importante car elle drive la relation client.
Je suis scrum master mais aussi DPO dans ma société, et je vois de tout dans les contrats
Le forfait comme tout ce qui est cadrage est à éviter le plus possible pour un projet Agile.
Mais avant cela, il faut aussi se demander si le projet doit vraiment se faire en Agile !!!
Parce qu’il faut être conscient que beaucoup font de l’Agile parce que c’est ce qui doit être fait maintenant et c’est tout.
Dernièrement, j’ai vu passer un contrat pour un projet de décommissionnement dont la date est connue. Le projet consiste à recréer la même chose avec des technos modernes pour remplacer un ancien système. Le contrat est au forfait, avec description de tout ce qui doit être fait mois par mois jusqu’à la date butoir : avec engagement de réussite très fort et bien entendu négociation agressive sur le temps à y passer. Et surprise en mode Agile !?!
Autant dire que l’équipe galère maintenant au plus haut point !!!
Donc pour répondre à ta question, il faut d’abord se demander si l’Agile est vraiment adapté au projet.
Ensuite, faire comme l’a dit Benjamin :
Le mieux de la régie
ou par lot avec au début un contrat un peu plus encadré pour rassurer le client puis de la régie.
Pour vous, un projet de refonte, ne peut pas se faire en agile? Avec une date fixe de bascule?
Pour moi, il y a plusieurs moyen de traiter le projet en agile.
Soit tu restes sur la même base de code et tu refonds le projet petit à petit en faisant de la dette technique pur et de la retro doc vivante si le projet actuel n’est pas encore dans ce niveau de techniques de code.
Soit tu commence un nouveau code et tu refonds petit à petit en priorisant par la valeur en decommissionnant petit à petit les briques refondues avec un Feature Flipping.
La date connue ne pose pas de problème, c’est le principe même de l’agile : date fixe, budget fixe et périmètre variable.
En gros, une refonte agile se négocie par un staffing et un rythme. Le projet peut s’arreter à tout moment, l’argent investi est utilisé en prod.
Comme je l’ai dit, tout est déjà cadré dans le contrat mois par mois jusqu’à la date butoir.
Il n’y a pas de « périmètre variable », surtout avec le peu de temps à passer pour nos ressources (puisque la négociation a été très agressive).
Du coup, mes collègues ont une sommes de tâches à réaliser à chaque itération avec un planning très serré. Et en parallèle, à chaque début d’itération le PO, côté client, organise une sprint def en se demandant qu’est-ce qu’il pourrait mettre dans le sprint !!!
Ok, dans ce cas, le contrat et l’etat d’esprit ne permettent pas de faire de l’agile.
Mais aucune autre forme de contrat permettra ce projet à etre une réussite en vrai. Un planning fixé à l’avance avec un périmètre et ressources fixes, c’est echec garantie pour n’importe quel type de gestion de projet
