Pour un bureau des méthodes web

En classe de quatrième, en cours de techno, j'apprenais que dans une entreprise, il y avait le bureau d'études et le bureau des méthodes. Les bureaux des méthodes, le groupe de personnes qui se disent "mais comment on fait pour mettre ça en pratique de manière récurrente ?". Cela pourrait paraître évident comme démarche, pourtant rares sont les personnes qui se posent la question de "comment on fait ?" et préfèrent "qu'est-ce qu'on vend ?".

Le bureaux des méthodes

Sur wikipedia, on trouve une définition du bureau des méthodes :

Le bureau des méthodes ou service des méthodes est, dans une entreprise, l'interface entre la ligne de production et le bureau d'étude. Il est chargé de concevoir et de fournir les outils utiles à la production afin d'améliorer la productivité globale de l'entreprise, d'améliorer les conditions de travail et de fournir les outils d'analyse nécessaires aux études de coûts standard, c’est-à-dire :

• vérifier, avec le bureau d'étude, la faisabilité et la fabricabilité d'un produit,
• de mettre en œuvre les moyens de production nécessaires (machines, opérateurs, matériels et équipements, …),
• définir les temps nécessaires à la production,
• définir les coûts de production,
• optimiser les temps/coûts de production.

"Le bureau des méthodes est l'interface entre la ligne de production et le bureau d'étude". Dans une agence web, si vous avez d'un côté la production (les devs) et de l'autre les concepteurs (les fameux designers ou parfois chefs de projets), vous devriez avoir entre les deux un service chargé de la réflexion sur la mise en œuvre de ce qui est vendu.

Dans certaines agences, on trouve une personne que l'on nomme "responsable qualité" qui justement (selon l'idée que je m'en fais) tient ce rôle d'interface entre la conception et la réalisation.

Dans les agences, où ce poste est inexistant ce poste peut être partagé entre un directeur technique (par exemple) et des chefs de projets de manière informelle ; attribué à un Scrum Master sur un projet ; ou confié à une équipe autonome.

Travailler sur les méthodes

Quand on pense qualité (dans le web), on imagine un personne inspectant chacun des produits sortant de la machine, effectuant une batterie de tests avec un microscope et publiant un rapport régulier sur l'état de la production.

C'est en partie ça, il y a une phase de contrôle, effectivement, mais pas seulement. La qualité étant un processus, il effectue à peu près tous les points que l'on trouve dans la définition du bureau des méthodes ci-dessus.

C'est-à-dire faire un état des lieux du processus du production et agir sur les points les plus critiques pour l'amélioration de la qualité globale ; tout cela s'effectuant dans le temps, sur le long terme.

Travailler sur quelles méthodes ?

Dans une vision archaïque du monde dans laquelle on dissocie la technique de la conception produit. Un responsable qualité aura comme objectif de garantir une résultat correspondant à une exigence définie dans un cahier des charges (exemple un niveau bronze accessiweb). On le jugera sur le code.

Dans une approche un peu plus globale du processus du production, on sait d'expérience que si la phase de conception est incomplète (ne traite pas de l'accessibilité), vous pourrez mettre toute l'énergie que vous voulez, jamais vous ne réussirez à atteindre le niveau requi.

Le principal frein que vous allez identifier sera avant tout d'ordre humain. On a beau faire ce qu'on veut, une personne compétente est toujours plus efficace qu'une personne inexpérimentée. Ceci va vous amener à réfléchir à la formation de chaque intervenant du projet (l'ensemble de la chaîne) et à mettre en place un programme de monté en compétence.

Apprendre à bien faire

Que ce soit dans un modèle séquentiel ou dans un modèle collaboratif, il semble important de se poser la question de la manière de bien faire les choses. Pour cela il faut comprendre comment ça marche.

Dans un modèle séquentiel avec le bureau d'étude d'un côté et les développeurs de l'autre ; le responsable qualité sera chargé d'estimer, par rapport à un projet donné, les moyens à mettre en œuvre pour sa réussite. Il pourra juger de la pertinence des compétences de chacun en estimant leur capacité de réussite et de progression. Son œil extérieur, en dehors du flux de production, est un bon moyen d'apaiser et de motiver les relations entre les différents intervenants.

Dans un modèle collaboratif, il faut procéder de la même manière. Dans la méthode agile, on a eu l'idée du Scrum Master ; cette personne a le rôle de facilitateur de projet. Elle veille au bon grain et au suivi de la méthode convenue en début de sprint ; la méthode constitue la règle permettant la résolution des conflits ("euh, les mecs on avait dit ça").

Scrum Master ou pas, il convient de réserver un temps de réflexion à propos de la manière dont on fait les choses. C'est ce qui doit être absolument abordé en réunion de début et de fin de sprint (…).

Comment ça marche le web ?

Rappelez vous vos différents entretiens d'embauche dans lesquels vous assuriez à votre interlocuteur que vous étiez possédé par une motivation débordante de vouloir tout faire, tout cela nourrit par une capacité exceptionnelle d'adaptation et de progression illimité.

Vous mentiez, mais à moitié ; la motivation de savoir faire était bien présente, mais quand vous regardez la manière dont tout cela s'est réalisé sur les projets, vous constatez que tout cela s'est passé un peu de manière empirique et que, si vous vous êtes bien monté en compétence, ce n'est pas forcément le cas de votre voisin (on a toujours plus petit que soit, et plus grand aussi du coup).

Oui votre voisin remplace encore une à une toutes les mauvaises entrées dans un document alors que le "remplacer par" général existe. Pire, il pense qu'un intégrateur (il l'appelle comme ça, alors que son vrai nom c'est master of UX) est un simple maquettiste qui met en forme le code HTML fournit par un développeur (ne rigolez pas, ça existe).

Pourquoi cela ? Parce que quand tout le monde travail dans son coin, qu'on pense que chacun sait se servir parfaitement d'un système d'exploitation, qu'on ne parle pas des méthodes, tous ensemble, alors on stagne : survivre ou mourir.

On devrait ne pas hésiter à parler de choses qui peuvent sembler évidente et être sûr que chaque intervenant sait les maîtriser. C'est le meilleur moyen de progresser. Il s'agit de la culture générale d'un métier.

Tout ça pour dire

Les relations dans vos équipes entre les barbus et ceux avec les lunettes en bakélites sont au point mort. Vous entendez des phrases comme "je pisse du code" ou "j'en ai rien à faire de ton avis, je te demande juste de faire ton taf et de coder cette fonctionnalité… pour demain… matin" ; pensez méthode et parler web.

En fonction de votre configuration engagez un responsable qualité web, envoyer vos équipes en séminaire, en formation accessibilité, permutez des postes de manière ponctuelle, organisez des ateliers… mais parlez web et de ses méthodes.

Parler web, c'est parler de la naissance du web, du pourquoi du web, des standards ouverts, du W3C, de l'histoire des grandes sociétés, des navigateurs, de l'open source, du copier/coller, de Pirate Bay…

Parler web permet de modifier sa conception réelle du web et d'engager le discours sur la manière de s'inscrire dans son ensemble.

Note 1 : Je pourrais écrire un billet sur le besoin d'avoir au sein de son entreprise un historien du web, un érudit, essentiel pour engager les jeunes pousses dans une démarche volontariste et pour maintenir les passions.

Note 2 : Je vous conseille vivement la lecture du site openweb.eu.org.