Expérience Design au sein d’un projet DBT

1. Qu’est-ce que le design ?

Dans un sens global du terme, le design est un processus intellectuel créatif, pluridisciplinaire et humaniste, dont le but est de traiter et d’apporter des solutions aux problématiques de tous les jours.

Et effectivement, c’est la manière dont on l’envisage aujourd’hui dans notre manière de travailler.

Voici 4 dates sont importantes pour vous expliquer au mieux le concept de design :

• Le 7 mai 1851 : exposition universelle au Crystal Palace à Londres. C’est la première architecture qui a été designée en kit.
• En 1859 : la chaise n°14 de Thonet est produite en série. C’est un peu le concept d’Ikea, penser la construction d’une chaise en objet modulable.
• En 1919 : apparition du Bauhaus. Cette date est très marquante car c’est la concrétisation du fait que la forme suit la fonction. Aller identifier la fonctionnalité qu’on veut dégager et la conceptualiser.
• Depuis quelques années : création du design system. Vous en avez entendu parler ? Je vais vous expliquer ça en détail un peu plus tard, c’est un peu la retranscription de ces trois dates que je vous ai mentionné avant, qui viennent vraiment alimenter le design digital, comme on l’utilise aujourd’hui, et donc faire du design industriel sur les outils Internet.

Voilà ça c’était la petite intro historique… Vous n’aurez pas de questionnaire à la fin je vous rassure ^^

2. Quelle est la place du design dans un projet DBT (Digital Business Transformation) ?

Dans notre approche de transformation digitale au sein des entreprises, le design s’inscrit à la frontière des quatre piliers :

1/ Une organisation avec une base agile

Les méthodes agiles permettent d’installer une nouvelle organisation de travail adaptée au client, qui sera amené à être améliorée en permanence pour créer une structure solide et viable.

2/ L’utilisation de moyens digitaux

De bonnes pratiques digitales doivent être embrassées par chacun afin de trouver le juste équilibre entre stratégie, besoins des utilisateurs et production, afin d’instaurer une bon esprit d’équipe au sein d’un projet en constante évolution.

3/ Une collaboration totale

La collaboration au travers des différentes structures, peu importe le type d’organisation, cela passe par la confiance et la bienveillance de chacun.

4/ Une volonté de dessiner le futur

Et enfin, la volonté de conceptualiser le future grâce à des solutions génératives. Réfléchir à la façon dont nous pouvons assumer la prochaine vague de transformation et systématiser des composants afin de créer une conception solide et durable. Le design vient ainsi transformer et accompagner le changement au sein même de l’entreprise.

3. L’exemple du projet One Carrefour

Je vais vous remettre un peu de contexte en prenant comme exemple le projet Carrefour…

Il y a eu d’abord une volonté de la part d’Alexandre Bompard quand il a été nommé à la tête de Carrefour, d’investir dans le digital. Il a donné un impact sur la manière dont il voulait diriger Carrefour, parce qu’il y avait un grand enjeu : celui de combattre Amazon (ou en tout cas essayer de répondre au fait qu’Amazon gagnait de plus en plus de terrain). Et donc, il a été décidé après une phase préparatoire avec toute la partie management de créer un projet qui s’appellerait « One Carrefour« . Ce serait un plateau constitué d’experts du monde entier, afin de créer un MVP (Minimum Viable Product) en seulement 6 mois.

C’était 280 personnes avec 27 expertises et 32 nationalités, sachant que l’anglais était la langue qui était parlée sur le plateau. Et tout ça s’est transformé pendant 6 mois en 1830 meetings, 1989 user stories, 200 000 lignes de codes, 6 démos et 8 sprints. C’est pour vous donner une indication de l’ampleur du plateau, de tout ce que ça comportait en termes d’interactions aussi bien humaines que d’expertises. Et ce fut vraiment la richesse de ce projet, aussi bien sur le plan humain que sur le plan professionnel.

