Donnez de Meilleurs Retours à Vos Collègues (avec Ryan Schaefer de Viget)

Lisez la transcription :

Nous essayons de transcrire nos podcasts à l’aide d’un logiciel. Merci de nous excuser pour d’éventuelles erreurs, le robot n’étant pas toujours exact à 100%.

Ben Aston :

Bienvenue dans le podcast DPM où nous allons au-delà de la théorie pour donner des conseils concrets pour mieux diriger des projets digitaux. Merci de nous écouter. Je suis Ben Aston, fondateur de The Digital Project Manager.

Alors, comment gérez-vous le fait de donner des retours aux membres de votre équipe ? L’accueillez-vous facilement parce que, eh bien, vous savez que vous avez raison, vous êtes chef de projet, ou l’évitez-vous car vous craignez de ne pas être pris au sérieux ? Peut-être recevez-vous des retours et pensez-vous que personne ne comprend réellement ou même n’écoute ce que vous avez dit, mais, en tant que chefs de projet, nous sommes responsables de la réussite du projet, ce qui est difficile lorsque nos équipes semblent souvent foncer tête baissée dans la mauvaise direction.

Vous découvrirez dans le podcast d’aujourd’hui quelques moyens simples pour donner des retours qui aideront vos équipes à livrer un meilleur travail et à garder vos projets sur la bonne voie.

Aujourd’hui, je suis accompagné de Ryan Schaefer. Ryan est passé de la conception et création de sites web à la gestion de leur développement, et il travaille à Washington DC dans une agence appelée Viget. Bonjour Ryan.

Ryan Schaefer :

Salut Ben. Merci de m’accueillir.

Ben Aston :

Super. Alors Ryan, raconte-nous un peu ton rôle actuel, et ce qui m’intéresse vraiment, c’est comment tu as fait cette transition du design/développement vers le chef de projet. C’est une question qu’on nous pose souvent. Qu’est-ce que tu fais aujourd’hui ? C’est du PM pur ou tu mets parfois encore un peu la main à la pâte ?

Ryan Schaefer :

Je dirais que c’est davantage du PM pur, mais ce qui a facilité ma transition, c’est d’avoir compris tous les raisonnements et processus qui interviennent dans la conception et le développement.

Du coup, ça me permet de discuter avec nos talentueux designers et développeurs sur un pied d’égalité, sans avoir à demander la signification des acronymes ou la nature des outils, des choses comme ça.

Mon expérience dans une ancienne agence RP sur un poste à double casquette — relation client et exécution — m’a préparé à réfléchir sur comment transmettre les choses à un client et comment collaborer avec le reste de l’équipe. Ça a été une transition assez naturelle pour moi vers du PM à grande échelle.

Ben Aston :

Mais comment cela s’est-il produit ? Quel a été le déclic qui t’a fait dire, « OK, j’y vais, je deviens PM » ?

Ryan Schaefer :

C’est un peu lié à l’envie de gérer depuis une vue d’ensemble plutôt que d’agir en vase clos, mais la raison principale est surtout que je voulais rejoindre une entreprise composée de passionnés du digital, à la pointe, car ça change clairement notre façon de vivre, et être entouré de personnes qui comprennent et valorisent ça, tout en étant experts dans leur domaine digital, c’était important pour moi. Cela allait m’aider à progresser professionnellement.

Ben Aston :

Super. Raconte-nous un peu ce que tu fais actuellement. Chez Viget, à quoi ressemble le rôle de PM ?

Ryan Schaefer :

Tout d’abord, c’est Viget (à prononcer « Vijet »). On nous pose souvent la question.

Ben Aston :

Vid-get ? Vig-et ?

Ryan Schaefer :

Viget, oui.

Ben Aston :

Tu sais, je suis même allé sur leur site et j’ai cliqué sur un chat qui disait que c’est Viget.

Ryan Schaefer :

Oui, il y a un bouton pour dire bonjour. C’est Viget.

Ben Aston :

Voilà ce qui arrive quand on a un nom original. Et ça veut dire quoi ?

