Reportez la fermeture. Soyez à l’aise avec l’incertitude!

Nous ne sommes pas confortables avec le doute et l’incertitude. Nous voulons toujours résoudre les problèmes afin d’éliminer l’incertitude et atteindre la fermeture. Mais l’incertitude peut être une bonne chose : elle laisse les choix ouverts! Forcer une fermeturre prématurée – comme faire un gros design de solution en amont, ou avoir un document de spécification avec de minutieuses tâches à faire – coupe nos options et nous rend vulnérable aux erreurs. En déclarant artificiellement une décision, comme la date de fin d’un projet, n’enlève en rien l’incertitude. il fait juste la masquer.

Notre besoin de fermeture s’explique par notre tentation d’éliminer l’incertitude, que nous soyons prêts à le faire ou non. Mais fixer une décision prématurément réduit nos options, probablement au point d’éliminer le bon choix.

Dans un projet logiciel, comme avec tout projet exploratoire dans n’importe quelle discipline, nous apprenons un peu plus chaque jour. Nous apprenons plus sur les utilisateur, le projet lui même, l’équipe, la technologie etc.

Ceci veut dire que nous serons à notre meilleure connaissance (intelligence) à la toute fin du projet, et à notre meilleure ignorance au tout début. Voulons nous prendre des décisions tôt? Non. Nous voulons reporter ces derniers le plus que possible afin de prendre une meilleure deécision plus tard. Mais cela signifie que les problèmes critiques peuvent rester en suspens pendant une longue période, ce qui rend beaucoup de gens profondément mal à l’aise.

Résistez à la pression. Sachez que vous aller atteindre une décision et l’affaire va être résolue, c’est juste pas aujourd’hui!

Le développement Logiciel en Agile embrasse l’idée de travailler avec l’incertitude. Au départ, vous ne savez pas quelle sera vraiment la date de fin du projet. Vous n’êtes pas 100% certain quelles fonctionnalités seront présents dans la prochaine itération. Vous ne savez pas combien d’itération vous allez avoir. Et ceci est Parfaitement OK: C’est exactement le genre d’incertitude que vous voulez être confortable avec. Vous allez trouver les réponses au fur et à mesure que vous avancer, et vers la fin, toutes les questions vont être répondues.

Vous pouvez bien sur, faire quelques pas pour essayer d’éliminer l’incertitude. Probablement que vous allez discuter avec vos pairs, chercher de l’information par ci par là, ou construire un prototype ou quelque chose du genre. Mais même si ces étapes vont vous aider peu ou beaucoup, ce n’est pas une cure totale. Il en restera toujours des éléments qui sont incertains, et ce n’est pas mauvais. Grugez, effritez et réduisez petit à petit, mais ne clouez pas tant que ce n’est pas encore prêt.

Pour quelque chose dont vous ne connaissez pas mais qui doit être connu par les autres, comme une date de go-live par exemple, vous pouvez l’exprimer comme une cible avec une indication de votre degré de confiance. Par exemple la date pourrait être le 1er Octobre avec une chance de 40%. Mais pensez avant de communiquer une date avec une certitude de 80%! Les gens comprendront que ceci est “presque certain” sans voir qu’il y’a 20% de chance que l’on y arrive pas.

Si vous devez communiquer l’info sur l’architecture au tout début, soyez à l’aise de communiquer que vous ne savez pas quelle va l’architecture finale du logiciel à ce moment. Faites des pas réels pour éliminer l’incertitude, et vous allez pouvoir répondre à cette question à un certain stade du projet.

Dans tous ces cas, l’important n’est pas la cible, mais le processus de travail lui même.

Je comprends que ce n’est pas si évident d’être confortable avec ces idées. Mais il vaut mieux faire face à l’incertitude et d’avoir une attitude consciente au lieu de la masquer.

Ces propos sont profondément inspirés de l’excellent livre “Pragmatic Thinking and Learning” de Andy Hunt