Scotty : Le Maître de la Gestion des Attentes au 23ème Siècle

Je passe beaucoup de temps à bord de l’USS Enterprise originale ces derniers temps. Bien qu’il soit facile de se laisser charmer par le charisme chaotique du Capitaine Kirk ou la logique froide de Spock, la vérité doit être dite. Le vrai génie de ce vaisseau ne porte pas d’uniforme doré ou bleu. Il porte du rouge et a un accent écossais discutable.

Je parle de Montgomery “Scotty” Scott.

Beaucoup voient en l’Ingénieur en Chef un personnage comique ou un homme qui aime un peu trop se plaindre que “les moteurs ne vont pas le supporter”. Ils ont tort. Scotty est le seul adulte dans la pièce. Il est le plus grand praticien de l’art perdu de la Gestion des Attentes.

Le Faiseur de Miracles Calculé

Il y a une structure classique dans presque chaque épisode. Où que l’Enterprise aille, quelque chose de terrible se produit. Les boucliers tombent. Le moteur à distorsion meurt. Les Klingons attaquent.

Kirk, avec l’urgence de quelqu’un qui doit finir un scénario en 45 minutes, hurle dans le communicateur : “Scotty ! Combien de temps avant d’avoir la puissance de distorsion ?”

Scotty, avec la voix tremblante de quelqu’un qui assiste à l’apocalypse, répond : “Capitaine ! Les cristaux sont fracturés. Il me faut au moins huit heures ou nous allons tous devenir de la poussière spatiale !”

Kirk, imperturbable, rétorque : “Vous en avez deux.”

Et que se passe-t-il ? Exactement à la marque d’une heure et cinquante-neuf minutes, Scotty livre le moteur entièrement fonctionnel. Kirk sourit et le qualifie de “faiseur de miracles”.

Pour un observateur non averti, Scotty semble incompétent pour avoir manqué l’estimation de si loin, ou malhonnête pour avoir gonflé les chiffres. Mais ce n’est pas de la malhonnêteté. C’est de l’Ingénierie Défensive.

La Psychologie du Commandement

Scotty comprend une vérité fondamentale sur le leadership et la gestion de projet que beaucoup d’entre nous ignorons. Le Commandement (qu’il s’agisse du Capitaine Kirk ou de votre Product Manager) ne se soucie pas de la thermodynamique. Il ne se soucie pas de la complexité du code ou de la dette technique. Il se soucie du résultat.

Si Scotty disait la vérité honnête (“Capitaine, cela prend deux heures si tout se passe bien”), Kirk, en tant que manager agressif, exigerait que ce soit fait en une. Et quand quelque chose irait inévitablement de travers à mi-chemin, le vaisseau exploserait et le blâme retomberait sur l’ingénieur.

En disant “huit heures”, Scotty crée trois choses vitales :

1. Une Marge de Sécurité : Si quelque chose casse (et c’est toujours le cas), il dispose de six heures de “marge” pour résoudre le problème sans que le Capitaine ne panique.
2. Le Contrôle du Récit : Il définit la gravité de la situation. Il rappelle au commandement que les lois de la physique ne sont pas des suggestions.
3. La Valeur Perçue : Quand il livre en deux heures, il n’a pas juste fait “son travail”. Il a accompli un miracle.

C’est le concept de “Sous-promettre et Sur-livrer” élevé au rang d’art. Scotty ne protège pas seulement sa réputation. Il protège l’intégrité du système contre les demandes absurdes de ceux qui pensent que résoudre des problèmes complexes n’est qu’une question de “pousser plus fort”.

La Leçon pour les Développeurs Juniors

Si vous débutez dans le monde du développement, écoutez ce que je dis.

Il y a une impulsion naturelle à vouloir faire plaisir. Votre Tech Lead ou votre PM viendra à votre bureau et demandera : “Combien de temps pour implémenter cette API de paiement ?” Vous regarderez, vous penserez au meilleur scénario possible où le café est chaud et Stack Overflow (maintenant l’IA) a toutes les réponses, et vous direz : “Oh, je peux le faire en deux jours.”

Vous venez de signer votre arrêt de mort.

Au moment où vous trouverez un bug dans une bibliothèque tierce ou que le serveur de test tombera en panne, vous serez en retard. Vous ferez des nuits blanches. Vous livrerez du code sale. Et à la fin, personne ne vous remerciera pour l’effort. Ils se souviendront seulement que vous étiez en retard.

Faites ce que fait Scotty.

Si vous pensez que cela prend deux jours, dites quatre. Si le PM pleure, négociez à trois. Utilisez ce temps supplémentaire pour tester votre code, pour documenter, pour gérer l’imprévu.

Si vous finissez en deux jours ? Parfait. Livrez-le en avance. Vous serez vu comme efficace et proactif. Vous serez le faiseur de miracles qui a sauvé le Sprint.

Il ne s’agit pas de mentir. Il s’agit de comprendre que le développement logiciel, tout comme l’entretien d’un moteur à distorsion avec des cristaux instables, est un processus chaotique. Votre travail n’est pas seulement d’écrire du code. C’est de gérer le chaos pour que votre Capitaine n’ait pas à le faire.