Comment optimiser votre processus grâce à la gestion des flux de travail (avec Marc Boscher d’Unito)

Lisez la transcription :

Nous essayons de retranscrire nos podcasts à l’aide d’un programme logiciel. Merci de pardonner d’éventuelles fautes de frappe, car le robot n’est pas toujours 100 % exact.

Ben Aston :

Perdez-vous beaucoup de temps à essayer de trouver l’information dont vous avez besoin ? Je suis sûr que oui. Et en tant que personne qui gère une équipe, voir votre équipe passer des heures à chercher une information est extrêmement pénible. Mais la réalité, c’est qu’il n’existe pas de système de gestion de flux de travail unique et universel. Tandis que votre équipe UX et stratégie pourrait préférer Trello ou Asana, vos développeurs voudront invariablement utiliser JIRA. Alors comment gérer cette pagaille ? Qui décide au final ? D’ailleurs, il existe un rapport de McKinsey qui note que la majorité des employés passe environ huit heures par semaine simplement à chercher des informations.

La bonne nouvelle, c’est qu’il existe une solution à ce problème : un système de gestion de flux de travail. Donc si vous souhaitez économiser du temps, en gagner pour votre équipe et votre budget, continuez d’écouter le podcast d’aujourd’hui. Nous allons parler de la création et de l’optimisation d’un système de gestion des flux de travail. Merci de votre écoute. Je m’appelle Ben Aston. Je suis chef de projet digital et fondateur de thedigitalprojectmanager.com. Notre mission est d’aider les chefs de projet digital à mieux livrer et à aider ceux qui gèrent des projets dans un environnement numérique à réussir.

Donc si vous souhaitez rejoindre notre tribu, rendez-vous sur The Digital Project Manager point com. Vous y trouverez de nombreuses ressources pour acquérir des compétences, gagner en confiance et commencer à mieux piloter vos projets. Aujourd’hui, je suis rejoint par Marc Boscher, un développeur web devenu chef de produit, et maintenant PDG et fondateur d’Unito. Marc, bienvenue dans le podcast !

Marc Boscher :

Merci de m’accueillir.

Ben Aston :

Parlez-nous un peu de votre parcours. Comment passe-t-on de développeur web à chef de projet, puis chef de produit, jusqu’à créer sa propre entreprise ? Parlez-nous un peu de cette évolution.

Marc Boscher :

Eh bien, cela a pris quelques années, je suppose, mais tout a commencé lors de la bulle internet, avec des changements très rapides. J’ai plongé dans la technologie jusqu’au produit. Et cela fait essentiellement 20 ans que je travaille dans le produit. Et, dans ce domaine, vous avez cette chance d’observer continuellement des problèmes et vous vous dites sans cesse « quelqu’un devrait résoudre ça, quelqu’un devrait résoudre ça », sans jamais le faire vraiment. Mais j’ai gardé cette liste et, finalement, Unito est né de l’un de ces problèmes que j’observais constamment.

Ben Aston :

Donc, vous dites avoir travaillé dans le produit depuis 20 ans, mais Unito est une solution relativement récente. D’où vous est venue cette inspiration spécifique pour répondre à ce problème ?

Marc Boscher :

Eh bien, la gestion de produit, et dans une certaine mesure la gestion de projet, impose de collaborer avec énormément d’équipes et de groupes différents, aux compétences variées, et, bien souvent, vous n’avez aucune autorité hiérarchique. Vous n’êtes pas leur chef, vous devez gérer par l’influence. Donc, vous ne choisissez pas quels outils ils vont utiliser. Vous subissez le mélange d’outils utilisé par chaque équipe avec laquelle vous travaillez. Je me retrouvais donc à naviguer sans cesse entre Zendesk, Asana, JIRA, GitHub, et tant d’autres, devant payer le prix de cette diversité. C’est l’un de ces moments où l’on se dit : quelqu’un devrait résoudre ça. Traditionnellement, la solution, c’était d’imposer à tous le même outil. Mais l’idée, avec l’évolution des API, était : « Peut-on connecter ces outils entre eux ? Peut-on laisser chacun dans son outil, sans que les chefs de projet perdent du temps à courir après des mises à jour ? » C’est comme cela que l’idée s’est développée : une solution à nos propres frustrations. Et, comme c’était prévu dès le départ, on a tenté le coup, on a essayé, et, voyant que ça prenait, eh bien… nous y sommes encore aujourd’hui.

