Jérémy Jeanson's blog
chasseur de bugs depuis .net 1.0

Voici un article que je rêve d'écrire depuis longtemps. Le sujet est assez vaste tout en restant centré sur deux mots qui s'opposent. On peut le constater en permanence dans les entreprises de services : fonctionnel et Technique

• Est-il justifié de faire une différence entre personnels fonctionnels et techniques ?
• Un « profile technique » peut-il vraiment échanger avec un « profile fonctionnel » ?
• Combien de fonctionnels faut-il pour faire tourner en rond un technique ?
• Combien de techniques faut-il pour faire avaler des couleuvres à un fonctionnel ?
• Pourquoi considérerait-on systématiquement que fonctionnel et techniques ne sont pas au même niveau hiérarque ?
• Pourquoi chacun n'en a rien à faire du travail de l'autre ?
• Pourquoi chacun n'a pas confiance en l'autre ?
• … etc …

Depuis des années, je suis convaincu que vouloir systématiquement faire un distinguo entre fonctionnel et technique est une absurdité sans nom. Dans la culture française, cela semble normal. Il faut des chefs, et il faut des exécutants. Peu importe si les uns comprennent les autres. La séparation « fonctionnel » contre « technique » me semble venir en grande partie de là.

Malheureusement pour ceux qui pensent ainsi, les « techniques » aussi appelés « techos », ne sont pas des cas sociaux. Ils apprennent, ils réfléchissent, ils ont fait des études. Pire encore, ils ont de l'expérience, et des idées. Si, un techos c'est ça en 2016. Bien évidemment, il y a le techos qualifié de « foncièrement mauvais ». Il ne veut pas de tout cela, et il fait ce métier pour des raisons alimentaires. C'est moche, mas cela existe, et parfois ce peut être due au fait de se faire continuellement bâcher par des fonctionnels (tellement intelligent « eux »). Oui, cette guéguerre futile fait des victimes.

Malheureusement, de l'autre côté du ring, on a voulu rester au même stade de l'évolution. Souvent, les plus expérimentés des fonctionnels ou chefs de projets, sont des anciens profiles techniques qui ont voulu quitter le technique pour s'élever (ou pour ne plus avoir de problèmes techniques à résoudre). Ils rappelleront peut-être parfois ce passé pour assoir leurs décisions. Après quelques années sans pratique, ils seront difficilement crédibles et ne feront qu'alimenter les histoires drôles des techos. Pour les plus jeunes, la voie royale semble être l'école de management (héritière du programme de l'école de commerce). Sur le papier, on y forme les esprits conquérants de demain. Pour quelques un, on offrira une visite chez le dentiste pour rallonger les dents. À d'autres, la faculté de dire « Google est ton ami » et de passer pour des stars. Heureusement, il y a toujours du bon grain parmi l'iveraie.

Les méthodes agiles, sauveuses de l'humanité pour les uns, bouc émissaire pour les autres

En 2016, ces les mots « technique » et « fonctionnel » doivent disparaitre de notre vocabulaire ! Il n'y a pas vraiment d'autre solution. Avec l'agilité, de bonnes idées sont arrivées. Leur appropriation et leurs adaptations auraient dû mettre fin à cette séparation. Malheureusement, on le voit bien dans la pratique, certains s'en sont servi pour déstructurer totalement toute notion d'organisation, de délais, et dire que si c'était le bordel, c'était à cause de l'agilité. Ce qui devait conduire à la responsabilisation de tous à conduit à la distension et au « lavage de mains collectif ».

Rien n'est de leur faute. Pire, dans certain cas, j'ai vu des responsables de projets dits « fonctionnels », expliquer qu'ils n'utiliseraient pas l'outil agile, car « trop technique » (ex : TFS et ses requêtes pourtant si pratiques pour suivre et anticiper l'évolution d'un projet). Le technique est devenu l'excuse du fonctionnel et vice versa.

Dans le même ordre d'idées, j'ai vu des « fonctionnels » ne pas vouloir utiliser Test Pro avec TFS, car trop « technique ». Lest tests sont donc fait approximativement, sans forcément suivre un plan de tests complet et sans jamais le reproduire, le tout sans rapport de test, juste un bug…. Comment voulez-vous que vos développeurs arrivent à reproduire les bugs et comprennent le contexte de ceux-ci ?

Quel avenir ?

Si on y réfléchit bien. Tant que les entreprises chercheront une compétence sans l'autre, on restera dans la même situation. Heureuses, on peut voir ici et là que les choses changent. De plus en plus d'entreprises cherchent des chefs de projets qui ont un vrai bagage technique, et des architectes qui comprennent les besoins fonctionnels des utilisateurs. Ils leur demandent de produire, assister les développeurs, recueillir le besoin tout en conduisant les projets. On admet enfin que les personnes qui réalisent ont besoin de comprendre ce qu'elles font et pour qui elles le font.

Alors, que va-t'y 'il devenir ce ceux qui veulent rester 100% fonctionnels, ou 100% techniques ?

Le 100% technique n'existe pas, car il réalise un besoin. Quoi qu'il arrive, il doit comprendre ce qu'il fait. Il faut donc enfin admettre qu'il comprend, et qu'il n'est pas qu'un exécutant. Avec le temps, vous vous rendez compte qu'il est frustré de coder des générateurs de fichier CSV pour les utilisateurs, alors qu'il sait leur fournir de vrais fichiers Excel. Si vous êtes l'ermite 100% techos qui code pour lui et non pour répondre à un besoin, vous êtes mal. Vous voulez rester tel un bœuf dans le sillon, cependant vous arrivez au bout de celui-ci. Fuyez ! Il n'y a pas d'issue pour vous L

Le 100% fonctionnel me semble avoir un avenir incertain dans l'entreprise. Comment justifier une charge à 100% toute la journée sur toute la durée des projets, si les équipes sont impliquées et savent s'auto gérer ? Le reporting ne prend plus autant de temps qu'avant. La production des graphes n'est plus aussi chronophage que dans les années soixante. Elle se fait même tout seule aujourd'hui. Et le recueil du besoin n'occupe pas à temps plein. Le fonctionnel « passe plats » ralentissant plus le projet qu'il en le fait avancer, il va falloir s'occuper autrement. Test, hotline, formation… il y a des possibilités. Cependant, le fonctionnel qui n'est pas en mesure de travailler en équipe et qui ne fait que se placer en « chef de » a peut-être du souci à se faire pour son avenir. Le « bore out » est proche.

Moralité

Ces deux profils n'existent pas. Ce sont des compétences que chacun doit avoir. On ne peut faire que si on sait faire, et on ne le fait que si on sait ce que l'on fait et pourquoi.

Dites au revoir au « fonctionnel » et au « technique », dites bonjour à « votre équipe » !