Les 6 leçons pour réussir vos projets tech en start-up

Mon co-fondateur et CTO Arnaud m’a appris plusieurs leçons décisives pour réussir les projets tech dans les start-ups, qui ont confirmé ce que j’ai vécu dans mes expériences précédentes de consultant dans des projets digitaux. je vous partage les 6 leçons que j’ai trouvées les plus intéressantes. 

Attention, elles ne sont pas intuitives pour les non-devs, beaucoup de non initiés ne seront pas d’accord :

Leçon 1 : Simplifiez votre projet

Plus le projet est complexe, moins il a de chances de fonctionner. Ce n’est pas évident de construire du logiciel qui marche : c’est tout un art. Quand tu te prépares à développer une usine à gaz, pense à des entreprises comme Blablacar qui emploient des centaines de talents pour développer une plateforme qui ne propose qu’un seul service, demandez-vous pourquoi elles continuent quand même de recruter.

Simplifiez votre offre un maximum et testez-la à la main avant de la développer. Si elle ne fonctionne pas, débarrassez-vous en plutôt que de la garder comme un « plus » sur votre site.

Leçon 2 : Le temps de développement n’est pas un bon critère de décision pour développer ou pas une nouvelle fonctionnalité

Ne pensez pas uniquement au temps de développement, mais aussi au temps de maintenance lié à chaque nouveau développement : toute fonctionnalité que vous développez aujourd’hui freinera tous vos développements futurs.

Pour illustrer ce point, imaginez que vous avez écrit un livre en 10 tomes. Puis imaginez que votre éditeur lit le résumé de votre ouvrage puis vous dit : « je veux que vous rajoutiez un père à votre personnage principal ! »

Pourquoi pas, mais cela aura des conséquences sur toute l’histoire. Ca a l’air simple, mais un bon écrivain ne prendrait pas une telle demande à la légère. 

C’est un peu pareil quand je débarque devant Arnaud et que je lui dis : « En plus de nos cours en groupes hebdomadaires, je veux qu’on développe des stages intensifs. » Un non-dev ne se rend pas forcément compte de tous les impacts que cela aura sur les centaines de milliers de lignes de code existants.

NB : Arnaud l’a finalement développé, mais ce qui me paraissait un petit projet a fini par durer 3 mois !

Leçon 3 : Ne développez pas trop vite

Souvent, développer trop vite revient à saccager le produit et créer de la dette technique que les développeurs ne finiront probablement jamais de rembourser.

Avec une grosse dette technique, des équipes de dizaines de développeurs n’arrivent plus à développer une seule fonctionnalité qui marche. Et surtout, elles n’arrivent plus à attirer et garder les bons profils et se retrouvent avec beaucoup de turnover ou une armée de développeurs qui ne produisent rien. Si vous voulez développer plus vite, réduisez le scope de vos développements plutôt que de mettre la pression sur vos développeurs.

Leçon 4 : Recrutez des développeurs séniors

Ne recrutez pas que des développeurs juniors, même s’ils ont l’air de développer vite : ils vont vous générer une dette technique colossale. Pensez à recruter des gens expérimentés pour les encadrer, les aider à simplifier les développements et à faire suffisamment de tests pour ne pas bousiller votre plateforme.

Leçon 5 : N’écrivez pas de cahier de charges

Les développements ne vont jamais se passer comme prévu. Ne développez jamais une application suite à un devis avec un prestataire externe : ça ne marche pas car justement il faut un cahier des charges figé.

J’ai pu vérifier cette affirmation dans mon réseau : Toutes les startups qui ont essayé de le faire ont échoué sur leur produit, et celles qui s’en sont le mieux sorties ont du reconstruire leur produit.

Quand un prestataire reçoit votre cahier des charges et découvre tous les problèmes que vous n’avez pas vus en l’écrivant, vous pourriez lui laisser l’entière responsabilité : après tout il a signé ! Ne le faites pas, faites des allers-retours, découpez vos projets en petits morceaux et privilégiez plutôt des petites specs courtes. Vous allez comprendre pourquoi dans la dernière leçon.

Leçon 6 : Vous ne pouvez pas tout avoir

Parmi ces 3 dimensions, vous devez être flexible sur au moins une pour que vos projets soient livrés :

1) Qualité du projet

2) Coût / temps de développements

3) Scope du projet

Vous pouvez choisir d’être rigide uniquement sur 2 dimensions parmi ces 3.

Les grands projets que l’état ou les grandes entreprises peuvent se permettre vont privilégier la qualité (1) et un scope large de fonctionnalités (3), et pourront alors se permettre de débourser les sommes nécessaires (flexibles sur la dimension 2).

Quand vous fixez un scope détaillé (cahier des charges) et fixez le coût du projet (budget limité, deadline fixe ou nombre limité de développeurs), vous risquez de saccager le produit. Beaucoup de startuppeurs racontent s’être faits « arnaqués » par des prestataires de service. Non, c’est juste qu’on ne peut pas tout avoir en même temps ! En général les bons prestataires vous mettent en garde, mais peut-être pas suffisamment pour ne pas non plus perdre le projet.

Enfin, si vous êtes une Start-up, vous ne pouvez pas lésiner sur la qualité (1) et en général vos coûts sont limités (2). Donc ne demandez pas trop de fonctionnalités. Faîtes simple !

La construction de logiciel est un art, et j’ai la chance d’avoir à mes côté un maître en la matière. Merci Arnaud de nous apporter ton expertise et de la transmettre depuis 3 ans à nos supers développeurs Julien, Guillaume et Bilel qui gagnent énormément en séniorité grâce à toi ! Ils comprennent aujourd'hui pourquoi au dernier entretien d’embauche je leur ai dit qu'ils ont une chance inouïe de rejoindre l’équipe d’Arnaud :)

Si vous connaissez un développeur sérieux et passionné qui cherche un stage de fin d’étude, même dans 6 mois, marquez-le en commentaire ou partagez-lui cet article, vous boosterez peut-être sa carrière : « Quand le disciple est prêt, le maître vient ».