12 types de développeurs ultra-efficaces. (1/2)

Voici une question à 1 million d’euros : quelle est LA chose la plus importante dans un projet informatique collaboratif ?

Le travail d’équipe, on est d’accord, mais “avoir une bonne équipe”, ça ne veut pas dire grand chose.

Prenons plutôt la question à l’envers, qu’est-ce qui fait une mauvaise équipe ? Une mauvaise entente, des dramas, un mauvais esprit d’équipe où personne ne pense aux autres, une incompréhension du travail de l’autre, une non-complémentarité…

S’il y a bien une chose que l’on remarque, c’est que la plupart des équipes ne fonctionnent pas parce qu’il y a une mauvaise symbiose entre les membres. Ça arrive que des équipes soient ruinées par des fauteurs de troubles, mais c’est quand même une minorité des cas.

La clef de la réussite qui va débloquer quasiment toute les situations, c’est de comprendre les autres : leur personnalité, leur travail, leur manière de faire et surtout la valeur qu’ils apportent à l’équipe et au projet.

Ça à l’air simple dit comme ça, mais malheureusement, beaucoup d’équipes ne font pas cet effort, surtout quand s’agit d’une équipe entièrement composée de développeurs.

En général, on a tendance à classer et à catégoriser les gens sur des choses triviales, comme leurs compétences techniques. Par exemple, en mettant d’un coté les développeurs front-end, et de l’autre les développeurs back-end, sans distinction supplémentaire.

C’est pratique de savoir sur quel domaine technique la personne se sent le plus à l’aise, mais c’est clairement insuffisant. C’est comme catégoriser des profs sur la couleur de chemise.

Nous autres développeurs, nous avons tous des profils très variés. En matière de technique, certes, mais il ne faut surtout pas négliger la personnalité, la manière de travailler, de s’organiser, les forces et les faiblesses. Tout ça, ce sont des choses qui peuvent apporter un plus à l’équipe à leurs manières.

Et quand cette répartition est bâclée ou pas faite du tout, c’est un énorme manque à gagner pour le projet. On se retrouve avec des développeurs qui travaillent à 40% de leur plein potentiel, et qui n’ont jamais la possibilité d’exprimer l’étendue de leurs capacités.

Pire encore, il y a certains cas où des compétences sont assimilée à tort à une perte de temps. Alors qu’en réalité, elles sont dotées d’une très grande valeur ajoutée, mais certains managers vont les ignorer parce qu’ils ne comprennent pas les bénéfices à long terme que ces compétences apportent.

C’est notamment le cas par exemple pour la veille technologique, le design d’applications, le développement de prototypes, etc.

C’est aussi ridicule que de donner une arme à un médecin pour qu’il aille se battre au front, au lieu d’agir là où il est réellement compétant. Bref, un énorme gâchis.

Vous l’aurez compris, la compréhension du profil de chacun est au centre du travail d’équipe. Connaître les autres, c’est ça la chose plus importante dans un projet informatique collaboratif.

Et quand je dis connaître, je ne parle pas de se partager un kebab de temps en temps, je parle bien sûr d’un point de vue professionnel, mais les deux ne sont pas incompatibles ! (sauf s’il prend sauce ketchup).

Par “professionnel”, j’entends le profil d’une personne : ses forces, ses faiblesses, les tâches sur lesquelles il est le plus productif, le moins productif, sa personnalité, sa manière d’être, de travailler et de s’organiser, ce qu’il aime et ce qu’il déteste, ses valeurs morales, la meilleure manière d’interagir avec lui…

Le but est de pouvoir comprendre exactement comment cette personne peut devenir un atout presque indispensable au projet et aux autres membres de l’équipe.

Et ça commence avec vous-même !

Et oui, prendre du recul, apprendre à se connaître et se remettre en question de temps en temps, ça n’a que du bon, même dans l’informatique.

Et si vous arrivez à faire ça avec tous les membres de votre équipe, déjà, vous allez comprendre que même si votre équipe est composée de personnes qui font tous le même métier (développeur), leurs profils varient tellement qu’il serait dommage qu’ils travaillent tous sur les mêmes tâches.

Mais en plus de ça, vous allez vous rendre compte qu’en réorganisant un peu la manière dont votre équipe travaille, la productivité au sein du projet va littéralement doubler, voir tripler, en plus de rendre les membres heureux de travailler sur des domaines où ils sont au maximum de leurs compétences.

