Après plus de 10 ans à échanger avec des pairs sur diverses expériences en IT, je me pose la question suivante : Pourquoi embaucher des ingénieurs ? Oui, c’est une vraie question !! Dans la plupart des annonces recherchant des développeurs, nous lisons ceci : « Recherche ingénieur […] bac+5 […] 5 ans d’expérience, etc. ». Ma question est donc belle et bien : pourquoi ? Qu’est-ce que les entreprises attendent de telles personnes ayant ce niveau de formation ? Est-ce qu’elles ont vraiment de quoi les intéresser ?

Et une fois embauchés, est-ce que ces entreprises savent vraiment tirer profit des capacités et du potentiel de ces profils ? Mettent-elles un environnement propice à l’expression de leurs talents ?

L’art et la manière de produire ?

Les entreprises IT recrutent très souvent des ingénieurs pour produire. Ce sont donc eux qui produisent les logiciels et qui ont une responsabilité sur la qualité, les délais, et la valeur apportée aux clients. En tout cas, c’est bien eux qui connaissent le métier de la production et qui sont montrés du doigt quand un problème apparaît.

Sauf que dans les faits, s’ils en sont bien responsables et qu’ils sont reconnus comme des « sachants » de la manière de produire, il n’est pas rare de voir des organisations faire appel à des « experts » pour définir le processus optimal de production. La mise en place d’une cellule architecture ayant la responsabilité d’expliquer aux ingénieurs comment produire « proprement » en est un symptôme. Ces architectes sont bien souvent totalement éloignés du terrain, ce qui rend leurs décisions parfois quelque peu caduques (pour être gentil). Pire, il arrive même que l’entreprise fasse appel à des consultants externes, encore plus éloignés du terrain et du contexte de l’organisation. Les ingénieurs n’ont plus qu’à faire avec ce qu’on leur donne, et pour éviter toute tentative disruptive de leur part, certaines entreprises n’hésitent pas à investir dans des ERP. De cette manière, elles empêchent toutes prises de décision rapides (toutes améliorations ?).

Produire la bonne pièce ?

L’ingénieur a aussi des capacités d’analyse et d’adaptabilité. S’il n’est pas reconnu comme légitime sur la manière de produire, peut-être pourrions-nous lui faire confiance sur ce qu’il faut produire ?

Là encore, les entreprises traditionnelles rivalisent d’ingéniosité pour que leurs ingénieurs n’en aient pas. Par la mise en place de « spécifications détaillées » par exemple, elles empêchent toutes prises de décision ou d’adaptation. Lorsque ces mêmes entreprises cherchent à « faire de l’agile », elles nomment des Product Owner qui ne rédigent plus des « spécifications détaillées », mais des « user stories ». Bien souvent, ce qui change n’est que le nom, et ces user stories ne sont que des micro-spécifications et non de vraies user stories dont la principale vertu est d’être une source de communication et lien entre l’implémentation et le métier.

Conséquences ?

Au final, les ingénieurs n’ont qu’à suivre les directives sur ce qu’il faut produire et sur la manière dont il faut s’y prendre. Le seul moment où ces entreprises laissent les ingénieurs faire preuve d’ingéniosité, c’est pour adapter les théories qu’on leur impose à la réalité du terrain. Ils se transforment alors petit à petit en « pisseur de code ». Ajouter à cela la mise en place de mauvais KPI (tel que j’en parle dans ce billet), et on a une recette idéale pour générer frustration, démotivation, désimplication et gaspillage.

Le fait d’avoir des gens qui pensent à la place de nos ingénieurs est un manque de confiance évident et est simplement catastrophique pour l’entreprise. Pablo Pernot nous l’explique très bien dans son article Management d’hier et d’aujourd’hui. Ce manque de confiance engendre des équipes où l’énergie consommée à trouver des excuses dépasse largement l’énergie utilisée à améliorer la performance opérationnelle.

Et du coup, on fait quoi ?

Changer notre façon de faire et mettre les ingénieurs en situation de pouvoir s’exprimer, tout simplement. Le Lean tend à mettre les équipes en capacité de s’auto-gérer. L’agilité fait d’ailleurs de même, s’en est même un des principes de base. Non seulement on va leur faire confiance sur l’organisation de la production, mais on va également s’appliquer à leur donner tout ce dont ils vont avoir besoin pour produire la bonne pièce au bon moment avec le bon niveau de qualité. Pour cela, le manager va devoir quitter son rôle de « command and control ».

Par la mise en place d’objectifs clairs sous forme de KPI (Pour rappel, il y a les bons et les mauvais KPI), le manager annonce clairement ce qu’il attend de l’équipe. L’équipe a alors une vision extrêmement claire de ce qu’elle a à réussir, de ce pour quoi elle doit « se battre ». J’aime cette phrase que mon mentor Cecil Dijoux m’a dite un jour :

Les équipes n’ont pas le devoir de réussir, mais elles doivent en avoir le droit

Avec cette vision extrêmement claire, les gaspillages deviennent évidents, l’entraide prend tout son sens, les axes d’amélioration deviennent visibles. Le manager n’a donc plus qu’à accompagner l’équipe, l’encourager, l’aider à progresser pour atteindre ses objectifs. Et il ne va pas le faire sans méthode. Grâce au Gemba, le manager Lean va sur le terrain, au plus près des équipes de production. Il va voir et comprendre clairement ce qui se passe dans les équipes pour pouvoir les aider et prendre des décisions en toute connaissance de cause. Il n’est plus là pour supposer des améliorations sur un modèle de production théorisé sur un Power Point. Il voit, comprend, et agit pour réellement apporter son aide sur des problèmes concrets. C’est un changement de paradigme fondamental.

Pour engager les équipes et leur faire prendre conscience de l’importance de leur travail, ce n’est pas un expert ou un manager qui viendra leur parler, mais le client directement. Pour suivre la satisfaction client, le Lean n’a pas peur de demander à chaque développeur de réaliser une enquête de satisfaction directement avec le client. Le fait de discuter avec un client réel change souvent le regard qu’un ingénieur porte sur le produit et sur la production au sens large.

Ce qui va en production, c’est ce qu’a compris le développeur.

Finalement, le Lean répond à ma question. En challengeant les équipes, on encourage la créativité, l’ingéniosité, la prise de décision, le leadership. Le Lean fait rentrer les ingénieurs dans un monde où ils conçoivent et appliquent leur propre modèle en étant guidé par la satisfaction de leurs clients. Toute l’entreprise se positionne alors autour d’eux pour les encourager et les mettre en situation de réussir et de s’améliorer.

Finalement, j’en viens même à me demander si le fait que le marché soit si tendu, que les ingénieurs soient si difficiles à recruter, et encore plus à garder, n’est pas une conséquence d’une mauvaise stratégie de production ?

Et vous, pourquoi recrutez-vous des ingénieurs ?

PS : Je n’ai pas parlé de S@fe pour éviter de rendre cet article trop long :-p