5 principes clés que tout responsable de l’ingénierie doit maîtriser

1. Le principe de Pareto : Concentrez-vous sur ce qui compte vraiment

Dans le monde des affaires et de l’ingénierie, les efforts ne sont pas toujours suivis de résultats. La plupart de vos actions ne font pas bouger l’aiguille. Le principe de Pareto, mieux connu sous le nom de règle des 80/20, stipule que 80 % des résultats proviennent de seulement 20 % des intrants. Il s’applique partout : une fraction de vos clients génère la majeure partie de votre chiffre d’affaires, une petite partie des caractéristiques de votre produit suscite la majorité de l’engagement des utilisateurs et une poignée de goulets d’étranglement est à l’origine de la plupart des défaillances du système.

Les responsables de l’ingénierie qui comprennent ce principe peuvent améliorer radicalement l’efficacité. Le défi consiste donc à savoir qui 20 % sur lesquels se concentrer. Et c’est là que les choses se compliquent. Les biais cognitifs et la dynamique de groupe compliquent l’établissement des priorités. Les équipes perdent souvent du temps sur des décisions à faible impact, un phénomène connu sous le nom de « bike-shedding » (de l’anglais « bike »). La loi de Parkinson sur la banalité). This happens when people obsess over minor, easy-to-understand details (like picking a UI color) while neglecting complex but important issues (like system architecture).

Il y a aussi la conception par comité, où un trop grand nombre de parties prenantes dilue la prise de décision, ce qui aboutit à des produits médiocres et surdimensionnés. Plus il y a de voix dans la salle, moins le leadership est décisif. À cela s’ajoute la pensée de groupe, où les choix consensuels remplacent la réflexion approfondie et indépendante.

Alors, quelle est la solution ? Une priorisation brutale. Utilisez la prise de décision fondée sur les données pour identifier les domaines à fort impact. Supprimez les distractions. Faites confiance aux chiffres, pas aux opinions. Les meilleurs dirigeants se concentrent sur le travail qui fait réellement avancer l’entreprise. Si vous optimisez tout, vous n’optimisez rien.

2. La loi de Hofstadter : Tout prend plus de temps que prévu

La planification est une illusion. Quelle que soit votre expérience, quel que soit le nombre de fois où vous vous êtes déjà fait avoir, tout prend plus de temps que prévu, même lorsque vous vous attendez à ce que cela prenne plus de temps. C’est la loi de Hofstadter en action, et c’est une vérité fondamentale dans le développement de logiciels et dans le monde des affaires.

Pourquoi l’estimation est-elle si difficile ? Parce que les systèmes modernes sont absurdement complexes. Chaque projet logiciel repose sur des couches de dépendances, d’interactions imprévisibles et de dette technique. Vous devez écrire du code et l’intégrer dans un écosystème où une seule erreur peut tout casser.

La sous-estimation a des causes bien connues :

• La règle des quatre-vingt-dix : « Les premiers 90 % du code représentent les premiers 90 % du temps de développement. Les 10 % restants du code représentent 90 % supplémentaires. » Cela explique pourquoi les projets traînent à la ligne d’arrivée – les corrections de bogues, l’intégration et les cas limites prennent plus de temps que prévu.

• La loi de Parkinson : « Le travail s’étend pour remplir le temps disponible. Si vous donnez à une équipe six semaines pour livrer une fonctionnalité, elle prendra six semaines, même si elle pourrait le faire en quatre.

• La complexité cachée : Chaque application présente un niveau de complexité irréductible (loi de Tesler). Some things can’t be simplified without breaking functionality.

Comment contourner ce problème ? Ajoutez un tampon. Prenez votre estimation la plus optimiste et ajoutez-y 50 %. C’est du réalisme, pas du pessimisme. Ne faites pas de promesses, mais tenez vos promesses. Soyez prêt à faire face aux inconnues. Si un projet semble devoir durer six mois, prévoyez-en huit. Et ne pensez jamais qu’une date limite signifie que quelque chose sera terminé. Les délais ne sont que des espoirs et la réalité l’emporte toujours.

3. La loi de Brooks : L’ajout de personnes à un projet tardif le rend plus tardif.

La plupart des cadres partent du principe que si un projet prend du retard, la solution la plus évidente est d’y affecter davantage de personnel. Logique, n’est-ce pas ? Plus de mains, plus de rapidité. Mais ce n’est pas du tout le cas. La loi de Brooks, nommée d’après Fred Brooks (auteur de The Mythical Man-Month), affirme que l’ajout de personnes à un projet logiciel tardif ne fait que le retarder.

