Compo­si­tion d’une équipe tech­nique produit


– Dis, on met quoi dans une équipe tech­nique ?

Ça dépend du temps, du produit, des besoins. Voici ma recette par défaut, à réagen­cer en fonc­tion de la réalité. Il reste qu’à chaque fois je finis par me dire que j’au­rais aimé la voir suivre ce schéma :

1 et 2 : Donc au début on commence, il faut un ou deux déve­lop­peurs. Idéa­le­ment à ce niveau ils savent toucher un peu de front et un peu de back, et appré­cient de pouvoir inter­ve­nir partout. Pas d’ad­mi­nis­tra­tion système à cette taille, on exter­na­lise un maxi­mum.


Petit inter­mé­diaire. Il faut une direc­tion tech­nique avant de passer au troi­sième membre de l’équipe. Ce peut être un direc­teur tech­nique à part entière ou un des deux déve­lop­peurs qui a suffi­sam­ment de bouteille mais il faut quelqu’un qui a une vision tech­nique, et pas un néophyte.


3 : Le troi­sième c’est le grand oublié : le web desi­gner. Il fait de l’UX, de l’UI, et va défi­nir une vraie expé­rience client. Bien évidem­ment tout dépend du métier et du produit mais recru­ter trop tard est habi­tuel­le­ment une erreur. La mode est de consi­dé­rer que ce profil doit même faire partie des fonda­teurs.

4 : On complète avec un troi­sième déve­lop­peur. On peut commen­cer à envi­sa­ger un spécia­liste qui apporte une exper­tise qui manque aux deux autres mais il faudra quand même qu’il accepte de toucher un peu à tout.

5 : L’équipe commence à avan­cer, main­te­nant il lui faut quelqu’un pour donner une direc­tion et prendre du recul. On peut l’ap­pe­ler product owner, respon­sable produit, chef de projet fonc­tion­nel, analyste métier… Il aura pour charge de réflé­chir aux usages, imagi­ner le produit, assu­rer la vision. Ce doit être quelqu’un de dédié, sans posi­tion hiérar­chique sur le reste de l’équipe.

6 (et 7 ?) : L’équipe avance, dans le bon sens, il reste à lui donner un peu de puis­sance avec un ou deux autres déve­lop­peurs. À partir de quatre déve­lop­peurs c’est la taille où l’ef­fort est démul­ti­plié et où on peut commen­cer à assu­rer les impré­vus, ou les congés de chacun. Au delà de 5 déve­lop­peurs on commence à faire des sous-équipes et ça n’a plus grand inté­rêt.
Les équipes les plus dyna­miques avec lesquelles j’ai travaillé ont des déve­lop­peurs qui travaillent tous sur l’in­té­gra­lité du produit mais on peut aussi avoir quelques experts qui inter­viennent essen­tiel­le­ment sur leur domaine de compé­tence.

8 : Second grand oublié : Le dev op – ou sys admin, peu importe le nom. Son rôle est d’as­su­rer la produc­tion mais sa réelle valeur est de flui­di­fier tout l’ou­tillage interne, comme la plate­forme d’in­té­gra­tion conti­nue ou les scripts de déploie­ment.
Il n’a d’in­té­rêt qu’a­vec une équipe qui tourne, mais s’en passer c’est comme conti­nuer en gardant un boulet aux pieds. Avant ce sont les déve­lop­peurs qui sont obli­gés de perdre du temps et du focus avec tout ça.

9 : Je vais à neuf avant de m’ar­rê­ter mais j’ajoute quand même un dernier profil avec un tech­ni­cien. C’est lui qui va assu­rer les tâches d’ex­ploi­ta­tion courantes, s’oc­cu­per du support tech­nique, du support utili­sa­teur, et soula­ger le product owner.
On peut s’en passer mais c’est au prix d’un manque de focus non négli­geable, donc d’un peu de gâchis.


Je n’ai pas parlé de mana­ger mais à neuf le besoin s’est peut-être déjà fait sentir depuis un petit moment. S’il existe, il peut faire le dixième. Le problème du mana­ger mérite plus d’un billet mais je retiens une règle : ni la direc­tion commer­ciale de la société, ni le product owner de l’équipe. Ce peut être le CTO qui gère la direc­tion tech­nique décrite plus haut.


