Le management est un métier

Manager est un travail à part entière, qui consiste à faire faire aux autres. Or la plupart du temps, on en vient à manager par progression dans une activité professionnelle. Un bon vendeur évoluera naturellement vers de l'encadrement d'équipe commerciale. Un bon informaticien se verra proposer comme progression logique de carrière d'encadrer des équipes. Comme si, finalement, l'expérience opérationnelle d'un métier était la compétence la plus importante pour encadrer, et qu'elle arrivait mécaniquement avec les années pour la plupart des gens.

Ceci semble malheureusement totalement faux. Non seulement il est possible d'encadrer une équipe sans connaître au départ son métier, mais à l'inverse les meilleurs experts d'un domaine ne font pas systématiquement de bons managers.

Car pour faire faire aux autres, il faut beaucoup plus exercer un savoir être qu'un savoir faire. En effet, l'objet, la "matière première" du management, c'est la personne encadrée et sa relation personnelle avec son encadrant. Ce n'est pas celle du travail qui doit être accompli par l'équipe : le client pour le commercial, le système d'information pour l'informaticien, etc. Et c'est bien en travaillant son image, son crédit et son autorité auprès de son équipe qu'on développe cette relation. La connaissance technique préalable du métier sous-jacent n'est qu'un moyen utile d'y parvenir, mais n'est ni nécessaire, ni suffisant.

