Certaines personnes pensent que la meilleure façon d’estimer un projet est d’avoir des exigences détaillées et des informations de conception pour chaque fonctionnalité. Elles peuvent soutenir que c’est la manière la plus professionnelle et précise d’aborder le problème. Toutefois, je ne partage pas cet avis. Je pense qu’il est plus important de pouvoir prendre rapidement des décisions concernant le périmètre du projet sans passer trop de temps et de ressources à faire des estimations détaillées. Pourquoi ? Parce que les estimations détaillées se révèlent souvent fausses ou sans pertinence plus tard, et elles créent un « inventaire gaspillé » qui aurait pu être utilisé pour des activités plus valorisantes. Je vous suggère de ne faire des estimations détaillées que lorsque le calendrier le permet, et lorsque vous avez une compréhension claire de la valeur et de la priorité de chaque fonctionnalité.

L’une des problèmes les plus frustrants, les plus répandus et apparemment tout simplement sinistres dans le développement d’applications est le « syndrome du “Oui, mais” », observation de la réaction des utilisateurs à chaque logiciel que j’ai jamais développé.

Pour une raison quelconque, j’observe toujours deux réactions immédiates, distinctes et séparées lorsque les utilisateurs voient pour la première fois l’implémentation du système :

• « Wahou, c’est super cool ; on peut vraiment l’utiliser, quel beau travail, bon boulot, etc. » • « Oui, mais, hum, maintenant que je le vois, et si on faisait… ? N’aurait-il pas été bien si… ? Que s’est-il passé avec… ? »