Encore une fois, je ne suis pas le bon interlocuteur pour vous parler de la contractualisation. Je vais tenter de répondre tout de même à vos remarques...
Même si c'est très juste, ça ne fait pas "sérieux", ça fait un peu marchand de tapis.
Dans tous les cas, tu ne souhaites pas faire de méthodes agiles avec un client qui ne veut pas s'impliquer. Ces méthodes demandent une présence beaucoup plus grande du client. Pour XP, tu as un client sur site. Pour Scrum, tu as une démo par mois. Alors certes tu peux adapter, prendre un représentant du client, mais il est impératif que tu ais un engagement fort du client final.
Par ailleurs, c'est un peu comme ça que fonctionne la régie. C'est donner à ton fournisseur une obligation de moyen, et non de résultats. Il est clair que c'est faire beaucoup plus confiance au fournisseur que dans un forfait classique, où le fournisseur doit remplir une spécification et non un besoin client évolutif.
Enfin, après plusieurs avenants, la relation client/fournisseur en arrive souvent à un point très similaires. Les avenants se font de plus en plus courts, et le contrat liant fournisseur et client se tourne vers la maintenance...
Par contre je nuancerais le "win-win" car dans ce cas de figure c'est davantage le client qui gagne
Davantage que quoi? Que le contrat classique ? Celui où :
Côté fournisseur :
On est en retard, je paye tous les pots cassés
On est en avance, je temporise pour justifier ma vente initiale
Côté client :
On est en retard, youpi je vais leurs mettre des pénalités
On est en avance... ah ? Ca n'arrive jamais ?
Mais au final, le problème est toujours présent sur l'estimation du périmètre avant contractualisation, non?
Comme pour une gestion de projet en V, tu commenceras par une étude complète du projet. Tu diviseras le projet en modules, que tu estimeras en temps, en risque et en valeur client. Une fois ce travail effectué, tu peux contractualiser. Puis tu fera ta spécification (ou l'équivalent) en fonction de ces priorités. Une spec. "just in time".
Si le périmètre change, tu estime la durée de ces nouveaux besoins. Lorsque ceux ci concernent une partie non implémenté, aucun souci. Si ceux ci concernent une partie déjà codée, il faut simplement les compter comme de nouveaux développements. Et retirer du contrat le surplus.
Pour reprendre une image que j'ai vue sur une présentation, imagine toi une échelle, avec une limite au Xième barreau. Tout ce qui est en dessous ne sera fait que "si on a le temps". Ce qui est au dessus sera implémenté. Le client a toute latitude pour déplacer les briques au dessus ou en dessous de la limite, dans la mesure où le temps de réalisation reste constant. Au final, l'engagement pris initialement ne signifie que "Produire X points de tâche en X temps".
0 |
0 |
Envoyé par Heziva
)