Ben Aston :

Super. Alors, dites-nous, quels sont les outils que vous intégrez en interne ? Je sais qu’on peut connecter des outils et logiciels de gestion de projet comme Trello et Asana, mais quelle est, selon vous, la combinaison d’outils que vous reliez, et comment ça fonctionne ?

Marc Boscher :

Personnellement, je suis un vrai fan d’outils, donc je les utilise quasiment tous ! C’est toujours enthousiasmant de tomber sur une interface qui correspond à sa façon de penser ou à son rôle. On y gagne beaucoup en termes de productivité, mais souvent, la vraie difficulté, c’est de convaincre les autres de l’adopter.

Je pense que la plupart des obstacles à l’adoption des technologies, aujourd’hui, ne sont plus d’ordre technique—il ne s’agit plus vraiment d’installer un logiciel ou de le déployer—mais de convaincre les gens de l’utiliser. Nous avons actuellement une douzaine d’intégrations. Nous venons de lancer l’intégration avec ClickUp il y a quelques semaines, une autre va arriver la semaine prochaine et encore une autre dans trois ou quatre semaines. Nous développons activement des intégrations pour le secteur de la gestion de projet et du travail collaboratif : Asana, Wrike, Trello… Nous avons aussi débuté avec les outils pour développeurs.

Donc, GitHub, BitBucket, GitLab et JIRA : l’objectif étant vraiment de connecter les chefs de projet avec des équipes techniques ou des utilisateurs métiers qui ne parlent généralement pas la même langue — même la langue des outils. Avec le temps, nous avons ajouté Zendesk (support), HubSpot (ventes et CRM côté marketing). L’enjeu est donc bien plus large : comment envisager le travail non plus seulement comme un processus d’une seule équipe, mais à travers toute l’organisation ? Et là, il y a véritablement un gaspillage massif de temps.

Ben Aston :

Vous êtes donc un mordu d’outils. Y a-t-il de nouveaux outils récemment découverts qui vous enthousiasment particulièrement, au point que tout le monde devrait les adopter ?

Marc Boscher :

En fait, tous les outils que nous intégrons sont parmi les meilleurs du marché. Mais nous pensons qu’aucun outil n’est parfait pour tout le monde, cela dépend de ce que vous voulez accomplir, qui vous êtes et de votre façon de travailler. C’est une conviction profonde. Je ne recommande pas l’un plutôt que l’autre, cela dépend vraiment du contexte. C’est l’essence même de notre philosophie : chacun possède son outil, ce qui le rend productif, voire super productif. Mais le défi, c’est que les outils ne sont jamais les mêmes… Les nouveaux apparaissent chaque jour. Nous privilégions ceux qui sont populaires ou croissants, à condition qu’ils incluent une couche API pour permettre l’intégration. La plupart des outils actuels proposent cet aspect écosystème.

Ben Aston :

Super. Marc a d’ailleurs écrit un article à ce sujet sur thedigitalprojectmanager.com, intitulé « Comment construire un système de gestion de flux de travail », qui inclut plusieurs exemples. Mais pour ceux qui ne l’ont pas lu, pouvez-vous nous expliquer ce que vous entendez par gestion de flux de travail ? En tant que chefs de projet, nous connaissons la notion de processus : il s’agit d’aller du point A (début du projet) au point B (fin du projet), en franchissant des étapes. C’est le processus.

Autrement dit, il y a différentes étapes pour aboutir à la livraison d’un projet. Et, au fil du parcours de A à B, on apporte de la valeur. Donc, expliquez-nous ce qu’est exactement la gestion de flux de travail : où s’inscrit-elle dans cette démarche, pour passer de A à B tout en générant de la valeur malgré les contraintes du projet ?

Marc Boscher :

