Il s'agit de proceso y gérer les attentes et très peu de choses à voir avec la technique. L'erreur que commettent (à mon avis) la plupart des clients, en particulier les petites sociétés de conseil, est d'opter pour un contrat à prix fixe (avec éventuellement une assistance facturée T&M : time and materials). Il s'agit d'un exercice de gestion des risques, ce qui est compréhensible.
Le problème est qu'ils paient ce risque plus faible de trois façons :
- Vous payez une prime pour un risque moindre. Il s'agit d'un principe fondamental qui est aussi vrai dans le développement de logiciels que sur les marchés financiers ;
- Le risque peut être tellement élevé pour le(s) développeur(s) que le coût augmente de façon astronomique, ce qui ne profite à personne (en fait, cela profite au développeur jusqu'à ce que les choses tournent mal, ce qui finit presque toujours par arriver) ; et
- Vous passez tellement de temps à élaborer un cahier des charges et à formaliser les produits livrables et les critères d'acceptation que vous oubliez que vous venez de dépenser 300 000 dollars pour rédiger un document Word de 300 pages au lieu de, vous savez, coder quelque chose.
Tout cela a pour effet de rendre le résultat final plus coûteux pour le client, de démotiver le développeur (qui veut écrire des documents Word de 300 pages ? Sérieusement !) et de retarder l'obtention d'un résultat par le client (augmentant ainsi le risque de dérapage, qui est directement proportionnel à la longueur du projet).
Les deux parties seraient souvent mieux servies en adoptant une approche T&M combinée à une certaine forme de méthodologie de prototypage rapide avec des livrables ou des démonstrations régulières au client à un intervalle de 4 à 6 semaines maximum. Cela permet de gérer les attentes. Si le client peut voir que quelque chose est en train de se passer, cela le met à l'aise et vous permet de vous atteler à la tâche (plutôt que de passer du temps en réunion à examiner des diagrammes de GANTT).
Vous devez donc essayer de convaincre votre client d'opter pour une approche graduelle (petits pas), où il peut voir ce qu'il obtient, comment cela évolue et participer au processus. Cette approche permet d'obtenir des résultats plus rapidement et est finalement moins coûteuse (les deux parties partageant la charge du risque).
Une chose que de nombreux développeurs semblent également oublier est qu'ils sont comme des sujets royaux dans la France du XVe siècle. Ils peuvent avoir des privilèges, voire des richesses, et de nombreux avantages, mais ils servent au gré du roi (ou de la reine), qui peut les décapiter sur un coup de tête. J'entends par là que c'est le client qui, en fin de compte, détient le pouvoir et que vous, en tant que développeur, existez pour lui faciliter la vie et non l'inverse.
Si le client veut un site web rose et vert développé en Cobol on Rails fonctionnant sur un serveur virtuel Vax/VMS sur l'iphone du patron, eh bien c'est ce qu'il obtient. Vous pouvez utiliser votre expertise et votre expérience pour essayer de le convaincre que ce n'est pas une bonne idée, mais en fin de compte, si c'est ce qu'il veut, vous avez deux choix : le lui donner ou partir.
Trop de développeurs tombent dans le piège de donner aux gens ce qu'ils pensent devoir avoir, et non ce qu'ils demandent. GRAVE ERREUR. Une partie du processus consiste à garder les canaux de communication ouverts avec le client afin d'éviter de prendre la tangente en pensant qu'il veut quelque chose (ou en décidant qu'il devrait avoir quelque chose) alors qu'il s'attend à quelque chose de complètement différent.
Même un petit projet de développement de logiciel peut facilement atteindre 6 chiffres. Il s'agit généralement d'un investissement important pour celui qui le paie. Ils ont le droit d'être nerveux et vous avez la responsabilité de les rendre heureux.