Voici pourquoi :

1. Frais généraux de communication : Chaque nouveau membre de l’équipe augmente la complexité de la coordination. Dans une équipe de cinq personnes, il n’y a que 10 canaux de communication. Vous doublez l’équipe pour la porter à dix personnes ? Il y a alors 45 canaux de communication. Plus vous ajoutez de personnes, plus vous passez de temps à organiser des réunions, à synchroniser les connaissances et à éviter les malentendus.

2. Délais d’intégration : Les nouveaux ingénieurs ont besoin de temps pour monter en puissance. Ils posent des questions, ont besoin de conseils et ralentissent les membres de l’équipe senior. Au lieu d’accélérer le développement, ils introduisent des frictions.

3. Divisibilité des tâches : Certaines tâches ne peuvent pas être réparties entre plusieurs personnes. Si un module logiciel nécessite une compréhension approfondie de l’architecture, le fait d’y affecter davantage d’ingénieurs ne sera d’aucune utilité – il pourrait même aggraver la situation. Vous ne pouvez pas accélérer une grossesse en engageant neuf femmes qui porteront chacune le bébé pendant un mois. Certaines choses prennent du temps.

Quelle est donc l’alternative ? Au lieu d’augmenter les effectifs, optimisez l’efficacité.

• Rationalisez les flux de travail : Supprimez les obstacles inutiles et les étapes redondantes.

• Améliorez l’automatisation : Utilisez des outils qui réduisent les tâches manuelles.

• Améliorez la collaboration : Les petites équipes bien alignées sont plus performantes que les grandes équipes fragmentées.

« Des entreprises comme WhatsApp, Airbnb et GitHub se sont développées à grande échelle avec des équipes d’ingénieurs réduites. Elles se sont attachées à travailler plus intelligemment, et pas seulement à travailler plus. Lancer des corps sur un problème est une façon paresseuse d’éviter de résoudre des problèmes plus profonds. Le véritable défi consiste à s’assurer que l’équipe dont vous disposez déjà travaille à son plein potentiel. »

4. La loi de Goodhart : Les mesures seules ne résoudront pas vos problèmes

Ce qui est mesuré est géré. Lorsqu’une mesure devient un objectif, elle cesse d’être une bonne mesure. C’est la loi de Goodhart, qui explique pourquoi les mesures de performance, lorsqu’elles sont utilisées à l’aveuglette, peuvent se retourner contre vous.

Les cadres aiment les indicateurs. Ils veulent des chiffres simples pour suivre la productivité, l’efficacité et le succès. Le problème ? L’ingénierie logicielle n’est pas une chaîne de production. Vous ne pouvez pas mesurer le travail de connaissance de la même manière que vous mesurez la production dans une usine de fabrication. Les développeurs doivent résoudre des problèmes, remanier le code et prévenir les catastrophes avant qu’elles ne se produisent.

Prenons l’exemple des lignes de code (LoC). Si vous jugez les ingénieurs en fonction de la quantité de code qu’ils écrivent, ils en écriront plus, mais plus n’est pas nécessairement mieux. Plus de code signifie plus de bogues, plus de maintenance et plus de complexité. Un excellent ingénieur peut supprimer des milliers de lignes de mauvais code et améliorer les performances, mais si vous mesurez la productivité en fonction du nombre de lignes de code, il aura l’air improductif.

Vous pouvez également vous pencher sur la réduction du nombre de bogues. Si les performances d’une équipe sont jugées à l’aune de la réduction du nombre de bogues signalés, il se peut qu’elle commence à jouer le jeu :

• Ils corrigent d’abord les bogues faciles (au lieu de s’attaquer aux vrais problèmes).

• Ils évitent de signaler les problèmes (pour maintenir les chiffres bas).

• Ils préconisent des solutions rapides et temporaires (qui créent une dette technique à long terme).

Quelle est donc la solution ? Des mesures plus intelligentes. Les leaders du secteur se sont éloignés des mesures naïves et ont adopté des cadres holistiques tels que :

• Cadre SPACE : Il prend en compte la satisfaction, la performance, l’activité, la communication et l’efficacité pour obtenir une vision équilibrée de la productivité de l’ingénierie.