C’est en fait très semblable à ce que nous connaissons, au processus. Les gens emploient souvent les termes flux de travail et processus de façon interchangeable. Mais nous aimons distinguer les deux : les processus sont généralement plus linéaires, étape après étape, un enchaînement d’actions. C’est notre façon naturelle de penser et de planifier—on établit une séquence : d’abord ceci, puis cela, etc. Puis la réalité s’impose.

Quand les gens commencent à travailler, on découvre des imprévus, on doit collaborer avec d’autres équipes dans un environnement très dynamique. Aujourd’hui le travail digital est beaucoup moins linéaire, nettement plus imprévisible. À nos yeux, il y a donc un processus de développement logiciel, un processus de campagne marketing, de lancement de produit, ou un processus commercial, chaque équipe devant définir le sien — il existe d’ailleurs pléthore de cadres pour cela.

Mais dès qu’on commence à collaborer au-delà des frontières d’une équipe, ce n’est plus la même logique. Il s’agit surtout de réunions, d’appels sur Zoom, de chats, bien plus que d’utiliser des outils qui nous permettent de gérer le travail et la livraison. La gestion des flux de travail, à l’inverse, c’est une couche qui connecte tous ces processus, qui fait le lien entre eux, ce qui fait énormément de sens.

Ben Aston :

Donc, si le système de gestion de flux de travail prend en compte ce genre de scénarios « si… alors… » et que le chemin A-B d’un projet est rarement linéaire, comment fait-on concrètement pour gérer les retours, les changements de direction ? Par exemple, que se passe-t-il quand l’UX est validé mais pas les maquettes graphiques ? Comment faire progresser le projet et s’assurer que les bonnes personnes sont informées, que le développement peut commencer ou non ? Une vision plus complexe et nuancée peut donc rendre la livraison plus efficace, car on n’est plus prisonnier du processus purement linéaire, mais on avance par cycles qui s’entremêlent, notamment pour l’UX, le design, le développement, la QA. Tout cela peut fonctionner plus harmonieusement si ces cycles sont bien liés. C’est ça, la gestion de flux de travail ?

Marc Boscher :

Exactement ! On reprend ici beaucoup de principes de l’agilité : ne pas chercher à tout contrôler, donner de la liberté, faciliter la collaboration, supprimer les obstacles, travailler en cycles courts… Mais les outils d’aujourd’hui compliquent souvent les choses, car chacun utilise le sien, chacun a son propre processus. Ainsi, la première étape d’une bonne gestion des flux de travail, c’est d’aller là où le travail s’effectue : accepter que les gens travaillent dans des espaces différents, et s’y rendre.

Donc, intégrer les outils là où l’action se passe. La deuxième étape consiste à cartographier le flux à travers ces outils, à façonner son déroulement : quels sont les règles, les points de passage ? Comment, par exemple, le marketing collabore avec le développement, ou comment, lorsqu’une fonctionnalité nécessite l’avis des designers ou des chefs de projet ou des développeurs, ça s’organise ? L’idée n’est pas de contraindre, mais d’ouvrir des passerelles pour une coopération sécurisée, à partir des outils de chacun.

Sans devoir courir après les infos. Un exemple simple : vous avez votre plan projet sous forme de Gantt dans Write, Asana ou tout autre outil. Il y a une tâche à faire par des développeurs : elle devient automatiquement un ticket JIRA, et reste synchronisée. Ainsi, le chef de projet voit le démarrage, les affectations, le passage dans un sprint, son évolution… et tout cela dans son propre outil !

Marc Boscher :

Cela permet de visualiser instantanément les dépendances avec d’autres équipes ou tâches, sans devoir jongler entre les outils. On reconnaît où le travail se passe, on connecte, puis on définit des règles : dès qu’un événement a lieu sur ce projet, je veux le voir dans mon plan projet, par exemple. Dès lors, plus besoin d’abandonner vos outils. L’information devient accessible partout ; la collaboration est enrichie, les frictions disparaissent. Là, on peut réellement optimiser et s’améliorer.

Ben Aston :

