Voilà maintenant bientôt de deux ans et demi que je développe et maintient le système d’information qui permet de gérer l’activité de Zenride. Coordonner toutes les parties prenantes de notre activité (salarié, gestionnaire de flotte, vélocistes, bailleurs) s’est révélé plus complexe que je n’imaginais1.

Et pourtant, malgré la croissance forte que l’on a connu, je suis toujours seul sur le développement2. On a envisagé dès le début d’étoffer l’équipe, et on s’est reposé la question à l’occasion de potentiels nouveaux projets, mais jusque là, c’est passé !

Je ne m’estime pas meilleur programmeur que la moyenne, pas nécessairement le plus rapide non plus, et je suis bien conscient des imperfections du projet. Alors c’est quoi la recette ? Je pense que l’erreur souvent commise est de réfléchir aux moyens, au lieu de mettre plus d’énergie sur les besoins. Pour éviter cet écueil, je garde en tête trois règles simples, dans cet ordre : refuser, de-prioriser, simplifier.

Refuser

Dire non à une demande de fonctionnalité est théoriquement le plus facile, et pourtant c’est peut-être le plus difficile.

Quand il s’agit de demande émanant d’un client, cela demande une bonne maturité pour jauger si cela sera utile aussi pour d’autres clients ou si on peut gagner le client tout en refusant cette demande. Certaines demandes s’écartent aussi de la proposition de valeur du produit et de la société, n’apportant rien à la cible habituelle.

Il est tout aussi difficile de dire non à des idées en interne, de nouveaux projets, d’activités annexes, de fonctionnalité, etc. Ce ne sont pas les méthodes qui manquent pour déterminer si cela est pertinent ou pas pour la société, mais souvent l’enthousiasme des entrepreneurs l’emportent sur la rigueur.

Savoir dire non fait partie du quotidien d’un dirigeant. Je vois cela comme une compétence clé car cela aide à rester concentré et ne pas se disperser. D’expérience, le focus est un facteur majeur de succès.

Dé-prioriser

Si on ne peut pas dire non, la seconde option est de dé-prioriser. A-t-on une contrainte de date réelle ? Est-ce aligné avec nos objectifs business à court terme ? Que risque-t-on à le reporter à plus tard ?

Dé-prioriser à une grande vertu : avec le temps qui coule, cela permet de s’apercevoir qui a vraiment besoin de ce développement. C’est toujours amusant de s’apercevoir que la société poursuit sa croissance malgré que certaines fonctionnalités qui nous semblaient critiques il y a 6 ou 12 mois, n’aient pas encore été développées…

Si vous êtes à l’aise avec la prise de risque, et capable d’être agile pour réagir rapidement si besoin, laisser couler le temps est un très bon outil pour juger des priorités !

Simplifier

Quand on ne peut plus dire non, ni dé-prioriser, il reste un dernier levier : simplifier fonctionnellement. Ok pour le faire, mais pas cette usine à gaz là, on va simplifier !

Quelque part, cela revient à refuser et dé-prioriser, à l’échelle de la fonctionnalité. A-t-on vraiment besoin de tout faire ? N’essaye-t-on pas de régler un problème qui ne s’est pas vraiment encore posé ? A-t-on besoin de toutes ces données, de toutes ces validations, de toutes ces interfaces ? Ne peut-on pas découper en plusieurs étapes (ce qui permettra au passage de juger de la pertinence avec les résultats de la première étape) ?

Je n’ai pas vraiment de méthode en tête pour simplifier fonctionnellement. Pour les produits du type système d’information, le nombre de modèles à créer ou modifier peut être un bon indicateur du potentiel de simplification.

Expérience & coût

Appliquer ces trois règles demande au final beaucoup d’expérience. Il faut une bonne autorité pour dire non ou dé-prioriser, et assez de recul sur la vie d’un produit pour estimer à quel point on peut simplifier tout en obtenant les résultats business attendu.

C’est là où un profil sénior fait toute la différence, et je suis convaincu que c’est clé pour une startup qui n’a pas encore atteint son product-market fit. Je vois parfois des fondateurs non techniques s’entourer de profils techniques junior : je pense que c’est une erreur majeure…

Je comprends bien sûr la question du coût. Mais au risque de provoquer, un développeur, ça ne coûte pas cher. Ce qui coûte cher, c’est de développer des fonctionnalités qui ne servent à rien, car mal conçues, ne répondant à aucun besoin, mal communiquées, et qui finissent à la poubelle. Un bon logiciel qui répond à un besoin permet de tels effets de levier que l’enjeu à mon sens est de bien évaluer les demandes, plus que de se concentrer sur le coût du développeur3.

Ces trois petites règles ont beaucoup de valeur au début de la vie d’une startup, où le product-market fit n’est pas clairement atteint et où les moyens sont limités4.

À Zenride, nous sommes en train de tourner cette page, puisque le product-market fit est clairement derrière nous, et que nous pouvons investir significativement pour conquérir le marché. Du coup, je recrute 😉

  1. Je fais bien la différence entre complexe et difficile. Notre projet ne présente aucun enjeu technique majeur, ce n’est pas difficile. Mais l’ensemble des règles métiers en fait un projet complexe. Et j’essaye d’éviter qu’il soit compliqué, c’est à dire inutilement complexe !
  2. J’ai été aidé par deux personnes en freelance pendant quelques mois quand même !
  3. Cela vaut d’une certaine manière par toutes les promesses de gain de productivité… Mieux vaut commencer par faire le ménage dans les demandes, le gain sera bien plus significatif
  4. Paradoxalement, avoir des moyens très limités aide grandement à s’astreindre à ces règles, puisqu’il n’y a pas le choix. Rien de pire que d’être trop nombreux, c’est le meilleur moyen de faire des choses inutiles.