Pourquoi le travail au temps passé ?

Jumboweb a vécu des hauts, des bas, des périodes fastes, des périodes creuses, nous nous sommes perpétuellement remis en question et, au fil des années, nous avons trouvé des réponses aux problèmes récurrents que nous rencontrons. Ces problèmes, nous en partageons une bonne partie avec toutes les SSII et les développeurs freelance du monde.

Nous avons notamment adopté le travail au temps passé, et je vais prendre quelques minutes pour vous expliquer comment et pourquoi nous avons trouvé judicieux de le faire.

L’échec du forfait

Un projet informatique est souvent, pour ne pas dire toujours, complexe. Il a plusieurs facettes, front, back, api, sécurité, design, ergonomie, etc. Le temps passé se chiffre alors en semaines, en mois de travail. Or il est prouvé qu’au delà d’une vingtaine d’heures, il est très difficile voire impossible de vraiment prévoir le temps qui sera réellement passé.

Pourquoi ? Parce que l’être humain n’est pas fait pour prendre en compte autant de facteurs à la fois, si tant est que tout soit spécifié et clair dès le départ du projet, ce qui n’est pas si fréquent que ça. Le développeur moyen n’échappe pas à la règle, il est même désavantagé car il est maladivement, obsessionnellement optimiste. Que le développeur qui ne s’est jamais viandé me jette la première pierre. Les estimations ne tiennent jamais compte des conflits de versions de librairies, des limitations techniques découvertes sur le tard, des mises à jour plus ou moins foireuses de nos bien-aimés OS/frameworks/IDEs (biffer la mention inutile). J’en finirai sur ce sujet en disant que s’il est innovant, le projet présente forcément des particularités nouvelles, auxquelles on ne se sera pas encore frotté, ce qui rend toujours plus difficile l’estimation.

Solution massivement appliquée dans les SSII, estimer, puis doubler ou tripler le temps donné par le développeur pour espérer être dedans. Résultat des comptes, au forfait, quelqu’un se fait toujours avoir. Soit le client, soit son développeur. Le pire dans tout ça, c’est que le client grave son projet dans la pierre, il n’est plus autorisé à changer d’idée, sous peine de se retrouver sous une pluie d’avenants, qui viendront encore saler la note. Le forfait, c’est l’illusion du contrôle.

Comment vendre le temps passé ?

Une fois que l’on a dit tout cela, on n’est pas plus avancé pour autant. Combien de fois ai-je déroulé mon explication ci-dessus face à un prospect enthousiaste, qui fait mine de tout comprendre, puis, quand j’ai fini, stoïque, imperturbable, me pose la fatidique question : “C’est bien tout ça, mais combien ça va me coûter au final ?”. ¡Caramba! Encore raté.

La question est légitime. Nos clients sont des PME, des grands groupes, des porteurs de projets. Ils ont tous en commun d’avoir un budget, plus ou moins serré, et le temps passé leur fait peur.

Nous ne nous interdisons pas de faire des estimations. C’est nécessaire le plus souvent, surtout si le client prévoit de financer le développement par un crédit ou une levée de fonds. Seulement cela reste des estimations, nous ne nous engagons pas fermement. Voilà pourquoi.

La liberté c’est maintenant

On l’a dit, en plus du problème de l’estimation, le gros point noir du forfait, c’est son coté statique. Tout est écrit et on ne peut rien changer. Au temps passé, pourquoi s’embarrasser de cela ? Nous définissons avec notre client ce qui va se passer sur un “sprint” de 15 heures. J’ai bien dit heures.

En effet 15 heures c’est assez court pour avoir un retour très rapide. 15 heures c’est assez long pour pouvoir sortir un lot conséquent de fonctionnalités.

Sur 15 heures il reste possible humainement de voir où l’on va, de délivrer chaque fonctionnalité de façon à ce qu’elle soit testée, validée et livrée individuellement. Une fois les 15 heures réalisées, on fait le point, a-t-on fait plus que prévu, moins, où sont les points de blocage ?

On recommence ainsi pour chaque lot de fonctionnalités, ce faisant on s’engage et on engage de fait le client dans le processus de développement de son application en le faisant valider chaque élément de celle-ci. Et on lui permet de changer d’avis. Initialement il avait prévu un envoi de mail, finalement ce sera un push mobile ? Pas grave, l’envoi de mail n’a jamais été codé.

En prenant le changement à la racine, le temps passé économise du temps de développement, de la motivation et de l’énergie que l’on investira dans les fonctionnalités qui ajoutent vraiment de la valeur à l’application, tout en impliquant le client.

