En tant que développeurs logiciels, nous sommes constamment chargés d’estimer le temps qu’il faudra pour accomplir des tâches ou livrer une fonctionnalité. Cependant, estimer le temps et l’effort requis pour le développement logiciel est notoirement difficile. L’imprévisibilité des défis techniques, les exigences changeantes et les obstacles imprévus signifient souvent que nos meilleurs efforts pour estimer peuvent encore mener à la frustration quand les choses ne se passent pas comme prévu.

L’idée d’écrire cet article m’est venue en lisant le livre de Robert C. Martin The Clean Coder, dans lequel il explique que les estimations sont intrinsèquement imprécises. C’est particulièrement vrai dans l’industrie logicielle, où les problèmes sont souvent complexes et les obstacles que nous rencontrons sont, par essence, imprévisibles. Bien que nous puissions avoir une idée approximative du temps qu’une tâche prendra, il n’y a aucun moyen de prévoir toutes les complications qui pourraient survenir en cours de route.

Cependant, ce que font les vrais professionnels, par opposition à simplement estimer, c’est s’engager sur des délais. Selon Robert C. Martin, bien que nous puissions estimer en interne, nous devons également nous engager sur une date ou un délai spécifique. Ce niveau de responsabilité nécessite maturité et responsabilisation. C’est une chose de donner une estimation, mais c’en est une autre de s’engager sur une date, connaissant les défis qui nous attendent. C’est cet engagement, plutôt qu’une simple estimation, que nous, en tant que développeurs logiciels, devons apprendre à maîtriser.

L’analogie des mécaniciens

En réfléchissant à cela, l’analogie de prendre une voiture chez le mécanicien m’est venue à l’esprit. Lorsque vous laissez votre voiture pour des réparations, le mécanicien vous fournira généralement une estimation du moment où la réparation sera terminée. Si c’est une tâche simple, comme remplacer une pièce, le mécanicien pourrait vous dire qu’elle sera prête d’ici la fin de la journée. Pour des réparations plus compliquées, il pourrait dire que cela prendra quelques jours.

D’après mon expérience, les mécaniciens ont tendance à se donner un peu de temps supplémentaire lorsqu’ils fournissent une estimation. Ils savent que les choses peuvent mal tourner, comme des pièces qui n’arrivent pas à temps, des problèmes inattendus qui surgissent, ou des complications qui pourraient retarder le travail. C’est pourquoi ils vous disent souvent de revenir en fin d’après-midi, même si la tâche n’est qu’une affaire d’une heure, ou ajoutent un jour ou deux supplémentaires à l’estimation pour les opérations plus longues, s’assurant qu’ils ne sont pas trop optimistes et laissant place à l’incertitude. Bien que cela puisse occasionnellement conduire à une situation où la réparation prend un peu plus de temps que prévu, en tant que client, je suis généralement compréhensif, même si cela signifie que je dois prendre des dispositions pour réorganiser quelques choses. Après tout, le mécanicien a communiqué le potentiel de retards et a pris un engagement réaliste.

Cette transparence et cet engagement réaliste sont ce qui manque, je crois, à l’industrie du développement logiciel. Dans de nombreux cas, en tant que développeurs, nous hésitons à fournir des engagements qui incluent la marge d’erreur nécessaire. Pourquoi ? Les mécaniciens sont-ils naturellement doués dans ce domaine ? Quel est leur arme secrète ?

Essayer de plaire aux managers

Dans l’industrie du logiciel, les principales personnes envers qui nous prenons des engagements sont souvent nos managers. Contrairement aux mécaniciens, qui traitent leurs clients comme… des clients - c’est-à-dire qu’ils se concentrent sur la satisfaction client - les développeurs abordent souvent leurs managers avec l’objectif de leur plaire, ou de les impressionner. Après tout, ce sont eux qui décident de votre prime… Donc nous faisons un pari. Et nous continuons à le faire jour après jour, semaine après semaine, en croisant les doigts et en espérant le meilleur. Mais ce faisant, nous pouvons minimiser les risques ou les défis impliqués dans un projet, en fournissant des estimations trop optimistes dans une tentative de leur plaire. Le problème ici est que cela peut mener à des promesses brisées, des délais manqués, et un manque de confiance, sans parler du redouté burn-out. Tout le contraire de l’effet escompté.

Le problème fondamental est que nous ne considérons pas nos managers comme des “clients” au sens traditionnel. De la même manière qu’un mécanicien n’essaie pas d’impressionner le propriétaire de la voiture mais se concentre plutôt sur la livraison d’une réparation satisfaisante, nous devrions viser à satisfaire nos managers, pas simplement à les impressionner. La vérité est que lorsque nous essayons de plaire ou d’impressionner nos managers, nous essayons vraiment juste de nous satisfaire nous-mêmes. Satisfaire vos managers peut sembler moins gratifiant à court terme, mais croyez-moi, cela s’avérera la meilleure option à long terme : en nous concentrant sur leur satisfaction plutôt que d’essayer de leur plaire, nous pouvons établir des attentes plus réalistes et favoriser une relation de travail plus honnête et transparente.

Un manager satisfait

Alors, comment pouvons-nous améliorer cette dynamique ? La réponse réside dans un mot simple : Honnêteté.

Commencez une conversation avec votre manager. En fait, il pourrait être utile pour les équipes d’avoir un “Indice de Satisfaction du Manager” (similaire à un indice de satisfaction client) pour évaluer ce que leurs managers veulent et attendent vraiment. Avoir une conversation franche avec votre manager sur ses attentes et priorités peut aider à aligner vos engagements avec ce qui est réalistement réalisable.

En nous concentrant sur la satisfaction plutôt que sur l’impression, nous pouvons construire un environnement de travail plus honnête, transparent et efficace. La plupart des managers (sauf quelques vieux de la vieille, endurcis, sans cœur / peu sûrs d’eux - on les connaît) apprécieront de savoir que leurs développeurs sont engagés à livrer un travail de qualité, même si cela prend un peu de temps supplémentaire. En fin de compte, cette approche mène non seulement à de meilleurs résultats mais renforce également la confiance et la relation professionnelle entre développeurs et managers.