Ce que 9 ans au service des porteurs de projet m’ont appris

Et voilà, une page se tourne. Après presque neuf ans à travailler pour le BearStudio, une société de service, je passe à un nouveau chapitre professionnel. Il n’y a pas de meilleur moment pour synthétiser les apprentissages que je tire de cette expérience, ce que je vais faire dans ce premier article de blog.

Le BearStudio, c’est un petit studio de développement web et mobile dont les mantras sont “#NoBullshit” et “De l’idée à la mise en production”.

• NoBullshit, parce qu’on a toujours dit ce qu’on pensait ouvertement, que ce soit aux clients, pour un devoir de conseil, ou aux développeurs, dans l’optique de progresser du mieux possible.
• De l’idée à la mise en production, parce qu’on assiste les porteurs de projets dans le cycle complet de la vie de leur projet. Qu’il s’agisse de nouveaux entrepreneurs ou de clients de grandes entreprises, le but est de mettre à disposition de nos clients l’agilité, les connaissances et les ressources de l’entreprise.

Je suis arrivé au BearStudio moins d’un an après sa création, quand l’équipe était composée du CTO, du designer et dev front, et d’un ou deux développeurs back. Une équipe aussi petite permet de travailler en direct avec les différentes personnes de l’équipe, mais aussi en communication directe avec les clients. C’est donc plus simple d’apprendre de chacun et de chaque rôle : designer, dev front, dev back, infra, CTO, commercial, etc.

Je vais donc tenter de résumer tout ce que j’ai pu apprendre sur l’entrepreneuriat et sur le développement durant ces 9 années au sein d’une équipe qui est passée de 3 à 30 personnes.

Tester son idée et valider un marché

Lorsqu’on développe un produit, on a souvent une vision et des envies bien définies, ce qui nous amène à nous faire une idée de la “perfection” de notre produit. Selon moi, c’est pour cette raison que trop d’entrepreneurs attendent d’avoir le produit parfait avant de le lancer, ce qui est une grosse erreur la plupart du temps.

1. Ça coûte cher : plus vous viserez un produit parfait, plus ça nécessitera de budget pour le développer. En comptant que le TJ (tarif journalier) de développeurs expérimentés en France est de 500 à 600 €, et que des fonctionnalités peuvent prendre 5, 10 ou 30 jours, le projet parfait coûte rapidement cher.
2. Ça prend du temps : au-delà du coût induit par le temps de développement des fonctionnalités dont l’application pourrait se passer, cela signifie que ce temps n’est pas investi dans d’autres sujets prioritaires pour faire grandir le business autour de l’application.
3. L’expérience me montre que c’est peine perdue d’imaginer ce que les utilisateurs vont faire de notre produit. Évidemment, je parle ici des grandes lignes. Je ne dis pas qu’en développant une application de réservation de billets d’avion, on doit laisser les utilisateurs s’en servir pour réserver des places de concert. Je dis simplement qu’un entrepreneur et son équipe ne représentent pas un échantillon de population suffisant pour comprendre les besoins et habitudes de tous les utilisateurs, ainsi que les opportunités dans le business ciblé par l’application. C’est en mettant l’application dans les mains des utilisateurs que des besoins se créent, et il n’y a rien de mieux qu’un besoin remonté par un utilisateur prêt à payer pour ça.
4. Et s’il n’y avait pas de marché dans ce domaine d’application ? La meilleure étude de marché consiste à proposer le produit final et voir si des utilisateurs se manifestent. Mais rien ne sert d’avoir une application parfaite. C’est la raison pour laquelle il est important de viser un MVP (Minimum Valuable Product).

S’organiser pour faire avancer son projet

Comme je le disais, il y a toujours beaucoup de choses à faire quand on démarre un projet, qu’on parle
d’entrepreneuriat, d’intrapreneuriat ou simplement de prestation.

