Je suis tombé ces dernières journées sur un vidéo de Ryan McMinn intitulé All Roads Lead to Rails{en}. Ce vidéo fort intéressant a soulevé de nombreuses questions. Devrait-on offrir des contrats forfaitaires pour le développement d’application? Une facturation à l’heure contredit mon blogueur et gourou mercatique Brendon Sinclair. Comme Brendon explique dans son balado (Podcast pour les intimes – Merci Grand Dictionnaire terminologique), The Best Way to Price Your Services and Deliver Value to Your Clients{en}, ceux qui facture leur clients à l’heure sont des LOOOOOOOSSSSEEEERRRRRRS. Après de nombreuse discussions entre Jean-Marc et moi, nous avons décidé de ne plus offrir de contrats à prix forfaitaires, quitte à être traité de LOSER en défiant ouvertement mon gourou. Je vous explique le raisonnement : Martin Fowler explique bien la grande difficulté de réaliser du code. Dans son texte « The New Methodology{fr} », les conclusions que le code source est un document de conception et que la construction du logiciel est l’utilisation du compilateur change beaucoup de nos perspectives de travail mais surtout d’évaluation de la charge de travail. Évaluer un travail créatif est une tâche très ardue. Lors du développement du logiciel, la cible est toujours changeante avec des ajouts, retraits, oublies et modifications. Ryan McMinn dans sont vidéo explique que lorsqu’on travail à prix fixe, il est presque impossible d’arriver tout juste à la valeur prévue. Si on estime trop bas, nous allons perdre notre rentabilité, si nous estimons trop haut, le client se sentira arnaqué ou nous perdrons la vente. Peu de gens seront content. « Oui, mais Hugues : comment le client peut-il avoir confiance qu’il ne sera pas surchargé et que le travail avance bien ? » Cette question est bien valable et la réponse est très simple. Vous faite de petites itérations. Lorsqu’à tous les mois le client reçoit une livraison, il est capable de déduire votre avancement. Avec une approche par tests, il sera facile de le convaincre que le système fonctionne. Ce qui nous rappelle la deuxième règle du manifeste Agile{fr}. Le logiciel fonctionnel primant sur la documentation exhaustive. Dans le cas où vous pouvez avoir un processus répétable, je suis tout à fait en accord avec Brendon Sinclair sur le fait de facturer à la valeur du service. Un hébergement Web, un analyse en un nombre de points limités, un nom de domaine et plein d’autre service peuvent être inclus dans cette catégorie de processus répétable.
