– Dis, on met quoi dans une équipe technique ?
Ça dépend du temps, du produit, des besoins. Voici ma recette par défaut, à réagencer en fonction de la réalité. Il reste qu’à chaque fois je finis par me dire que j’aurais aimé la voir suivre ce schéma :
1 et 2 : Donc au début on commence, il faut un ou deux développeurs. Idéalement à ce niveau ils savent toucher un peu de front et un peu de back, et apprécient de pouvoir intervenir partout. Pas d’administration système à cette taille, on externalise un maximum.
Petit intermédiaire. Il faut une direction technique avant de passer au troisième membre de l’équipe. Ce peut être un directeur technique à part entière ou un des deux développeurs qui a suffisamment de bouteille mais il faut quelqu’un qui a une vision technique, et pas un néophyte.
3 : Le troisième c’est le grand oublié : le web designer. Il fait de l’UX, de l’UI, et va définir une vraie expérience client. Bien évidemment tout dépend du métier et du produit mais recruter trop tard est habituellement une erreur. La mode est de considérer que ce profil doit même faire partie des fondateurs.
4 : On complète avec un troisième développeur. On peut commencer à envisager un spécialiste qui apporte une expertise qui manque aux deux autres mais il faudra quand même qu’il accepte de toucher un peu à tout.
5 : L’équipe commence à avancer, maintenant il lui faut quelqu’un pour donner une direction et prendre du recul. On peut l’appeler product owner, responsable produit, chef de projet fonctionnel, analyste métier… Il aura pour charge de réfléchir aux usages, imaginer le produit, assurer la vision. Ce doit être quelqu’un de dédié, sans position hiérarchique sur le reste de l’équipe.
6 (et 7 ?) : L’équipe avance, dans le bon sens, il reste à lui donner un peu de puissance avec un ou deux autres développeurs. À partir de quatre développeurs c’est la taille où l’effort est démultiplié et où on peut commencer à assurer les imprévus, ou les congés de chacun. Au delà de 5 développeurs on commence à faire des sous-équipes et ça n’a plus grand intérêt.
Les équipes les plus dynamiques avec lesquelles j’ai travaillé ont des développeurs qui travaillent tous sur l’intégralité du produit mais on peut aussi avoir quelques experts qui interviennent essentiellement 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’assurer la production mais sa réelle valeur est de fluidifier tout l’outillage interne, comme la plateforme d’intégration continue ou les scripts de déploiement.
Il n’a d’intérêt qu’avec une équipe qui tourne, mais s’en passer c’est comme continuer en gardant un boulet aux pieds. Avant ce sont les développeurs qui sont obligés de perdre du temps et du focus avec tout ça.
9 : Je vais à neuf avant de m’arrêter mais j’ajoute quand même un dernier profil avec un technicien. C’est lui qui va assurer les tâches d’exploitation courantes, s’occuper du support technique, du support utilisateur, et soulager le product owner.
On peut s’en passer mais c’est au prix d’un manque de focus non négligeable, donc d’un peu de gâchis.
Je n’ai pas parlé de manager 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 manager mérite plus d’un billet mais je retiens une règle : ni la direction commerciale de la société, ni le product owner de l’équipe. Ce peut être le CTO qui gère la direction technique décrite plus haut.
Je n’ai pas mis de QA non plus. Je continue à penser que l’équipe doit être responsable de ce qu’elle livre. Une QA séparée à tendance à déresponsabiliser mais aussi à ajouter de la distance avec la réalité et du délai lors des livraisons. Ça aura du sens quand il y aura plusieurs équipes, pas tout de suite. Le dev op pourra par contre outiller et automatiser un maximum de tests et de processus entre temps.
Et vous, vous conseillez quoi comme composition ? Qu’ai-je oublié ?
Laisser un commentaire