mardi 10 juillet 2012

Gérer la hiérarchie dans une équipe de développement

Le débat initié récemment sur ce blog concernant la place du développeur a ouvert, au travers des commentaires, une question complémentaire à la fois plus vaste mais tout aussi importante : comment gérer l'évolution de carrière de chacun et, par extension, la hiérarchie dans une équipe ?

Il est à la mode de contester l'idée que la hiérarchie est nécessaire pour organiser une équipe. Je ne souscris pas à cette mode. Pour expliquer ma position, je veux d'abord revenir sur l'idée même de hiérarchie. Souvent, on considère que gravir les échelons de l'organisation d'une société donne droit à plus de "pouvoir" (notez les guillemets…). Cette idée, je la rejette également, tout en étant conscient que c'est effectivement comme cela que ça se passe, dans le faits, le plus souvent. 

De mon point de vue, appuyé par l'expérience (il ne s'agit pas là de pure spéculation intellectuelle, ni de posture éthique), la hiérarchie est nécessaire dans une équipe, car des décisions doivent être prises pour que les choses avancent. Et les décisions ne peuvent pas toujours être prises de manière collégiale. Aussi, je considère qu'évoluer dans une hiérarchie ne conduit pas à exercer plus de pouvoir, mais à assumer plus de responsabilités.

Certains m'ont objecté que pour être en mesure de faire face à ces responsabilités, il est indispensable d'avoir le contrôle de la situation, et donc le pouvoir, ne serait-ce que de prendre les décisions que l'on juge nécessaires pour mener à bien sa mission. Mon désaccord sur ce point est… subtil. Je pense que ce que l'on qualifie couramment de pouvoir devrait être considéré différemment : pour moi, c'est d'autorité dont on a besoin, laquelle doit être naturelle et légitime pour s'exercer pleinement. Je précise, pour éviter les quiproquos que j'entends autorité dans le sens de référence, et non pas dans son acception coercitive.

Le pouvoir confié arbitrairement à un membre de l'équipe, au prétexte qu'il serait directement lié à sa position dans l'organisation, ne sera pas, ou alors difficilement, accepté par ceux qui sont placés en-dessous (sur l'échelle des responsabilités). En effet, si l'on a pas confiance en la personne supposée assumer la responsabilité de la mission dans laquelle on est engagé, le risque est grand de contester voire même de refuser ses décisions. Avec des conséquences énormes sur le succès de l'équipe. 

Une autorité exercée sans légitimité provoque d'abord la frustration. Et la frustration dégrade considérablement la cohésion de l'équipe. Partant du principe que tous les membres de l'équipe ont une importance égale (chacun est indispensable à la réussite de tous), négliger sa cohésion est sans doute la pire erreur qu'un manager puisse commettre.

Aussi, au fur et à mesure que l'équipe s'agrandit, et que de nouvelles responsabilités sont identifiées, il faut trouver la bonne personne à qui confier cette responsabilité. Sur quelle critère ? Le plus important est sans doute la confiance. Pas seulement celle que le manager à dans le candidat qui lui semble être le mieux placé, mais aussi et surtout la confiance qu'ont ses collègues en ce candidat. C'est la confiance qui assurera la légitimité, et la légitimité qui à son tour assurera l'autorité. Et c'est enfin l'autorité qui garantira qu'une responsabilité sera prise en charge dans les meilleures conditions.

Parmi les dilemmes cornéliens auxquels le manager peut être confronté, il y a celui de l'ancienneté. Un membre de l'équipe doit-il se voir confier des responsabilités au seul titre de son ancienneté ? Théoriquement, non, bien sûr. Seules les compétences devraient guider une telle décision. Mais avec le risque là encore de frustrer ce membre de l'équipe si on lui préfère un plus jeune, ou un collègue arrivé après lui dans l'équipe. C'est ce qui explique que l'on préconise parfois de préférer solliciter quelqu'un de l'extérieur, dont on aura (un peu) moins de mal à expliquer qu'il est plus qualifié pour le job et que c'est pour ça qu'on le fait rejoindre l'équipe. 