Je n’ai pas mis de QA non plus. Je conti­nue à penser que l’équipe doit être respon­sable de ce qu’elle livre. Une QA sépa­rée à tendance à déres­pon­sa­bi­li­ser mais aussi à ajou­ter de la distance avec la réalité et du délai lors des livrai­sons. Ça aura du sens quand il y aura plusieurs équipes, pas tout de suite. Le dev op pourra par contre outiller et auto­ma­ti­ser un maxi­mum de tests et de proces­sus entre temps.


Et vous, vous conseillez quoi comme compo­si­tion ? Qu’ai-je oublié ?


6 réponses à “Compo­si­tion d’une équipe tech­nique produit”

  1. +1 pour le sysadmin. L’administration système est un vrai job à temps plein. Gérer le parc de serveurs (qu’ils soient loués ou achetés), les noms de domaines, mettre à jour les machines, les outils nécessaires aux développements, mettre en place les sauvegardes (ET LES VERIFIER REGULIEREMENT), mettre en place le monitoring, surveiller, configurer finement les services pour qu’ils soient performants, sécuriser les machines, configurer le réseau de production, régler les problèmes techniques etc etc..

    Si il n’y a pas d’admin sys (un vrai, pas un dev qui s’improvise admin-sys), cela peut être, soit très chronophage pour les développeurs parce que ce n’est pas leur métier, donc moins compétents, donc y passent plus de temps et du coup le développement en patis. Soit très dangereux, parce que personne n’y passe le temps nécessaire (pas le temps de faire les mises à jour, pas le temps de vérifier régulièrement les backups), et peut mettre en péril le projet quand ça tombe en rade (ça fait perdre de l’argent, du temps etc..).

    Pour moi, l’admin sys est la personne prioritaire à embaucher, par rapport à un dev, dés lors qu’on commence à mettre en production, quelque soit la grosseur de l’équipe. Un dev qui fait de l’admin sys, qui n’a pas l’expérience de la gestion de production (ce qui est très rare), ça revient à faire du bricolage, et c’est couteux au final. Ce n’est pas parce qu’on sait installer Postgresql, déployer un docker Redis, ou (croire qu’on sait) configurer un openssh ou un firewall, ou réaliser un script Ansible qu’on peut s’improviser admin sys.

    • Là on va passer le cap « 3 sys admin » à La Ruche, ce qui va permettre de réellement gérer la prod avec des rotations d’astreintes. Avant ça ne me choque pas si une grosse partie est faite par de l’infogérance.
      Par contre je vois un réel atout dès le début du projet pour gérer tout l’outillage interne des dev, les scripts de déploiements, le jenkins, l’organisation des machines virtuelles ou conteneurs pour faire tourner l’intégration continue, les mises à jour, l’infra de backup, les droits d’accès, le versionnement, la politique de mot de passe, etc. Bref, pas vraiment de la production, mais de l’exploitation interne, ce qui fait que les dev peuvent penser le code plutôt que de passer du temps sur tout ce qu’il y a autour.
      Après effectivement, il y a le monitoring de perf, les config avancées, etc.

  2. Pour ma part j’intègrerais vraiment le 3 dans 1 et 2. Sur tous les derniers projets que j’ai fait, soit on a intégré tout de suite des équipes d’ergo et c’était top, soit on ne l’a pas fait et ça a vraiment manqué. Dès les premiers développement c’est vraiment un profil qu’aujourd’hui je pense comme quasi indispensable pour le développement d’un produit.
    Après il est souvent complexe de s’en rendre compte, genre une interface simple et utilisable sur laquelle j’ai bossé à en réalité demandé le boulot de 3 designers, 1 ergo et 1 personne orienté contenu pendant 1 an (bon ok, pas à plein temps). Et pourtant il y a peu d’écrans.

    Après le bon profil n’est pas toujours évident à trouver, la meilleure personne avec qui j’ai bossé avec un profile mixte ergo + design (mais vraiment ergo, pas juste venu de l’ui) et était capable de créer et intégrer du css. Un peu mouton à 5 pattes mais ça permet aussi de faire travailler ce genre de profile à plein temps dès le début.

    2-3 devs + 1 profile du genre permet de vraiment avancer rapidement.

    Ensuite de même, je rejoins Laurent sur la nécessité du profile sysadmin. Même en externalisant beaucoup de chose un tel profil peut faire gagner beaucoup de temps. Par contre, il est probablement pas possible d’avoir un profil du genre à plein temps, ce qui peut être bien est qu’un des 2 devs initiaux ait une vraie compétence système en plus du dev. Ok on commence à avoir là aussi un profile à 5 pattes mais le gain peut être vraiment intéressant. Ça permet aussi de s’affranchir de pas mal de latence avec l’externe gérant l’infra. Et, mais on sort un peu du problème de l’équipe, externalisation au max avec des services ne nécessitant que peu d’admin, genre heroku, AWS, si possible pas de serveurs « propres ». (Idem sur un projet récent, 3 dev + 1 dev op, le développement est beaucoup plus fluide que sur les projets sans)

    Je me pose aussi une question sur l’ordre 4-5. Peut-être parfois est-ce plus intéressant d’avoir d’abord un PO avant un autre dev ? Histoire d’aider à se focaliser sur le plus utile avant de penser à monter en charge.

    • L’idée était de faire arriver les gens 1 à 1. Je ne me voyais pas forcément faire arriver le designer avant d’avoir deux dev pour réaliser quelque chose.

      Il est bien indispensable dès la première minute, mais il va être difficile d’occuper un plein temps de design s’il n’y a qu’un seul dev en face. Du coup je l’ai mis en troisième position. Si vous arrivez à avoir quelqu’un à temps partiel que vous pouvez intégrer ensuite à plein temps au sein de l’équipe (donc pas un freelance) ce serait parfait, mais là on commence à rêver (déjà que trouver les bonnes personnes dans l’ordre souhaité c’est un peu utopique…)

      Du coup quitte à jouer les doubles casquettes, je préfère qu’un des deux dev initiaux sache faire un design super basique et sobre mais pas trop dégueu. Je ne crois pas vraiment à la double casquette dev/sys parce que ça revient à faire du dev. Le sysop dédié ça permet d’avoir quelqu’un qui a pour rôle de faire l’outillage et qui justement permet de ne pas le mélanger avec le dev. J’ai peur qu’on perde une grande partie du bénéfice si c’est quelqu’un en double casquette (c’est la même chose pour le product owner, ce ne peut pas être un dev à mi-temps).

      Effectivement, j’ai mis « web design » mais il y a plusieurs rôles. Tu fais bien de rappeler que ce n’est pas une question d’écrans : Là où je suis en ce moment, pour 15 dev on a 2 UX et 1 UI, et ce n’est pas du luxe. Les UX pensent au scénario de navigation, au processus métier et à la façon dont il faut le penser pour l’utilisateur, là où l’UI est en bout de chaîne pour construire le graphisme lui-même.

      Si pour l’équipe complète il y a une vraie attente sur le design, on peut aisément tenter de séparer le web designer en deux personnes, une UX et une UI. Après ça commence à faire 10 personnes, ce qui est ma limite haute pour une équipe unie. À 10 on peut commencer à imaginer séparer en deux équipes de 5.

      Pour l’ordre entre le troisième dev et le po, je n’ai pas d’avis tranché. S’il y a un manager ou une direction qui apporte suffisamment de vision, ou si les dev sont très impliqués dans cette vision, je pense qu’on peut privilégier le dev. Là aussi c’est plus par peur de faire arriver un profil de product owner à plein temps sans l’occuper suffisamment. Il risque de soit prévoir trop de choses et frustrer tout le monde.

    • Oui c’est sur, les multiples casquettes dev/ops sont souvent complexes à gérer. Disons que (comme pour ce que tu dis côté ergo) ce qui est bien d’avoir au moins quelques sensibilités pour démarrer avant que l’équipe puisse prendre des gens à plein temps. Un minimum de sensibilité permettra au moins d’utiliser des plateformes type heroku pour avancer avec une assez faible complexité et une assez bonne réactivité.

      Quand tu parles de direction technique c’est interne à l’équipe ou externe ? Genre comme un scrum master intégré ou tu imagines quelqu’un qui peut aussi être directeur technique de plusieurs équipes (si on étend la problématique) ?

    • Ça peut être les deux. Les équipes que j’ai vu échouer sont celles où il n’y avait personne avec une vision technique pour décider où l’équipe allait, ou celles où la personne avec ce rôle n’avait clairement pas assez de bouteille et de recul pour ça.
      Ça n’empêche pas que les choix eux-même soient pris par l’équipe dans son ensemble, mais il faut quelqu’un qui insuffle tout ça, et qui ait l’expérience pour guider.

      Que ce soit un lead interne, un dev senior qui soit reconnu pour ça sans avoir d’étiquette précise, ou un directeur tiers, ça dépend trop des équipes et des besoins de la société donc je n’ai pas particulièrement d’avis.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.