Dès que l’on délivre des produits numériques, au sein d’entités où il s’agit de coordonner de grosses équipes, Jira s’impose comme l’outil de pilotage par excellence.
Intégrité du sprint, burndown, graphique de vélocité, diagramme de flux cumulé, graphique de contrôle… Une multitude de diagrammes et métriques est à disposition pour monitorer la charge, piloter la production et améliorer le flux de travail… des développeurs !
Qu’en est-t-il pour les designers ? Les organisations dans lesquelles opèrent ces derniers ne gagneraient-elles pas à intégrer pleinement ces derniers à leurs workflows Jira ?
Jira est un outil pour les développeurs, les designers utilisent Trello.
Les bons outils pour les bonnes personnes :
- Développeurs : ingénieurs : cerveau gauche : Jira
- Designers : artistes : cerveau droit : Trello
Je grossis à peine le trait. Raccourcis, mythes et blagues à part, force est de constater que si l’utilisation d’un Jira est une évidence pour l’IT, il en va tout autrement pour les équipes Design qui se verront bien souvent, au mieux, doté d’un Trello.
Héritage d’une époque à laquelle les designers étaient bien souvent regroupés au sein d’agences de communication et cantonnés au rôle d’exécutants – maintenant c’est différent, on a internalisé et conçu des centres de services qui ne disent pas leur nom… –, Trello a le mérite de représenter un premier pas vers l’organisation et donc à terme l’efficience.
Pourquoi Trello c’est bien mais pas assez ?
Pour l’exercice, je prends ici l’exemple de Trello car il est le plus répandu et donc le plus représentatif, mais le raisonnement est valable pour ses équivalents.
Que les fans et/ou captifs de Trello se rassurent, j’aime bien Trello, je l’utilise pour les choses peu importantes ! Plus sérieusement, je peux l’utiliser comme une espèce de to do list pour des sujets de petite échelle, impliquant peu de personnes, ayant vocation à être traités rapidement et ne nécessitant pas un réel pilotage, comme la préparation d’un team building par exemple.
Dans le même esprit, en fonction du contexte, il m’arrive aussi d’utiliser les tableaux kanbans de Notion, d’Airtable ou de Miro… coucou Robert !
J’ai aussi essayé Asana, Monday, ClickUp et autres outils de “management de projet” – ce sont eux qui se présentent comme tels – et ils ont chacun leurs qualités mais j’évolue dans le management de produit, pas de projet… Ça n’est pas anecdotique.
J’ai bien évidemment connu les sacro-saints fichiers Excel mais est-ce bien la peine que je m’y attarde ?
Ce point quant aux principaux outils étant évacué, rentrons dans le vif du sujet !
Ce que permet Trello
Trello permet aux équipes de travailler plus confortablement, en centralisant les demandes. Celà libère les designers de la charge organisationnelle et de la gymnastique intellectuelle que représentent des besoins exprimés sur de multiples canaux de communication, leur permettant ainsi de faire ce qu’ils savent le mieux faire : designer. Intéressant comme idée non ?!
Outre cet aspect, non négligeable, de confort de travail, Trello a la capacité de donner en temps réel une vue d’ensemble sur les travaux attribués aux équipes Design, d’un point de vue global et individuel, ce qui s’avère particulièrement utile à toute personne en charge de “gérer” les activités Design. Je n’emploie pas ici, à dessein, le terme “pilotage”. Nous y reviendrons.
Cette “big picture” comme il se dit, l’expression prenant tout son sens dans l’exemple qui suit, permet à n’importe quel Product People coutumier des managements visuels – ce qui devrait être un pléonasme – d’avoir un instantané de l’état du flux de conception et d’identifier en un simple coup d’œil les situations à risque en fonction de la répartition des tickets dans les différentes colonnes du tableau.
Ah ! Tant qu’on parle de tableaux, ouvrez-les ! Transparence, premier pilier de Scrum.
Ce que permet Jira
Je vais maintenant m’intéresser à un certain nombre d’éléments qui, cumulés, font la singularité et la force de Jira dans des écosystèmes complexes, vastes et hétérogènes par rapport aux multiples supposés concurrents et produits de substitution.
La clé du pilotage : le monitoring
Ce que j’ai traité dans la première partie de cet article relève de la visualisation de l’activité et, comme nous l’avons vu, il s’agit là d’une excellente pratique : rendre visible les choses.
La continuité de la visualisation est le monitoring, “conduite assurant la surveillance d’une opération ou d’un processus industriel du type continu” selon le Larousse.
“If you cannot measure it, you cannot improve it”. William Thomson dit Lord Kelvin
“You can’t manage without measuring, and what is measured gets done. Measurement is the antidote to ambiguity. It forces you to impose clarity on vague concepts and to take action”. Anders Wester
Du monitoring découle la capacité de piloter. En effet, si le fait de visualiser un flux nous permet d’avoir une tendance, il ne nous offre pas la possibilité de mettre en place un pilotage digne de ce nom, c’est-à-dire qui s’appuie sur des métriques, raison pour laquelle j’ai précédemment employé le terme “gérer” plutôt que “piloter” lorsque je parlais des outils type Trello.
Trello nous permet de percevoir le vrombissement du moteur, c’est bien ; Jira nous offre un cockpit avec des jauges et des témoins lumineux : c’est encore mieux.
Les story points et les sprints
Nativement, Trello n’offre pas la possibilité de chiffrer les tickets, ni de créer des sprints.
Si l’on peut légitimement, en fonction de son contexte, opter pour un système Kanban plutôt que Scrum, et donc de sprint, on peut difficilement s’affranchir des story points, excepté dans le cas d’une approche “no estimate”.
J’ouvre une brève digression sur le “no estimate”. Pour ne pas trop m’attarder sur cette approche, je dirais que le “no estimate” ne peut être viable que pour des équipes matures, rompues à l’agilité, et intégrées dans des organisations elles-mêmes matures… Le “no estimate” ne veut pas dire “on se fiche des estimations, on y va au feeling”, bien au contraire, elle dénote d’une agilité prégnante et éprouvée.
Si vous êtes inscrit dans une approche “no estimate”, vous êtes déjà sans nul doute sur Jira, ou alors vous avez le goût du risque.
Digression terminée, revenons-en à nos moutons story-pointés… Les story points représentent un formidable outil permettant d’obtenir des métriques capitales pour analyser la charge et le flux, offrir de la prédictibilité, piloter finement, ce que ne propose pas nativement Trello.
Alors je vois venir les taquins… “Hé les Power-ups de Trello, qu’est-ce que t’en fais ?!”. Oui on peut faire des choses avec les power-ups Trello, pour les story points et les sprints il y a par exemple Dashio. Ou encore “Tu devrais savoir que mon-logiciel-alternatif-préféré permet de chiffrer des tickets”, là encore c’est juste. C’est vrai pour les story points et les sprints, ça l’est également pour d’autres aspects mais c’est l’agglomération native de features que l’on peut trouver sur certains outils et dans une certaine mesure qui font de Jira le leader. Je ne parle même pas des plugins que l’on peut greffer ou qui finissent par être absorbés par Jira, ni de la puissance que représente un Jira Align quand on travaille à échelle.
Les rapports et tableaux de bord
Si, comme on l’a vu en début d’article, un management visuel – qu’il soit de type Kanban board ou Scrum board – permet à un œil aguerri d’identifier les situations à risque, la tendance d’un flux de travail, quid de l’analyse fine, de la résolution de problèmes et, surtout, de l’anticipation de ces derniers ?
Une simple vue board ne permet pas d’aller si loin, d’avoir une compréhension détaillée de ce qu’il se passe sur le flux de travail. Les rapports Jira, une bonne quinzaine, nous permettent d’avoir cette analyse systémique : que se passe-t-il sur ma chaîne de valeur, d’un point de vue macro d’une part, d’un point de vue micro d’autre part ; où sommes-nous en risque, où sommes-nous particulièrement efficients.
Je ne rentrerai pas ici dans le détail des différents types de rapport, le sujet est trop vaste et mériterait un article à lui seul – si vous souhaitez en apprendre davantage, vous pouvez jeter un œil ici –, je vais toutefois donner quelques exemples non exhaustifs, tirés de mon expérience, de ce que permettent les rapports.
Le rapport des tickets créés comparés aux tickets résolus m’a par exemple permis d’alerter partie-prenantes et top management quant à la charge qui s’accumulait pour mes designers. Ces deux simples courbes m’ont offert la possibilité de donner corps aux alertes remontées par l’équipe et restées vaines de la plus simple et percutante des manières : “En rouge ce qui nous est demandé, en vert ce que l’on aborde ; le delta est de tant, au regard de notre débit, nous avons 70 jours calendaires de travail en backlog, je vous laisse faire le calcul en jours ouvrés. Que fait-on ?”.
Les choses sont tout à coup devenues plus palpables, et pour tous. Nous avons trouvé des solutions. Les gens ont besoin de chiffres, pas qu’un sentiment leur soit communiqué.
Le diagramme de flux cumulé me permet d’identifier les éventuels goulets d’étranglement, ce qui a pu par exemple m’être utile pour mettre en exergue que, pour un stream sur lesquels été reproché aux designers de ne pas délivrer assez rapidement, il y avait eu un amoncellement de tickets en attente de validation, “grippant” la chaîne de production et retardant les étapes en aval, accroissant en finalité le lead time, le temps de traversée d’un ticket sur l’ensemble du flux.
Dans ce même exemple, le graphique contrôle me permet de mettre des métriques sur la situation, à savoir un temps de validation moyen trois fois supérieur au temps moyen de production sur une période donnée… Si les designers ne délivraient pas assez rapidement ça n’était pas faute de s’y employer, c’était dans ce cas précis dû à des délais de validation démesurés. Redoutable. Généralement ce genre de situation ne se produit qu’une fois.
Ces rapports me permettent aussi de m’assurer que l’on délivre de manière régulière, c’est notamment le cas grâce au graphique de vélocité dans le cas d’une production cadencée sous forme de sprints, ou via le rapport sur l’âge moyen, qui rend possible le monitoring sur la durée les variations éventuelles du delivery, comme le permet également le graphique de contrôle évoqué précédemment.
Généralement, un seul rapport n’est pas suffisant, ou du moins pas assez. C’est en croisant ces rapports et en “jonglant” avec les filtres que l’on identifie le ou les irritants, bien souvent situé(s) sur les zones d’adhérence entre plusieurs services – on pourrait parler de SAFe qui préconise d’œuvrer avant tout sur ces jonctions plutôt que sur les étapes en elles-mêmes mais ça n’est pas le sujet ici – et que l’on est en mesure de trouver des axes d’amélioration en vue d’une excellence opérationnelle.
Si ces rapports permettent de comprendre les causes d’un problème survenu, ils sont avant tout destinés à être observés régulièrement afin de pallier les situations problématiques et idéalement de les anticiper. Pour qui s’y intéresse, ils représentent le journal du lendemain.
Un rapide point sur les tableaux de bord pour conclure cette section, ils sont un agrégat de rapports compilés sur une seule et même page. La force des tableaux de bord réside dans le fait que ces derniers sont propres aux usages et besoins de chacun, en effet, un designer n’utilisera pas les mêmes widgets – nom donné aux rapports intégrés aux tableaux de bord Jira – qu’un product owner, un scrum master, un designOps, un manager, etc. Chacun aura donc un tableau de bord répondant au mieux à ses attentes et à son périmètre.
Différentes granularités et différents types de tickets
Une autre singularité de Jira et non des moindres : la notion de granularité.
Si Trello offre une checklist par ticket, Jira offre une tout autre dimension : epics, user stories, tâches, pour citer les trois niveaux proposés et généralement utilisés.
La puissance de cette granularité réside dans un monitoring à plusieurs niveaux :
- Macro, avec les epics
- Intermédiaire, avec par exemple les user stories
- Micro, avec les sous-tâches
Chacun de ces niveaux pouvant disposer d’un workflow et de spécificités propres. Sans trop entrer dans les détails, vous pourrez selon votre contexte et écosystème, avoir des types de tickets particuliers, chacun ayant éventuellement un flux de travail qui lui est propre, des champs particuliers, voire des automatisations… Je vous laisse entrevoir ce que ça ouvre comme champ des possibles.
A savoir, si les types de tickets des niveaux les plus macro – epic – et micro – tâches – sont “figés”, le niveau intermédiaire est quant à lui personnalisable avec d’autres types de tickets proposés par Jira, tels que les “bugs” par exemple, ou que vous créerez vous-mêmes… En effet, l’utilisation du terme “user story” n’est pas toujours des plus pertinent en matière de Design, particulièrement selon le découpage qui aura été réalisé en amont mais c’est un autre sujet.
Petit retour d’expérience sur la sémantique : en fonction du rôle et de la maturité de mon interlocuteur, j’évite parfois d’employer des termes tels que “user story” ou, pire, “epic” afin d’éviter d’apporter plus de questions que de réponses et/ou d’entrer dans une guerre de clochers. J’y préfère un vocabulaire simple et généraliste tel que “ticket de niveau 1, 2 et 3” ou “ticket parent, enfant, petit-enfant”. C’est peu orthodoxe j’en conviens, mais l’essentiel demeure selon moi d’établir un vocabulaire commun facilitant la compréhension et l’alignement du plus grand nombre. Ceci étant, si vous souhaitez vous intéresser davantage à ce sujet, je vous invite à lire l’article suivant : Un outil puissant mais méconnu : récit sur l’epic.
Une intégration avec les autres workflows de l’entité
Autre point et non des moindres, l’intégration avec les autres flux de travail de l’organisation.
Faisons un petit exercice de pensée, projetons-nous non pas dans les bois – elle n’est pas facile – mais dans une grande organisation qui délivre un produit numérique…
Le produit communique des besoins aux équipes design et développement en vue de maximiser la valeur produit. Le design délivre des prototypes de qualité à cadence régulière, c’est signe que le flux de travail fonctionne bien… En ce qui concerne l’IT, la vélocité est soutenue, très peu de bugs, vite corrigés et même l’intégration est parfaite. Le produit, légitimement, est content ; on a là une équipe qui tourne à la perfection !
Ah oui ?! En est-on certain ? Comment on le jauge et en juge ? On fait une somme ?
- Produit : checked
- Design : checked
- IT : checked
Donc système : checked ? “Les calculs sont pas bons Kevin”. Le fait que les différents éléments d’un système fonctionnent supposément parfaitement n’implique pas nécessairement la performance de ce dernier. On peut très bien avoir des temps de cycle optimaux en design et en développement mais un time to market long. Or ce qui nous intéresse, c’est de livrer de la valeur utilisateur rapidement, pas de créer un stock de valeur qui attend d’être consommé.
On ne le répétera jamais assez, beaucoup – la plupart ? – des problématiques naissent sur les zones d’adhérences. C’est vrai entre deux étapes d’un workflow propre à un pôle de compétences, ça l’est d’autant plus entre deux services ayant potentiellement des workflows distincts.
Comment s’assure-t-on que le système performe ? À vos crampons ! Vous allez comprendre… On a les MNM : Messi, Neymar, Mbappé ; on serait en droit d’aspirer à un PSG plus performant.
Il faut analyser le système non seulement segment par segment, mais aussi et surtout dans son entièreté. C’est ce que nous permet Jira, si tant est qu’il soit administré en ce sens.
Un exemple de cas concret où deux services auraient des flux de travail distincts :
- Le design livre des prototypes en accord avec les besoins clients et les enjeux business, ils sont validés. Done.
- L’IT développe, passe en recette, met en prod, tout est parfaitement opérationnel. Done.
Tout est ok ? Non, le design a plusieurs mois d’avance sur l’IT : muda, surproduction, surtraitement ou surstockage.
Il est intéressant de se pencher sur cette notion de “muda” qui fait partie du triptyque “Muda, muri, mura” qui nous vient du lean et de le transposer à notre cas d’usage. Soit on surproduit ou surtraite, on connaît la difficulté qu’ont les designers à se limiter à un MVP – à tort ou à raison – ; soit on surstocke et je voudrais pointer la définition du surstockage : “stocks excessifs de matière ou d’information en raison des coûts associés de stockage, de risques de péremption, d’invendus etc.”.
“Risques de péremption” c’est une notion intéressante dans notre secteur. En effet, dans quelle mesure ce que l’on produit est-il périssable ? Pas besoin d’en faire la démonstration…
Je vous accorde que dans ce cas tout le monde devrait se rendre compte qu’il y a un problème. Étonnamment ça ne l’est pas toujours. Encore une fois il faut aller plus loin qu’un sentiment même s’appuyant sur des faits que chacun est à même de constater, il faut mettre des chiffres : “Le design a X mois d’avance sur le développement. Il y a un problème, qu’est-ce qu’on fait ?”.
Bien sûr, on pourra là encore m’objecter que rien n’empêche de faire cette analyse en parallélisant les stats – si tant est qu’il y en ait – d’un outil à un autre, c’est vrai, mais qui le fait ? Comment ? A quelle fréquence et surtout combien de temps ça prend ? Encore un gaspillage, consommer ponctuellement ou régulièrement un temps certain d’Humain pour une tâche pouvant être exécutée quasi instantanément et en continu par la “machine”.
Ça n’a pas de sens et ça ne tient pas sur la durée, parole d’un DesignOps qui a trop croisé de données provenant d’extractions d’environnements différents sur Excel.
Une modularité inégalée
Outre la modularité des flux de travail présentée précédemment, on ne peut pas traiter des particularités de Jira sans évoquer sa modularité en matière de visualisation, d’architecture de l’information, bien que cette dernière soit régulièrement mal exploitée car administrée hors sol.
Nous avons parlé en début d’article de la visualisation. Une des contraintes quand on cherche à visualiser quelque chose, ici en l’occurrence un flux de conception, c’est de mettre la bonne focale. Dit autrement, il s’agit de configurer l’outil de telle sorte que la vue qu’on en tire soit pertinente et exploitable, que l’on soit en mesure de visualiser facilement ce qui nous est utile, que l’on “y retrouve ses petits” pour parler trivialement.
Jira, bien configuré, nous permet ça.
Je ne vais pas ici entrer dans tous les aspects liés à la configuration et la modularité, le sujet étant trop vaste et légèrement complexe, mais je vais aborder quelques concepts majeurs afin que vous puissiez vous projeter.
Les colonnes représentent bien évidemment les différentes étapes de notre flux de travail mais qu’en est-il si, par exemple, plusieurs produits ou verticales exploitent le même flux ? Plusieurs solutions existent pour rationaliser la vue du tableau afin qu’elle soit la plus lisible possible.
Les lignes d’eau, couloirs horizontaux permettant de regrouper des tickets en fonction de propriétés communes, sont la solution la plus naturelle pour répondre à la segmentation évoquée.
Pour aller plus loin, il est possible d’attribuer un liseré de couleur aux cartes – tickets – selon une propriété choisie.
Une solution intéressante pourrait être de coupler ces deux possibilités dans le but d’avoir un tableau le plus affiné possible, avec par exemple une ligne d’eau par verticale produit et des couleurs en fonction du domaine d’expertise – UX ou UI – si l’on a besoin d’avoir des métriques distinctes sur ces dernières.
Une autre piste, plus conventionnelle, serait par exemple d’avoir une ligne d’eau par priorité : P0, P1, P2, P3 – P0 étant alors ce que l’on appelle communément “autoroute” et que Jira nomme « accélérer », c’est à dire la voie des tickets qualifiés d’urgents soit parce qu’ils sont marqués d’une deadline soit, soyons honnêtes, parce que la demande provient du top management.
Petite préconisation : pour que P0 ait un sens, et donc une valeur, il faut absolument l’utiliser avec parcimonie ; si tout est prioritaire, rien ne l’est.
Pour filer l’exemple, dans un cas où la conception serait pilotée par la date – hé oui, ça arrive encore malheureusement –, on peut utiliser les liserés de couleur au regard de la deadline : vert pour ce qui sera à délivrer sous tel délai, orange pour ce qui concerne la période active – éventuellement un sprint – et rouge pour ce qui est un retard… Oui le pilotage à la date parallélisé à l’agilité ne font pas bon ménage.
Ces lignes d’eau et liserés de couleur fonctionnent comme je l’ai introduit grâce aux propriétés des tickets. Dans les grandes lignes, ces dernières peuvent notamment être du type étiquette, composant, sprint, responsable et de nombreux autres.
C’est le JQL, langage de requête propre à Jira, qui permet en fonction de ces propriétés d’aiguiller les tickets dans tel(s) et/ou tel(s) projet(s), tableau(x), ligne(s) d’eau.
Le JQL offre également la possibilité de créer des “filtres rapides” au sein des boards, afin de masquer des tickets en fonction de telle(s) ou telle(s) propriété(s) et donc de ne n’afficher que les tickets correspondant à une requête précise : verticale, priorité, étiquette, responsable, etc.
Nous avons vu deux exemples de configurations des tableaux Jira, il en existe d’autres. En effet, il n’y a pas de meilleure solution dans l’absolu, a contrario il y en a des mauvaises, la meilleure solution est celle qui répond au besoin des différentes typologies d’utilisateurs.
Il se peut, dans certains cas, qu’il y ait plusieurs vues portant des tickets identiques, précisément parce que ces différentes typologies d’utilisateurs peuvent avoir des besoins particuliers, ou plutôt un prisme différent.
Il se peut également qu’un tableau agglomère plusieurs autres, eu égard à un besoin particulier. Exemple afin d’illustrer mon propos : dans la mission où j’évolue actuellement, les designers ont besoin d’une vue sur leurs plateformes respectives ; pour ma part ainsi que pour le head of design, nous avons besoin d’avoir une vue globale à tout le design ; j’ai donc construit un board par plateforme dont les lignes d’eaux correspondent aux verticales, ainsi qu’un master regroupant tout le travail de conception où les lignes d’eaux correspondent aux plateformes.
Ce qu’il faut retenir : Jira c’est ce que vous en faites, par conséquent il doit être designé – vraiment – et les meilleures personnes pour le faire sont les doers, ce sont eux qui connaissent le mieux leurs besoins. Jira ne doit pas être configuré en chambre ou de manière générique, ça n’a aucun sens et c’est absolument contre-productif.
Petit tips pour les designers et heads of design : lorsque que vous effectuerez une demande de configuration de votre/vos tableau(x) Jira, de votre/vos workflow(s), de vos propriétés vous risquez de vous heurter à des fins de non-recevoir, à des “on ne peut pas faire ça”… Faites-en ce que vous voulez mais sachez que c’est bien souvent faux ; la réalité est que c’est contraignant et que ça peut nécessiter un travail assez conséquent en termes d’administration en fonction de la structure et de la configuration du Jira à l’échelle de l’organisation.
Deuxième tips : cartographiez vos usages et besoins et designez votre Jira en amont de vos demandes, le template Kanban de Miro est tout à fait adapté à cet usage, et aidez votre administrateur Jira à comprendre la réelle teneur et tout le bien-fondé de vos attentes.
Autres aspects
L’idée n’est pas de traiter tous les aspects et fonctionnalités de Jira mais de mettre en exergue les éléments forts structurant ma réflexion mais si vous voulez approfondir le sujet, jetez par exemple un œil à ce qui peut être fait en termes d’automatisation ou d’intégration de plugin.
La feature Trello qu’il manque à Jira
Il me tenait à cœur de mentionner ici une feature dont dispose Trello et qu’il manque à Jira. Hé oui ! Il y en a au moins une, qu’Asana notamment a reprise et qui, étant chaque jour de plus en plus d’actualité, finira assurément par être intégrée à Jira : Trello Colorblind Friendly Mode, un mode facilitant les personnes touchées par le daltonisme.
Le principal inconvénient de Jira
Jira est une grosse machine, qui nécessite un certain temps à être assimilée en vue d’une administration efficace. Il est difficilement envisageable qu’un designer soit en charge de cette dernière. Ceci étant, comme on l’a vu, il est indispensable à l’établissement d’une solution pertinente que ses utilisateurs – en l’occurrence ici, les designers – soient impliqués dans la conception de leur projet Jira : workflow(s), écrans, tableaux, etc.
Une fois cette phase de conception effectuée, l’implémentation devra être effectuée par une personne disposant d’une solide connaissance de l’outil. Cette tâche revient généralement à un administrateur dédié mais il est tout à fait envisageable qu’en fonction de son parcours un DesignOps soit à même d’y procéder, ce qui offre notamment l’avantage d’avoir la main sur les différents artefacts de Jira et d’être ainsi en mesure de pouvoir itérer rapidement sur ces derniers le cas échéant.
Jira : qu’en pensent les designers ?
Outre le fait que Jira soit prétendument “un outil pour les développeurs”, ce à quoi je tâche de répondre durant cet article, un aspect qui m’est souvent remonté par les designers est “Jira c’est pas fou en termes d’UI”.
C’est vrai, et si on met les mains dans le moteur, l’administration, j’ajoute volontiers que ça n’est pas fou non plus en matière d’UX… Mais on n’a rien fait de mieux jusqu’à maintenant pour piloter un produit dans son entièreté.
Les vraies questions qu’il conviendrait de se poser pour un designer seraient :
- Est-ce compliqué à utiliser ?
- Qu’est-ce que j’y gagne ?
Quand j’ai commencé à sensibiliser des designers aux apports de Jira et à essayer de les embarquer – il y a maintenant 5 ans, c’était alors encore moins dans les usages que ça ne peut commencer à le devenir aujourd’hui – j’ai vite compris que leurs a priori reposaient bien souvent sur un raccourci type “Hum… c’est un outil de dév’, ça doit être compliqué. Warning!”.
Aussi, j’ai pris l’habitude de désamorcer les inquiétudes en introduisant Jira comme un Trello à l’échelle. Et c’est exactement ce qu’il est pour l’usage qui en sera généralement fait par un designer : du drag & drop de cartes, attribuées à des personnes et représentant des tâches, au sein de différentes colonnes d’un tableau, permettant le regroupement de ces dernières en fonction de leur état d’avancement.
Pour cet usage qui, j’insiste, est celui de l’immense majorité des designers, Jira n’est pas plus compliqué à utiliser qu’un Trello.
Les plus curieux quant à eux, s’alimentent de la mine d’informations qu’offre Jira. Ce qui génère des échanges constructifs entre Design et Produit allant dans le sens d’une appropriation de la démarche DesignOps par les équipes en vue d’un design scalable.
Quelques soient leurs profils, tous les designers que j’ai eu le plaisir d’accompagner reconnaissent rapidement les apports de Jira, à minima en termes de confort de travail.
Je trouve de la satisfaction quand un directeur artistique, avec tout ce que cela implique généralement en matière de mindset, me dit “je ne suis pas sûr que ce soit fait pour moi, ces tickets et toute cette démarche d’industrialisation mais au moins maintenant on y voit clair… D’ailleurs je pense que ça serait bien que tu nous montes un Jira sur tel nouveau produit”.
Conclusion
Bien que de nombreux outils de monitoring existent et disposent chacun de qualités indéniables, Jira demeure incontestablement le plus pertinent – le seul ? – dès lors que ce monitoring s’effectue sur différentes granularités.
Il est capital de garder à l’esprit que l’utilisation d’un outil de monitoring ne saurait se limiter au pilotage et à l’amélioration continue d’un service. S’il le permet brillamment, sa véritable puissance réside dans le fait qu’il offre la possibilité de la faire à l’échelle d’une flotte en agrégeant les métriques de chacun des navires qui la composent.
C’est de ça dont ont besoin les clients pour lesquels j’interviens : optimiser – donc monitorer – l’activité design d’une part et réduire le time to market d’autre part.
Envie d’échanger à ce sujet ? Parlons-en sur We Love Product!
Retrouvez-moi sur LinkedIn.