4. Quels rôles sont fondamentaux pour une équipe de création ?

Il n’est pas toujours facile de bien différencier les différents rôles d’une équipe créative au sein de la DBT (Digital Business Transformation). Du coup je vais revenir sur ces trois profils principaux, il en existe d’autres, mais au sein de Carrefour, ce sont ceux que l’on a utilisé :

Le premier, c’est l’UX Researcher : c’est la personne qui a comme objectif de dresser un portrait des utilisateurs et comprendre leurs besoins, leurs envies, par le biais d’entretien, de focus group et de test utilisateurs. Normalement toute l’équipe devrait connaitre son utilisateur final, échanger avec lui et découvrir comment il interagit avec le produit. Mais comme ce n’est pas possible, c’est grâce à l’UX Researcher qu’on peut avoir cette notion des moyens de consommation des utilisateurs.

Ensuite, c’est le profil de l’UX designer : il est là pour s’assurer que le produit offre la meilleure expérience en terme d’ergonomie et de visibilité. Il doit créer des parcours afin que tout se passe bien de A à Z pour l’utilisateur, puis il se penche sur le squelette de chaque écran, ce que l’on appelle des wireframes. Il réfléchit à l’expérience digitale du produit.

Et le dernier profil, c’est l’UI Designer : il réalise toute la partie visuelle de l’interface. Il fait le lien entre l’utilisateur et le produit final. Son travail consiste à donner vie aux wireframes en prenant en compte à la fois le côté esthétique et fonctionnel, tout en s’assurant qu’il transmette les valeurs de la marque.

5. Design workflow dans une DBT

Pour vous expliquer comment tout ce petit monde s’organise pour travailler ensemble, je vais vous montrer un exemple concret :

1/8. Au début, il y a un ticket Jira

Comme nos équipes travaillent en agile, ça commence toujours de la même façon : d’abord il y a un PI planning qui permet de décider des nouvelles fonctionnalités à prioriser durant les 3 prochains mois. On les ajoute dans le backlog pour les redistribuer aux features team sur les différents sprints à venir. On fait d’abord appelle à l’UX puis à l’UI, et s’il s’agit d’un gros sujet qui a besoin de beaucoup plus d’insights et de recherches, on fait appelle aux UX Researcher en amont.

2/8. Comprendre les besoins des utilisateurs

Le PI planning a permis de prioriser les besoins business, mais à cette étape, on tente de comprendre si les besoins sont en accord avec les besoins des utilisateurs et faisable techniquement avec les architectes. C’est grâce à la data des UX Researchers ainsi que de leurs entretiens avec les utilisateurs que l’on va obtenir des prises de positions solides.

3/8. Du macro au micro

L’étape suivante sera d’entamer les conversations le plus rapidement possible avec toutes les parties prenantes du sujet. Car dans le cas d’un gros sujet, il va y avoir beaucoup d’impacts et de contraintes. On va élaborer un workflow afin de le faire valider par tous et voir s’il n’y a pas de points bloquants ou de données manquantes. À cette étape là, c’est le travail commun de la stratégie, des développeurs, des UX designers et des architectes.

4/8. Le temps de penser aux détails

Une fois le workflow validé, on va passer aux détails des écrans, appelés les wireframes. On comprend bien la relation entres les métiers : ce n’est pas seulement le travail d’une seule personne, plus les échanges vont commencer en amont avec toutes les parties prenantes, plus le projet découlera simplement et sans accros jusqu’à la fin du parcours. Ici, on échange beaucoup avec les UI et les développeurs.

5/8. Tester nos hypothèses

À présent, c’est le moment de valider notre idée, parce que jusqu’ici, ce ne sont que des hypothèses. On va enfin pouvoir tester avec de véritables utilisateurs afin de valider, rectifier ou infirmer nos idées. Les UX et les UI créent des prototypes réalistes afin que les utilisateurs puissent se projeter dans un cas d’usage concret du site. Il ne s’agira que de maquettes animées au clics afin de ne pas faire perdre de temps aux développeurs inutilement.