Ryan Schaefer :

« Ensemble, nous prospérons », en latin.

Ben Aston :

Bien sûr.

Ryan Schaefer :

Quelque chose comme ça.

Ben Aston :

Ma mère aurait honte de moi. Maman, désolé. Elle est prof de latin. Je devrais savoir ça.

Ryan Schaefer :

Le latin était ma matière préférée au lycée — enfin, non, pas du tout. On était obligés de le prendre, c’est fou !

Ben Aston :

Bon, cela t’a bien préparé à toutes les langues que tu parles aujourd’hui, non ?

Ryan Schaefer :

Oui, exactement. Donc, mon rôle chez Viget en tant que PM recouvre beaucoup d’aspects différents. Il y a bien sûr les responsabilités cœur du PM — planning, budget, calendrier, staffing et ressources ; et aussi des aspects liés à la gestion de produit. Nous n’avons pas de chef de produit dédié, donc les PM s’occupent beaucoup des parcours utilisateurs, de la définition des fonctionnalités, des tests QA, de bien comprendre les entreprises et les produits qu’on doit livrer, de l’intérieur comme de l’extérieur.

Ben Aston :

Donc c’est de la gestion de projet et de produit ?

Ryan Schaefer :

Oui, c’est un —

Ben Aston :

Un mélange des deux.

Ryan Schaefer :

Oui. Les deux vont ensemble, c’est utile de les faire en même temps, mais ça reste suffisamment différent pour que ce soit intéressant de changer de rythme et de passer de la gestion à la réalisation.

Ben Aston :

Super. Peux-tu nous parler de projets sur lesquels tu travailles actuellement ?

Ryan Schaefer :

Bien sûr. Je viens justement de passer à temps plein sur un seul projet — ce qui ne m’était jamais arrivé — et il s’agit d’un grand site marketing ainsi qu’un portail destiné à divers groupes d’utilisateurs connectés, avec des données spécifiques pour chacun.

On refait tout l’écosystème, on met à jour le design de tous leurs supports digitaux, puis on travaille aussi sur une feuille de route pour de futurs produits comme une appli. C’est très prenant, je suis ravi de me plonger à fond sur un projet, d’apprendre tout dessus.

Ben Aston :

Tu vas justement intervenir bientôt au DPM Summit sur la gestion d’un projet de développement d’application native. Un avant-goût ? Qu’as-tu découvert concernant ces applis ?

Ryan Schaefer :

Oui, mon intervention va porter sur… En fait, je vais m’appuyer sur ce que j’ai appris lors du plus gros projet ici, à savoir le design et le développement d’une application Android.

J’aborderai ce que j’en ai retiré, principalement les différences entre la gestion d’un projet d’application native et celle d’une appli web courante, les bonnes pratiques, et puis aussi des points techniques dont le PM doit avoir conscience.

Quelques exemples : le coût d’échec est énorme sur une appli car en cas de bug, elle plante, alors qu’un site web se recharge. Aussi, les langages utilisés pour une appli native ne sont pas du tout les mêmes que ceux du web comme JavaScript. Il faut trouver 90% d’une solution contre 30 à 40% côté web, où JavaScript remplit le reste.

Il y a aussi plein de contraintes de système, comme l’utilisation hors-ligne. Comment l’appli fonctionne-t-elle sans connexion ? Que font les menus de votre téléphone, comment interagissent-ils ? Ce genre de problématiques.

Ben Aston :

À l’heure où beaucoup optent pour des apps web, quel est ton regard sur la tendance web vs app native ?

Ryan Schaefer :

On remarque de plus en plus de services comme Squarespace, les thèmes WordPress, Weebly etc. qui permettent à n’importe qui de créer un joli site avec peu de compétences techniques.

Du coup, il devient rare de faire de purs sites marketing. La création d‘applications natives n‘est pas encore accessible à ce point, donc il y a beaucoup de potentiel. Et puis, c’est sympa de dire « On a une appli » !

Ben Aston :

Oui.

Ryan Schaefer :

