Discussion :

[Stéphane le calme]

Comment augmenter la taille de son équipe de développeurs tout en préservant sa productivité ?
Un développeur propose des axes à suivre

Lorsque les entreprises sont tenues par les délais, il arrive qu’elles décident d’embaucher du personnel pour pouvoir livrer un projet à temps. Amir Yasin, cofondateur de June, propose quelques conseils qui peuvent servir à orienter la croissance de son équipe en sécurité.

Prenez votre temps pour vous développer de manière durable : neuf femmes et un mois ne font pas un bébé

Lorsque vous embauchez quelqu'un, il lui faudra au moins deux ou trois semaines pour devenir productif. La plupart des gens en conviennent. Un autre truisme bien connu dans le secteur de la technologie, mais que peu de personnes acceptent c’est que pendant ces deux ou trois semaines, ces nouveaux membres de l'équipe drainent l’équipe vers le bas. Ce n’est pas parce qu’ils sont mauvais, c’est parce qu’ils drainent du temps et de l'attention de la part des autres membres de l'équipe afin d’obtenir des réponses aux questions qu’ils se posent ou juste pour obtenir des informations. Par la suite, ces échanges vont les rendre productifs, mais, durant ces deux ou trois semaines, ces échanges nuisent à la productivité. Aussi, embaucher à un rythme plus rapide qu'un nouveau membre par équipe chaque mois met une pression énorme sur le reste de l'équipe. Non seulement cela a des conséquences sur le temps de travail de votre équipe, mais cela peut également accroître la quantité de temps qu'il faut aux nouveaux membres pour devenir productifs. Cela peut même susciter des conflits au sein de votre équipe étant donné que la pression suite au fait que « maintenant vous avez la main-d’œuvre » augmente tandis que la productivité réelle diminue. Les gens que vous allez perdre seront probablement les personnes que vous pouvez difficilement vous permettre de perdre.

Assurez-vous de la cohésion de l'équipe : « l'engagement individuel envers un projet collectif - voilà ce qui fait qu'une équipe, une compagnie, une société, une civilisation fonctionnent». - Vince Lombardi

En plus de réduire l'efficacité de l'équipe sur une période de temps, ajouter des personnes à une équipe en une fréquence plus rapide qu’une fois par mois freine l'assimilation. Lorsque l'assimilation de l'équipe est freinée, l’équipe court le risque de voir sa cohésion en pâtir. Quand un nouveau membre arrive au sein d’une équipe, il est préférable de l’aider techniquement en répondant à des questions sur le code de base, etc., mais, en tant qu’ingénieurs, il nous arrive de négliger l'aspect social dans le processus d’en faire un membre de l'équipe à part entière. Si l’équipe au complet va déjeuner tous les vendredis, il faut s’assurer d’inviter les nouveaux avant. S’il y a d’autres habitudes que l’équipe a développées, il faut s’assurer que les nouveaux en fassent partie. Lorsque vous comprenez vos collègues, il est plus facile de savoir comment mener des discussions ouvertes sur des sujets comme l'architecture et le codage. Il faut également pouvoir être suffisamment ouvert pour vous séparer des personnes qui nuisent à la cohésion du groupe aussi vite que vous le feriez pour des raisons techniques. C’est très important. Cela ne signifie pas renvoyer les gens qui ne veulent pas aller déjeuner avec vous, mais si l'équipe a besoin de marcher sur des œufs quand il faut échanger avec un membre, alors ce membre ne doit probablement pas rester au sein de cette équipe.

Amir Yasin

Passez du temps à vous assurer du succès du nouveau membre : « se réunir est un début, rester ensemble est un progrès, travailler ensemble est la réussite » Henry Ford

