Comment sommes-nous passés d'une équipe de 2 à 7 personnes par projet ?
Le trimestre dernier, on a eu une problématique en or chez Drakkar : on a eu plus de demandes que ce qu’on était capable de produire.
Alors est arrivé un cas auquel vous faites peut-être face : il a fallu mettre en place des process internes clairs afin de déléguer avec efficacité.
Sauf que structurer une équipe et établir des process internes n’est pas chose facile. Quelles tâches déléguer ? À qui ? De quelle manière ? C’est à toutes ces questions que je me suis confronté !
Je vous partage les solutions que j’ai mises en place dans cet article !
D’abord, il a fallu réfléchir aux différentes tâches qu’une boîte comme la nôtre est amenée à accomplir.
Selon moi, il y a 4 phases quand vous faites du service :
- Vente ;
- Gestion projet ;
- Exécution ;
- Relation client.
Évidemment, je ne pouvais pas continuer de tout faire, alors je me suis alors posé des questions.
Quelles tâches déléguer en fonction de mon profil ?
Voici un profil de personnalité que j’aime beaucoup de par sa simplicité : la méthode DISC.
Pour ma part, je suis complètement dominant (pas étonnant pour un ancien sportif de haut niveau). Ce qui fait que :
- Pour la vente : je suis extrêmement compétiteur et très à l’aise pour signer de nouveaux contrats ;
- Pour la gestion de projet : je n’ai toutefois pas toujours la rigueur nécessaire pour la gestion de projet. Il faut plutôt un profil Conscience/Stabilité qui correspond bien plus à Jean, mon associé ;
- Pour l’exécution : je pense que le sujet n’est même pas de savoir à quel profil l’exécution correspond (probablement conscience pour un développeur). Selon moi, un CEO ne peut pas être dans l’exécution. Son rôle est d’établir les objectifs, d’y faire adhérer et de s’assurer que tout le monde se sente bien et ait ce qu’il faut pour les atteindre ;
- Pour la relation client : je n’ai pas toujours la diplomatie et la patience nécessaire à la relation client. Il faudrait plutôt un profil stabilité/influence.
Je pourrais me dire : « c’est facile, je ne fais plus que de la vente ». Oui, mais non… Évidemment, il y a des conséquences à déléguer chaque phase. J’ai donc dû comprendre les enjeux avant de prendre une décision.
Avant de déléguer, quels enjeux faut-il prendre en compte ?
Voici, selon moi, les risques pour chaque tâche que l’on délègue (en tant que co-fondateur) :
- S’agissant de la vente : si c’est mal vendu (mauvaise compréhension du besoin et de la solution que nous pouvons apporter, délais trop courts, mauvais prix…) ;
- Pour la gestion de projet : beaucoup de frictions, plus grosse dépendance vis-à-vis de la personne en charge ;
- Pour l’exécution : une perte de qualité potentielle ;
- Pour la relation client : c’est avec la vente que la relation client s’établit. Si elle est mauvaise, la relation client est moins bonne.
Chez Drakkar, notre grosse valeur est la compréhension des besoins et notre accompagnement. Nous avons donc décidé, avec Jean, mon associé, de l’organisation suivante : Je gère la vente et la relation client, il gère la gestion de projet et c’est lui qui réalise les ateliers de conception.
Les 4 phases que j’ai décrites ci-dessus sont bien jolies en théorie, mais dans la vraie vie, elles ne sont pas si distinctes que ça. On a donc dû penser les choses autrement.
Quelles tâches déléguer en fonction de notre cœur de métier ?
Chez Drakkar, on aide les entrepreneurs à comprendre le besoin de leur client et à y répondre par une solution numérique. Ce qui veut dire que nous ne sommes pas une simple agence web, nous avons tout un « process » d’accompagnement en plus.
Nous avons alors 3 phases distinctes :
- Conception ;
- Développement ;
- Mesure.
Chaque phase étant fondamentalement différente, nous avons donc dû mettre en place des process différents pour chacune d’entre elles. Je vais donc revenir sur chaque phase une à une.
Quelles parties de notre phase de Conception déléguer et comment ?
Dans la phase de conception, nous avons 8 modules :
- Relevé des besoins : qui sont les utilisateurs ?
- Priorisation des besoins : quelles fonctionnalités sont indispensables pour chaque utilisateur ?
- Parcours utilisateurs : quel chemin l’utilisateur va-t-il parcourir sur notre application pour répondre à son besoin ?
- Maquettes UX : où l’utilisateur va-t-il devoir cliquer pour répondre à son besoin ?
- Test des maquettes : est-ce que les utilisateurs arrivent de manière simple à résoudre leur problème via notre application (avant même d’avoir posé la moindre ligne de code) ?
- Maquettes UI : l’heure de mettre un coup de pinceau et rendre tout joli selon la charte graphique !
- Architecture technique : quelle est la solution technique la plus adaptée pour donner vie à ces maquettes ? Pouvons nous utiliser du no-code ou des APIs ?
- Évaluation et développement : combien de temps (et donc d’argent) va prendre la réalisation du MVP ?
Nous avons donc besoin de quatre métiers distincts :
- Product manager pour toute la conception produit, gestion des besoins, mise en place et analyse des tests maquettes ;
- UX designer ;
- UI designer ;
- Développeur pour l’architecture et l’évaluation technique.
Cependant, si nous avons quatre personnes différentes sur cette phase, le coût de transmission est énorme. Comment s’assurer que :
- l’UX designer comprenne bien les enjeux côté utilisateurs et côté client ?
- L’UI designer comprenne bien les choix UX ?
- Le développeur comprenne bien les enjeux utilisateurs et financiers ?
Notre solution, c’est la polyvalence. Avoir un product manager qui a des notions de développement web et d’UX. Un UX designer qui est aussi UI designer et sait faire du front-end. Un développeur qui a un profil d’entrepreneur.
Donc comment cela se passe-t-il concrètement ?
Le consultant produit va jusqu’à faire les maquettes UX. Il a des notions d’UX et de développeur. Donc il essaie d’imaginer l’interface la plus intuitive et simple d’un point de vue code.
Ensuite, c’est très simple pour l’UX designer de comprendre les enjeux. Il met à profit son expérience pour aller plus loin. Une fois les tests effectués, il réalise l’UI.
Par la suite, un développeur prend la main. Il a les maquettes établies par le designer et le backlog établi par le consultant produit. Il imagine donc l’architecture technique la plus adaptée. Puis, il estime le temps nécessaire à la réalisation du MVP.
Le résultat, c’est 0 temps de transmission et un excellent suivi
Grâce à ce process et à la polyvalence de nos équipes, nous n’avons presque pas de temps de transmission. Ce qui veut dire que le coût pour déléguer est presque nul (sous réserve d’avoir des talents, mais c’est un autre débat).
Sur cette phase de conception, Jean, mon co-fondateur, prend le rôle du consultant produit et n’a plus qu’à gérer 50 % de cette phase.
Cela nous permet de garantir une grande qualité sur les premiers ateliers qui sont fondamentaux pour toute la suite. Et de déléguer le design et l’évaluation tout en gardant une maîtrise totale de l’avancement du projet.
Comment déléguer la phase de Développement ?
Nous développons selon la méthodologie SCRUM :
D’abord, il y a le product manager, Jean (il n’est pas présent sur l’image). Il est en charge du bon déroulement de toute la méthodologie et vient accompagner le product owner.
Le product owner, ou le client si vous préférez, est chargé de la vision du produit. C’est lui qui prend la décision finale sur le développement ou non d’une fonctionnalité.
Le SCRUM Master (moi), est l’arbitre entre le product owner et les développeurs. Il s’assure donc que les tâches demandées sont réalisables et que les développeurs avancent bien.
Le SCRUM Master effectue principalement deux tâches : les mornings et les codes reviews.
Étant donné que je gère la relation client et que je suis un ancien développeur, il fait sens pour moi d’être le SCRUM master sur chaque projet. Cela permet de savoir parfaitement où en est le projet à tout moment lorsque l’on discute avec le client.
Donc, comment réduire le temps que j’y passe pour pouvoir gérer 10 projets en parallèle si besoin ? Nous allons donc nous intéresser séparément à chacune de ces deux tâches.
Les mornings : le rituel journalier pour prendre la température
Généralement, le morning se fait à 9 h du matin. C’est un point très rapide (10min-15min) où on prend la température des développeurs et on y voit :
- Ce qu’ils ont fait la veille ;
- Ce qu’ils comptent faire aujourd’hui ;
- Quels sont leurs points de blocage potentiels.
Mais, il y avait deux problèmes avec ces mornings :
Premièrement, l’horaire, car 9 h c’était trop tôt pour certains développeurs et trop tard pour d’autres. D’un point de vue efficacité, vraiment pas top. Pour moi, en faisant cela, on ne joue pas le jeu du remote. En effet, imposer des horaires fixes ne fait pas bénéficier de l’avantage numéro 1 du travail à distance : les équipes sont plus productives, car elles travaillent de la manière qui leur convient.
De plus, je commence à travailler à 7 h 30 tous les matins. Le matin, je me garde au minimum 2 h de travail en profondeur. Ce créneau à 9 h venait donc me casser ce moment absolument stratégique.
Deuxièmement, la rédaction des comptes rendus et le manque d’efficacité. Étant donné que 9 h était la première heure de la journée pour la plupart des développeurs, ils n’avaient pas forcément les idées claires sur ce qu’ils avaient fait la veille. Surtout le lundi matin !
De plus, pour garder un historique des décisions prises, il est important de rédiger des comptes-rendus de chaque morning.
Sauf que le faire faire aux développeurs en live implique qu’ils n’écoutent pas leurs collègues. Alors, c’était moi qui étais chargé de le faire. Mais cela me prenait au minimum 20 minutes.
Donc, tous les soirs à 18 h, mes devs reçoivent ce message automatique sur Slack :
Ils ont pour consigne de l’envoyer le soir ou le lendemain matin. Ils prennent le temps de réfléchir de leur côté et rédigent eux-mêmes le compte-rendu. Toutefois l’écrit ne remplace pas l’oral pour une bonne cohésion de groupe. Certains problèmes restent cachés.
Alors on a décidé de maintenir les mornings… Mais de les déplacer à 14 h. C’est donc des « cafés » (sauf pour notre développeur Rémy qui habite en Espagne et qui mange à 15 h).
De plus, le compte-rendu est déjà écrit. Donc c’est juste un moment de cohésion où tout le monde échange de manière informelle.
Les codes reviews : s’assurer que le code est de qualité et scalable
Habituellement, c’était moi (le SCRUM master) qui les faisait...Mais !
Effectuer les codes reviews (vérifier la qualité du code) est un travail qui demande de la profondeur. Or, je suis constamment dérangé (étant donné que c’est moi qui gère la vente et la relation client).
Il a donc fallu déléguer cette tâche : nous avons sur chaque projet un développeur expérimenté qui n’a qu’une seule mission, vérifier la bonne qualité du code produit par les développeurs.
S’agissant du process : Une fois qu’un développeur a terminé une fonctionnalité, il fait une demande au développeur expérimenté. Celui-ci demande potentiellement des changements. Le développeur les prend alors en compte. Si le développeur expérimenté est satisfait, on passe à la fonctionnalité suivante !
PS : les devs sont bien français, mais ils se parlent en anglais. Pourquoi ? L’anglais est un peu la langue universelle des développeurs. Si jamais la startup explose et qu’il faut prendre des développeurs étrangers, ce n’est un problème pour personne de reprendre l’historique du code si tout est en anglais.
Résultat : du code de meilleure qualité et un temps passé minime
Le projet est beaucoup plus solide, car les codes reviews sont de meilleure qualité.
Je ne passe quasiment jamais plus de 30 minutes par projet et par jour.
Pourtant, j’ai une vision parfaite de l’état d’avancement du projet qui me permet d’avoir une excellente relation client.
Comment avoir une efficacité redoutable sur notre phase de mesure ?
Cela se décompose en 3 phases :
- La stratégie de feedback & KPIs ;
- Le choix et implémentation des outils ;
- Les recommandations.
Expliquer à une personne externe les enjeux de l’application prendrait un temps monstre. Là aussi, nous avons notre formule magique : la polyvalence.
Jean maîtrise la plupart des outils du marché d’Analytics et a parfaitement les enjeux en tête de par son rôle de product owner. C’est donc lui qui choisit les outils.
Si jamais l’implémentation de certains outils est poussée, il fait la base et délègue à la bonne personne. Comme les KPIs sont établis et que la base de l’outil est là, il y a, là aussi, très peu de temps de transmission.
Nous avons donc une efficacité redoutable et nous sommes en mesure de déléguer sans aucun problème.
Après des semaines d’itérations, voici notre résultat…
Voilà comment nous sommes passés d’une configuration « Jean et moi, nous faisons tout » à une équipe 7 personnes au minimum :
- Un.e product owner (le client) ;
- Un. e product manager responsable de la vision d’ensemble ;
- Un. e UX/UI designer ;
- Un. e SCRUM master ;
- Un. e développeur expérimenté en charge de la qualité/scalabilité du code ;
- 2 développeurs (ou plus).
J’espère que cet article vous a aidé à mieux comprendre comment nous fonctionnons et comment nous avons effectué cette transition.
Rendez-vous très bientôt pour faire le bilan sur les nouveaux process !
Si d’ici là, vous voulez échanger ou si vous avez des questions, je vous répondrai avec grand plaisir à cette adresse : nathan.menard@drakkar.io