Mais il reste aussi beaucoup de produits ou logiciels inexplorés. Ce sur quoi je travaille actuellement, comme un portail utilisateurs, ce n’est pas vraiment possible avec Squarespace ou équivalent.

Cela apporte une grande capacité de personnalisation, c’est stimulant pour les designers/dev, mais il y a aussi matière à innover pour créer des produits d’entreprises toujours plus innovants.

Ben Aston :

Super. Et côté outils, qu’utilises-tu dans ta « boîte à outils PM » au début d’un projet ?

Ryan Schaefer :

J’aime bien organiser un kickoff client orienté discussion, faire un appel de vision, où l’on discute des objectifs, des problèmes, de l’état actuel de leur produit, mais aussi organiser des ateliers de problématisation, d’objectifs, d’interviews parties prenantes etc.

Toutes ces infos, impossibles à obtenir lors de la vente, sont cruciales pour bien cerner le contexte. Une fois ce diagnostic fait (qui peut prendre du temps !), on commence vraiment le projet armé de connaissances qui permettent d’être plus efficace et de livrer un meilleur produit.

Niveau outils : Airtable, évidemment GitHub Projects, Zen Hub, Trello. On a testé tout ça, en fonction des clients et de ce qu’on recommande.

Ben Aston :

Des outils PM magiques récemment découverts ? Astuces favorites ?

Ryan Schaefer :

Deux choses : je me suis penché sur les raccourcis clavier de mon ordi et il y en a tellement, ça fait gagner un temps fou à force. Même si c’est quelques secondes, multipliées des centaines de fois…

L’autre chose —

Ben Aston :

Ton raccourci préféré du moment ?

Ryan Schaefer :

Oh, commande-majuscule-T, pour rouvrir l’onglet fermé le plus récemment.

Ben Aston :

Pas mal !

Ryan Schaefer :

Il est vraiment utile.

Ben Aston :

Moi j’aime bien Windows-V sous Windows 10, qui affiche l’historique du presse-papiers.

Ryan Schaefer :

Wow !

Ben Aston :

Je suis du genre à écrire un truc, à le copier, puis à oublier de coller. L’historique, images comprises, c’est très utile. Alors, Windows-V et commande-maj-T, voilà votre astuce de la semaine !

Ryan Schaefer :

Ça c’est vraiment top.

Ben Aston :

Autre découverte ?

Ryan Schaefer :

L'outil qui a changé ma vie récemment c’est Notion. Tu connais ?

Ben Aston :

Oui.

Ryan Schaefer :

Une application workspace, pour prendre des notes, collaborer, gérer offline, interface super propre, pages imbriquées sans limite, appli web et mobile. Très personnalisable.

Ça me permet en réunion de noter vite fait et de remettre ça au propre tranquillement ensuite.

Ben Aston :

Avec tous ces projets et outils, qu’est-ce que tu trouves difficile dans ton job ? Quelles sont les vraies difficultés au quotidien ?

Ryan Schaefer :

Beaucoup de choses ! Déjà, le manque de temps. Mais le plus dur, c’est le passage d’un contexte à l’autre.

Sur plusieurs projets à la fois, beaucoup de réunions à enchaîner, il faut être capable de changer de contexte instantanément. Je m’aide par une prise de notes très rigoureuse et en faisant une fiche pour chaque réunion. J’aime aussi prendre le temps le matin, café à la main, pour faire un point sur chaque projet : où il en est, où il doit aller. C’est une habitude à peaufiner mais c’est essentiel.

Autre enjeu : faciliter la collaboration, surtout dans la transmission entre design et développement. On reçoit des maquettes sublimes, mais comment documenter toutes les fonctionnalités front-end et leur gestion en admin ? On utilise Airtable pour structurer les contenus et faire le lien entre les éléments, ce qui facilite énormément la tâche des développeurs en estimation et exécution.

C’est encore un processus en évolution mais qui devrait s’avérer payant.

Ben Aston :

Tu peux nous expliquer comment tu structures Airtable ? Intégrations avec InVision/Sketch ?

Ryan Schaefer :

