Comment être plus réactif ?

La refonte de ce site n'était pas simple. Outre la révision de tous les contenus, la réécriture de certaines pages et l'écriture de nouvelles, cette refonte à nécessité une évolution en profondeur du CMS (Content Management System) maison qui me permet d'administrer le site.

Ces opérations se font le soir, entre 22h00 et 2:00 du matin, et à chaque fois que j'éteins ma machine, je suis effaré! Je suis effaré par la quantité de choses que j'ai pu faire sur le site en quelques heures alors que j'ai le sentiment qu'il me faudrait beaucoup, beaucoup plus de temps pour couvrir le même périmètre fonctionnel dans la sphère professionnelle.

Alors j'ai réfléchi aux différences de mode de fonctionnement entre mes projets personnels et mes projets professionnels. Voici le fruit de ces réflexions.

Commençons par le déroulement de mes projets informatiques dans ma sphère personnelle... Chaque soir, en m'installant dans mon bureau pour ma "seconde journée" de travail, je regarde les pages de mon site pour identifier les fonctionnalités à modifier dans cette seule soirée. Je mets rarement plus de 15 min avant de décider ce que je vais faire. J'écris peu : j'ai une image claire dans ma tête de ce que je veux faire et je n'ai besoin de l'expliquer à personne. Je fais mon design moi même, donc pas de longues séances de brief maquette avec un designer. Comme j'ai quelques (très) modestes compétences en développement PHP et base SQL, je code moi même. Je teste, je corrige, je mets en production, je me couche.

Voyons maintenons le déroulement d'un projet informatique dans ma sphère professionnelle.

- La maîtrise d'ouvrage a une idée d'évolutions. Ils en parlent en interne ; potentiellement un PowerPoint est fait pour en parler aux managers.

- On interroge la MOE pour en connaître le coût ; en retour on leur demande une expression de besoin écrite.

- Une fois rédigée elle part pour instruction à la maîtrise d'œuvre qui ne comprend toujours pas bien de quoi on parle. On se réunit, on en reparle.

- On fait des ateliers fonctionnels, on rédige des spécifications. On établit un chiffrage, un planning, on se réunit pour en parler : trop cher, trop long alors on revoit le périmètre et on recommence.

- On se réunit encore, on relit puis on se revoit pour la validation et démarrage du développement : on ré-explique le projet au développeur qui comprend différemment selon le principe du téléphone arabe.

- À la livraison la maîtrise d'ouvrage ne reconnaît pas forcément son besoin ; discussions, échanges, décisions, corrections. Une fois validée, la mise en production est programmée en respectant un train préétabli.

La morale de cette histoire est simple : plus la responsabilité des évolutions et plus la compétence à les mettre en œuvre sont concentrés sur un nombre très réduit de personnes, plus la réactivité est forte et le coût est faible. Il faut juste faire confiance à quelques individus, leur donner les clés fonctionnels et techniques du site et les laisser agir en leur âme et conscience. Les erreurs sont possibles et il faut les accepter pour ne pas paralyser de trouille toute l'équipe qui porte à elle seule le projet : c'est la contre partie d'une agilité extrême.

Ça ne peut pas s'appliquer à tous les projets. Ce n'est notammment pas adapté aux projets qui s'accostent a d'autres systemes moins agiles : interconnectez ces hommes & femmes hypers agiles à des collaborateurs dans un mode de fonctionnement hiérarchique classique et vous leur brisez les ailes. Reste à trouver la personne ou la petite équipe capable de gérer tout aussi bien les aspects fonctionnels, techniques et supports du produit, ce qui revient à chercher le mouton à cinq pattes !