6/8. Le design de l’interface

Prochaine étape, la partie UI. Il s’agit justement de concevoir l’interface finale à l’aide du design system. C’est le travail des UI (avec un peu de soutien UX), mais c’est surtout énormément d’échanges avec les développeurs, pour les onboarder correctement et s’assurer de réutiliser les composants et les animations existantes du design system. Mais cela ne s’arrête pas là, il va falloir penser à tous les écrans en responsive et créer une documentation détaillée.

7/8. Dév ready

Finalement, on est prêt à lancer en développement une fois que tout est approuvé. On continue à avoir les UX et les UI dans les conversations, parce qu’on sait comment ça marche, les demandes changent, les deadlines changent, ou bien on nous demande de petites retouches de dernière minute…

8/8. Continuous improvement

Ce qu’on vient de développer ne reste pas figé. Il va tout d’abord falloir effectuer un recettage pour corriger les bugs techniques à l’aide des QA, et la cohérence graphique avec les UI. Mais il y aura surtout une amélioration continue qui va se faire, ce qui est une fondation de la méthode agile et safe.

6. Design Ops, l’organisation chez les designers

C’est un terme qui s’est vulgarisé en 2017 chez Airbnb, quand ils ont créé leur Design Langage System, peut être que certains d’entre vous en ont déjà entendu parler, mais vous connaissez certainement plus le terme Dév Ops. En tout cas, la démarche et l’état d’esprit est similaire, mais cette fois ci, elle est appliquée au design et à l’expérience.

Design Operations : une démarche, mais aussi un état d’esprit, qui peut être porté par une personne ou une équipe complète, qui va s’occuper d’intégrer et de rationaliser l’ensemble du process de design au sein d’une entreprise. C’est aussi réfléchir à la manière dont on va travailler avec les autres, toujours en ayant pour objectif d’optimiser la production en réduisant au maximum les points de friction.

La finalité, c’est vraiment de générer un produit de haute qualité tout en prenant en compte l’évolution des besoins des utilisateurs. La démarche va s’articuler autour de 4 piliers qui sont : la coordination de l’équipe, les processus, les outils et enfin la culture du design.

1/ Un MVP sur 10 sprints : le design orienté production

La première phase du projet, c’était le MVP (Minimum Viable Product). Elle a été vraiment très intense sur le projet Carrefour, où il a fallu délivrer beaucoup en peu de temps. Les équipes avaient été réparties en feature team, composées à chaque fois d’un PO, d’un scrum master, de quelques développeurs et toujours d’un binôme UX / UI. C’était une configuration d’équipe très orientées production. Le but étant d’avoir des créatifs ultra spécialisés sur une fonctionnalité.

L’objectif étant de construire un esprit d’équipe fort, une grande solidarité et une bonne communication entre tous les membres d’une même feature team. Tout cela a été facilité par les valeurs de l’agilité. En terme de workflow, du côté design, on avait toujours un sprint d’avance sur les développeurs, ce qui nous permettait d’avoir un minimum de flexibilité, de pouvoir mieux cadrer les sujets et de faire en sorte que les développeurs ne soient jamais en attente de maquette.

La factorisation des designs a été plutôt limitée sur cette phase de MVP. Dans cette configuration d’équipe, on n’avait pas forcément le temps pour automatiser. Du coup, c’était assez difficile de prendre du recul sur notre travail.

Pour les développeurs, on a utilisé Zeplin, une plateforme qui nous permettait de copier nos fichiers sketch et où ils pouvaient venir inspecter chaque élément graphique pour en extraire les propriétés CSS. Pour les PO, on utilisait plutôt Invision qui était plus simple d’utilisation. En ce qui concerne les livrables, ça a toujours été un gros chantier que l’on a essayé d’optimiser tout au long du projet. Pour cette première phase de MVP, il y avait donc beaucoup de débrouille, mais tout le monde se serrer les coudes et était dans la même dynamique.

