Vous voulez savoir ce qui pourrait étonner l’ensemble du corps professoral côtoyé durant toute ma scolarité et quelques clients de longue date ? C’est que je passe parfois trop de temps à besogner sur des petits détails*. Régulièrement félicité et reconnu pour ma rapidité et ma réactivité, sans pour autant bâcler mon travail (poke Monsieur Rolland, je me souviens de vos petits mots sur mon carnet de notes de CM2, hein !), j’en avais presque fait une marque de fabrique et axais en partie ma communication dessus, mais aujourd’hui, je dois avouer que je ne suis pas systématiquement rentable sur les heures facturées et celles réellement travaillées. Je réfléchis donc à changer mon fusil d’épaule et vous partage ici mes réflexions.
Rentabilité rime-t-elle avec qualité ?
En effet, mes méthodes de travail sont loin d’être économiques. Mon éthique professionnelle associée à mon envie d’apprendre toujours plus me poussent à énormément me documenter au sujet de nouvelles technologies web (qui évoluent à une vitesse grand V), ou même sur un branding où le story telling doit être fact checké. Ces recherches sont chronophages et je ne compte pas l’inspiration initiale qui peut parfois disparaître aussi vite qu’elle est apparue. Quelle que soit la mission, je souhaite m’investir, donner le meilleur de moi-même, faire mieux que la fois précédente, et m’améliorer ! C’est alors que la fameuse deadline se rapproche et vient rappeler la fin de l’exploration, aussi passionnante soit-elle. Il est temps de poser le stylo et de rendre la copie. Un comble pour l’élève qui partait toujours avant l’heure et faisait plusieurs exercices d’avance jusqu’à n’avoir quasiment jamais aucun devoir à faire à la maison !
Actuellement, le travail à abattre sur chaque projet est de plus en plus conséquent ! Je me fais généralement l’avocat du diable en évoquant les pires scenarii. Je passe pour le pessimiste ou le casse-pied de service. Or, porter de l’importance sur certains détails permet longévité pour un logo et une marque, sécurité et meilleur rendement pour un site internet, éviter les tâches redondantes, etc. Les contraintes temps et budget des clients demeurent inamovibles, alors qu’ils sont souvent sous-estimés. Ainsi, il faut se résoudre à livrer un MVP (ou un simple POC selon moi), standardiser les propositions afin de rentrer dans les clous… Perfectionniste ? Peut-être… (mais je me soigne !) Quand le chargé de projet et le client se réjouissent du résultat, je dois certainement m’en contenter. À ces compliments, peut s’ajouter ce qu’un confrère m’a de nombreuses fois répété : « Ça fonctionne, c’est bon ! Inutile de faire un code ultra propre, de discuter des « broutilles » techniques avec le client, il ne les comprend pas, et surtout, il s’en fout ! ». Pourtant, à ce stade, le regret de n’avoir pu aller au bout de mes idées prend la forme d’une frustration, accompagnée heureusement d’une consolation : tous ces éléments inexploités me serviront la prochaine fois, je ferai mieux !
Ne pas confondre réactivité, agilité et surtout réalité !
Le principal problème vient probablement de la différence entre ce qu’attend un client et ce qui peut lui être livré en fonction de son budget et de ses délais. L’écart peut être tout bonnement monumental. C’est une honte, mais j’ai encore une majorité de projets sans véritable cahier des charges alors que je le réclame systématiquement. Si j’ai la chance d’obtenir au final un PowerPoint avec les minima : arborescence, objectifs, contenus, parcours utilisateurs, sans échanger 365 emails et appels, c’est déjà ça, et je peux parfaitement faire avec ! (Quoi ?!! Tu ne fais pas de project design ?!! Si, si, j’en parle juste un peu plus bas) Enfin, j’ai parfois l’impression que mes clients se sont habitués à ce que je transforme le plomb en or et l’eau en vin dans des temps records, et qu’ils en demandent toujours plus en fournissant de moins en moins. Je suis graphiste et non alchimiste ou Jésus ! Sans périmètre délimité, on se retrouve inévitablement aux journées portes ouvertes des requêtes sans fin ! Revenir sur ce qui a été validé, ce n’est pas de l’agilité ! « It’s a feature, not a bug », sans l’ironie qui entoure l’expression, résume bien la situation. Toutefois, j’ai encore du mal à bien le faire comprendre. Le plus « drôle », c’est quand le commanditaire réclame que la correction / modification / implémentation de fonction(s) soit faite dans la minute, pour ne pas dire la veille… Alors qu’à l’inverse, quand lui doit te remettre un élément, tu as le temps de rentrer 3 ou 4 autres dossiers et même de devenir papa ! On avait fixé des délais, non ? Qui est réactif ? Qui est souple ? Et qui ne l’est pas ?
Attention, je ne veux pas faire le mec qui se plaint ! J’ai du travail, je remercie une nouvelle fois mes clients de m’accorder leur confiance, et certains depuis plusieurs années déjà, malgré mes gueulantes ! Ces contrariétés sont assurément le quotidien d’une foule de graphistes, webdesigners et agences de communication, la preuve avec l’excellent compte Twitter Web Agency Fail. Toutefois, cela ne doit pas établir une norme. J’imagine que (beaucoup ?) d’autres prestataires gèrent mieux et qu’il existe des solutions viables et abordables. Tout n’est pas qu’une question d’argent. Je dois certainement cadrer et imposer des règles plus strictes. La liberté et la souplesse souhaitées pour les différents intervenants sont possiblement trop permissives et utopiques au vu de la rigueur qu’exigent les projets de branding ou de site internet. Je le répète : la réflexion et la conception en amont des négociations et de la vente, ce qu’on appelle le project design et qui fondent le socle d’un business plan ou d’un cahier des charges, sont des étapes essentielles dans une optique de viabilité à long terme d’un produit ou d’un service. L’agilité qu’on me ressort à toutes les sauces, notamment celle sans cahier des charges (LOL) et satisfaction client en priorité, c’est du bullshit de vendeur de tapis !
La philosophie Agile vise des itérations certes souples voire improvisées, mais elles demeurent avant tout intelligentes. Ne pas anticiper, se précipiter, se contredire et réagir sur ce qui devient plus des caprices que des imprévus ne constituent pas de l’agilité ! L’Agilité de peut pas non plus s’appliquer à tous les projets, et les méthodes « classiques », en cascade, sont parfois plus adaptées.
Évidemment, je ne dis pas que je peux tout prévoir, mais quand on arrive au pied du mur, que le client se cogne tête la première alors que je l’avais prévenu depuis un moment de faire autrement… C’est qu’il y a un problème de communication ou d’écoute… Et je déteste dire : « je l’avais dit… », et hélas entendre : « Dareth, tu avais raison. » #TrueStory
La méthode Scrum et ses sprints
Loin de moi l’idée de vous faire un cours magistral sur la culture Agile et le framework Scrum, d’autres le font beaucoup mieux. Ce billet se veut avant tout un retour d’expérience, et un constat de mon quotidien à un instant T. Je me permets juste de préciser quelques points du manifeste Agile déformés par certains. Comme je l’ai écrit dans mon précédent billet, il est question de former une équipe unie afin d’avancer ensemble. Encore une fois, il ne s’agit pas d’une opposition Client VS Prestataire. Les sprints se font aussi bien en collaboratif qu’individuellement d’une part et d’autre. « Les meilleures architectures, spécifications et conceptions émergent d’équipes auto-organisées ». « Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet ». Pour être pleinement satisfait, il faut aussi être prêt à entendre ce que le prestataire, normalement expert dans son domaine, juge pertinent pour votre besoin, et ne pas imposer une vision ne tenant pas compte de tous les tenants et aboutissants. Les phases de revue du product backlog, mais aussi celles des sprints et de ses rétrospectives doivent être des échanges bi-latéraux afin de rester constructives. Le chargé de projet se doit d’être neutre, d’enlever sa casquette commerciale, et la remplacer par celle du Scrum master de sorte à ce que les itérations se déroulent au mieux, en utilisant les outils adéquats (ce que le flood de mails n’est pas !). « La simplicité, c’est-à-dire l’art de minimiser la quantité de travail inutile, est essentielle ».
Slow business ou Slow management, et qualité de vie au travail
Autre principe Agile, et non des moindres : « réaliser les projets avec des personnes motivées. Fournissez-leur l’environnement et le soutien dont ils ont besoin et faites-leur confiance pour atteindre les objectifs fixés ». Bien que l’agilité prône les sprints rapides, on s’aperçoit qu’en terme de performance, la tendance va également au Slow business ou Slow management, partant du principe Less is More. Gare aux traductions hasardeuses, ce n’est pas forcément en faire moins, c’est FAIRE DIFFÉREMMENT toujours dans le but de FAIRE MIEUX. Peut-être plus lentement ou de manière plus réfléchie et optimale, ne pas presser et stresser les équipes avec des délais et des objectifs irréalistes, etc. Des collaborateurs heureux sont plus productifs ! Si vous ne l’aviez pas remarqué, je partage régulièrement sur les réseaux sociaux ma veille, actuellement axée sur les thèmes de la productivité et de la qualité de vie au travail. Il y a matière à échanger, et cela mérite largement un article dédié, à venir prochainement sans nul doute ! Mais pas tout de suite, hein ! ツ De toute façon, ça commençait à faire long là, non ? On continue en commentaires, curieux d’avoir vos retours !
*Autre preuve que je passe trop de temps sur les petits détails : je lis et relis au moins 150 fois mes articles avant de les publier… j’en fais tout autant après publication et diffusion, modifiant continuellement quelques mots et tournures… Quoi ? Ça non plus ce n’est pas de l’agilité ? ^^’
Laisser un commentaire