Donc il faut accepter que chaque équipe utilise ses outils favoris, et la difficulté constante quand on cherche à tout rassembler, c’est que chaque outil a sa propre philosophie de gestion de projet, ce qui facilite ou complique la collaboration selon les équipes. J’ai d’ailleurs essayé de faire travailler une équipe design sur JIRA… c’était un échec. Surtout quand on complexifie les workflows.

En pratique, donc, comment extraire ce processus et décider du niveau de complexité à donner au système de gestion de flux ? Comment éviter de tomber dans la lourdeur, particulièrement avec JIRA, quand on souhaite automatiser des actions entre, par exemple, Trello et JIRA ? Où placer la limite ? Quand commencer ?

Marc Boscher :

Pour nous, dès le premier jour, l’objectif était que les utilisateurs métier puissent le configurer eux-mêmes. C’est essentiel, car quand on veut connecter deux équipes, il ne faut pas avoir à solliciter un développeur pour monter une intégration. Tout est basé sur le design visuel et la possibilité pour un utilisateur de définir des règles dans un langage naturel (« quand ceci arrive, alors cela doit apparaître là-bas »). Il s’agit également de cartographier les écarts, car le niveau de détail d’un processus peut varier : en dev, il y a QA, revue de code, passage en préprod, etc., alors que le marketing se concentre sur la disponibilité de la fonctionnalité à lancer. La gestion du flux doit donc permettre le mapping entre des étapes qui ne coïncident pas forcément (10 étapes côté dev = 1 seule côté marketing).

Tout part d’une discussion : comment travaillez-vous, comment travaillons-nous, comment relier ces process ? Ensuite, il s’agit de laisser l’utilisateur métier ajuster la relation et d’itérer. On n’a pas besoin de tout prévoir d’un coup : partir avec une règle simple (« Si j’assigne à Ben, ça doit apparaître dans son outil », ou « Si j’escalade un ticket support, il doit arriver dans JIRA »), observer la circulation de l’information et ensuite, augmenter peu à peu la sophistication pour gagner en efficacité.

Ben Aston :

Je vois derrière vous ce qui ressemble à un workflow ou une cartographie : donc concrètement, quand vous réunissez différentes équipes, chacun travaillant sur des outils différents, comment formalisez-vous la compréhension de qui a besoin de quoi et quand ? Est-ce que vous modélisez tout dans l’outil ou préférez-vous encore passer par le tableau blanc, le schéma global ?

Marc Boscher :

On a vu des clients dessiner leur workflow, faire du tableau blanc. Nous avons donc intégré cette fonctionnalité directement dans l’outil : vous pouvez cartographier visuellement les flux, organiser le passage du travail d’une équipe à l’autre. Dans la discussion, c’est la clé : nous avons constaté que les clients connaissent parfaitement leur processus interne, il est documenté. Mais dès qu’ils cherchent à collaborer entre équipes, c’est l’inconnu. Les chefs de projet connaissent bien ça, car ils sont à la frontière des équipes, et font sans cesse la navette.

Plutôt que de passer leur temps à servir de pont à coups de copier-coller, si les outils deviennent transparents, la communication circule d’un outil à l’autre et les chefs de projet peuvent se concentrer sur l’essentiel : aligner les gens, surveiller les risques, définir les priorités, sans passer leur temps à informer chacun. Ce n’est pas là où l’on crée de la valeur, et pourtant, c’est ce que nous faisons trop souvent.

Ben Aston :

En effet, une grande partie du temps de gestion budgétaire sert à s’assurer que les bonnes personnes sont informées (lu le ticket, vu la mise à jour Trello…). Reconnaître que chacun travaille différemment, et l’accepter, puis relier tout cela (un ticket Trello créé = tâche JIRA créée), c’est sans doute l’avenir : permettre à chacun de travailler comme il veut. Mais alors, quand ça échoue, quels sont les défis de ce système ? J’imagine que le risque, c’est de se reposer naïvement sur l’outil, mais que des choses continuent de passer à travers les mailles du filet. Quels autres obstacles constatez-vous ?

Marc Boscher :