Comme il s'agit d'un métier en soi, le management exige à la fois des connaissances techniques (comment motiver, communiquer, construire et exercer une autorité), et des compétences humaines (capacité d'écoute, intelligence émotionnelle, contrôle de soi, etc.). Ces connaissances et ces compétences n'ont a priori rien à voir avec d'autres métiers qui auront pu amener une personne en position de manager.

Malheureusement, bien souvent les personnes sont promues manager sans aucune aide pour cette prise de conscience indispensable qu'ils vont à présent exercer un autre métier, en plus ou plutôt à la place de leur ancien métier technique. Ils continuent donc naturellement à exercer leur ancien métier. Ils briment fréquemment leur équipe car, après tout, s'ils sont là, c'est bien parce qu'ils sont probablement les meilleurs dans leur domaine. Ils s'attachent moins au résultat qu'aux moyens d'y parvenir. D'autres auront assez d'intuition pour adopter la bonne attitude, assez de charisme pour s'imposer naturellement et de finesse pour donner envie à leur équipe de les suivre. Mais ce ne sera pas sans faux pas. On n'apprend pas à faire du ski sans chute.

Fonctionnel et technique

Dans les projets de système d'information, on doit toujours avoir des "fonctionnels" et des "techniciens". Un fonctionnel sera en mesure de comprendre ce que veut l'utilisateur du système, ou ce qui sera pratique pour lui. Un technicien sera en mesure de comprendre comment fonctionne les systèmes, logiciels, languages, etc. pour le réaliser.

En effet, il est rapidement apparu dans les premiers grands projets que les informaticiens "technique" devaient consacrer un temps de plus en plus important à comprendre le fonctionnement des systèmes, et qu'il n'avaient par conséquent pas le temps d'écouter convenablement des utilisateurs, de leur faire accoucher de leur besoin, de réconcilier des points de vues ou des exigences divergentes, etc. Ce qui fait la joie du technicien, c'est la prouesse technique, l'utilisation d'une nouvelle technologie, épater ses collègues techniciens, bref toutes choses absolument dénuées d'intérêt pour l'utilisateur final. Quel intérêt d'avoir un graphique qui tourne en 3D si on n'arriva pas à lire les chiffres qui le constitue ?

Il fallait donc avoir une interface pour parler aux utilisateurs, essayer de se mettre vraiment à leur place, comprendre leur métier, et finalement le traduire en termes compréhensibles aux techniciens. Et surtout, après, s'assurer qu'ils font bien ce qui leur est demandé, et ne perdent pas leur temps en gadgets inutiles... Le "fonctionnel" est donc celui qui va parler au client, ou aux utilisateurs et qui est garant du résultat. Une sorte de "col blanc" de l'informatique.

Tout ceci marche plutôt pas mal. Néammoins, j'ai eu l'occasion de constater à plusieurs reprises les travers de ce modèle bien établi. Par exemple, on demande aux gens de se classer dans une catégorie ou une autre: poste spécifiques, équipe de "business analysis" dans les projets, etc. C'est nécessaire, mais la séparation devient forcément structurelle : équipe différentes, locaux voire localisation différente, traitements et salaires progressivement différents... En poussant ma description précédente du fonctionnel, on comprend aussi qu'il y a un embryon de "lutte des classes" entre fonctionnels et techniques. Car si l'un est col blanc, visible et valorisé, l'autre est à coup sûr col bleu. Avec le risque d'une guéguerre perpétuelle sur le mode: "ce que vous nous spécifiez est infaisable" / "vous ne vous intéressez pas à l'utilisateur". Ce dialogue de sourd arrive malheureusement assez souvent.
Pour ma part, je préferre ne pas choisir de "camp". L'informaticien idéal est celui qui est exactement entre les deux, et qui va savoir simultanément analyser le besoin fonctionnel et les contraintes techniques. Au cours de son analyse fonctionnelle, il saura anticiper les problèmes de performance, choisir une architecture adaptée, remettre en perspective des demandes de l'utilisateur et proposer un compromis entre utilité et difficulté.

Malheureusement, sur de gros projets, ceci est impossible. On ne peut pas être à la fois comptable, spécialiste de logistique, commercial, etc. Mais au moins faut-il empêcher une rupture entre les deux aspects. Pousser les techniciens à s'intéresser à l'utilisation de leur système, et les fonctionnels à la technique. Même s'ils n'en ont pas envie. Et surtout, éviter le snobisme. La communication doit être intense et poussée entre les deux aspects, et le respect mutuel.

Mots-clés : fonctionnel - technique

Des processus et des hommes

Si vous avez eu l'occasion de travailler dan une grande entreprise, vous n'avez probablement pas échapper au "processus". Le processus, c'est la formalisation d'une série de tâches effectuées par des hommes ou des machines. En fait, tout le monde fait du processus sans le savoir, comme monsieur Jourdain faisait de la prose ...

Pourquoi faut-il formaliser ces tâches, ces savoirs-faire, ces méthodes qui constituent la base de son métier? Tout simplement pour la partager et s'assurer que chacun emploie les même méthodes au sein d'un même groupe. La formalisation des processus est à la base des méthodes qualités, et fait partie du référentiel qualité. Une fois écrit, le processus peut servir à former de nouveaux collaborateurs, homogénéiser les pratiques, être amélioré, etc. Mais surtout, il doit être appliqué.

C'est souvent là que le bas blesse. Car, s'il est difficile d'expliciter simplement ce que l'on fait, il est encore plus difficile d'appliquer précisément une description simplifiée de sa propre pratique. En réalité, il existe beaucoup de cas particuliers dans une activité professionnelle. Il n'est pas très réaliste d'espérer les exprimer à la fois précisément et complètement. Surtout, un savoir-faire permet de réagir efficacement à une stuation quand elle se produit, mais pas d'anticiper et de catégoriser précisément toutes les circonstances a priori et de les ordonancer sous forme logique.

C'est pourquoi un processus ne doit pas être envisager une fois décrit comme une règle absolue et mécanique qui permettrait de faire abstraction de toute intelligence, ou de transformer une personne débutante sur une tâche en l'équivalent de quelqu'un ayant plusieurs années d'expérience. Un processus doit être vu comme un canevas, un guide mais pas un carcan. C'est d'ailleurs pour celà que les méthodes de qualité permettent de corriger et de raffiner progressivement les processus.

Plus on s'approche d'un objet et plus on distingue ses détails. Le tout est de savoir quand s'arrêter.

Mots-clés : processus - qualité