1. Commencer par des maquettes ou wireframes : S’il y a bien une étape qui permet de minimiser les incompréhensions, c’est la phase de maquettage. Elle sert en même temps d’expression du besoin que de phase de réflexion pour savoir comment le projet fonctionnera concrètement. Il est tout simplement inconcevable de demander à des développeurs de démarrer la création d’une interface s’il n’y a pas de modèle sur lequel se baser. Ne pas faire de maquettes, ou au minimum de wireframes, c’est le meilleur moyen d’avoir une application qui n’est pas cohérente (avec le besoin initial, d’une page à l’autre, visuellement, etc.). Si vous êtes entrepreneur, les maquettes vous permettent aussi, avec un budget bien moins élevé que le budget de développement, de juger de la qualité de votre prestataire.

2. Découper les tâches : Tout comme la tâche “Finir le projet” n’est pas acceptable en tant que tâche unitaire, les fonctionnalités “développer le dashboard utilisateur” ou “mettre en place le système de paiement” ne sont pas non plus assez fines et doivent être décomposées. C’est le meilleur moyen de correctement estimer la complexité cachée d’une tâche et d’éviter les écarts qui coûtent cher.

3. Estimer les tâches : Estimer les tâches : qu’on soit 1 ou 10 sur un projet, qu’on travaille pour soi ou pour un client, il est préférable d’estimer les tâches avant de les démarrer, parce que le meilleur moyen de ne pas respecter ses objectifs, c’est de ne pas s’en fixer. Autrement dit, le meilleur moyen de dépasser le budget, c’est de ne pas estimer les tâches. Notez qu’à chaque niveau d’avancement du projet, les estimations pourront être de plus en plus précises (wireframes/maquettes → conception préliminaire → conception détaillée).

4. Démarrer en apportant de la valeur : Démarrer en apportant de la valeur : et si vous pouviez construire votre maison en finissant votre salon en deux semaines, pour pouvoir y vivre, plutôt que d’avoir les murs de toute la maison, sans fenêtre, peinture ni meubles ? Ça vous semble utopique ? Ça ne l’est pas en développement d’application, car il est souvent possible de démarrer par la fonctionnalité ayant le plus de valeur ajoutée pour la tester et la faire tester. Pour donner un exemple très concret, lorsque j’ai créé TraveledMap, j’ai démarré par la page de présentation d’un voyage, avant même de pouvoir créer ce voyage. J’ai utilisé les données “en dur” d’un voyage (format JSON). Faire ça dans ce sens-là m’a permis de

   • présenter le voyage dont je revenais à ma famille, ce que je n’aurais pas pu faire si j’avais commencé par la création de voyage, or ils n’en avaient rien à faire de voir comment on créait un voyage ;
   • faire une démonstration du fonctionnement à des amis pour voir si l’idée leur plaisait, et obtenir leurs suggestions sur leur idée du fonctionnement de l’app ;
   • établir les données à rassembler lors de la création d’un voyage pour ensuite pouvoir l’afficher sur la page déjà existante ;
   • me motiver à continuer le développement du projet, fort du retour de mes démonstrations.

5. Finir des tâches avant d’en commencer de nouvelles : Il est important de garder en tête que tant qu’une fonctionnalité (ou correctif) n’est pas en production, il n’a pas de valeur pour l’utilisateur de l’application. Il faut donc penser à se mettre d’accord sur la “definition of done” et s’outiller pour s’assurer que les tâches ne restent pas “en cours” de développement, mais passent régulièrement à “done”. Je recommande les boards Kanban pour ça.

Sur l’état d’esprit

1. Voir le début d’une collaboration comme une période de “séduction” : Voir le début d’une collaboration comme une période de “séduction” : il est important de garder en tête qu’au début d’une collaboration (client / prestataire par exemple, mais ça marche aussi entre développeurs ou dans une collaboration business), la confiance est à établir. Lorsque je parle de “période de séduction”, il s’agit justement d’accélérer la phase durant laquelle la confiance se crée. Voici quelques conseils pour ça :

   • Être irréprochable sur la communication (être réactif, concis sans sous-communiquer, ne pas hésiter à communiquer en montrant des captures d’écran des résultats, s’assurer d’être clair, etc.).
   • Être proactif et force de proposition.
   • Être très rigoureux sur les obligations (mise à jour des tâches, etc.). Bien sûr, ça ne veut pas dire qu’il ne faut plus faire tout ça lorsque la confiance est établie, mais c’est très rassurant pour le collaborateur de voir qu’il peut se reposer sur vous plutôt que d’avoir à vous porter.

