C’est quoi une bonne équipe de développeurs ?

Une bonne équipe de développeurs fera un bien meilleur travail que toutes les rock-star à la con dont t’entends parler partout. C’est ton équipe qui est la plus importante pour construire ton produit. Aujourd’hui, je vais pas te parler d’une équipe remplie de rockstar. Je vais te parler d’une équipe rockstar.

Hard skill

On va parler de soft skill un peu plus tard, parce que dans un premier temps, les hard skill ça reste la base. Pour les deux au fond qui captent que dal, je parle de compétences en programmation. Une bonne équipe de développeurs est solide techniquement. On veut du gros, du gras, du poilu, ça chuchote à l’oreille de la machine et ça t’envoie des merge requests avec un fond de Mozart. Mais alors, ça veut dire que si t’embauches cinq seniors t’as gagné ? Oui et non. C’est pas si simple.

Déjà, il te faut de la diversité technique. Des gens intéressés par différentes technologies qui vont emboîter leurs expertises pour pondre des chefs-d’oeuvre. Une bonne équipe de développeurs ce sont des gens intéressés dans des domaines et des technologies différentes. Des développeurs qui vont pas hésiter à en savoir plus en permanence. Une équipe pareille, tu peux lui jeter n’importe quel défi à la gueule, elle va finir par trouver une solution.

T’as pas besoin d’avoir que des seniors pour faire ça. De toute façon, avec un marché du travail pareil, pour trouver, payer et garder cinq seniors il te faut un marabout à plein temps. Si t’es dans une boite de fou qui peut se permettre de faire ça, tant mieux pour toi. Sinon, il faut comprendre que junior ne veut pas dire incompétent, et vice-versa. En fait c’est positif d’avoir plusieurs niveaux d’expertises. Tu veux ça parce que les relations de mentorat dans une équipe de développeurs font des merveilles.

Une bonne équipe de développeurs est une équipe qui se transmet son expertise et son expérience. Les juniors s’épanouissent parce qu’ils sont épaulés par les seniors. Les seniors s’épanouissent car ils transmettent leur savoir et consacrent le reste de leur temps à régler des problèmes beaucoup plus pointus. Ton équipe s’épanouit car tout le monde apprend. Et quand une équipe s’épanouit, ça se voit sur la gueule des projets qu’elle sort.

Bien accompagné

En début de carrière, je bossais dans une équipe comme ça. T’as deviné, j’étais un des juniors. Je demandais fréquemment conseil aux seniors qui étaient eux-mêmes conseillés par un excellent lead développeur. Ça marchait très bien. On roulait comme des sauvages sur tous les projets que la boite nous envoyait. Et un jour le lead dev a posé sa dem’. Deux mois plus tard, il était parti et y’avait personne pour le remplacer. En quelques mois, y’avais le feu partout et c’était le chaos. Les projets n’avançaient plus car on partait dans tous les sens. Et cette bonne équipe a fini par se disloquer.

Une bonne équipe de développeur est guidée par un lead développeur. Son rôle est de montrer le cap. Avec son expérience solide il tranche sur les points techniques, maintient l’attention des développeurs sur les priorités et pousse tout le monde vers le haut. Il est totalement intégré à l’équipe et n’hésite pas à mettre les mains dans la merde pour aider. J’insiste sur le mot intégré. Lead dans lead dev, c’est important.

Maître de son destin

Pour qu’une équipe de développeurs fonctionne, il faut que tout le monde arrive à se supporter assez pour pas se taper dessus. La meilleure façon d’arriver à ça c’est de rencontrer les gens. Une bonne équipe de développeurs participe activement au recrutement de ses nouveaux membres. Et c’est vrai pour n’importe quelle équipe en ce qui concerne la façon d’être. Mais chez les développeurs c’est d’autant plus important côté philosophie de travail. Et là, je te parle bonnes pratiques, outils et façon de gérer les livrables. C’est crucial que tout le monde soit d’accord d’un nouveau recrutement.

Une bonne équipe de développeurs a son mot à dire sur la roadmap et le planning. C’est important qu’elle puisse être un minimum maître de son destin de ce côté-là. Ça veut pas dire qu’elle décide de tous. Ça veut dire qu’elle a assez d’influence pour faire bouger des délais absurdes ou supprimer des features inutiles. Sans ça, tu peux avoir la meilleure équipe du monde, si tu forces des choses qui font pas de sens à un rythme infernal : elle va échouer.

Évidant, mais souvent ignoré : si tu veux qu’une équipe brille il faut la challenger. Une bonne équipe de développeurs a une grande liberté sur sa façon de régler les problèmes complexes. Il faut montrer à ton équipe qu’elle ne perd pas son temps dans ta boite grâce à des défis sérieux et des technologies qui s’adaptent. Rien de mieux pour la motiver.

Un objectif de qualité

