Un logiciel n’est pas construit comme un produit, il est conçu comme une idée.
Lorsque nous parlons de la création de logiciels de qualité, nous ne parlons pas d’un produit qui passe par des machines dans une usine. Le logiciel est un réseau complexe d’idées, de problèmes uniques et de réflexion critique, dont aucun n’entre dans un moule.
Si vous essayez de mesurer les logiciels de la même manière que les produits physiques, c’est-à-dire en fonction de la production par unité de temps, vous passerez à côté de ce qui fait vraiment la qualité.
Chaque morceau de code est une tentative de résolution d’un problème unique et souvent imprévisible.
Et il n’existe pas d’approche unique pour le construire. Les mesures issues de la révolution industrielle peuvent fonctionner pour les tâches répétitives, mais elles ne peuvent tout simplement pas saisir les subtilités du développement de logiciels, où la créativité et l’innovation l’emportent sur la production brute.
Le suivi du temps fait perdre du temps et passe à côté de l’essentiel
Le suivi des heures incite les développeurs à faire des économies
Demander aux développeurs de passer des heures sur des tâches individuelles ne fait rien d’autre que de les encourager à finir vite plutôt que bien. S’ils pensent au temps, ils ne pensent pas à la qualité ou ne prennent pas le temps de s’attaquer aux problèmes importants et complexes qui apportent une réelle amélioration.
Ce type de structure axée sur le temps favorise la pensée à court terme. Les développeurs peuvent opter pour la facilité, en corrigeant les bogues au lieu de creuser en profondeur et de s’attaquer aux causes profondes.
En fin de compte, nous créons une culture dans laquelle il est plus important de cocher des tâches que de résoudre des problèmes de manière efficace.
Un code complexe ne peut pas être exécuté selon un calendrier précis
Le codage d’une véritable solution n’est pas quelque chose qui s’inscrit dans un chronomètre. Les tâches logicielles sont imprévisibles ; parfois, la correction d’un bogue ne prend que quelques minutes, et d’autres fois, il faut des jours, voire des semaines, de dépannage approfondi.
Les problèmes complexes ne sont pas accompagnés d’une estimation de temps, et en fixer une revient à demander à un artiste de deviner combien de temps il lui faudra pour peindre un chef-d’œuvre. Les développeurs doivent se concentrer sur les résultats, et non sur les heures, ce qui signifie qu’il faut abandonner les mesures de temps rigides qui ne servent qu’à créer de la pression et de l’anxiété autour de la vitesse plutôt que de l’excellence.
Les « culs dans les sièges » et les lignes de code ne mesurent pas les progrès réels
Vous ne pouvez pas forcer les résultats en augmentant le nombre d’heures de travail. Les développeurs ont besoin d’espace pour réfléchir, et pas seulement du temps qu’ils passent à leur bureau.
Certaines des meilleures solutions peuvent être trouvées après des heures de réflexion et seulement quelques lignes de code, mais ces lignes peuvent permettre d’économiser des centaines d’heures à l’avenir.
Si nous ne tenons compte que du nombre d’heures de travail, nous ignorons que le codage consiste à résoudre des problèmes et à trouver des solutions élégantes, et qu’il ne repose pas uniquement sur le fait de se présenter.
Moins de code peut signifier un meilleur code
Compter les lignes de code n’est pas plus fiable que de compter les heures de travail. Parfois, la véritable réussite réside dans la simplification. Supposons que vous réduisiez 1 300 lignes de code à 200 ; vous n’avez pas produit « moins », vous avez créé quelque chose qui fonctionne mieux, qui est plus facile à maintenir et qui permet de gagner du temps à long terme.
Ce n’est pas la quantité de code qui compte, mais la qualité, l’efficacité et la longévité. S’appuyer sur des mesures telles que les lignes de code ne fait qu’engendrer des systèmes gonflés et trop complexes, plus difficiles à maintenir et à améliorer.
Le travail à distance prouve que les développeurs n’ont pas besoin d’être constamment surveillés.
La pandémie a fait sortir les développeurs du bureau, et devinez quoi ? Nous avons constaté que le bon travail se poursuivait. Il s’avère que les développeurs n’ont pas besoin d’être surveillés par des managers pour être efficaces.
En fait, certains des meilleurs travaux sont réalisés lorsque les développeurs disposent d’un espace de réflexion et de la flexibilité nécessaire pour aborder les problèmes comme ils l’entendent.
L’accent n’est plus mis sur les heures et le lieu de travail, mais sur les résultats, et nous avons commencé à envisager la productivité sous un nouvel angle, en appréciant les résultats plutôt que l’assiduité.
Abandonnez définitivement les métriques de la chaîne de montage
Les anciennes métriques de la chaîne de montage ne fonctionnent tout simplement pas dans un monde distant et numérique. Les logiciels sont créés par l’analyse, l’exploration et la révision, et non par la répétition à la chaîne.
Les organisations qui l’ont vraiment compris abandonnent les indicateurs obsolètes et trouvent de nouveaux moyens flexibles de mesurer le succès des développeurs. Cela signifie qu’elles valorisent l’impact plutôt que les heures, les solutions plutôt que la vitesse et la qualité plutôt que la quantité, permettant ainsi aux développeurs de donner le meilleur d’eux-mêmes sans être soumis à la pression de mesures obsolètes.
Dernières réflexions
Voici donc la vraie question : Êtes-vous prêt à vous affranchir des mesures de productivité obsolètes et à aider vos développeurs à avoir un impact réel ? Si vous comptez encore les heures et les lignes de code, vous risquez même de freiner votre équipe.