2/ Stabilisation du MVP : Creative QA et Quick fix

C’est durant cette phase que le Design Ops va vraiment commencer à se matérialiser. On va démarrer par beaucoup de Creative QA (recettage graphique). Ce MVP est sorti en seulement 6 mois, et tout n’était pas forcément très propre, il va donc falloir faire une repasse sur l’ensemble de ce qui a été livré. Ce site a été utilisé par un premier groupe d’utilisateurs, et quotidiennement on va nous redescendre pas mal de problématiques rapides à résoudre ainsi que des verbatims qui vont nous permettre de concevoir une première version de Carrefour.fr plus viable.

À partir de là, on va sortir les designers des features team, car dans cette configuration, on manquait de coordination entres nous. On va aussi s’apercevoir qu’il y a des manquements dans certains parcours et dans l’expérience globale.

Le fait d’avoir conservé les designers dans les feature team a créé une dette graphique, mais aussi technique. Donc à ce stade, ils doivent se regrouper. Ils vont pouvoir s’aligner davantage, communiquer et se construire des connaissances plus larges, plus globale, des besoins environnants. En tant qu’UI designer, je vais connaître les sujets des autres UI, et je vais être capable de me dire « peut être que ce que je suis en train de faire aura une dépendance avec ce que mon collègue est en train de faire, ou aura un impact sur le travail d’un autre ».

On va donc commencer à co-construire à l’intérieur de notre équipe. Nous allons grandir et il va falloir aussi gérer toutes les arrivées en cascade avec des phases d’onboarding des nouveaux arrivants, tout en essayant de continuer à construire ces binômes UX / UI à l’intérieur de l’équipe.

On n’a pas encore de Scrum Master dédié à l’équipe design, mais on obtient de l’aide de temps en temps. On s’organise donc autour d’un premier tableau Kanban papier avec des Post-it. C’est assez rudimentaire, mais ça nous permet déjà de garder une vision globale, une cohérence visuelle industrialisée et de gagner du temps sur les prochains sprints.

On peut parler également de centralisation des fichiers design. On a utilisé Abstract, qui est un premier moyen de rassembler tous nos fichiers Sketch et de les partager à l’ensemble de l’équipe (Sketch n’était pas très élaboré à l’époque, ce qui n’est plus le cas maintenant avec Figma qui fait vraiment le job). Les UI vont être aussi beaucoup plus impliqués en amont dans les recherches UX. Les compétences et les réflexions vont se croiser davantage et chaque rôle va être en mesure de comprendre ce qui se passe en amont et en aval de son travail.

Donc, en tant que UI, si j’ai la connaissance en amont, je peux gagner du temps dans ma conception. Et idem en aval si je connais les contraintes techniques côté développeurs, je ne vais pas partir dans des hypothèses de design qui ne seront pas faisables.

3/ Accélération : New features

L’équipe commence a bien se structurer. On commence à parler le même langage. On gagne en souplesse et en agilité. Cette troisième phase du projet est une phase d’accélération. C’est vraiment une phase dans la continuité de la précédente. On va consolider certaines choses, on va en améliorer d’autres, on va tester et on va se planter, mais à présent on sera tous dans le même état d’esprit.

L’équipe sera de plus en plus transversale et aussi impliquée dans la stratégie du développement du produit. Ce qui va faciliter aussi le développement des nouvelles fonctionnalités. Après de son côté, Carrefour va constituer sa propre équipe expérience en interne en vue de notre départ. On va aussi avoir une grosse phase d’onboarding des nouveaux arrivants sur tous les process mis en place jusqu’ici.