2. Se battre contre le syndrome de l’imposteur : Dès les premiers mois de mon stage de fin d’études au BearStudio, je me suis retrouvé dans des situations où je pensais ne pas avoir ma place. Lorsqu’on m’a confié la gestion du projet principal en l’absence du CTO, par exemple, ou en allant faire du conseil auprès d’une entreprise de télécoms, et aussi lorsqu’on m’a demandé de préparer des sujets de conférence. Ce que je retiens de ces missions, c’est qu’on a tous un vécu différent qui fait qu’on a toujours des choses à apprendre. Il n’y a pas besoin d’être expert avant 15 ans de métier pour partager son expérience, d’une, parce que vous donnez un point de vue, et de deux, parce qu’il y aura toujours des gens moins expérimentés que vous pour écouter ce que vous avez à transmettre.

3. S’adapter à son contexte : Bien que ce conseil semble évident, j’ai été témoin de centaines de décisions prises en “suivant un manuel tout fait”, sans adapter les connaissances apprises au contexte de la situation. Un des exemples les plus marquants étant, il y a plusieurs années, lorsqu’une entreprise nous a recrutés sur un projet car son avenir en dépendait et qu’elle n’arrivait pas à tenir les deadlines fixées. En travaillant sur le projet, un collègue et moi nous sommes rendu compte que les développeurs continuaient d’essayer de produire le code parfait (DDD, architecture hexagonale, microservices), en faisant des reviews de centaines de retours, alors que la vie de l’entreprise dépendait de la tenue de ces deadlines ! S’adapter à son contexte revient ici à comprendre que ça ne sert à rien de produire du code facilement maintenable s’il n’y a plus de code à maintenir, car l’entreprise meurt.

Sur le recrutement, et pour se faire recruter

Au cours de mes différentes missions pour le BearStudio, j’ai effectué des dizaines d’entretiens, que ce soit pour recruter des stagiaires, des salariés, ou même pour faire du recrutement pour des clients. Voici donc ce que je retiens :

1. La logique avant la techno : La logique prévaut sur la connaissance d’une technologie précise. Un développeur sera toujours amené à utiliser des compétences qui ne touchent pas uniquement à la technologie pour laquelle il est recruté. C’est la raison pour laquelle il est important de tester le niveau de logique du candidat. Ce qu’il faut préférer, comme disait Montaigne, c’est “une tête bien faite plutôt qu’une tête bien pleine”. Pour cela, n’hésitez pas à faire passer un test technique d’algorithmie au candidat.

2. Ne jamais se fier uniquement au CV : Il m’est arrivé plus d’une fois d’interviewer des candidats ayant le double de mon nombre d’années d’expérience, mais n’étant pas capables de résoudre des problèmes simples de 3e ou 4e année d’études supérieures. Croyez-moi, il vaut mieux s’en rendre compte à l’entretien !

3. Tester aussi la techno cible : Bien que je recommande de tester avant tout la logique, il reste important de cerner le niveau de connaissance du candidat dans la techno ciblée.

J’écrirai prochainement un article sur le sujet des entretiens pour partager mon expérience en tant que recruteur, mais aussi en tant que candidat.

Conclusion

Si je devais résumer en quelques phrases les leçons que j’ai tirées pendant toutes ces années, je le ferais de la manière suivante :

Le monde du développement est un monde où les compétences sont hétérogènes. Vous pourrez parfois trouver des développeurs sortis d’études qui sont meilleurs que des développeurs de 40 ans ayant 15 années d’expérience. Il y a aussi parfois des “experts” qui mettront en avant des solutions qui ne marchent pas, ou en oubliant la raison pour laquelle nous travaillons : faire avancer des projets et des entreprises. Et même si parfois ça passe par la résolution de défis techniques, il ne faut pas se créer ces défis pour l’amour de la complexité. En d’autres mots : il faut s’adapter, et pour ça, mieux vaut avoir la tête bien faite que la tête bien pleine.