Si la cohésion d'équipe est essentielle, il est important que tout le monde y participe. Pendant le mois où vous supervisez un nouveau membre de l'équipe, cela fait partie du travail de tout le monde que de contribuer à la réussite du nouveau membre. Demandez de manière proactive s’il a des questions au sujet de la base de code, sur la façon dont les choses sont faites au sein de l'entreprise (voire le diriger vers des personnes plus indiquées pour répondre aux questions qu’il se pose), l’aider à comprendre la dynamique de l'équipe (rien à voir avec les potins sur les autres membres de l'équipe), prendre en considération ses opinions et demander comment est-ce qu’il faisait telle ou telle chose dans son précédent emploi. En clair, lui faire ressentir son appartenance à la tribu.

Maintenir un bon ratio senior – junior

Les ingénieurs juniors apportent l’énergie et la curiosité à l’équipe et sont les graines qui vont devenir de futurs ingénieurs seniors. De la même manière que les graines ne germent pas dans le vide (elles ont besoin de lumière, d’un sol fertile, mais aussi d’eau), les ingénieurs juniors ne deviennent pas des seniors sans matériaux ; ils ont besoin d’être guidés par les seniors. Pour Yasin, le ratio idéal serait trois seniors – un junior. Pourquoi ? Parce que :

• avec trois ingénieurs seniors, il est probable qu’au moins l’un d’eux sera disponible pour répondre aux questions ou guider lorsque le besoin se fera ressentir ;
• si un senior a de mauvaises habitudes, il y aura toujours deux autres seniors pour empêcher au junior de les copier ;
• avec au moins trois mentors, la quantité d’attention dont a besoin le junior n’empiète pas beaucoup sur la productivité d’un membre senior de l’équipe.

Restez ouverts aux conseils, propositions, critiques constructives

Ce n’est pas parce que vous voulez qu’un nouveau membre fasse partie de la « tribu » que vous ne pourrez pas apprendre de lui. Peut-être pourrait-il vous donner des conseils sur la façon de structurer un sous-projet plus efficacement ; il pourrait avoir rencontré des problèmes similaires avec son ancienne équipe et sera en mesure de partager son expérience avec vous. Peut-être a-t-il déjà expérimenté l’idée à laquelle vous pensez, ce qui va constituer un plus dans la mesure où il pourra vous aider à éviter certains désagréments. Peut-être pourra-t-il vous faire une autre suggestion à laquelle vous n’aviez pas pensé. Il faut vous rappeler que vous n'avez pas embauché une personne parce qu'elle était votre clone. Il faut alors profiter de cette nouvelle infusion d’énergie au sein de l’équipe ; de la même manière que l'ajout de carbone au fer rend plus fort, un melting-pot de talents rendra votre équipe plus forte.

Selon Yasin, la croissance d’une équipe de développeurs rime avec la croissance de la quantité de travail qu’elle peut produire tout en maintenant une cohésion : « faire cela correctement est beaucoup plus difficile qu'il n'y paraît en raison des pressions externes, comme "nous allons manquer de conclure la vente de l'année" ».

Source : billet Yasin

Et vous ?

Qu'en pensez-vous ?

[Matthieu Vergne]

Voilà qui me semble plutôt cohérent.

[Jarodd]

C'est plein de bon sens, difficile de ne pas être d'accord avec ça.
Par contre c'est bien plus compliqué à mettre en oeuvre au quotidien

[Escapetiger]

... Lire et s'inspirer du bouquin de Robert Sutton, professeur de management de Stanford :
En finir avec les «sales cons» au travail
Dans son livre volontairement provocateur, «Objectif zéro sale con», un professeur de management de Stanford, Robert Sutton, livre ses recettes pour venir à bout des pourrisseurs d'ambiance au bureau.
(...)
http://www.lefigaro.fr/vie-bureau/20...au-travail.php

[Mat.M]

Selon Yasin, la croissance d’une équipe de développeurs rime avec la croissance de la quantité de travail qu’elle peut produire tout en maintenant une cohésion : « faire cela correctement est beaucoup plus difficile qu'il n'y paraît en raison des pressions externes, comme "nous allons manquer de conclure la vente de l'année" ».
Qu'en pensez-vous ?

de toute façon sur un projet informatique ce sont les développeurs ( et les analystes aussi ) qui fournissent la majorité du travail,on ne fait pas de projet informatique sans développeurs.
C'est la loi du 80-20,bref les équipes techniques c'est plutôt 80% du travail

[Invité]

Le ratio exprimé exprimé est effectivement idéal. En France, pour cause de coût du travail excessif on voit trop souvent le ratio inverse. 3 juniors pour un sénior.
De plus il y a sénior et sénior. Un sénior, c'est plus de de 7 ans d'expérience, pas 3 ans comme l'affirment les ESN. Qui a travaillé sur des projets différents, qui a une vision plus large que le seul code (métier, système, devops...).
Il est également important d'avoir une documentation portant au moins sur l'architecture du logiciel. La documentation par le code c'est une bonne blague, à fortiori si on est sur des langages dynamiques (javascript, ruby ...).
J'ajoute qu'il es timportant d'avoir des rôles ou des spécialités techniques. L'approche tout le monde fait tout est trop souvent utilisée. Cela rassure les "décideurs" mais cela aboutit à une mauvaise qualité générale.

[Grogro]

... Lire et s'inspirer du bouquin de Robert Sutton, professeur de management de Stanford :
En finir avec les «sales cons» au travail
Dans son livre volontairement provocateur, «Objectif zéro sale con», un professeur de management de Stanford, Robert Sutton, livre ses recettes pour venir à bout des pourrisseurs d'ambiance au bureau.
(...)
http://www.lefigaro.fr/vie-bureau/20...au-travail.php

Par chance, je n'en ai pas dans la hiérarchie de ma boîte, au moins localement. Côté client en revanche, étrangement, quelques têtes me viennent à l'esprit.