Et vous n’avez pas besoin d’être un manager pour faire ça, une simple discutions durant la pause-café peut suffire à ouvrir les yeux de certains et à lancer un mouvement.

Bon, ça a l’air bien compliquer tout ça et ça relève plus de la psychologie humaine que de l’informatique. Mais au final, vous n’avez pas nécessairement besoin d’avoir un niveau d’analyse exceptionnel pour avoir une équipe qui fonctionne très efficacement.

La stratégie la plus simple est de catégoriser les personnes en fonction de leurs compétences à haute valeur ajoutée. Attention, je ne parle pas de développeurs front-end / back-end, mais bien de catégories qui reprennent les points que j’ai énumérés au-dessus (forces, faiblesses, méthodes de travail…).

Et ce sont justement de ces catégories dont je vais parler aujourd’hui, ce que j’appelle communément les types de développeurs. Par “type”, j’entends bien un continuum, chaque développeur étant plus ou moins chaque type.

Avant de continuer, je tiens tout d’abord à préciser que ce concept ne vient pas de moi, mais du bloggeur / podcasteur Neil on Software, de neilonsoftware.com.

C’est lui qui a inventé tous les types ainsi que leurs caractéristiques, et il a même fait un quiz pour déterminer quels types vous êtes, que je vous invite plus que fortement à faire avant de lire la suite de cet article.

En soi, il n’y a rien de scientifique ou de magique dans ce dont je vais vous parler, mais la manière dont il catégorise les développeurs est tout simplement excellente et bien plus intelligente que tout ce que j’ai pu voir ailleurs, et je pense qu’elle peut littéralement faire exploser le taux d’efficacité au sein de votre équipe. C’est pourquoi je reprends son modèle pour mon article.

Donc dans cet article, je vais détailler chaque type en reprenant les définitions de Neil, ainsi qu’en ajoutant ma patte personnelle et en expliquant en détail comment VOUS pouvez contribuer efficacement à votre équipe en fonction de votre profil.

Car c’est en exploitant VOS compétences, et non pas des compétences que l’on vous a attribué, que vous deviendrez un développeur ultra-efficace.

Note avant de commencer : l’article étant très dense en informations, j’ai choisi de le scinder en deux parties de manière à pouvoir explorer plus en profondeur chaque type. Vous êtes prêt ? C’est parti.

L’assassin

Un développeur ultra-efficace capable de finir son travail rapidement et silencieusement, avant mêmes que les autres savent qu’il a commencé.
Neil on Software

L’assassin, c’est le développeur ultra-productif par excellence. C’est le gars qui ne connaît même pas la notion de deadline parce qu’il ne l’a jamais atteint. Il travaille rapidement, efficacement, quitte même à faire des heures supplémentaires si nécessaire.

Il est vraiment impressionnant par sa rapidité de livraison, mais en réalité, c’est surtout quelqu’un qui connaît ses priorités et qui ne perd jamais de temps sur des détails sans importance. Le délai est sa priorité, et c’est tout sauf un perfectionniste. Plus il est rapide, mieux c’est.

L’assassin est un excellent technicien. C’est loin d’être le plus appliqué ou le plus rigoureux, mais il frappe fort sur une des 3 composantes d’un projet : le temps, qui est malheureusement la composante la moins respectée dans les projets informatiques (par rapport au coût et à la qualité). Et avoir quelqu’un de très productif pour rééquilibrer la balance est un gros point fort.

Valeur ajoutée

Si vous êtes un assassin, vous avez tout intérêt à passer un maximum de votre temps sur du développement et de l’intégration de fonctionnalités, en particulier si vous êtes sur un projet avec des délais assez shorts.

Et si un membre de votre équipe est un assassin, faites en sorte qu’il reste toujours au top de sa productivité, quitte à vous interrompre et l’aider s’il a un problème.

Assurez-vous aussi qu’il utilise son incroyable vitesse pour les bonnes choses, car si c’est pour résoudre des bugs, veiller ou écrire de la documentation, c’est du gâchis, et il y a plein d’autres profils qui conviendraient mieux à ce genre de tâche.

Mots clés

Productivité, vitesse, prise d’initiative, simple et efficace.

Attention !

La vitesse ne justifie pas le manque de qualité du produit final. L’intérêt de l’assassin, c’est avant tout de pouvoir livrer rapidement des fonctionnalités qui sont, certes améliorables, mais néanmoins de très bonne qualité.