Mais ça reste délicat bien sûr. Gare dans ce cas à ne pas démoraliser celui qu'on aura laissé "à sa place", car même si on fait souvent ce choix parce que la personne est à la place qui lui est la plus appropriée, il faut quand même trouver des motivations et un objectif personnel. Je reviendrai plus loin sur ce point.

L'ancienneté sur un poste donné, autrement dit l'expérience, ne garantit pas toujours la capacité à assumer des responsabilités autres. C'est là que je boucle la boucle avec le sujet précédent : l'expérience de développeur ne prépare en rien aux responsabilités de responsable de projet, c'est pourquoi on fait rarement évoluer les développeurs vers ce poste, ce qu'ils vivent pourtant le plus souvent comme une frustration.

L'erreur, dans cette situation, vient de ce que les responsabilités dans les équipes sont souvent mal identifiées. Il existe de nombreuses responsabilités que l'on peut dégager à l'intérieur de l'activité de développement, à commencer par l'architecture, mais aussi la qualité (via les tests), ou encore le design de bases de données. Chacune de ces responsabilités peut justifier la création d'un poste dédié, accompagné d'un package plus motivant que celui de "simple" développeur. Ce qui représente je pense le meilleur moyen de satisfaire le désir naturel de chacun de progresser professionnellement sans compromettre la cohésion de l'équipe.

Résumons-nous : la confiance mutuelle est la base de la cohésion de l'équipe. La confiance confère la légitimité nécessaire à exercer une autorité indispensable au bon fonctionnement d'une équipe. Et la confiance est toujours plus facile à accorder à quelqu'un dont on sait qu'il a une réelle maîtrise du sujet qui lui est confié. Alors je propose aux managers d'équipes IT d'être créatifs, de ne pas limiter leur hiérarchie à développeurs/chef de projet, de ne surtout pas mettre les premiers sous l'autorité du second, et de trouver à chacun la place dans la laquelle il se sentira respecté, car légitime, et qui répondra à ses aspirations en terme d'évolution de carrière. 

Pour cela, il ne faut pas hésiter à déléguer des responsabilités bien identifiées, et à créer des postes pour que chacun puisse exercer au mieux ses talents dans l'équipe. C'est ainsi que l'on pourra demander à quelqu'un de rester dans sa partie sans le frustrer. La position  de développeur ne doit pas être un fourre-tout de l'organigramme dans lequel on maintient tous les profils techniques dont on ne comprend pas toujours bien le job, et dont on pense parfois que la seule évolution de carrière consiste à migrer vers le management. 

Le développement est un métier technique, qui offre de multiples spécialisations, et c'est vers ça qu'il faut tendre : il faut former les collaborateurs sur des aspects plus précis du métier pour qu'ils puissent continuer de s'éclater dans leur job, de rendre d'inestimables services aux clients de leur société (pour le service) ou à leur employeur, et tout ça sans vivre la frustration de rester développeur pendant un temps infini, sans avancement ni de responsabilité ni de considération, et surtout, sans perspective !





jeudi 5 juillet 2012

Chef de projet, aboutissement de la carrière d'un développeur ?

Non, cent fois non !!!!!!!!!!!!!!!

Ceci est un cri du coeur... je viens de lire un billet très récent de Fred Hardy sur son blog mageekbox, lequel billet est une réflexion (amère oserais-je préciser) sur l'état du "marché" du développement. Une fois n'est pas coutume, je suis d'accord avec un certain nombre de constats de Frédéric, mais pas avec leur interprétation. Je reviendrai peut-être sur ces divergences ultérieurement, mais d'abord, je voudrais m'insurger contre cette idée parfaitement farfelue qui apparaît à plusieurs reprises dans les nombreux commentaires de ce billet : l'évolution normale, logique et surtout valorisante du statut de développeur serait celui de chef de projet.

Quelle aberration ! De ce que j'ai lu dans les commentaires, il semblerait que l'on fourre cette idée saugrenue dans la tête des futurs développeurs dès leur apprentissage... ceci expliquerait cela.

