Comment foncer dans le mur en tant que startup

Il y a quelques années, j'ai bossé sur un projet qui a fait un flop total.

Pourtant sur papier, tout aurait pu fonctionner.

• Le projet était sexy (comprenez intéressant... visuels élégants, features utiles)
• Il réglait une vraie douleur pour le client
• Il pouvait potentiellement être leader de ce marché

Je vais éviter de donner trop de détails sur le quoi, ni désigner l'entreprise en question mais vous montrer comment dans son process, cette société a réussi à se vautrer alors qu'elle avait tout pour cartonner.

Le projet avançait correctement, je ne dirais pas "bien" car je trouve qu'il y a des choses à reprocher à l'organisation et au modèle:

• Les équipes techniques étaient trop nombreuses
• Les PM se trompaient totalement d'objectif
• On ne prenait pas en considération l'avis des gens

Si bien que, cela faisait un moment que je m'étais rendu compte qu'on fonçait droit dans le mur.

On va décortiquer point par point, afin de comprendre pourquoi je pense que tout ceci n'allait pas.

Trop de devs, tue le dev

Vous savez, en tant que tech on a souvent affaire à des gens qui ne viennent pas du même monde et ont un schéma de pensée totalement biaisé sans employer un autre mot plus péjoratif.

Je pars du principe que lorsqu'une personne me dit:

Ah ok, le projet il met 1 an avec telle équipe ? Et bien on va doubler l'équipe...

Déjà, ça ne sent pas très bon.

On voit tout de suite qu'on a affaire à quelqu'un qui n'a rien compris. Difficile d'expliquer aux gens qu'on aura beau doubler le nombre de voies de TGV pour faire Paris-Bordeaux, on mettra toujours autant de temps à y aller.

Pourtant, ce n'est pas faute d'avoir dit.

Lorsqu'une équipe a trop de développeurs, cela crée une courbe de productivité qui s'inverse, car cela entraine une inertie inévitable dans le projet.

L'égo va s'installer dans le projet, et certaines personnes vont commencer à prendre l'ownership sur certains sujets.

Cela a pour effet de créer des "experts" d'un sujet métier, et dans la durée, réduire le savoir faire de ses collègues sur la même thématique.

Pourquoi ? Parce que ce sera toujours à cette personne de s'occuper de cette problématique.

Toujours ? Jusqu'à ce qu'elle parte, que d'autres mettent les mains dedans et réalisent que personne ne comprend le code qui a été fait.

De même, avoir trop de devs va entraîner inévitablement une réduction du niveau moyen de la qualité de code livrée.

Car il est difficile voire impossible de toujours recruter des devs avec le même niveau de skills.

A un moment on va devoir faire une concession pour accélérer. Donc on aura tendance à dire "oui", le plus rapidement possible au premier venu. A une personne qui aura fait preuve d'un niveau satisfaisant en entretien.

Et dès que cette personne aura rejoint les rangs, la qualité des reviews, la qualité de ce qu'il produit va irrémédiablement impacter le projet dans sa globalité.

Il suffit d'un loup dans la bergerie pour créer un vrai massacre. Et il suffira d'un seul dev, pour vous faire vivre votre pire bug en production.

Un choix douteux en matière d'objectifs

Certains PM, en cherchant à bien faire peuvent saboter votre projet.

De la même manière que chez les devs, les PM auront un impact sur l'implémentation de son produit.

Les PM représentent les choix de la société, son orientation stratégique.

En gros, le PM il va tenir le volant, tandis que les devs vont apporter la puissance à votre moteur.

Vous pourrez aller vite, vous pourrez être les plus rapides, si la personne qui tient le volant a décidé de vous faire prendre le mur, vous finirez dans le mur.

Et le PM va littéralement piloter la machine.

Lorsqu'il faudra choisir entre qualité de produit, fiabilité de produit et vitesse d'exécution, très souvent, il voudra les 3.

Il n'a pas tort, on essaye toujours d'obtenir le meilleur, mais à quel prix?

Est-ce que parfois, pour les PM, le "meilleur" n'est-il pas aussi totalement hors sujet ?

Sur ce projet, on s'est battu pendant des semaines avec les PM pour sortir une version imparfaite du produit. Une version un peu plus manuelle, qui nécessitait des opérateurs pour saisir une partie des informations.

Cela a abouti à un refus catégorique!

Pourtant, s'il fallait ajouter encore un dev pour promettre que le projet allait se boucler dans les semaine qui viennent, cela ne posait aucun problème.

Les PM continuaient à nous demander d'automatiser une partie des informations, de la saisie.

Malheureusement, nous ne pouvons le faire qu'avec un certain volume de données. Il aurait mieux fallu faire l'acquisition de clients, afin d'obtenir les données sur lesquelles s'appuyer pour accélérer le process.

Mais non, impossible de discuter, le projet sortira quand il sera 100% fini, donc: "continuez à intégrer de l'automatisation !"

Résultat: des mois après, les développements étaient toujours "en cours", pour un projet qui aurait déjà pu sortir depuis bien longtemps et tourner de manière plus artisanale.

Votre opinion ne compte pas

L'entreprise de manière générale, a une fâcheuse tendance à ignorer votre opinion lorsque d'après elle, vous ne provenez pas du domaine d'expertise en question.

De loin, cela s'entend, si l'on doit parler de finance, ce n'est pas aux devs qu'il faut demander conseil, mais aux comptables.

Si l'on doit parler contrat, ce n'est pas aux PM qu'il faut demander conseil, mais aux RH.

Jusque là tout semble logique. En revanche, quand il s'agit de produit, ceux qui ont leur mot à dire, sont les PM et les dirigeants. Votre avis en tant que dev ne compte pas.

De loin, tout ceci parait normal. Or, avec du recul, je ne peux pas m'empêcher de trouver ça bizarre.

Les devs travaillent sur ce produit, ils le manipulent tous les jours et sont probablement les plus au fait concernant l'avancement de celui-ci.

Et dans cette situation, je trouve cela étrange de ne pas tendre l'oreille quand ils sonnent l'alerte.

C'est comme s'il fallait être pompier pour crier "au feu !" sinon personne ne vous écoute. Dans cette situation, la notion d'expertise devrait être partagée.

Bilan

Combinez les trois points que je vous ai cité, vous détenez le cocktail pour planter votre projet à 99%.

Mais qui suis-je pour dire cela?

Après tout, je ne suis pas le contrôleur de gestion, encore moins le CPO.

Non, juste que j'ai assisté à la scène en première loge. Impuissant, j'ai regardé les équipes produits et moi-même à l'intérieur de l'engin, foncer dans le mur avec beaucoup d'entrain.

Mais le bilan est catastrophique. Ce sont des millions qui sont partis à la poubelle, un beau produit gâché et des remords.

Si vous aussi vous avez connu ce genre de situation, n'hésitez pas à donner vos conseils sur comment faire bouger les choses, comment être moteur dans la prise de décision.