Le télépathe

Un développeur ultra-efficace capable d’extraire des exigences non-exprimées et non-documentées des parties prenantes.
Neil on Software

Le télépathe, c’est le type à avoir lors d’une réunion avec des parties prenantes. C’est un excellent communicateur qui arrive à extraire toutes les informations possibles et inimaginables, et qui arrive à expliquer le besoin mieux que le client lui-même.

Il est curieux, pose beaucoup de questions, va en profondeur sur tous les sujets et arrive à déceler les zones sombres ou les incohérences dans les exigences d’un client.

Son gros point fort, c’est sa capacité exceptionnelle à pouvoir mener de longues discutions avec des parties prenantes pour pouvoir dresser un cahier des charges clair, complet et concis, ce qui permet à tous les autres de travailler dans les meilleures conditions possibles. En d’autres mots, il donne une direction précise au projet, et empêche son équipe de rester dans le flou.

Au final, le télépathe est surtout un intermédiaire entre les parties prenantes et les développeurs, ce qui n’en fait pas toujours un super technicien, mais un excellent chef de projet.

Valeur ajoutée

Si vous êtes un télépathe, vous devez assister aux réunions avec les parties prenantes coûte que coûte.

Attention, je ne dis pas que vous n’êtes qu’un bon qu’à faire des réunions, vous pouvez très bien être télépathe ET bon technicien, ou même autre chose.

Mais vous devez aussi savoir que votre compétence est rare, et que très peu de personnes ont assez de nerfs pour tenir de très longues réunions client.

Ça donne souvent lieu à un cahier des charges imparfait, donc re-réunion avec les clients, ce qui cause de la friction et du retard dans le développement.

Donc chef de projet ou non, vous avez la capacité de faire tourner la balance.

Mots clés

Communication, patience, analyse critique, logique.

Le tank

Un développeur ultra-efficace qui participe aux réunions et prend en charge toutes les tâches sans code, afin que les autres développeurs puissent coder.
Neil on Software

Le tank, c’est la personne qui se sacrifie pour le bien de tous en se tapant tous les trucs chiants et ennuyeux afin que ses collègues puissent travailler efficacement et sans interruptions. C’est littéralement le Jésus-Christ de l’équipe.

Il est régulièrement volontaire pour participer aux réunions, faire de la paperasse administrative, des rapports, écrire de la documentation, etc. pour protéger ses collègues du truc chiant qui s’appelle un projet. Bref, c’est un gars qui pense à l’équipe en permanence, c’est beau.

Bien sûr, il ne fait pas que ça, et il est souvent technicien avant tout.

D’ailleurs, être tank ne veut pas bouffer toute la misère non plus, et avant d’encaisser, ils doit d’abord déterminer si une tâche est importante ou non, et qu’elle ne soit pas juste un effets secondaires de la réunionite aiguë. Moins il y a de tâches à faire, mieux c’est.

Le tank est en général une des personnes les plus appréciées par les autres membres de l’équipe, et tout le monde le respecte pour son dévouement. Dans un monde de fous où les réunions apparaissent sans crier gare, le tank est là.

Valeur ajoutée

Si vous êtes un tank, ça signifie que vous accordez beaucoup d’importance au projet et à l’équipe. Dans ce cas… Je n’ai pas grand-chose à dire. Continuez comme ça 👌

Mots clés

Esprit d’équipe, organisé.

Attention !

Le tank n’est pas un larbin. Son travail n’est pas de satisfaire les caprices de ses collègues, mais bien d’apporter de la valeur à l’équipe. Souvenez-vous aussi que c’est un être humain qui a aussi ses limites, et être tank peut parfois s’avérer assez éprouvant. En aucun cas il faut abuser de lui.

Forcer quelqu’un à devenir tank (ou se forcer soi-même) est une très mauvaise idée si ce n’est pas dans la personnalité de la personne. C’est risquer sa perte de motivation, voir le burn-out dans le pire des cas. Le tank est avant tout un développeur, et là où certains vont prendre le rôle très facilement, pour d’autres, ce n’est tout simplement pas possible, et leurs compétences se trouvent ailleurs, ce qui n’est pas un mal !

Le chasseur

Un développeur ultra-efficace qui cherche pro-activement et corrige des bugs dés qu’il les trouve.
Neil on Software

