Donner une voix forte au design
Quelle est la place du design dans une organisation telle que SNCF Connect & Tech?
Comment donner une voix forte au design dans une culture Produit et Tech ?
Ce sont les sujets que nous avons abordé avec Julien Bouvet Head of Product Design chez SNCF Connect & Tech.
Dans la première partie de l’interview Julien a parlé de l’évolution du métier de designer et sa perception, du duo/ duel entre et de la théorie et la pratique du design et enfin de comment remettre le design au centre.
Ici nous allons aborder le pilotage collectif avec l’axe de la gouvernance entre les équipes et la vision en systèmes.
Pour l'écouter, c'est ici: https://podcast.ausha.co/pause-produit/la-pause-produit-julien-bouvet-sncf-connect-tech
Pilotage collectif au sein de SNCF Tech & Connect
PETER : Comment avez-vous créé ce pilotage collectif ? Avec le temps ?
JULIEN: Oui ! On le fait tout simplement en impliquant les personnes.
C'est à dire que quand on démarre un projet en conception, même ne serait-ce qu'en discovery, il faut absolument avoir par exemple du product management, mais aussi avoir de la tech.
C'est à dire que nous on a fait aussi une évolution des métiers tech l'année dernière avec l'introduction d'engineering manager. Ce sont des rôles-clés qui nous aident aussi à appuyer et les impliquer très tôt.
Les personnes qui sont dans les projets, la tête dans le guidon, n’ont pas toujours du temps.
Mais en isolant des personnes vraiment clés au sein de la tech, on peut les impliquer maintenant beaucoup plus facilement dans des réflexions de fond.
Travailler avec les architectes aussi.
Je pense que les designers ne se rendent pas compte à quel point on a les mêmes feuilles de route, les mêmes intérêts, les mêmes enjeux de projections dans le futur.
C'est à dire qu'aujourd'hui, notre rôle au-delà de la production même de parcours, c'est vraiment une traduction de la stratégie dans des effets tactiques qui sont donc soit ici côté urba, soit vraiment expérientiel côté design.
Et généralement, il y a beaucoup de porosité. Donc vraiment d'arriver à intégrer ça, dans les réflexions, se mêler aussi des sujets des autres, s'intéresser.
En tant que designer, je sais qu'on passe parfois beaucoup de temps à dire qu'on n'est pas compris. Mais il faut prendre du temps aussi pour comprendre les autres.
Il n'y a pas cinquante moyens d’y arriver : Il faut être présent. Il faut être avec les personnes.
Alors ça ne veut pas forcément dire être tout le temps sur le bench, tout le temps dans les DSM.
Mais par contre, se dire : je m'intéresse aux activités, je parle aux personnes, je lis la documentation, je n’ai pas peur des logigrammes.
Rentrer dans des choses un peu dures qui sont clés. C'est à dire qu'on ne peut pas faire une bonne expérience si on ne comprend pas ce qui se passe dans l'esprit de quelqu'un qui est lead tech ou de quelqu’un qui gère le produit.
PETER: Est-ce que derrière, vous êtes parti en disant: "On va se créer un framework. On va partir sur des cas d'usage ..." ?
JULIEN :
Alors ça c'est une approche qui est un peu personnelle : je ne veux pas trop regarder sur l'étagère. Par contre, arriver à prendre les objets, prendre les legos, les casser, regarder les pièces qui sont terre, pour dire "finalement je vais prendre tel et tel élément". C'est juste qu'on a décidé assez tôt.
Lorsqu'on a construit l'équipe actuelle à l'occasion de SNCF Connect, on était relativement peu. C'est à dire que globalement, il y avait moi, un lead UX, un lead UY. On a commencé à se poser autour de ça et on a regardé un petit peu, finalement c'est quoi les retours de rétro qu'on faisait au niveau design. C'est -à -dire qu'à l'époque on avait pas mal de produits sur lesquels on travaillait.
Il y avait des gens qui travaillaient sur oui SNCF, mais il y avait aussi des gens qui travaillaient pour l'assistance SNCF. Les activités externes existaient déjà. On travaillait déjà pour le groupe SNCF.
Et on a regardé un petit peu les choses qu'on attendait nous, les choses aussi qu'on avait connues.
On a globalement la chance d'avoir une équipe design qui a été très imprégnée d'agile. Moi ça fait 14ans que je travaille là-dedans.
On a pu voir des méthodes. On a pu tester le kanban, le scrum, etc.
On a regardé un petit peu, finalement : Puisque ça marche pour les devs, pourquoi ça ne marcherait pas pour nous ? On a commencé à démanteler tous ces morceaux-là.
Par contre, ce qu'on a fait, pour répondre à la question, on n'a pas pris quelque chose de tout fait.
On s’est demandé : Aujourd'hui, quels sont les sujets? Quels sont nos premiers problèmes ?
Et on en a fait un à la fois.
On a commencé tout bêtement au début de dire "Il faut un board" (mais au début, un board c’est juste des post-it sur un mur). Il ne fallait pas prendre des enjeux de malades dessus.
Petit à petit, on a commencé à structurer: « Bon, très bien. Maintenant, on arrive à gérer. Reprenons finalement les notions d'estimation, parce qu'on a besoin de quantifier notre travail. »
Donc on a commencé à regarder ça. Et puis une fois qu'on a ça : « Mais maintenant, comment peut-on être rigoureux ? Comment peut-on garantir la qualité de nos productions ? »
Il y a un truc qui s'appelle la définition de fini. On a été reprendre ça et on a appliqué nos critères design à la place. Ça s'est construit vraiment par accrétion.
Donc c'est vrai qu'aujourd'hui, on est vu en interne comme une grosse machine de guerre, mais en fait, elle ne s'est pas faite toute seule. C'est-à-dire que ce serait à refaire, on n'arriverait pas avec quelque chose de tout fait. On regarderait déjà aussi les personnes, parce que c’est aussi une question d'affinité.
Qui sont les gens autour de la table ? Est-ce qu'on a envie de le faire ensemble ? Et à partir de là, on commence par quoi ?
Et vraiment, pas forcément reprendre des choses toutes faites. Regarder les frameworks, c'est bien. C'est un peu comme le "benchmark".C'est important de regarder. C'est important de s'y intéresser.
Il faut bien se dire que ce qu'on regarde, c'est forcément imparfait. Et peut-être qu'on peut y apporter des twists qui nous sont propres.
PETER : Oui, c'est ça. Et puis ça revient à ce qu'on disait au début: la théorie & la pratique. Jusqu'à où elle est adaptée à notre contexte ou pas. Et qu'est-ce qu'on en fait ?
Dans cette transformation, est-ce qu’il y a eu des trucs qui t'ont marqué où tu t‘es dit : "Vraiment,à refaire ça on ne le fera jamais".
JULIEN : Jamais, je ne sais pas. Mais des échecs, il y en a plein. C'est littéralement du Test & Learn. A partir du moment où on considère le design littéralement comme du produit, on va appliquer les mêmes règles. Donc à partir de là, oui, forcément, il y a des choses qu'on essaie qui ne marchent pas.
Typiquement, ce que je disais tout à l'heure sur la création de collectifs trop vite.Ce plan de migration qu'on aurait dû faire, prendre le temps de discuter plus avec le product management. Maintenant, ça fonctionne bien. Mais ça a créé des incompréhensions. Ces incompréhensions créent une image qui n'est pas forcément la bonne.
C'est-à-dire que finalement la production est faite, mais est-ce que vraiment on a bien interagi ensemble ? Donc ce sont des choses comme ça. Ça peut être aussi des choix.
Par exemple, au tout début, on faisait des estimations.
Puis très naïvement, on reprend Fibonacci. On a fait nos fameux 5, 8, 13 ect.
Et au tout début, il y a eu une période où on commençait à faire de gros tickets. SNCF Connect est quand même sorti avec 150 fonctionnalités dès le premier jour. Donc c'est comme une énorme machine qui arrive tout de suite. Et on faisait des estimations qui étaient très grosses.
Donc on avait d'énormes tickets. Mais en fait, on perd des gens pendant deux semaines.
On se dit : « ça ne marche pas en fait. »
Parce qu'on perd en contrôle, on perd en visibilité, on perd en reporting aussi.
Quand on a besoin de dire aux autres : où est-ce qu'on en est ? Finalement, on n’est pas capable de le faire. Et je sais que maintenant, même si on ne l'a pas écrit dans une documentation, c'est une espèce de règle tacite: si on atteint 8, on sait qu'on doit redécouper.
Généralement, aujourd'hui, on a des niveaux où on se dit qu’on ne peut pas bloquer une personne plus d'une semaine sur un sujet. Si c'est plus d'une semaine, c'est certainement qu'on a mal découpé le sujet. Donc on essaie de retravailler le produit, mettre un jalon plus petit, etc.
Gouvernance entre les équipes
PETER : Puisque tu commences à en parler : Comment aujourd'hui, est-ce qu'il y a une gouvernance qui est claire entre les équipes, le projet ? Comment tu y arrives ?
JULIEN : La gouvernance est relativement claire.
C'est à dire que nous, on a deux modes de fonctionnement qui sont les projets. Comme je le disais, on a plusieurs activités. Donc forcément, les activités n'appellent pas toujours la même gouvernance.
On a l'activité classique un peu feature team.
Aujourd'hui, on a des gens qui interviennent sur des projets et sont littéralement confiés au projet. C'est-à-dire qu'on les met littéralement avec le product owner. Et donc finalement, c'est un mode très classique qui a ses avantages.
Il y a aussi ses inconvénients, forcément, mais qui répondent à des besoins très spécifiques.
Et à côté de la partie plutôt Connect, donc là, plutôt en mode très collectif, on a vraiment un pilotage très centralisé. Mais on a essayé de le faire le plus transparent possible. Je donne un exemple, parce que typiquement, dans ce cas je n'étais pas sûr au tout début.
Finalement, on voit la vertu aujourd'hui. Ma propre réunion d'équipe est ouverte.
C'est à dire qu'aujourd'hui, on a du développeur, du product management qui passe une tête.
PETER : Quand tu dis ouverte, c'est-à-dire que tout le monde peut entrer ?
JULIEN: C'est-à-dire que tout est ouvert. Il y a un lien de connexion. Les gens se mettent dessus voire interviennent pendant la réunion. Et en fait, c'est pour cette histoire, on a vraiment vocation de limiter notre temps de réunion. Plutôt que de faire une réunion d'équipe classique, on a fait le choix de dire : On va faire une réunion. On va faire les validations et les design critics simultanément.
Parce que finalement, que ce soit moi ou les designers, ça reste la même chose.
Est ce qu'on est d'accord, pas d'accord ? Est-ce que ça respecte le design system, les principes expérientiels, etc. ?
Et c'est une réunion où on le rend transparent.
Typiquement, cette gouvernance-là, elle permet d'avancer en plein jour. C'est-à-dire qu'il n'y a pas de choses qu'on ferait en disant : "Zut, qu'est-ce qui s'est passé ?"
Ce pilotage centralisé permet aussi d'aller plus vite. C'est tout bête, quand on a plein de projets, quand on isole les équipes, forcément, le flux de travail n'est jamais continu. Il y a forcément une équipe qui met un peu plus sous pression qu'une autre.
Nous, cette gestion collective nous permet aussi de contrebalancer ces effets-là. Quand on sent quelqu'un en difficulté, on n'hésite pas à remettre des ressources en plus. Quand quelqu'un est disponible, cette personne se rend disponible pour les autres. On avance avec cette notion un peu organique. Et ça, ça se fait aussi en visibilité.
C'est qu'aujourd'hui, quand on suit la traçabilité (je pense que je vais en faire hurler plus d'un) on utilise Jira. Parce qu'on peut se rendre dans la même source de vérité que la tech.
Donc on utilise Jira. On en tire beaucoup de profits. Et on peut suivre qui intervient dessus.
On note ce qui est fait, qui porte le sujet, avec qui et les produits qui interviennent dessus.
Donc il y a vraiment ces notions de rendre traçable, rendre visible, ne pas hésiter à archiver.
Besoin d’un coup de main pour créer ton porfolio, notre porfolio maker en accès libre est ici
Penser collectif mais aussi systèmes
PETER : Est-ce qu'aujourd'hui, tu es le seul à avoir cette approche transparente sur la partie des ou le produit, la tech. ? Je pense qu'il faut qu'on en revienne aussi au collectif parce que c'est un mot qui me touche directement. Ce qu'on met derrière le collectif, ce que ça veut dire.
Mais est-ce que ça a eu des répercussions ?
JULIEN : On est regardés. On a ce genre d'échanges. Aujourd'hui, ce n'est pas forcément un choix qui a été fait et qui se respecte aussi pour une simple raison. Ce n'est pas parce que ça fonctionne pour nous que ça fonctionnera pour nos activités.On n'a pas de rôle de prosélyte dessus.Au sein du design. C'est à dire que lorsqu'on parle de notre modèle, on n'arrive pas en disant, "Notre modèle est forcément meilleur." On est très fiers de ce qu'on a fait, forcément. On aime en parler. On aime expliquer ce qui nous rend différent sur le marché français voire européen par rapport à d'autres acteurs.
Pour autant, je pense qu'il y a un grand rapport d'humilité dessus. Donc si à un moment des personnes sont amenées à s'intéresser à ça, il vaut mieux les laisser venir de manière très organique dessus. Aujourd'hui, ces entraides, nous, on essaie un peu de pousser plus pour des gestions de... Typiquement, les sujets d'amélioration continue.
C'est-à-dire qu'on a des projets qui sont très vastes. C'est peut-être le seul endroit où on dit, "Peut-être qu'il y a quelque chose à jouer."
Chez nous, au niveau du product management, ces notions de solidarité existent. Elles sont différentes, elles sont formalisées de manière un peu plus particulière, mais elles existent. Donc typiquement, un sujet, on sait qu'il y a des product managers qui font ce travail-là, justement, d'organiser ce rapport organique au reste de la structure. Et de la dire, justement, on en a créé un framework, on en a fait un DOM et on l'impose à tout le monde. Non.
PETER: Non, je comprends. Je ne voyais pas comme : on impose.
C'est cool. C'est créer une certaine émulation avec d'autres équipes, parce qu'on voit les vertus de ça, dans cette notion de partage, d'implication, d'un maximum, rassembler les gens autour du produit concret.
JULIEN : Après, il faut aussi expliquer, ça prend du temps. C'est à dire que quand on prend l'entreprise Connect&Tech, il ne faut pas oublier que la sortie de Connect a été tumultueuse. On avait d'autres préoccupations. Par les frameworks, on avait besoin de soigner le produit, ajouter des fonctionnalités manquantes, etc. Donc vraiment, on était plus focus dessus.
Ce sont des discussions qu'on commence à avoir parfois.
Mais encore une fois, je ne m'attends pas à ce que si demain, on utilise un peu la même philosophie dans d'autres métiers, qu'on arrive au même résultat. Je pense qu'il ne faut pas arriver en disant : «C'est l'outil qui fait l'artisan ».
Je pense qu'à un moment, il faut se dire : peut-être qu'il y a d'autres réponses.
Par exemple, si on se dit, on fait le même modèle sur Tech, très bien. Mais quelles sont les spécificités dans ce cas-là ?
Et je pense qu’en parler, exposer, passer du temps… Je sais que nous, on commence à mettre en place aussi des problèmes d'accompagnement.Il y des personnes d'autres services qui veulent venir voir comment on travaille. Ils passent une journée avec nous.
Et a contrario, on fait la même chose. On a envoyé des personnes passer une demi-journée, une journée avec le service. C'est juste qu'historiquement, ça existe. C'est le « vis ma vie » : c'est une chose très connue dans le monde de la Tech. Mais on se dit, c'est une bonne occasion aussi de montrer comment on travaille, d'approcher les personnes.
C'est vrai que les vertus que l'on voit aujourd'hui pour faire un peu « marque employeur ».
C'est vrai que notre fierté, c'est que les personnes qui sont parties de l'équipe ces dernières années aujourd'hui reviennent. C'est à dire qu'on a beaucoup de recrutements, c'est des anciens qui reviennent.
PETER : C'est un très bon marqueur.
JULIEN: C'est un peu une fierté qu'on a : les gens sont contents d'être avec nous et de faire partie d'un collectif.
PETER : Et entre le moment où ils partent et où ils reviennent, est-ce qu'ils voient du changement? Est-ce qu'il y a cette notion de dire : ça a encore évolué dans le bon sens ?
JULIEN : J’ose croire que oui. Mais, je pense que c'est très subjectif de ma part. Maintenant, ce qu'ils voient, c'est aussi qu’on a continué à grandir. C'est qu'une équipe qui était 5 et passée à 10, de 10 et passée à 20, 20, on est bientôt à 30.
Ils voient aussi la structure grandir. Il y a aussi cette résilience que l’on gagne. Et on parlait justement aussi d'équilibrage.
Typiquement, un choix qu'on a fait : on est passé à un modèle, on était vraiment en 100% transverse pour les équipes, et on est revenu sur quelque chose de beaucoup plus proche du product management.Ce sont des notions en fonction de l'univers.
C'est-à-dire qu'on crée des univers qui sont sur des grands ensembles expérientiels. On s'est raccroché à ce système-là.
Parce que même pour des designers, ce n'était pas toujours évident. Un designer peut avoir deux modes. Il a soit un mode très associé à un produit, très focus dessus, ou quelqu'un qui va plutôt penser en système.
L'enseignement, c'est que tout le monde ne pense pas en système. Il faut aussi raccrocher les gens sur un territoire qui est plus connu. Donc aujourd'hui, on en est là. C'est ça l'évolution.
Les personnes qui reviennent, c'est comme en musique, c'est l'album de la maturité.
PETER: C'est vrai que ça arrive toujours. Album de la maturité ou de la renaissance.
JULIEN: Exactement. On arrive effectivement toujours à ce niveau.
On est un grand public.
PETER : Oui. complètement. Mais ça marche bien, a priori.
La partie 2 de l’interview s’arrête ici, la troisième arrive très vite !
Pour recevoir la Pause Produit :
Inscrivez-vous ici ! La Pause Produit, c'est un article et un podcast par mois pour partager l'expérience et les challenges de Heads of Product, Design & Agile.
Besoin d’un coup de main pour créer ton porfolio, notre porfolio maker en accès libre est ici