Ca fait des années (moi aussi je suis vieux ;)) que je m'interroge sur le fait que des développeurs qui ont encore du lait sur le clavier (2-3 ans d'expérience) proclament et même réclament la responsabilité de chef de projet. Je ne comprenais pas bien d'où leur venait cette idée absurde qu'il leur fallait accumuler de l'expérience sur un métier pour prétendre ensuite à en exercer un autre ! Comme si un serveur de restaurant devait naturellement devenir cuisinier. Non pas qu'il ne le puisse pas, mais simplement son expérience, même si elle est dans un domaine proche, n'a rigoureusement rien à voir.

Car la réalité est celle-ci : un développeur devenu chef de projet, ce n'est pas un développeur qui a réussi, mais au contraire, souvent, un développeur qui a échoué. Soit il s'est trompé en démarrant dans le développement (il n'était pas fait pour ce métier), soit il n'est pas parvenu à exercer convenablement ce métier (et donc il n'était définitivement pas fait pour). Et la confusion vient peut-être du fait que certains chefs de projet ont tendance à penser qu'ils sont également chefs des développeurs, en leur imposant des délais en dépit du bon sens, en faisant preuve d'une autorité artificielle et mal à propos, là où au contraire, ils devraient être à l'écoute et au service des développeurs pour maximiser les chances de succès des projets dont ils ont la responsabilité.

Un développeur produit du code. C'est le fondamental. Le corollaire, c'est qu'il conçoit des applications. Quand il est bon. Et ça, c'est être architecte. Et c'est ça l'aboutissement d'une carrière de développeur. En aucun cas chef de projet. D'autres possibilités s'offrent aux développeurs, comme consultant, formateur ou encore expert technique. Mais toujours pas chef de projet !

Pour résumer la situation, passer du développement à la gestion de projet, c'est une reconversion professionnelle. Rien d'autre. Ces deux métiers n'ont rien en commun, si ce n'est qu'ils évoluent en symbiose, l'un ayant besoin de l'autre. Mais les qualités requises pour exercer l'un et l'autre sont très différentes.

Un développeur doit avoir des qualités d'abstraction, de concentration, de conception, de persévérance  et de compréhension technique là où l'on attend d'un chef de projet qu'il soit parfaitement organisé, capable de communiquer tant avec un client qu'un développeur (c'est leur seul lien !) et de suivre méthodiquement l'évolution d'un projet pour s'assurer qu'elle concorde d'une part avec la planification et d'autre part avec les contraintes dictées soit par le métier, soit par le client, selon les circonstances.

Les développeurs doivent s'ôter de la tête que leur salut passe par l'abandon de la technique (chef de projet, c'est un job du côté management de la force, pas du côté technique) - ou alors, je le répète, c'est qu'ils se sont fourvoyés.

Pour finir, un mot sur les fantasmes salariaux... une société qui paierait à prix d'or un chef de projet et négligerait ses développeurs fait une grosse erreur. Il est beaucoup plus difficile de trouver sur le marché un développeur compétent (fut-il spécialisé sur tel ou tel framework plutôt que globalement expert sur un langage, ping @mageekguy ;)) qu'un chef de projet. D'ailleurs, certaines statistiques démontrent que développeurs et chefs de projet, pour une expérience identique, ont des salaires très similaires, et même à l'avantage du développeur au-delà d'une certaine expérience (d'après une étude du cabinet Hayes et de Cadremploi citée dans un numéro récent du magazine Programmez).

Je jette donc un pavé dans la marre : un développeur mal payé, c'est sans doute qu'il s'est mal vendu (par exemple au mauvais employeur), ou alors qu'il se surestime (désolé de rappeler que l'on est pas développeur senior après 3 ans d'expérience !). Le développement est un métier difficile, qui requiert de nombreuses qualités et beaucoup d'expérience, et quand les deux sont réunis, le profil a de la valeur sur le marché, beaucoup de valeur.

Si vous aimez la technique, poursuivez dans cette voie, les entreprises ont besoin de vous ! En cela je rejoins Frédéric, les bons profils de développeurs se raréfient, et pas parce que certains se sont spécialisés des frameworks, mais parce que trop renoncent ou changent de carrières pour s'orienter, souvent beaucoup trop tôt dans leur carrière, vers le management.