[Les coulisses] Comment nous sommes passés d'une équipe de 2 à 7 personnes par projet ?

Le trimestre dernier, on a eu une problématique en or chez Drakkr : on a eu plus de demandes que ce qu'on était capable de produire.

Alors est arrivé un cas auquel tu fais 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 ?

A qui ?

De quelle manière ?

C'est à toutes ces questions que je me suis confronté...

Je te partage les solutions que j'ai mises en place dans cet article !

Image de couverture de l'article [Les coulisses] Comment nous sommes passés d'une équipe de 2 à 7 personnes par projet ?

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 tu fais du service :

  1. Vente
  2. Gestion projet
  3. Exécution
  4. Relation clients

Evidemment, je ne pouvais pas continuer de tout faire…

Je me suis alors posé la question :

Quelle 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.

Illustration méthode DISC

Pour ma part, je suis complètement Dominant (pas étonnant pour un ancien sportif de haut niveau).

Ce qui fait que :

  1. Vente : je suis extrêmement compétiteur et très à l'aise pour signer des nouveaux contrats.
  2. Gestion projet : par contre, je n'ai pas toujours la rigueur nécessaire pour la Gestion projet. Il faut plutôt un profil Conscience / Stabilité qui correspond bien plus à Jean, mon associé.
  3. Exécution : je pense que le sujet n'est même pas de savoir à quel profil l'Exécution correspond (probablement Conscience pour un dev). 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.
  4. Relation clients : je n'ai pas toujours la diplomatie et la patience nécessaire à la Relation Clients. Il faudrait plutôt un profil Stabilité / Influence.

Facile, je ne fais plus que la Vente.

Oui, mais non… Evidemment 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 à prendre en compte ?

Voici, selon-moi, les risques pour chaque tâche que l'on délègue (en tant que co-fondateur) :

  1. Vente : mal vendu (mauvaise compréhension du besoin et de la solution que nous pouvons apporter, délais trop court, mauvais prix…).
  2. Gestion de projet : beaucoup de frictions + grosse dépendance vis-à-vis de la personne en charge.
  3. Exécution : perte de qualité potentielle.
  4. Relation client : c'est le sales qui le fait et la relation est donc moins bonne.

Chez Drakkr, notre grosse valeur est la compréhension du besoin et notre accompagnement.

Nous avons donc décidé, avec Jean (mon associé), de l'organisation suivante :

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.

Il a alors fallu se demander…

Quelle tâches déléguer en fonction de notre coeur de métier ?

Chez Drakkr, 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 :

  1. Conception
  2. Développement
  3. 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 :

  1. Relevé des besoins : qui sont les utilisateurs ?
  2. Priorisation des besoins : quelles fonctionnalités sont indispensables pour chaque utilisateur ?
  3. Parcours utilisateurs : quel chemin l'utilisateur va parcourir sur notre application pour répondre à son besoin ?
  4. Maquettes UX : où l'utilisateur va t'il devoir cliquer pour répondre à son besoin ?
  5. 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) ?
  6. Maquettes UI : l'heure de mettre un coup de pinceau et rendre tout joli selon la charte graphique !
  7. 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 ?
  8. Evaluation 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 :

  1. Product manager pour toute la conception produit, gestion des besoins, mise en place et analyse des tests maquettes
  2. UX designer
  3. UI designer
  4. 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 :

Notre solution : 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 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 dev. 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.

Derrière, 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.

Résultat : 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.

2. Comment déléguer la phase de Développement ?

Nous développons selon la méthodologie SCRUM :

Illustration méthode SCRUM

D'abord, pas présent sur l'image, il y a le product manager (Jean).

Il est en charge du bon déroulement de toute la méthodologie et de venir accompagner le product owner

Ensuite, il y'a le product owner (le client).

Il est en charge de la vision du produit. C'est lui qui prend la décision finale sur le fait de développer ou non une fonctionnalité.

Ensuite il y a le SCRUM Master (moi).

Il 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 :

Etant 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.

En effet, cela permet de savoir parfaitement où en est le projet à tout moment lorsqu'on discute avec le client.

La question était 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éparemment à chacune de ces deux tâches.

Les mornings : le rituel journalier pour prendre la température

Généralement, le morning se fait à 9h le matin.

C'est un point très rapide (10min-15min) où on prend la température des développeurs et on y voit :

J'avais deux problèmes avec ces mornings…

Problème 1 des mornings : L'horaire

Pour commencer, 9h 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 à 7h30 tous les matins. Le matin, je me garde au minimum 2h de travail en profondeur. Ce créneau à 9h venait donc me casser ce moment absolument stratégique.

Problème 2 des mornings : La rédaction des comptes rendus et le manque d'efficacité

Etant donné que 9h était la première heure de la journée pour la plupart des développeurs, il n'avaient pas forcément les idées au clair 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 leur collègues. Du coup, c'était moi qui étais en charge de le faire.

Problème : ça me prenait au minimum 20min.

La solution

Tous les soirs à 18h, mes devs recoivent ce message automatique sur Slack :

Screenshot message automatique Slack pour les compte-rendus de mornings

Ils ont pour consigne de l'envoyer le soir ou le lendemain matin.

Du coup, ils prennent le temps de réfléchir de leur côté et ils rédigent eux-mêmes le compte-rendu.

Mais l'écrit ne remplace pas l'oral pour la cohésion de groupe et découvrir des problèmes cachés.

Alors on a décidé de maintenir les mornings…

Mais de les déplacer à 14h.

C'est donc des "cafés" (sauf pour notre développeur Rémy qui habite en Espagne et qui mange à 15h).

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 code reviews : s'assurer que le code est de qualité et scalable

Habituellement, c'était moi (le SCRUM master) qui les faisais.

Sauf que…

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…

Ce qui entraîne qu'aujourd'hui…

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.

Au niveau 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 !

Screenshot Pull Request entre les développeurs Rémy Menard et Nicolas Filzi

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 meilleur qualité et un temps passé minime

Le projet est beaucoup plus solide car les code reviews sont de meilleure qualité.

Je ne passe quasiment jamais plus de 30min / projet / 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 ?

Nous avons 3 phases :

  1. Stratégie de feedback & KPIs
  2. Choix et implémentation des outils
  3. Recommandations

Expliquer à une personne externe les enjeux de l'application prendrait un temps monstre. Là aussi, 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 on arrive sur l'implémentation d'outils poussés, il fait la base et délègue à la bonne personne. Comme les KPIs sont établis et la base de l'outil est là, il y a, là aussi, très peu de temps de transmission.

Et le résultat…

Nous avons 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 d'au minimum 7 personnes :

J'espère que cet article t'a aidé à mieux comprendre comment nous fonctionnons et comment nous avons effectué cette transition.

RDV dans un an pour faire le bilan sur les nouveaux process !

Si d'ici là, tu veux échanger là-dessus ou si tu as des questions, je te répondrai avec grand plaisir !

👉 nathan@drakkr.com

Nathan Menard, CEO Drakkr et développeur web
Nathan Menard

CEO Drakkr