En développement logiciel on nomme parfois DEFINITION OF DONE les conditions à remplir pour considérer un travail fini. Lors de l'implémentation d'une nouvelle fonctionnalité, l'introduction d'un nouveau logiciel, ou une migration, par exemple.
Je n'ai jamais été un grand adepte du concept en pratique. Et je ne trouve pas les débats enflammés sur la bonne définition d'un grand intérêt.
Cela dit l'expérience des succès et des foirages m'amène par moment à m'emparer de la notion, en la résumant à sa plus simple définition :
C'est DONE si un utilisateur en fait usage quotidiennement
Pour éviter cela dit que ce ne soit jamais DONE, ou seulement dans 10 ans, j'y ajoute :
Ca doit être DONE fin de semaine
Repeat. Voilà.
Deux règles super simples.
Spoiler: les mettre en oeuvre est très compliqué.
Je vois encore trop souvent des violations manifestes de ces deux principes, j'insiste donc lourdement.
Si cela fait six mois ou un an que vous développez un truc qui n'a aucun utilisateur quotidien, vous demandez implicitement à votre patron ou client de supporter sur ses propres économies l'ensemble de votre salaire annuel, sans aucun retour sur investissement.
Parfois c'est sa faute : il n'a qu'à trouver des utilisateurs après tout 🤷♂️. Classique en startup.
Et puis parfois pas, aussi 😉.
Mais ok. C'est très très compliqué, trop compliqué. Que peut-on faire collectivement pour améliorer tout cela ?