• Métriques DORA : Mesure la fréquence de déploiement, le délai d’exécution des changements, le temps moyen de récupération et le taux d’échec des changements – des indicateurs réels d’équipes logicielles performantes.

• Expérience du développeur (DevEx) : se concentre sur l’élimination des frictions dans les flux de travail des développeurs plutôt que sur l’imposition d’objectifs de productivité artificiels.

En fin de compte, les indicateurs doivent guider les décisions, et non les dicter. Mesurez ce qui compte, mais ne laissez jamais les chiffres remplacer le jugement. Les meilleurs dirigeants savent que les grandes équipes ne se construisent pas en poursuivant les mauvais objectifs. Au contraire, elles se construisent en créant un environnement dans lequel les personnes peuvent donner le meilleur d’elles-mêmes.

5. La loi de Conway : La structure de votre organisation façonne votre logiciel

Votre architecture logicielle reflète votre organigramme. C’est la loi de Conway, qui explique pourquoi vos systèmes finissent par être aussi fragmentés, lents et bureaucratiques que vos équipes.

L’idée de Melvin Conway est simple : La façon dont les équipes communiquent détermine la façon dont leurs logiciels sont construits. Si vos équipes sont cloisonnées, votre architecture le sera également. Si les différents départements se parlent à peine, attendez-vous à des API mal adaptées, à des travaux en double et à des flux de travail inefficaces.

« Le logiciel ne façonne pas l’entreprise, c’est l’entreprise qui façonne le logiciel.

Observez les grandes entreprises dotées de structures rigides et bureaucratiques. Leurs systèmes sont souvent lourds, lents et inefficaces, à l’image de leur processus décisionnel. En revanche, les entreprises dotées de petites équipes autonomes construisent des systèmes plus rapides, plus modulaires et plus adaptables.

Amazon l’a compris très tôt. Jeff Bezos a appliqué la « règle des deux pizzas » : les équipes doivent être suffisamment petites pour pouvoir être nourries avec deux pizzas. Cette structure a donné naissance aux microservices-de petits composants logiciels indépendants qui communiquent entre eux, à l’instar des équipes légères d’Amazon.

Alors, comment appliquer la loi de Conway à votre avantage ?

1. Alignez les équipes sur l’architecture : Si vous voulez un logiciel modulaire, structurez vos équipes en conséquence. Divisez les équipes monolithiques en groupes plus petits et plus ciblés dont la responsabilité est clairement établie.

2. Encouragez la collaboration interfonctionnelle : Les grands systèmes ne se construisent pas en vase clos. Favorisez la communication entre les équipes d’ingénieurs, de produits et d’entreprises.

3. Réduisez les frictions au sein de l’organisation : Simplifiez la prise de décision, supprimez les couches superflues et veillez à ce que les équipes puissent agir rapidement sans avoir à attendre l’approbation de dix personnes différentes.

Si votre logiciel est un gâchis, ne vous contentez pas de blâmer les développeurs. Examinez attentivement la structure de votre entreprise. Réparez les goulets d’étranglement de la communication, et vos systèmes suivront. Les meilleures entreprises technologiques conçoivent des équipes performantes qui créent des logiciels performants. inévitable.

Principaux enseignements pour les dirigeants

• Donnez la priorité aux tâches à fort impact : Concentrez-vous sur les 20 % de tâches qui génèrent 80 % des résultats (principe de Pareto). Identifiez et hiérarchisez les projets les plus importants afin de maximiser la productivité de l’équipe et d’éviter de gaspiller des ressources sur des travaux à faible impact.

• Planifiez avec des délais réalistes : Adoptez la loi de Hofstadter – les projets prennent presque toujours plus de temps que prévu. Ajoutez une marge à vos estimations de temps pour tenir compte des complexités imprévues et garantir des délais de livraison plus précis.

• Évitez d’avoir recours à des équipes élargies comme solution : La loi de Brooks montre que le fait d’ajouter des personnes à un projet en retard a souvent pour effet de le retarder. Au lieu d’élargir les équipes, rationalisez les processus, améliorez la communication et encouragez la collaboration pour maintenir l’efficacité et réduire les retards.

• Utilisez des mesures intelligentes et globales : Ne vous fiez pas à des mesures unidimensionnelles telles que les lignes de code ou le nombre de bogues. Adoptez des cadres tels que SPACE ou DORA pour évaluer la productivité de manière plus efficace et apporter des améliorations significatives sans fausser les résultats.