Cette fois-ci, on va avoir une scrum master dédiée, qui va nous aider à gagner en autonomie, mais aussi à nous améliorer en permanence. On a notre tableau Jira maintenant, qui structure bien les différentes phases de vie des tickets. On récupère bien maintenant des besoins de la part des PO et non des solutions toutes faites comme ça pouvait être fait en MVP pour aller plus rapidement. Notre Jira va devenir un espace dédié où l’on va pouvoir mieux qualifier, mieux quantifier et mieux distribuer les tâches au sein de l’équipe.

Un petit détail (mais qui a vraiment son importance dans la diffusion de la culture du design sur le plateau) : c’était l’impression des screenflows. Les parcours vont être imprimés sur des grands formats papier et affichés sur les murs, ce qui va vraiment faciliter les échanges entre les parties et permettre aussi de gagner beaucoup de temps. On va mettre en place systématiquement des reviews UX et UI sur un grand écran tactile. Chaque designer va être encouragé à partager son travail avec le reste de l’équipe, puis par la suite avec les PO et les développeurs. Ces petites reviews timeboxées permettaient vraiment de gagner un temps fou en conception, d’avoir des échanges très rapides et on ressortait avec beaucoup de matière pour avancer.

Ces design reviews vont vraiment contribuer à la diffusion de la connaissance et de la culture du design, au même titre que les screenflows. On va avoir une approche de plus en plus user centric avec beaucoup de tests utilisateurs que l’on va pouvoir les visionner en direct. On aura des comptes rendus très complet des User researchers ce qui va nous donner matière à travailler. Il y aura également un point hebdomadaire avec la data pour obtenir des informations sur les comportements et les bloquants des utilisateurs, ce qui va venir nourrir et alimenter nos réflexions.

Donc, on a bien vu l’évolution de la place du design au sein du projet Carrefour entre la phase de conception du MVP et le moment ou l’on va quitter le projet à l’automne 2019. On a construit un produit et on a aussi co-construit la place du design et sa culture chez Carrefour.

7. Le design system

Un ensemble vivant de composants, de patterns et de principes intégrés, partagés et rationalisés, qui définissent le design global d’un produit.

A présent, on va pouvoir matérialiser tous ces principes et les choses qu’on a pu expérimenter. On va les concrétiser et les rendre plus solides et pérennes. L’idée qu’on a eu par rapport à l’usage de cette méthodologie, c’est d’amener une stratégie du changement et essayer d’optimiser la manière de construire les choses. Ca veut dire qu’on ne va pas tout casser pour reconstruire mais réutiliser ce qui est existant, rationaliser le design au niveau de sa construction.

Cela repose sur cinq piliers qui vont être : des composants, des guidelines, des bonnes pratiques, des livrables, des outils et tout cela sera englobés dans des process qui vont être repensé pour être plus souple et évolutif.

1/ Pourquoi l’implémenter ?

On a voulu passer d’un système de production un peu artisanal où tout était siloté, très contextualisé dans des feature team, à de la production industrielle ou l’on va pouvoir automatiser les process. Accélérer, délivrer et surtout réutiliser les composants pour ne plus que ce soit du prêt à jeter ou pensé de manière trop contextuelle. Ici l’idée c’est de gagner en qualité et en quantité.

Cela va nous permettre de réduire la complexité avec ce qu’on appelle une source de vérité. Ça veut dire qu’au lieu d’avoir plusieurs variations, on va avoir un seul référentiel qui va être le fichier design system sur Figma, l’outil qu’on utilise à présent, mais pour les développeurs cela va être Storybook.

L’idée c’est d’être souple, pérenne et évolutif et on essaye de voir sur le long terme. D’autant que ce produit sera géré par le client. C’est lui qui va continuer cette histoire sans nous. Donc l’idée c’est de reconnecter les différents savoir faire afin de créer plus d’émulation et de ramener de la vision.

2/ Comment le mettre en place ?