La communication reste capitale, système ou pas. Mais une fois que vous facilitez la communication, que chacun peut utiliser son outil au quotidien, pour collaborer avec ceux qui sont ailleurs, cela devient facile. C’est un peu comme un orchestre : chaque musicien a son instrument (son outil), les violons sont sur Trello, le piano sur JIRA. Le chef d’orchestre—souvent le PM—essaie de garder tout le monde synchronisé, sans imposer à tous d’utiliser les violons. Chacun a son style, c’est leur force : à vous de les guider. C’est ça, la gestion de projet digital moderne : diriger un collectif autonome, où chacun maîtrise son instrument.

L’enjeu, c’est que tout le monde puisse voir le chef, et se voir mutuellement. Aujourd’hui, les équipes sont dispersées, avec le télétravail c’est encore pire (fuseaux horaires, latence, etc.), donc rester à l’unisson est complexe. La gestion des flux devient alors une sorte de chef d’orchestre, orchestrant tout le monde sans casser leurs habitudes, à travers les outils et les continents.

Ben Aston :

Comment voyez-vous l’évolution future de tout cela ? Le rôle du chef de projet ? L’outil ?

Marc Boscher :

J’espère qu’ils passeront moins de temps sur la paperasserie, et plus à orchestrer. Nous pensons que la multiplication des outils va s’amplifier (le développement logiciel est facile, la distribution aussi, donc chaque équipe adoptera son outil préféré). Il faut donc aller là où se fait le travail et accepter cette pluralité, en gardant le lien. Une fois que cela est acquis, la gestion des flux offre une visibilité bien supérieure à ce qui se passe réellement. Vous disiez en introduction « qui gagne ? », or cela suppose qu’il y ait un perdant, c’est-à-dire quelqu’un obligé d’adopter l’outil de l’autre. Nous croyons en un futur où chacun garde son outil et où l’intégration est transparente pour tout le monde, et nous espérons être cette plateforme qui facilitera cela.

Ben Aston :

Admettons que je sois nouveau sur la question des processus ou de la gestion des flux de travail, comme beaucoup d’agences ou studios de 5 à 10 personnes qui courent après les livraisons (CEO aussi business dev, aussi gestionnaire de projet…). Où commence-t-on, entre le design du processus et l’optimisation ? Ceux qui se disent « je ne savais même pas qu’on avait un process… » : quelles sont les premières étapes pour l’optimisation et l’automatisation ?

Marc Boscher :

Il y a toujours des gains rapides à saisir et le seuil d’entrée est beaucoup plus bas qu’on ne le pense. Ce n’est pas si complexe que cela. Souvent, dans les petites structures, il faut s’adapter aux outils des clients, donc à chaque projet il faut réapprendre un outil différent. La prochaine fois que vous démarrez un projet, commencez par regarder quel outil le client utilise, quel est votre outil idéal. Si vous pouviez n’utiliser qu’un seul outil en interne, créez une routine projet, et la prochaine fois, si un client en utilise un autre, testez l’intégration des deux via un flux. Essayez, c’est bien moins disruptif qu’on l’imagine, le ticket d’entrée est faible : vous pouvez démarrer sur un seul projet, une seule équipe, un seul flux (ex : une simple demande marketing transmise au développement). Même une petite amélioration sur un flux vous fera gagner du temps et vous pourrez itérer à partir de là.

Ben Aston :

Adopter une démarche agile, c’est tester, apprendre, optimiser. Quand on conçoit ou optimise un process, on ne tombe jamais juste du premier coup. Mais identifier les « quick wins », voir où la dernière mission a échoué ou patiné (ex : pourquoi le design a-t-il commencé en retard ? Pourquoi le dev a-t-il démarré trop tôt ?) : autant d’opportunités pour renforcer ses process. On cartographie, on teste, on corrige. C’est une bonne manière de démarrer. Merci Marc de nous avoir rejoints aujourd’hui, c’était un plaisir !

Marc Boscher :

Merci, Ben.

Ben Aston :

Pour en savoir plus sur la conception de processus en gestion de projet, rendez-vous sur thedigitalprojectmanager.com. Vous y trouverez un grand nombre de ressources, d’adhésions et de formations en ligne. À la prochaine, et merci de votre écoute.