Il y a des intégrations selon l’outil, nous on utilise Figma principalement, mais pas d’intégration directe pour l’instant. Le côté base de données relationnelle, c’est ça le gros atout. On peut croiser des infos très facilement, c’est lisible, scalable.

Ben Aston :

Pour ceux qui ne connaissent pas, comment tu structures concrètement Airtable ?

Ryan Schaefer :

Au départ, on liste les éléments de navigation via une arborescence, puis on utilise différents « onglets » (je n’ai plus le terme exact), qui ressemblent à des tabs. On peut alors lier les éléments, différencier les nouveaux avec des tags, catégories, couleurs, titres spécifiques…

Cela donne à toute l’équipe une vision claire, partagée et la source de vérité du projet.

Ben Aston :

Oui, c’est un vrai défi : comment passer de l’UX au développement tout en gardant la trace des exigences ?

Ryan Schaefer :

Exactement.

Ben Aston :

Comment encoder cela ? Airtable, c’est astucieux. Le fait de tout référencer permet d’éviter les erreurs fréquentes avec Word ou Google Sheets. En mode base de données, tout est bien centralisé et référencé. Très malin.

Passons à ton article, qui porte sur comment donner des retours constructifs, utiles à la réussite du projet et du produit.

Pour ceux qui ne l’ont pas lu, peux-tu donner ton avis sur la question ? Pourquoi a-t-on tendance à se retenir ? Qu’est-ce qui nous freine ?

Ryan Schaefer :

Je pense qu’il y a deux raisons principales.

Déjà, on n’a pas envie de vexer nos collègues ou de piétiner leur travail. Ensuite, on manque parfois de confiance dans notre propre avis, surtout face à des experts techniques.

C’est légitime, mais en tant que PM, on est la personne la plus proche du client, et on a un regard neuf, on simule la vision de l’utilisateur final. Notre retour est donc très précieux, différent de celui qui crée vraiment l’élément.

Il faut assumer cette légitimité et se dire : « Ok, en tant que PM, je découvre ce livrable comme l’utilisateur. Est-ce que le message est clair ? Est-ce qu’il cible la bonne audience ? Comprend-on que c’est un menu déroulant ? » Ce retour instinctif aide l’équipe à recadrer et à valider l’adéquation avec l’objectif business.

Ben Aston :

Je partage cette vision du PM comme gardien du succès et de l’expérience utilisateur avec un œil neuf.

Tu donnes dix conseils dans l’article, et tu commences par insister sur la nécessité de te positionner comme informé, notamment via une plongée dans le projet client. Comment être sûr d’être vraiment informé ?

Ryan Schaefer :

C’est une bonne question ! On ne sait jamais tout, et c’est normal.

Ben Aston :

Oui.

Ryan Schaefer :

Mais organiser un appel vision, où on découvre comment l’entreprise se perçoit et où elle veut aller, c’est déjà une excellente base. Discuter avec les parties prenantes, comprendre leurs plans, permet de relier tout ça aux objectifs du projet. Toutes ces infos doivent transparaître dans ce qu’on va construire.

Il faut recueillir assez d’informations spécifiques dans ces échanges pour comprendre ce qu’ils veulent, et se positionner en facilitateur pour les mener là où ils veulent aller (redéfinir la com, le branding, une refonte esthétique ou lancer une appli, etc).

C’est un processus évolutif, très prenant au départ mais qui fluidifie la suite et améliore le résultat final.

Ben Aston :

Pour être informé, il faut comprendre le client, ce que représente la réussite pour lui, connaître ses utilisateurs. Mais aussi, comme tu le dis, savoir s’imprégner des différentes disciplines. Comment t’y prends-tu avec des domaines comme le QA ou l’UX ?

Ryan Schaefer :

Le but est de pouvoir donner un retour pointu, mais objectif. Pour cela, il faut dialoguer avec l’équipe, assumer ses lacunes, ne pas hésiter à observer le travail d’un UX ou d’un dev, apprendre au contact.