En arrivant sur cette masse de dette graphique et technique, on va venir collecter, pour pouvoir comprendre, questionner, nous aligner ensemble pour évidemment transformer, mais surtout pour évoluer, parce que ça veut dire que le design system est toujours en perpétuelle mutation. Ce n’est pas juste un outil qui va rester figé, mais au contraire, qui va vraiment permettre de rester pérenne dans le temps. Toujours basé sur les 5 piliers : composants, livrables, guidelines, outils et process. Tout ce qui va être guidelines, outils et process viennent entourer les composants. Mais c’est vraiment ce qui va permettre de mettre de l’huile dans les rouages et faire que tout s’enchaîne correctement ensuite. On est parti sur l’idée de l’Atomic Design qui est un principe de construction modulaire. L’idée c’est de décomposer les éléments du plus petit au plus grand, les référencer et mieux les organiser avec les développeurs.

On aura toujours le même élément qui a été pensé, délivré et qui sera construit au même endroit. Du coup, au niveau logistique, c’est bien plus simple et ça évite de faire des doublons.

3/ Les flops

Comme les développeurs sont une ressource rare, ils avaient très peu de temps pour implémenter les composants du design system et ce n’était jamais priorisée. Et qui dit peu de temps, dit pas de gouvernance, pas d’alignement et accumulation de dettes… Ça se complexifie au fur et à mesure. Et c’était toujours pareil. Du coup on a réussi à avoir un seul développeur dédié durant 1 mois pour développer les composants, c’était super. Mais un décalage avec ce qu’il y avait en production persistait puisqu’il n’y avait pas assez de monde pour les implémenter sur le site derrière. La dette des QA a donc explosé.

4/ Les tops

En résumé, c’était vraiment la communication. Nous avions une unique source de vérité sur laquelle on pouvait s’appuyer. Nous avions une base de discussion qui nous permettait de rationaliser et d’institutionaliser certains process, ce qui a créé un mouvement de bascule entre le quick and dirty à usage unique, vers plus de qualité et de de vision. Cela va également permettre un onboarding simplifié des nouveaux arrivants.

8. La philosophie

Suite à cette expérience chez Carrefour et à tous les autres projets DBT auquel nous avons pu participer, nous avons élaborer 6 grandes règles qui sont toujours valables aujourd’hui. Alors bien sûr, il ne s’agit pas de vous donner un manuel tout fait de pratiques à mettre en place nécessairement, mais juste de vous exposer ce qui a pu nous guider au travers de nos projets afin que cela puisse vous inspirer ou vous aider à résoudre certaines problématiques :

1/ La vision

On est tous dans le même bateau

C’est une vision commune qui pour nous est appelée One Carrefour. Elle a permis d’infuser une vision globale au sein des équipes : tous ensemble sur un même plateau, de pays différents avec des langues et cultures différentes, clients comme prestataires sont mélangées sans aucune distinction d’appartenance. L’ensemble du plateau a pu se créer une culture commune en s’alignant et en créant un échange de connaissances sans a priori. La vision était connue de tous car on avait régulièrement une communication devant toutes les équipes afin d’atteindre une intelligence collective sur le projet, ce qui apportait à chacun une grande implication et motivation pour mener son équipe au but.

2/ Le mindset

Finalement, tout commence par cela. Chacun de nous doit appliquer une certaine bienveillance et se mettre à la place de l’autre quand il s’exprime. Nous tentions de parler un langage accessible afin de faire monter en compétence notre interlocuteur. On essayait de toujours expliquer notre démarche afin que personne ne se sente exécutant, mais bien comme partie prenante du projet. Et cela va permettre à long terme de créer un rapport de confiance entre les différentes parties. Tous au même niveau, sans hiérarchie apparente, nous devions être à la fois organisés dans nos tâches, mais aussi en être responsables. Nous étions les garants d’un sujet qui va être notre combat durant tout le sprint et nous avons dû à la fois rassembler et diffuser les informations autour de celui ci.

3/ Team first

Seul on va plus vite, ensemble on va plus loin.

