Minimum Viable Technology (MVT)

Comment avancer vite & délivrer pour l'entreprise.

L'équipe technique, c'est l'arme ultime de certaines entreprises.
Mais pour d'autres, cela peut être un véritable goulot d'étranglement. Car parfois, alors qu'elle pense bien faire, elle installe les futurs blocages aux objectifs de l'entreprise.

Nous allons parler dans cet article d'over-engineering, d'over-thinking, de coupage de cheveux en quatre, de branlage de mouche ... bref, nous allons mettre en avant une philosophie vertueuse pour la santé de vos projets.

“Engineers should be fast acting cowboys
instead of calm clear-headed computer scientists .”
— Jeff Bezos, Amazon
🔫

L'approche MVP

La philosophie "Minimum Viable Product" (MVP) encourage les équipes à construire uniquement le minimum requis à un moment précis, pour s'en servir ensuite de socle pour itérer / améliorer et avancer.
L'approche MVP permet d'expérimenter rapidement et d'enclencher une approche fail-fast-and-invest-where-needed.

Coté produit, c'est une approche qui fait aujourd'hui consensus.
Mais pourtant, coté tech, rien de tout cela !

Au contraire, depuis des décennies, on observe toujours une prévalence d'approches défensives et quasi-paranoïaques (qui était nécessaire pour des projets en waterfall avec une release au bout de 1 ou 2 ans).
Et dans un monde qui bouge rapidement - et pas uniquement les start-ups - cela devient franchement un désavantage compétitif.

Une tendance naturelle à l'over-engineering

C'est à dire à anticiper et à résoudre des cas que l'on n'a pas encore rencontrés et que l'on ne va probablement jamais rencontrer. C'est un problème quasi-inévitable si on ne lutte pas proactivement contre.

Démonstration par l'exemple

Itération #1 : “Pouvoir voler.“, deux approches et chacun a ses raisons de penser qu'il donne le meilleur pour l'entreprise :
Itération #2 : “Pouvoir se rendre d'un point A à un point B.“, ces 2 solutions sont OK.
Itération #3 : “Pouvoir faire l'aller-retour plusieurs fois.“, ces 2 solutions sont OK.
Itération #4 : “Pouvoir transporter des messages.“, ces 2 solutions sont OK mais un avantage pour le Concorde : il est bien plus rapide et pourra transporter des colis !
Itération #5 : “Pouvoir atterrir sur la cheminée d'une maison.“, outch ! l'équipe Concorde est bloquée. L'équipe Vautour est encore OK.
Itération #6 : “Pouvoir faire des déplacements trans-Atlantique.“, à cause de l'itération précédente, l'équipe Concorde est out (c'est dommage pour le coup !). L'équipe Vautour va devoir bricoler quelque chose avec plusieurs oiseaux qui vont se relayer, mais elle commence à être embarrassée et va penser sérieusement à un refactor.
Bon, vu les besoins, il veut quoi le client ? Le traineau du Père-Noël ou quoi ??!

Malheureusement, ce n'est pas une caricature.

Les fondements du problème

Plus sérieusement, le problème, là, c'est que jusqu'à l'itération #5, votre jeune ingénieur bac+5 va trouver la solution Vautour complètement simpliste, voire ringarde.
D'ailleurs, son désir de vouloir le mieux pour l'entreprise, également poussé par son intellect et son égo, le portera naturellement vers la solution du Concorde.
Pire, jusqu'à l'itération #5, le Vautour est même difficile à défendre.

Nous ne sommes pas des robots complètement rationnels, et bien au contraire, nous avons un plan de carrière en tête, un skill plan à avancer et c'est très difficile de résister au "cool".

Le grand public (ou le client, les non-tech) vont avoir tendance s'émerveiller devant la navette spatiale : C'est clair, franchement, quel formidable outil !
Les space-nerd (que je suis) ou les vrais-ingénieurs, eux, savent que la navette spatiale était un cercueil volant qui coûtait bien trop cher (à mettre au point et à opérer). Et avec tout ce budget alloué à l'Espace gaspillé, qui sait où nous serions arrivés à l'heure actuelle

De même, les développeurs juniors ont tendance à valider leurs choix en fonction de ce que les grandes entreprises (ou GAFA) font, considérant alors ces solutions comme des standards.
Mais ces structures sont dans des univers très différents — en terme d'échelle, d'exposition de la marque, d'impact de chaque feature, et de pertes financières en cas de bugs.
A contrario, les plus petites bénéficient d'une liberté perdue de longue date par ces géants, et devraient utiliser cette souplesse à leur avantage.

Les stratégies mises en place par les grandes entreprises sont très souvent non-pertinentes pour les intérêts des entreprises plus petites.

Minimum viable technology (MVT)

La solution à ces problèmes est de construire avec le minimum de technologie nécessaire pour le projet et ses itérations planifiées à date.

Naturellement, chaque entreprise est à un stade différent de son évolution. Ce qui est du MVT pour une grosse entreprise peut être de l'over-engineering pour une startup.

“There is nothing so useless as doing efficiently
that which should not be done at all.”
— Peter Drucker
😮

Les entreprises, et particulièrement les start-ups, expérimentent beaucoup et seulement quelques fonctionnalités survivent au market-fit.

L'implacable loi de Pareto (ou loi du 80–20) est là pour nous le rappeler :
Seulement 20% des fonctionnalités auront besoin d'être approfondies,
le reste finira aux oubliettes.

Donc cherche à envoyer en production ASAP, Done is better than Perfect. Et ensuite, itère et améliore en te basant sur le monde réel et sur des cas clients réels.
Si on te demande de tuer une mouche, pour commencer, tu dois construire simplement une tapette à mouche ou un petit spray.
Si cette feature survit au marché (20% de chances) et qu'il y a besoin de tuer des animaux plus gros, tu pourras augmenter le réservoir de ton spray ... ou faire une plus grosse tapette à mouche ! 🤔

---

Vous pouvez continuer la lecture avec les 9 principes du MVT.

---