Question stupide ? Pas forcément. Livrer un logiciel de qualité est toujours mieux que de livrer un produit de mauvaise qualité et livrer dans les temps est toujours mieux que de livrer en retard. Mais après ça ?
Un bon logiciel trouvera toujours son public, et ce, même s’il est livré avec 1 mois ou 1 an de retard. L’approche proposée par le patron de Basecamp tourne différemment la question : Il vaut mieux livrer vite un produit fini à 80% plutôt que de passer des semaines à peaufiner des fonctionnalités qui ne sont peut-être pas fondamentales. Le plus important est d’avoir le coeur de l’outil qui fonctionne bien. Le mieux est l’ennemi du bien. Un produit qui fait le job à 80% et qui satisfait l’utilisateur est amplement suffisant pour une première version. Pour une refonte majeure, l’enjeu est différent.
Et pour les livraisons intermédiaires ?
S’il s’agit de corrections de bugs (comme c’est souvent le cas), le correctif doit faire le job : bien et si possible vite. Il faut ennuyer le moins possible l’utilisateur. Une modification de maintenance soulage un problème mais n’apporte pas d’autre satisfaction : elle doit donc être le plus indolore possible.
Et lorsqu’il faut livrer à une date imposée ?
Dans ce cas, et si le planning a dérivé, la meilleure à faire consiste à livrer moins mais livré bien. Pressurer les développeurs pour réaliser un travail de qualité dans un temps trop court ne peut rien amener de bons. Par contre, vilains raccourcis et approximations sont assurément des bombes à retardement pour la vie du logiciel à venir.
Et si le logiciel est fini avant la date fatidique ?
Honnêtement, c’est assez rare. Mais en même temps c’est une chance non pas pour ajouter des fonctionnalités mais pour fignoler ce qui le mérite : la doc, le support et pourquoi pas faire tester le produit à un certain nombre de personnes sélectionnées afin de faire remonter les problèmes que l’on ne voit plus à force de regarder l’outil en chantier au quotidien.