Libres mais pas irresponsables

Revenons sur le point en fin de sprint. On y fait l’analyse du sprint qui vient de se terminer, mais aussi sur l’avancement global de l’application. Etonnament, il suffit de 3 ou 4 sprints pour commencer à avoir une vision assez claire du projet et de sa deadline.

Ainsi si nous allons plus vite que prévu, le client paiera moins cher. Si nous prenons du retard, il le sait au plus tôt, et ne le découvre pas au bout de 6 mois, quand il est trop tard et que le projet se retrouve en déficit à tel point qu’il est compromis. Il peut décider de retirer des features, ou de revoir son planning.

Le client ne s’engage que pour le sprint en cours, il est libre de nous quitter à tout moment avec son code sous le bras. Pensez-vous que nous ayons intérêt à le décevoir ?

Au forfait, dès l’instant où l’on signe, les intérêts du développeur et de son client divergent. L’un veut tout pour le prix indiqué, l’autre veut faire au plus vite, uniquement ce qui est écrit. Le temps passé, en laissant sa liberté à chacun, laisse la place à une certaine forme de partenariat de confiance entre le développeur et son client.

La transparence comme seule devise

Autant le dire tout de suite, développeurs, si vous adoptez le temps passé, alors vous devrez faire quelques concessions. Imaginez une seconde que vous achetiez une voiture, sans en connaitre à l’avance ni le prix, ni la couleur, ni la date de disponibilité. Votre client est dans cette posture. Vous vous devez de lui donner toute la visibilité possible.

Chez Jumboweb, nos clients ont accès à un suivi du sprint en cours, story par story, un historique de tous les sprints précédents et un burndown chart estimant d’un coup d’oeil l’avancement global du projet.

En complément nous avons développé, en nous appuyant sur l’api letsfreckle (notre tracker temps), un outil de suivi en temps réel du travail de tous les développeurs. Chaque client a un dashboard pour son projet, où il peut voir toutes les entrées de temps, passées ou en cours, et un récap de la facturation sprint par sprint.

L’idée est simple : tuer dans l’oeuf toute inquiétude du type “Est-il en train de bosser ?” (traduction : suis-je en train de payer ?) ou “Où en est-il du sprint ?” (traduction : est-il en train de prendre du retard ?)

Dites tout à votre client. Vous aurez d’abord l’impression que vous perdez votre liberté, il n’en est rien. C’est justement parce que l’information est disponible qu’il ne ressentira plus le besoin d’aller vérifier ce que vous faites. En revanche il saura s’il peut vous appeler maintenant ou pas. Oui, il saura même que vous n’aurez bossé que 2 heures ce fameux vendredi où vous avez chopé la crève. Mais qu’importe puisqu’en toute transparence, vous n’aurez facturé que 2 heures !

Le temps passé, en obligeant à la transparence la plus totale, lève les incompréhensions entre le développeur et son client, et tend à pacifier les relations qui s’orientent moins vers le controle financier, et davantage vers le sens du service, la valeur ajoutée. Les factures, envoyées à chaque fin de sprint, récompensent régulièrement le développeur, et aident le client à lisser ses dépenses.

Trop beau pour être vrai ?

Attention. Oui, on peut travailler au temps passé, mais pas avec tout le monde.

• Le temps passé ne conviendra pas aux grands comptes, qui veulent un devis précis et une facture globale.
• Il ne conviendra pas aux clients qui sont mal organisés ou qui manquent de temps pour s’investir.
• Il ne conviendra pas si vous ne savez pas mettre en valeur ses avantages dès le premier contact avec votre prospect (et ça se travaille, croyez-moi).

Pour tous les cas où ça coince un peu, on peut parfois trouver une solution intermédiaire (achat de tickets de temps, forfaitisation par petits lots), mais mon conseil, c’est d’éviter autant que possible de déroger à la règle. Trop de modes de fonctionnement différents en parallèle provoqueront forcément des effets pervers un jour ou l’autre, coté métier ou côté financier.

Conclusion

Après plusieurs mois d’expérience sur le mode temps passé, nous n’avons aucunement l’intention de revenir en arrière. Nous avons réduit notre rentabilité lorsque nous avons choisi cette façon de faire, mais pour ma part, je me suis senti plus en paix avec moi-même, et plus proche des intérêts de mes clients.

Moins riche, mais plus libre.

Et vous, franchiriez vous le cap ?