C’est dans le besoin que l’on reconnaît ses consultants.
Aujourd’hui le sujet qu’on vous propose n’est pas du tout technique et plus « soft » que d’habitude.
Tout au long de ma carrière, j’ai eu l’opportunité de rencontrer plusieurs dizaines (probablement centaines) de développeurs, de consultants BI, d’experts ETL, de techniciens ou encore de statisticiens pour vérifier leur niveau technique et approuver/désapprouver une éventuelle embauche. (Je sais qu’un chargé de recrutement junior serait amusé par ces chiffres – ils font sûrement autant d’entretiens candidats par mois que j’en ai probablement réalisé dans toute ma vie, mais c’est difficilement comparable).
D’un point de vue informaticien, consultant, parfois formateur, mentor et architecte, j’ai remarqué qu’il y a très peu des choses qui sont importantes pour moi :
- la capacité à réfléchir indépendamment,
- l’orientation résultat,
- la productivité,
- le sens de l’équipe (je ne dit pas « esprit d’équipe », uniquement « sens »).
Si vous trouvez pertinent d’ajouter/supprimer des éléments, n’hésitez pas à m’envoyer un commentaire pour étoffer cette liste.
Probablement, j’ai été influencé par « Valve Handbook For New Employees », mais j’avais réfléchi à cette liste un peu avant avoir lu ce document incroyable, mais vous pouvez l’utiliser pour référence : https://ithealth.io/wp-content/uploads/2020/05/Valve_Handbook_LowRes.pdf
La capacité à réfléchir indépendamment
J’ai vu beaucoup de personnes qui sont bloquées par ce qu’elles ont appris à l’école, dans un livre ou une présentation. Des personnes qui rencontrent des difficultés à réfléchir en dehors d’un cadre prédéfini.
Je me posais la question du pourquoi nous en sommes là et visiblement la réponse se trouve dans le « confort ». À vrai dire, il est tellement confortable de faire un travail répétitif. Même dans l’innovation, « surfer » sur la vague dominante, beaucoup ne veulent/peuvent pas faire autrement.
En général, si le candidat/collaborateur ne peut pas répondre à la question suivante : Pourquoi vous utilisez Hibernate, Spring, ORM en général ou même MVC » ? C’est mauvais signe et annonciateur de problèmes à venir. Cela ne veut pas dire que la personne en question n’est pas qualifiée, mais si vous occupez un rôle de mentor, vous avez probablement intérêt de la faire sortir du cadre qu’elle s’est auto-créée.
Les avantages apportés au business ? De meilleurs résultats, flexibilité d’IT, plus d’engagement, moins de « burnout ».
TL;DR Oui, je pense qu’il faut pouvoir aller voir l’architecte et lui poser une question de ce type : « Pourquoi exactement on utilise Oracle (ou Hive) et non pas une base analytique pour notre DWH ? » ou « Pourquoi on a besoin d’écrire le back et le front indépendamment ? ».
L’orientation résultat
Je me pose des questions :
- Pourquoi deux personnes avec le même niveau de formation, face à un même problème jamais vu auparavant, produisent des résultats très différents ?
- Pourquoi le support d’un éditeur est bloqué sur un problème alors qu’un consultant junior peut trouver une solution ?
- Pourquoi certains ingénieurs mettent « SQL » dans leur CV, alors qu’ils ne peuvent pas répondre à des questions basiques et expliquent cette situation par un « besoin de réviser » ?
- Pourquoi parfois un DBA connait mieux l’ETL que certains consultants ETL ?
- Pourquoi, aussi, un consultant BI connait mieux sa base de données que le DBA lui même ?
- Pourquoi la complexité algorithmique est un « rocket science » pour beaucoup de consultants ?
Je ne pense pas qu’il y a des personnes vraiment « incapables », et en plus je pense que nous en sommes les premiers responsables. Essayez de compter le nombre de spécialisations IT et vous verrez que les compétences sont en général très « silotées ».
Dans cette situation, seulement des personnes très motivées par l’intérêt d’offrir le meilleur service aux clients ont des compétences transverses et, face à une situation compliqué, vont être en mesure d’offrir des solutions pertinentes.
Vous imaginez, il nous fallait même un « Manifesto for Software Craftmanship » (http://manifesto.softwarecraftsmanship.org/):
Pour visualiser ce que j’avance, j’utilise la méthode suivante (aussi dans le livre de Valve, mais inventé, comme j’ai appris, encore en 1991) :
Vous voyez comment « I » se transforme en « T » sur les images ?
Pourquoi généralement je préfère un « apprenti » à un « débutant » même s’ils ont un niveau de compétences similaire ? Ça me montre la motivation, l’intérêt pour l’environnement technologique, sa vision générale des solutions, bref, tout ce que peut servir au résultat de son travail.
Il y a un autre effet de bord très intéressant : chaque personne veut être « importante » et si tout ce que voit cette personne c’est un domaine très spécialisé, elle va probablement trouver comment le complexifier (ex. DBA de MeP va créer des normes complexes, un expert en ETL – un nouveau framework inutile, etc).
Les avantages apportés au business ? Meilleur « bus factor » (connaissances non silotées), capacité d’accomplir des projets plus importants, équipe plus saine.
TL;DR Oui, je pense qu’un spécialiste « pure Windows » et « pure data viz » doit pouvoir, dans certaines situations, ouvrir Google et écrire « comment créer un script bash ». On doit changer notre habitude de dire « expert en X » par « il est mieux en X que dans d’autres domaines », mais c’est tellement idéaliste …
La productivité
Je me pose des questions :
- si une personne peut trouver les solutions aux problèmes auxquels personne d’autre ne sait les aborder…
- si la personne peut livrer le projet 2x plus rapidement (j’ai eu un cas de 60x plus vite !!!)…
- si la personne est à l’aise avec des problèmes que le métier n’arrive pas à résoudre depuis des années…
doit-elle être « reconnue » ? Si oui, comment ?
Personnellement, je voudrais travailler avec des personnes qui savent améliorer le monde autour de nous, les outils qu’on utilise, automatiser le travail que personne ne veut faire, « exploser » les solutions « d’état de l’art ».
Pourquoi, donc, dois-je être parmi les managers qui comptent les consultants, développeurs, ops par nombre de « têtes » comme un éleveur avec son cheptel ?
Les avantages apportés au business ? Productivité ?
TL;DR Je réponds à la question « et quoi faire avec une personne médiocre? » par « éviter ».
Le sens d’équipe
« Last but not least », ce paramètre est difficile à estimer, mais il vous ait déjà arrivé de vous dire « j’aurais préféré ne pas avoir une telle personne à côté de moi »… et c’est normal.
Je fais allusion aux personnes toxiques, dénuées de la capacité à écouter, aux personnes trop expérimentées, qui ne peuvent/savent pas accepter ses erreurs ou ne comprennent pas tout simplement qu’il existe des domaines où il leur manque des compétences. Notamment, le chef de projet qui dit « c’est impossible, mais il le faut et c’est ton problème », ou le développeur qui produit le code le moins lisible possible …
On ne demande pas beaucoup ici car les personnes « difficiles » nous sommes tous de temps en temps. La question c’est la quantité …
TL;DR Oui, je pense qu’il faut se séparer d’un chef de projet, qui par ses méthodes de travail, provoque le départ de développeurs vers une autre société.
Bonne santé à vous et à votre équipe.