Le chasseur est un debuggeur humain à toute épreuve. Il maîtrise le processus de A à Z, que ce soit la recherche des bugs, la priorisation, la correction, et bien sûr, ~le truc que tout le monde fait~, les tests unitaires.

Le chasseur est obsédé par les défauts. Pour lui, soit l’application est stable, soit elle ne sort pas, un point c’est tout. Il est rigoureux et attentionné aux détails, mais il n’est pas maniaque pour autant : il sait prioriser et reconnaître quels bugs sont graves et doivent être corrigés instantanément, et quels bugs peuvent attendre leur tour.

Il sait aussi détecter les non-bugs, comme les défauts de design (architecture), les trous de sécurité etc… Bref, rien ne lui échappe.

Le chasseur est particulièrement important puisqu’il est garant de la stabilité d’une application, et vous pouvez vous assurer qu’avec lui sur le sujet, le nombre de bugs après déploiement va grandement diminuer. D’autant plus qu’il s’agit d’une compétence rare, et donc encore plus précieuse.

Valeur ajoutée

Si vous êtes un chasseur, vous n’avez pas nécessairement besoin d’être testeur ou contrôle qualité pour apporter de la valeur au projet, rien ne vous empêche d’avoir une routine de débuggage quotidienne de quelques heures quitte à manger sur votre temps de développement.

Vous pouvez utiliser ce temps pour rechercher et corriger des bugs, écrire des tests unitaires, faire des tests d’intégration, résoudre des tickets, etc.

Il n’y a pas de temps perdu quand on teste, et malheureusement, peu de gens le font, donc si vous avez un réel talent pour ça, il n’y a aucune excuse pour vous en priver !

Mots clés

Perfectionniste, attention aux détails, analytique, méthodique.

Attention !

Ne pas être TROP perfectionniste non plus, si après 30 tests unitaires vous ne trouvez toujours aucun bug, il n’y a pas de raison que vous en trouviez beaucoup après 1445 tests. Il faut savoir être raisonnable pour rester performant.

Note

Les chasseurs sont directement rattachés aux métiers de la sécurité informatique, donc si cette branche vous intéresse, vous avez tout intérêt à devenir un meilleur chasseur que Bear Grylls lui-même.

Le magicien

Un développeur ultra-efficace qui peut résoudre n’importe quel problème de code avec facilité, peu importe la difficulté.
Neil on Software

Le magicien ne porte pas son nom pour rien, il est tellement doué qu’on a l’impression qu’il vient d’un autre monde. C’est une personne qui est capable de résoudre des problèmes logiques, algorithmique, d’optimisation, de sécurité… Un peu tout en fait, et ce devant les yeux ébahis de ses collègues qui se croient dans un show de David Copperfield.

Bien sûr, il n’y a pas de secret, le magicien est généralement une personne avec un excellent esprit de logique et de résolution de problème, en plus d’être une véritable bibliothèque de connaissances et d’expériences.

Il est extrêmement efficace, car bien qu’il ne soit pas le développeur le plus rigoureux ou productif, il n’est quasiment jamais bloqué et trouve toujours des solutions rapidement à ses problèmes, même quand ils ont l’air complètement impossibles à résoudre, ce qui inverse complètement la balance.

Mais il est encore plus efficace lorsqu’il aide les autres, en particulier les développeurs qui sont beaucoup plus productifs que lui, mais bien moins perspicaces, et donc plus à même de se retrouver complètement bloqués, comme l’assassin par exemple.

Valeur ajoutée

Si vous êtes magicien, il ne faut pas hésiter à aller aider vos collègues lorsqu’ils sont bloqués sur un algorithme afin qu’ils puissent travailler le plus efficacement possible. Quitte même à devenir la personne de référence de votre équipe, à qui tout le monde se confie en cas de problème.

Mots clés

Logique, perspicacité, connaissance, expérience.

Attention !

Ne pas gonfler ses chevilles et sous-estimer les autres pour autant. Encore une fois, chaque profil a son domaine d’expertise, et l’esprit de logique n’est qu’un ingrédient parmi tant d’autres (rigueur, productivité…).

Le ranger

Un développeur ultra-efficace qui recherche des nouvelles technologies qui sont meilleures que celles actuellement utilisées.
Neil on Software