Pour faire du développement de qualité, il faut respecter des standards et s’imposer des bonnes pratiques. Une bonne équipe de développeurs s’impose, avec un plaisir non dissimulé, un haut niveau de standards et de bonnes pratiques. La qualité d’une équipe est mesurée à la qualité des projets qu’elle produit dans les temps impartis. Et la qualité, c’est pas un truc qui tombe du ciel magiquement parce qu’on a fermé les yeux et on y a cru très fort. La qualité c’est un effort d’équipe, une discipline de groupe, une tradition forte qui est sauvagement défendue par tout le monde.

Une bonne équipe de développeurs va maintenir la qualité de son travail dans le temps. Elle va le faire grâce au respect des règles, peu importe le contexte. Et là, je te parle de chose comme le style du code, les code reviews, le pair programing et un vrai process de QA.

La qualité sera également maintenue grâce à des outils automatiques. Tous les tests roulent dans la CI. Les déploiements ne se font pas s’ils ne passent pas. Pareil avec les linters et les analyseurs statiques de code. Une bonne équipe de développeurs va imposer du temps pour ses outils et sa recherche de qualité. La pipeline devient une barrière contre le caca. Tout est mis en place pour que les erreurs humaines soient minimisées.

Elle se connaît

Une bonne équipe de développeurs communique sans filtre et sans politique. Tu n’as pas de non-dits. C’est la plupart du temps le problème des équipes qui fonctionnent mal. Il faut immédiatement crever les abcès. Sinon ils vont peser de plus en plus lourds avec le temps qui passe. Sans ça, tu te retrouves avec une équipe super bizarre. Plus personne se parle en vrai et tout le monde s’insulte en code review sur GitLab.

Pour éviter ce genre de situation, il faut forcer les discussions ouvertes et bienveillantes. Pour arriver à ces discussions il faut laisser du temps à ton équipe de se connaître. C’est impossible de réunir une équipe et au bout de deux semaines d’être les rois du pétrole. Une bonne équipe c’est comme un bon vin. Ça prend du temps, mais ça vaut le coup. Il y a toujours un temps d’adaption.

Une bonne équipe de développeurs est une équipe qui se connaît bien. Elle a développé des automatismes avec le temps. Elle sait qui sera le meilleur pour travailler sur une tâche. Elle sait comment parler à chacun des membres, car tout le monde est différent. En insistant sur une communication franche et bienveillante, tu vas commencer à souder un groupe fort.

On gagne ensemble, on perd ensemble

Tu ne dis pas « j’ai échoué » tu dis nous avons échoué. Tu ne dis pas « j’ai réussi » tu dis nous avons réussi. Tu n’as pas de victoire personnelle, tu amènes des choses positives à ton équipe. Tu ne fais pas une erreur qui va te valoir la honte et les reproches, ton équipe va apprendre à éviter cette erreur dans le futur. Tu vas me dire que c’est des conneries de bisounours et je pense que tu as tort.

Ça crée un effet de groupe, une cohésion qui est cruciale dans les moments difficiles. Une bonne équipe de développeurs est un groupe soudé et indivisible, peu importe la situation. Dans un domaine où l’ego est tant présent, où les connaissances tant diverses et les erreurs tant fréquentes, une équipe sur qui tu peux compter est un formidable atout.

Quand on gagne, tout le monde gagne et on fait la fête. Quand tu ship, quand tu atteins un objectif, quand l’équipe fait quelque chose de significatif : il faut marquer le coup. On sort, on va se boire des grosses biérasses et on apprend à se connaitre un peu plus. Sans forcer les gens évidement, mais c’est vraiment quelque chose qui amène beaucoup de fêter les victoires dans un contexte hors bureau.

Quand on perd, tout le monde perd et on débrief. On critique les idées et les solutions, pas les gens. Pourquoi nous avons fail en tant que groupe et comment éviter de refaire l’erreur dans le futur ? Quand c’est la faute d’une seule personne, on le dit, mais on s’en fout. La question ne sera pas pourquoi une personne a fail, mais comment on peut faire pour que personne ne reproduise la même erreur dans le futur. Quand cette personne ça sera toi, ce qui va arriver sûr et certain, tu seras content quand tout le monde ne te crachera pas à la gueule en même temps.

Une bonne équipe de développeurs n’est pas en compétition en interne et met de côté les égos personnels. Elle les met de côté pour le produit qu’elle développe. Elle les met de côté pour le succès du groupe. Avec un groupe pareil tu vas avoir des gens qui se font confiance et surtout qui ont confiance en eux-mêmes. La confiance ça aide beaucoup pour mieux bosser. Tu vas avoir des gens investis dans leur travail. Naturellement, ils vont vouloir toujours mieux faire pour amener plus de valeurs au groupe. Et par la même occasion à l’entreprise en général.

Épilogue

Alors attention, calme-toi, c’est pas parce que ton équipe ne coche pas toutes les cases que vous êtes nuls. Là, je te parle de la version super optimale. T’arrives à faire tourner une config de team pareil, tu vas littéralement rouler sur tous les projets possibles. Après c’est mon avis, t’en penses quoi toi ?