Il existe plein de ressources (tutoriaux, articles, pratiquer un peu en dev ou design…). J’essaie de passer cinq heures par semaine à bidouiller ou à lire des articles pour garder l’esprit affûté. Plus tu participes à des réunions, plus tu acquiers naturellement cette culture digitale.

Ben Aston :

Tes sites de référence ?

Ryan Schaefer :

Thedigitalprojectmanager.com. Aussi Girl’s Guide to Project Management, Ad Week pour la créativité, W3Schools pour les questions techniques. Plein de trucs utiles pour apprendre.

Ben Aston :

Parfait. J’encourage aussi à monter des petits projets pour se familiariser vraiment, ne pas se limiter à la théorie.

En faisant le truc soi-même, on comprend mieux le travail du développeur et l’effort que ça représente quand on donne du feedback.

Une anecdote où ça t’aurait joué des tours ? As-tu déjà eu le cas où on t’a rembarré pour avoir donné un retour sur un domaine qui n’était pas le tien ?

Ryan Schaefer :

Ce n’est pas encore arrivé, heureusement. Je dirais que c’est aussi grâce aux gens avec qui je travaille, mais surtout, en gardant le point de vue client, chacun respecte cette vision. On fonde tout sur les objectifs décidés en amont.

Au final, ce n’est pas « je n’aime pas cette couleur », mais « ce coloris, bien que tertiaire dans la charte, prend beaucoup de place, ça risque-t-il de gêner le client ? » Le designer y aura réfléchi et expliquera sa logique, et si ça fait sens, parfait. Sinon, il ajustera.

Ben Aston :

Important aussi de rappeler qu’on n’est pas seul : faire intervenir le directeur artistique si besoin. Bien s’entourer.

Dans ton article, tu parles aussi de préparer les différentes réactions de l’équipe face au feedback, de doser honnêteté et bienveillance sans brouiller le message. C’est compliqué, comment t’y prends-tu ?

Ryan Schaefer :

Ce n’est pas une science exacte ! Mais déjà, être spécifique réduit les risques de malentendu. Il ne s’agit jamais d’un goût personnel mais d’une observation objective liée à l’objectif du projet.

Il faut aussi faire confiance à l’équipe, montrer que l’on croit en leurs compétences. Cela encourage même les plus sensibles aux critiques constructives.

Un feedback précis est généralement bien accueilli, tant qu’il ne tombe pas dans la condescendance.

Ben Aston :

En guise de conclusion, si quelqu’un craint que son avis ne soit pas pris en compte par l’équipe UX ou design, quel conseil donnerais-tu ?

Ryan Schaefer :

Je dirais : si quelque chose ne vous semble pas correct dans un prototype ou une maquette, ne réagissez pas à chaud. Prenez le temps de réfléchir, de noter les problèmes et d’envisager des suggestions d’amélioration. Cela vous permet d’argumenter et d’être écouté lors du prochain échange.

Plus vous prenez le temps, plus vos remarques seront précises et appréciées. Votre interlocuteur sera d’autant plus prompt à les intégrer dans la prochaine version.

Ben Aston :

Excellent conseil ! En effet, des critiques spontanées et vagues risquent de braquer. Mieux vaut exposer ses réserves, expliquer le pourquoi et proposer des solutions. Raisonner ensemble peut déboucher sur des ajustements pertinents et constructifs.

Ryan, merci beaucoup d’avoir été avec nous !

Ryan Schaefer :

Merci beaucoup à toi !

Ben Aston :

Et vous, qu’en pensez-vous ? Vos retours sont-ils bien accueillis par l’équipe ? Racontez-nous en commentaire et rejoignez-nous sur thedigitalprojectmanager.com pour rejoindre notre équipe Slack et participer à la discussion sur la gestion de projet.

Si vous avez aimé ce que vous avez entendu aujourd’hui, merci de vous abonner et de prendre quelques minutes pour laisser un avis honnête sur le podcast DPM sur Apple Podcasts. Vos notes et commentaires sont précieux pour nous, merci beaucoup.

À bientôt, et merci pour votre écoute.