Le ranger, c’est le roi des veilleurs. Non pas que ce soit un fainéant, mais que c’est une personne qui va régulièrement partir à la recherche de nouvelles technologies afin d’améliorer les conditions de travail des développeurs et la qualité du produit final.

C’est quelqu’un avec un réel esprit critique, qui fait des analyse pointues sur des technologies en filtrant la hype des objets brillants, et en se focalisant sur les résultats à long termes. C’est le chercheur de pétrole de l’informatique, qui voit gros et qui ne se contente pas d’une petite flaque pour implanter son exploitation.

Leur but est de faire LA découverte qui va apporter un maximum de valeur au projet, et ils font régulièrement des prototypes pour tester leurs idées. Et si leur trouvaille ne rentre pas totalement dans les clous du projet, c’est poubelle et au suivant.

Bien sûr, ce sont avant tout des gens curieux, qui suivent les news de très prés, lisent beaucoup blogs, et ont un flux RSS long comme mon bras afin tirer le meilleur du marché. Pour être un ranger, il faut aimer apprendre et évoluer en permanence.

Valeur ajoutée

Si vous êtes ranger, ça peut valoir le coup de dédier un peu de temps chaque jour à de la veille technologique, en particulier si vous travaillez avec des technologies un peu dépassées.

N’hésitez surtout pas à faire des prototypes afin de tester vos idées, ce n’est jamais du temps perdu. Et dés que vous avez fait une découverte vraiment intéressante, présentez là au reste de votre équipe.

C’est une discipline souvent discréditée, mais qui a le potentiel de faire gagner énormément à un projet : temps, argent, maintenance, pérennité, confort de travail, qualité du produit final, et j’en passe. Sur les projets, et tous ceux qui suivront.

Et s’il s’agit d’une autre personne qui propose une technologie, essayez toujours d’émettre un avis critique, quitte à la remettre en question si elle ne rentre pas exactement dans les clous du projet.

Mots clés

Pragmatique, analyse critique, curiosité, optimiste septique.

Attention !

Le ranger ne doit jamais prendre des décisions à l’instinct et dois TOUJOURS faire preuve d’esprit critique. Ses décisions vont impacter tous les futurs développements du projet, et quand elles sont imparfaites, elles peuvent causer de gros dégâts : dette technique, friction… Ce n’est absolument pas un rôle funny fun fun à prendre à la légère.

Le rôle du ranger est aussi souvent discrédité, considéré comme étant une perte de temps. C’est bien sûr faux, mais beaucoup ne le voient pas de cet œil, et le ranger sera parfois amené à devoir argumenter sur l’importance de son rôle au sein du projet, ce qui peut-être compliqué avec certains managers.

C’est aussi une personne qui va régulièrement faire face à de la résistance au changement de la part de son équipe. Passer d’une technologie à une autre n’est pas toujours facile, et beaucoup se contenterons uniquement de voir ce changement comme une plaie sans penser aux immenses bénéfices derrière.

Et c’est encore une fois au ranger d’argumenter sur l’intérêt de ce changement afin de faire changer l’avis général (à condition que sa décision soit la bonne, bien entendu).

L’article commence à être long, donc je m’arrête ici pour cette première partie. Dans la seconde, je parlerais bien sûr des 6 types restants, et je vous expliquerais en détails comment réorganiser légèrement et simplement votre équipe afin que chacun puisse utiliser ses compétences au maximum, et ainsi rendre votre équipe 3 fois plus productive.

Je vous mets aussi en bonus un bilan critique de mes propres compétences suite au quiz de Neil on Software, ou j’y détaille mes points forts, mes points faibles et les compétences sur lesquelles je suis en train de travailler, avec une paire d’anecdotes personnelles en prime.

Au risque d’en décevoir certains, je suis loin d’être un dieu vivant, et je suis moi aussi sur la voie longue et torturée du développeur ultra-efficace !

Et comme vous avez pu le voir, il y a beaucoup de choses à dire sur les compétences de développeurs, et je n’ai fait qu’en gratter la surface lors de cette partie (de même pour la prochaine).

Ainsi, laissez-moi un commentaire en dessous si vous voulez un article allant plus en profondeur sur une de ces compétences, que ce soit sur la veille technologique, la démarche de tests ou la productivité de manière générale. Je prends tous vos avis en compte afin d’écrire des articles de qualité qui vont vous faire devenir des développeurs surhumains.

Accéder au bonus : J'analyse mon propre profil de développeur.