Points Clés
Cet article explique les différences entre le forfait et l’agilité, ainsi que les difficultés qui peuvent surgir lorsqu’on essaie de mettre en place un projet agile dans un cadre forfaitaire, il est crucial de prendre en compte les aspects spécifiques à considérer pour aborder les projets forfaitaires dans ce contexte.
Les points durs entre forfait et agilité
Rappel : le forfait
Il définit à l’avance 3 contraintes à respecter
Le périmètre
- L’agilité, c’est la promesse faite au client de pouvoir changer librement d’avis
- En début de projet on ne sait pas à l’avance quel logiciel on aura à la fin
- En début de projet on ne sait pas à l’avance quel logiciel on aura à la fin
- Problème: la contrainte du périmètre est une cible mouvante
- Le système de troc devrait pourtant rassurer les clients. On part d’un Backog initial contractuel et on le fait évoluer avec un mécanisme de troc d’exigences.
- Oui mais :
- Le client n’a pas nécessairement la compétence pour challenger les chiffrages
- Sans concurrence, le fournisseur pourrait chiffrer à la hausse
- Devoir supprimer des exigences est quelque chose de stressant pour un client
- Le périmètre fonctionnel ne peut pas être réduit à un nombre de Points d’Efforts
La collaboration
C’est l’une des 4 valeurs du Manifeste Agile
- Faire un projet Agile comporte un certain nombre de risques pour le fournisseur :
- Spécifications produites en flux tendu => peut créer un déficit d’inputs pour l’équipe de dév
- L’Agilité c’est une certaine culture de l’oralité. En cas de litige, les écrits ne permettront peut-être pas de retracer toutes les décisions.
- Démarrer un projet avec une faible expression de besoin et sans spécifications détaillées peut ouvrir la porte à toutes les dérives en cas de malhonnêteté de l’une des Parties.
Avant de se lancer dans un projet Agile, il faut s’assurer de la capacité du client à collaborer honnêtement, et à dépasser les archétypes du Forfait dans lequel toutes les responsabilités sont déportées sur le fournisseur
- Problèmes :
- Comment définir la « collaboration » dans un contrat ?
- Comment mettre en évidence un manquement à l’obligation de collaborer ?
- Contraindre des gens à collaborer a-t-il un sens ?
Niveau avancé:
Bien démarrer le projet
Le niveau de maturité Agile des clients est souvent faible. Aussi, il faut porter une attention toute particulière à la phase de démarrage :
- De poser les règles du jeu qui prévaudront tout au long du projet
- De partager une vision commune du périmètre du projet
Choisir le Product Owner
Le choix du Product Owner est la décision la plus importante du projet.
Le Client et le fournisseur du service doivent tomber d’accord sur le choix du product owner. Ne pas hésiter à être « Lourd » avec le client si nous ne sommes pas convaincus du choix.
- Qualités du Product Owner :
- Est une seule et unique personne
- Est la même personne tout au long du projet
- A un intérêt marqué à la réussite du projet
- Connait et sait expliquer les règles de gestion mises en jeu dans le projet
- Est dédié au projet – est disponible à tout instant pour l’équipe projet
- Est capable d’arbitrer, de décider dans des délais courts (< 1j en moyenne)
- Accepte le principe de troc des exigences (sait renoncer à des exigences)
- Est le décideur ultime sur les aspects fonctionnels et techniques du logiciel
- tout en étant éventuellement assisté par des experts métiers et techniques
- ses décisions engagent toute l’entreprise, incluant le payeur
- Est salarié de l’entreprise.
La vision du projet
- Le client n’a pas de spécifications, mais il doit avoir une vision de son projet
- La vision du client est le seul point de repère fixe du projet. Le reste changera tout le temps. Cette info est donc essentielle !
- La vision devrait préciser (doit tenir sur 1 page recto)
- Une liste résumée des fonctionnalités clés de l’application
- Une vision du ROI de l’application
- Des objectifs et des motivations pour les atteindre
- Des risques
Template:
+Attentes : Ergo, perfs, qualité, conduite du projet, techniques, etc.
+Objectifs : Enjeux de dates, enjeux de périmètre, …
+Risques : Risques vus par le client
+Hors scope : Ce que le client ou le prestataire de service décident d’exclure du périmètre
“ Deriving scope from goals :
In the future, this will be one of most important software development topics, and I want to raise awareness about it. “
Specification by Example – How Successful Teams Deliver the Right Software – G. Adzic (Manning, 2011)
Le levier de souplesse
flexibility
- Un projet est gouverné par 3 grandes contraintes : un budget, une date, un périmètre
- Pour réussir un projet de ce type, ne laissez pas croire à votre client qu’il peut exiger un respect scrupuleux de ces 3 contraintes
- Demandez à votre client d’indiquer quelle contrainte est :
- Non négociable
- Importante
- Négociable
Ce type de discussion avec un client est riche d’informations sur sa capacité à accepter les avantages et les contraintes de l’Agilité. S’il est totalement hostile à votre discours, ne faites pas d’Agilité
Décider le + TARD Possible
Il existe 2 stratégies en résolution de problèmes :
- En largeur : approche en entonnoir
- En profondeur : approche en tunnel
Souvent les gens préfèrent l’approche en Profondeur car elle permet de réduire rapidement la complexité
Inconvénient l’approche en Profondeur :
- elle oblige à prendre des décisions structurantes très tôt
Approche en largeur:
La feature est entiérement implementé en une seule itération
Approche en profondeur:
La feature est implémentée sur plusieurs itérations
Avantages de l’approche en largeur :
- Permet d’avoir toutes les grandes fonctionnalités (en version simplifiée) très rapidement => recette + intéressante
- Permet de dé-risquer les projets fortement drivés par les délais
- S’adapte mieux aux changement d’avis. Permet d’éviter le rework de code
Inconvénients de l’approche en largeur :
- Approche non naturelle
- Ne jamais faire de choix => bloquer les développeurs
Refaire le Backlog
Le Backog est l’instrument de pilotage le + important !
Or, celui soumis au client en phase de réponse à appel d’offre est souvent :
- Truffé d’erreurs
- Non lu par le client
C’est pourquoi, il faut le refaire avec le client en début de projet :
- Lister les exigences
- Chiffrer les exigences => oui avec le client !
- Prioriser les exigences
Avantages de refaire le Backlog et le chiffrage avec le client :
- Être sûr d’avoir une vision initiale partagée du logiciel
- Mettre le client en confiance lors de troc d’exigences
- Avoir une priorisation qui tient compte de la vraie valeur métier
- Avoir un Backlog qui utilise le vocabulaire métier
Les erreurs souvent commises :
Mener les ateliers
Pour que le client tire profit d’une approche Agile, il faut accepter de lui laisser le temps de « maturer » sur son besoin
Bannissez les pratiques de :
- faire un maximum d’ateliers en début de projet pour cadrer le besoin
- forcer des prises de décision pour sécuriser vos chiffrages
Les bonnes pratiques pour mener les ateliers sont :
- Faire les ateliers au fur et à mesure des sprints
- livrer fréquemment du logiciel fonctionnel et faire tester par le client
- expliquez que certains chiffrages sont des enveloppes budgétaires à respecter
- ne pas laisser croire que chaque responsable de domaine a un droit de décision => le seul qui décide c’est le Product Owner (y compris les aspects techniques)
- chercher la décision minimale sur laquelle tout le monde est d’accord et la développer (approche en largeur)
Démarrer les développements
Les chefs de projet ont tendance à faire démarrer les développements trop tard. Ils souhaitent avoir un maximum d’entrants avant de démarrer : storyboard, piste graphique, cadrage fonctionnel, etc.
Inconvénients :
- Lourds investissements financiers sans aucune production de logiciel => risque !!!
- Symptomatique d’une approche en profondeur : on veut tout simplifier dès le début du projet
Avantages de démarrer les développements relativement tôt :
- Le fait d’avoir produit du code permet de cadrer naturellement le client.
- Tant qu’aucune ligne de code n’a été produite, le client se sent libre de tout remettre en cause d’un atelier sur l’autre.
- Dé-risquage du projet => un Logiciel opérationnel est la principale mesure d’avancement (7ième principe du Manifeste Agile)
Soigner votre relation client
Soignez la qualité de votre relation client !!!
Prenez un même projet et une même équipe
- Cas 1 : le client est dans de bonnes dispositions envers vous
- Cas 2 : client est dans de mauvaises dispositions envers vous
- La différence entres les 2 c’est au moins 10% de marge
Comment développer une relation de qualité ?
- Soyez prévisibles
- Dites la vérité
- Dites le même quand c’est dur
- Dites le tôt
- Choisissez vos mensonges, sinon vous vous pendrez avec
- Une relation de confiance se créé au goutte-à-gouttes, mais se perd par litres
Soyez engagés
- Parlez de vos pistes de solutions
- Montrez votre engagement à trouver rapidement une solution
Développez la solidarité
- Ne vous engueulez jamais avec un client !
- Faites des rétrospectives d’équipes client / fournisseur
- Trouvez des solutions aux problèmes de votre client, même sans contre partie immédiate
- Impliquez votre client dans le recherche de solutions pour vos problèmes
- Sortez des sujets polémiques avec une solution en 50 / 50
- Soyez en mesure de négocier => définissez vos leviers de souplesse !
Soyez compétent : livrez un logiciel de qualité
- Si votre équipe livre un logiciel de qualité, un budget, une date peuvent devenir négociables
- Si vous livrez de la m**de, rien ne sera négociable !
Durant le projet
Votre objectif : la réussite du projet
- Sur un projet qui va mal :
- La marge n’est plus pilotable ni prédictible
- Sur un projet qui va mal, il est très difficile de négocier un avenant / une rallonge
- Pour faire de l’argent, votre projet doit bien aller, il doit réussir
- Votre première préoccupation doit être : la réussite du projet
Définissez votre marge de manœuvre
- La réussite oui, mais pas à n’importe quel prix
- Définissez les seuils de tolérance avec votre agence, selon :
- L’historique de business avec ce client
- Le potentiel du client
- Le caractère stratégique du projet pour votre société
- Etc…
- Traduisez ces seuils en souplesse sur la marge
- Pilotez votre projet à l’intérieur de cette marge de manœuvre
- Quand vous approchez la limite de cette marge, référez à votre agence
Surveillez l’équilibre des intérêts
- Ayez temps en tout temps à l’esprit le respect des intérêts mutuels
- Quand vous commencez à voir un déséquilibre dans la relation dites le, et agissez !
- Ex : vous êtes en dessous de vos objectifs financiers alors que la santé du projet est bonne
- Ex : vous êtes au dessus de vos objectifs, alors que le client a coupé 30% du périmètre
Limitez vos demandes d’argent
- Avant de demandez de l’argent, trouvez d’autres solutions :
- Avec le client, supprimez régulièrement les exigences inutiles du backlog
- Soyez techniquement malins : proposez des solutions équivalentes, mais moins chères
- Troquez une exigence « peau de banane » contre un effet Whaouh pas cher
- Transférez des tâches chez le client
- En dernier recours :
- Négociez un avenant / une rallonge
- Informez en le client tôt, qu’il ait le temps de trouver des solutions
- Vous ne pourrez pas le faire 50 fois. Alors choisissez bien quand et quoi demander
Pas de décalage planning
- Faites tout pour atteindre vos objectifs de dates
- Un report de date fait très mal à la marge
- Mieux vaut staffer 1 ICD maintenant, que prolonger 2 semaines 1 équipe complète
- Sécurisez votre mise en prod avec l’approche en largeur
Le contrat
Un modèle de contrat
- La contractualisation Agile est un sujet difficile auquel les juristes sont mal formés
- Il n’existe pas de contrat Agile type qui fasse l’unanimité :
- Difficulté à définir les changements de périmètre
- Difficulté à faire de la collaboration en engagement fort
- Le plus souvent ça fini avec :
- Un contrat au forfait plus ou moins traditionnel => risque porté par le fournisseur
- Un contrat en régie => risque porté par le client
Les points durs
- J’ai longtemps tenté de rédiger un contrat Agile :
- Gestion du périmètre avec du troc de Points d’Efforts à ça ca va…
- Levier de souplesse, collaboration à c’est là que ça ne va plus
- Les gens sont capables d’entendre qu’il faut un levier de souplesse, mais pas toujours de l’écrire :
- Le modèle du contrat au Forfait est encore très ancré !
- Si je projet dérape et qu’on s’aperçoit que j’ai signé un contrat comme ça, aïe aïe !
- Notre service juridique ne va jamais accepter une telle chose !
- La collaboration :
- Comment définir la collaboration ? Comment définir la non collaboration ?
- Impossible d’invoquer une manquement aux obligations d’une des Parties sur un concept aussi difficile à définir
Alors quelle(s) solution(s) ???
2 types de contrats
Il n’existe pas de solution unique, mais un contrat adapté à chaque projet
Je vais vous parler :
- d’un contrat signé avec un client
- d’une alternative à ce contrat (non signé)
Premier contrat : client α
- Le principe :
- La collaboration, c’est lorsque chaque Partie a le soucis des intérêts de l’autre (sans oublier les siens)
- Un moyen pour y parvenir :
- Que chaque Partie soit libre de pouvoir mettre fin au contrat à tout moment
Deuxième contrat : client β
- Le principe : le partage de risque
- Le budget est estimé au début du projet sur la base d’un nombre de Points d’Efforts à livrer pour une date donnée
- Si le périmètre est livré avant la date prévue => client et fournisseur se partagent l’économie
- Si le périmètre n’est pas livré à la date prévue => client et fournisseur continuent les développements en se partageant le surcoût
- Garde-fous possibles :
- Si la raison du retard est exclusif à l’une des parties, pas de partage de responsabilité
- Le ratio de partage peut être déterminé par l’investissement initial que le client a mis :
- – Dans la complétude de son Cahier des Charges
- – Dans une phase de cadrage
- Au-delà d’un certain dépassement (X semaines) => arrêt du projet
- – Evite que le client veuille profiter trop longtemps d’un TJM très avantageux
Important !
Pour que ces types de contrat soient signables par un client, il faut lui donner d’excellentes garanties sur la qualité des livrables.
L’avant-vente
Agilité : côté pile / côté face
- Vous avez compris que dans un projet Agile, il y a des choses
- Que les clients aiment : changer d’avis, pas d’effet tunnel, …
- Que les clients aiment moins : le levier de souplesse, le partage de responsabilité, la liberté des parties, …
- Que les clients aiment : changer d’avis, pas d’effet tunnel, …
Mes conseils
- Sans projet, pas d’Agilité => en AVV, votre priorité est de faire rêver votre client !!!
- Et les sujets qui fâchent ? :
- La première fois évoquez le sujet lors d’une rencontre physique
- Voyez quel accueil le client réserve à ces propos
- Si le client est réceptif, ou connait l’agilité, ce type de discours devient un ATOUT !
- Si le client n’est pas réceptif, n’en parlez plus. Ré-ouvrez le sujet une fois le projet gagné
0 commentaires