Comment on estime les projets web chez Lonestone ?
17 mars 2023
Nos experts partagent leurs expériences sur le blog. Contactez-nous pour discuter de vos projets !
Chez Lonestone, on conçoit et développe des webapps et des sites web pour nos clients depuis quelques années déjà. C’est un sujet que l’on maîtrise.
En revanche, quand il s’agit d’estimer le temps de réalisation d’un projet, c’est tout de suite plus compliqué.
Chiffrer un projet est un vrai défi, c’est un exercice :
qui demande du temps,
qui demande l’implication de plusieurs collaborateurs aux compétences complémentaires,
qui doit bien être fait rapidement, dans un moment où le temps nous manque souvent.
Pourtant, c’est une étape importante : un projet correctement chiffré permet d’aborder sereinement la phase de production.
Ces derniers mois, on a eu la chance de travailler sur des projets radicalement différents les uns des autres. Que ce soit par leur nature, par la taille des entreprises de nos clients, par la diversité des équipes projets, par les types de prestations que nous avons menés.
Comme à chaque fois, on a fait le bilan de ces projets (sous forme de rétrospectives) et on s’est rendu compte que nos estimations n’étaient pas toujours très justes. On a essayé de comprendre pourquoi et voici les 4 points qui ont retenu notre attention :
1 - Un projet peut être complexe pour plusieurs raisons :
La complexité d’un projet tient à plusieurs facteurs :
le type de prestation (est-ce une mission de design, de développement, de conseil business — ou les 3 à la fois ?),
le périmètre du projet (est-ce que l’on a une vision claire du travail à effectuer ou est-ce qu’au contraire il y a des zones de flou ?),
sa durée (est-ce un projet sur 5 jours, 5 semaines, 5 mois ?),
notre expérience sur le type de projet (est-ce que l’on a déjà fait, est-ce que l’on sait faire ?),
l’urgence de la demande et les contraintes planning,
le nombre de parties prenantes,
l’expérience du porteur de projet coté client,
les risques externes et les contraintes sur lesquelles nous n’avons pas la main (par exemple si la solution que l’on envisage repose en partie un service que l’on ne maîtrise pas),
et sûrement bien d’autres facteurs !
Tous ces facteurs peuvent se combiner et dans ce cas, la complexité du projet est exponentielle.
Par exemple, un projet aux enjeux politiques, à mener dans un planning serré, qui va faire intervenir chez nous une équipe pluridisciplinaire (PO, designer(s), développeurs.euse(s)) et que l’on va co-réaliser avec un autre prestataire avec qui nous n’avons encore jamais travaillé, est bien plus complexe qu’une mission de développement de 3/4 jours, au-delà même de la complexité du projet en lui-même.
Cette complexité amène du risque : le risque de perdre du temps face à de longs circuits de validation, d’avoir du mal à se comprendre entre designers et développeurs, d’avoir une organisation très différente de celle du prestataire, ne pas prioriser les mêmes aspects du projets et in-fine, de ne pas tenir les délais et/ou les budgets.
Et le risque, on essaye au maximum de le maitriser.
Un des moyens de maitriser le risque est de se fixer des objectifs clairs et réalistes par rapport à la complexité du projet.
C’est une approche pleine de bon sens, mais il nous semble indispensable de définir en interne le ou les objectifs de la mission et ce, dès la phase d’avant vente. Est-ce que l’on souhaite être rentable ? À réussir le projet pour nous en faire une belle référence ? Est-ce qu’il y a un objectif de formation ou de montée en compétence de l’équipe ?
Une fois le ou les objectifs de la mission définis et que l’on commence à rentrer dans le vif du sujet, il est primordial — pour limiter le risque d’incompréhension en interne — de partager une vision commune sur le sujet. C’est d’autant plus vrai pour les projets les plus longs et les plus complexes. Pour cela, nous avons fait le choix d’aller au plus vite sur des éléments concrets en passant — dès la phase d’avant-vente — par une étape de maquettage.
2 - Il est rarement possible de chiffrer le dev sans avoir défini le design
Nos projets varient de quelques jours à quelques mois de travail et — ce n’est un secret pour personne — plus un projet s’étale dans le temps, plus le risque de se tromper est élevé.
D’abord, parce qu’un projet long nécessite l’intervention de plusieurs expertises, que ces expertises dépendent les unes des autres et aussi parce qu’il nous est difficile de nous projeter sur des périodes si longues, d’anticiper tous les risques.
Aussi, bien souvent, notre client attend de nous que nous estimions la phase de design et la phase de développement de son produit. Pour avoir au plus tôt la visibilité suffisante sur le projet et pour qu’il puisse limiter les risques de son côté (aller cherche du budget, des contraintes planning plus souples, etc.).
Alors, comment peut-on chiffrer le développement sans avoir une idée précise de ce à quoi va ressemble le produit fini ? C’est comme si nous devions estimer le coût de construction d’une maison avant d’avoir les plans définitifs : ça ne fonctionne pas.
Nous avons donc pris la décision — pour les projets longs — d’allouer un peu de temps à l’équipe design pour maquetter la solution de manière macro.
L’objectif est d’avoir une vision commune et partagée de ce à quoi va ressemble le projet une fois terminé.
Dans la pratique, cette phase consiste à créer des wireframes (qui seront challenger lorsque le projet débutera réellement) ou des schémas (arborescence ou cartographie, par exemple) permettant de mieux comprendre le périmètre du projet et d’identifier les risques.
Ce temps est un investissement qui nous coûte un peu au début du projet, mais qui nous permet, in fine, d’économiser beaucoup de temps.
Mais au-delà de partager la vision sur le produit fini, il nous faut partager le même plan d’attaque, la manière dont on va le réaliser.
3 - L’humain est mauvais pour estimer
Nous — humains — sommes assez mauvais lorsqu’il s’agit de traiter un problème complexe et d’avoir une vision globale sur un sujet. Nous avons tendance à découper une grande tâche en petite tâche plus facile à appréhender.
Jusqu’à récemment, nous n’avions pas de vision exhaustive et partagée de toutes les tâches d’un projet. Le risque est alors de minimiser toutes les tâches secondaires associées à une tâche principale.
Par exemple : nous prévoyons d’organiser un atelier en phase de cadrage. Pour cet atelier, nous devrons préparer la trame d’animation, les assets (supports d’atelier), prendre contact avec les participants, caler un créneau, parfois réserver un lieu dédié puis, après l’atelier, mettre au propre ce que l’on a produit et d’envoyer un CR.
Pour une tâche qui semblait tenir sur une demi-journée, on a finalement au moins le double pour la préparation et la restitution.
En créant un listing exhaustif des tâches sur Airtable (on reviendra sur ce sujet dans quelques jours sur notre fil Twitter), nous nous appuyons désormais sur des éléments factuels et concrets, limitant ainsi les mauvaises surprises au cours du projet.
4 - L’estimation d’une tâche dépend de l’estimateur
Estimer une tâche donnée peut varier du simple au triple en fonction du niveau expertise, de l’expérience et des domaines de prédilection de l’estimateur.
Jusqu’à récemment (et c’est encore parfois le cas, pour des sujets bien spécifiques), un de nos Account Managers faisait un appel aux volontaires sur Slack pour demander de l’aide pour la phase d’avant-vente, notamment pour l’estimation des tâches.
Le problème principal étant que nous n’avions pas suffisamment d’éléments factuels sur lesquels nous appuyer et qu’une tâche simple pour un estimateur peut sembler bien plus complexe pour un autre estimateur.
La mise en place du tableau de listing des tâches a en partie résolu ce problème mais nous avons décidé d’aller plus loin en mettant en place un rôle “estimateur” qui a du temps dédié pour participer activement au chiffrage des projets.
Nous avons donc un “estimateur PO”, un “estimateur designer”, trois “estimateurs développeurs”. Dans la pratique, ce sont des référents. Libres à eux de se faire aider par d’autres collaborateurs en fonction de la complexité du projet à estimer et pour challenger les estimations.
Pour résumer
Les projets de ces derniers mois ont été l’occasion de prendre un peu de recul sur nos manières d’aborder les projets et de prendre conscience que :
la complexité d’un projet dépend de plusieurs critères et nous nous efforçons de définir des objectifs réalistes par projet,
allouer du temps en avant-vente pour maquetter / schématiser le produit permet de partager une vision commune sur le produit final et simplifie grandement les échanges dès le début du projet,
nous devons au maximum nous appuyer sur des éléments factuels (estimations précédentes, REX, abaque) et sur nos expériences passées pour limiter les risques d’erreurs lors du chiffrage,
la mise en place d’un rôle “estimateur” permet d’allouer du temps aux estimations, de reconnaître l’expertise des estimateurs et de capitaliser plus facilement sur les projets précédents.
Même si ces pistes d’améliorations ne garantissent pas que nos projets soient toujours bien chiffrés, nous avons remarqué une nette amélioration, que ce soit concernant le chiffrage en lui-même mais aussi en terme de confort de chiffrage. Les avant-vente se font un peu moins dans l’urgence, nous anticipons de mieux en mieux les risques et sommes bien plus réactifs lors de la réponse à nos clients.
Si le sujet vous intéresse, nous vous présenterons bientôt plus en détail l’abaque de chiffrage que nous avons conçu sur Airtable.