C’était finalement le leitmotiv durant toute notre collaboration. Nous essayions sans cesse d’impliquer, de communiquer, de partager aux différents acteurs du projet pour collecter du feedback et faire constamment évoluer et roder les discours, pour que tout le monde puisse porter les décisions et les intentions au sein des équipes. Et à l’échelle du studio, on essayait de porter la voix de sa feature team puisque même en équipe design, nous étions toujours référent d’une certaine feature team afin de porter la voix de celle-ci et de porter les préoccupations du PO. Et plus nous partagions nos idées à l’équipe, plus le résultat de notre travail devenait solide avec une approbation collective et unanime. Les connaissances de chacun étaient complémentaires et venaient alimenter la vision pour prendre les meilleures décisions à l’instant T. Donc, là où nous pensions parfois perdre du temps en présentations et délibérations, il se trouve qu’on en gagnait énormément par la suite. Plus de retours a posteriori, que ce soit du PO ou des développeurs, à cause de problématiques techniques ou de choix stratégiques.

4/ Baby steps

On avance un pas après l’autre. Il était primordial, dès notre arrivée sur le projet, d’être à l’écoute du client et de son historique. On a eu beaucoup de choses à apprendre, il fallait écouter hypothèses et arguments. Mais il ne fallait surtout pas avoir peur de poser des questions bêtes ou de faire des erreurs, sans hésiter à tout remettre en question. Nous avons testé beaucoup, nous nous sommes plantés souvent, puis nous avons recommencé encore plus juste dans notre approche et sans intuition. Nous avons fait parler uniquement les résultats. Quand les PO avaient tendance à écrire des solutions toutes faites sur les tickets Jira, soit nous refusions de prendre le ticket, soit on le traité quand même, mais en général, ça nous donnait un résultat faussé, car orienté dans une certaine direction. Donc par la suite, nous avons réussi à mettre en place un brief type obligatoire lors du remplissage d’un ticket qui leur a permis de se focaliser uniquement sur le besoin.

5/ Pick your battle

Choisissez vos batailles avec sagesse…

Parfois, la volonté de changer les choses est très forte, mais la capacité à la mettre en pratique est encore plus forte. C’est toujours bon d’avoir une vision à long terme et un point de vue, mais dans les faits, vous allez surtout vous heurter à pas mal de murs, voire même avec la politique interne de l’entreprise. Nous avons donc appris à penser course à long terme. Accepter le fait que parfois, nous devions savoir lâcher prise sur certains sujets pour en gagner d’autres qui seront plus importants à nos yeux. Pour défendre nos convictions, nous nous sommes appuyés d’arguments solides, de chiffres et de résultats et nous avons réussi à créer un rapport de confiance avec nos PO. Nous attendions le bon moment et le bon niveau de maturité du projet. C’est surtout ça la plupart du temps. Et de plus en plus souvent, nous réussissons à les convaincre.

6/ Community of pratice

C’est le fait d’embrasser le changement. Chaque projet est différent, on le sait. Et dans un projet DBT, on ne peut pas se permettre des réflexions du type « C’est comme cela que l’on fait les choses » ou bien « Nous avons toujours fait comme cela ». On ne peut pas se reposer sur ses acquis. Il va falloir jeter ses aprioris et prendre chaque obstacle comme une opportunité d’apprendre et finalement, de réapprendre et de nous adapter. Il faut toujours rester ouvert à ce défi et ne pas avoir peur de faire fausse route et de se remettre en question.

Donc, globalement, la manière la plus sûre d’être juste, c’est de connaître par coeur la vision de l’entreprise, d’être bienveillant et de se mettre à la place de la personne en face de vous (quel que soit le rôle que vous jouez dans le projet), de vous renseigner sur la personne qui utilisera le produit que vous êtes en train de concevoir, et avec cette perspective, votre projet DBT devrait être réussi.

Cet article a été rédigé en collaboration avec :