Cibler Les Exigences (avec Kelly Suter de BI Worldwide)

Lisez la transcription :

Nous testons la retranscription de nos podcasts à l’aide d’un logiciel. Merci de pardonner toute faute : le robot n’est pas fiable à 100 %.

Ben Aston :

Bienvenue dans le podcast DPM, où nous allons au-delà de la théorie pour donner des conseils experts en gestion de projets digitaux et ainsi vous aider à mieux piloter vos projets. Merci d’écouter, je suis Ben Aston, fondateur du Digital Project Manager. Soyez honnêtes : est-ce que votre client s’est déjà retourné à la fin du projet pour dire, « Bravo, c’est exactement ce que l’on voulait, c’est précisément ce que vous aviez annoncé au début, formidable, vous avez tout parfaitement capté sans rien oublier » ?

Eh bien, j’en doute… Et probablement parce que vos exigences n’étaient pas suffisamment cadrées. Alors, comment gérer les exigences pour éviter de finir dans le chaos, et donner au client comme au développeur toutes les informations dont ils ont besoin pour bien faire leur travail ? C’est justement l’objet de notre épisode : les exigences projets.

La façon dont on définit un projet et ses fonctionnalités pour que tous sachent ce qui va être livré. Fondamentalement, les exigences sont selon moi un outil de communication, mais très difficile à maîtriser, car si elles sont trop vagues, on gagne certes en souplesse, mais on ne récupèrera probablement pas exactement ce qu’on espérait. Si on les définit trop strictement, il risque de manquer des éléments. Alors comment trouver le juste équilibre ?

Aujourd’hui, je discute avec Kelly Suter. Kelly est cheffe de projet technique chez BI Worldwide, et l’une des expertes résidentes au Digital Project Manager – bonjour Kelly.

Kelly Suter :

Bonjour, merci de m’accueillir, Ben.

Ben Aston :

C’est super de t’avoir avec nous. Je crois que c’est notre deuxième podcast, non ?

Kelly Suter :

Oui, tout à fait.

Ben Aston :

On avait enregistré un podcast il y a longtemps. Pour les gens qui t’auraient oubliée, tu peux nous présenter rapidement ton parcours, comment tu t’es lancée dans la gestion de projet ? Je pense que comme beaucoup d’autres chefs de projet, ton parcours est original. Personne ne rêvait d’être chef de projet enfant, alors raconte-nous : comment es-tu devenue PM digital ?

Kelly Suter :

Oui, j’ai démarré ma carrière pro comme journaliste sportive, car j’avais étudié la communication, avec une spécialisation en relations publiques et médias. J’ai vite compris que la presse écrite n’était plus l’avenir, alors j’ai bifurqué vers la publicité, et j’ai travaillé trois ans comme attachée de presse, principalement pour la marque « Sesame Street Live ». J’ai vraiment développé l’image de cette marque pendant trois ans, puis une connaissance dans une agence eCommerce personnalisée, une agence digitale full service, m’a proposé : « On n’a pas de service gestion de projet ici, tu voudrais essayer ? » J’ai répondu, « C’est quoi, exactement ? » Mon père avait une agence de design graphique, donc j’étais familière de l’ambiance des agences, très mouvementée. Mais j’ai accepté pour voir.

J’ai donc rejoint l’agence ; mon premier livre sur le sujet était « People, Pixels, and Process » de Meghan McInerny (je ne me rappelle plus de l’ordre exact du titre), mais je l’ai lu et appliqué...

Ben Aston :

Oui, je vois très bien.

Kelly Suter :

Oui. Je...

Ben Aston :

People, Pixels… Il me semble que c’est bien « People, Pixels, and Process ».

Kelly Suter :

Voilà. J’ai appliqué ce livre du mieux que je le pouvais à l’agence en face de moi : on était 12. On faisait des sites vitrine et eCommerce sur mesure. Quatre ans plus tard, j’avais monté une équipe de sept chefs de projet. On a pu structurer un process, qui n’a cessé d’évoluer. Ensuite, je me suis sentie très à l’aise avec Magento, Drupal, Cantego, WordPress… J’ai voulu approfondir ma technique, alors j’ai sauté sur l’opportunité d’un poste de cheffe de projet technique chez BI Worldwide où je suis aujourd’hui. J’avais envie de replonger dans l’opérationnel et d’aiguiser mes compétences techniques. J’adore ce rôle, c’est passé très vite, mais j’en suis ravie.

Ben Aston :

Je suis curieux : aujourd’hui, c’est le job de tes rêves ? Car tu as fait du journalisme sportif, travaillé pour Sesame Street, et maintenant le digital en gestion de projet. Mais alors, que voudrais-tu faire idéalement ?

Kelly Suter :

C’est une excellente question. Ce que je préfère dans mes expériences récentes, chez Irish Titan notamment, cet autre studio dev, c’est d’arriver dans un environnement où le process n’existe pas vraiment, ou commence tout juste à émerger. Pas que les équipes ne soient pas talentueuses, mais j’adore relever des nouveaux défis : mettre du process, structurer les choses, permettre aux équipes de souffler (« ah, on a enfin un cadre… »). Je pense que mon boulot de rêve, ce serait d’être ce « pompier » qui intervient dans des entreprises récentes ou des start-ups pour mettre en place un process solide, changer de contexte, relever des défis. J’aime quand c’est challengeant.

Ben Aston :

Très bien. Quels sont justement les défis auxquels tu fais face aujourd’hui ? Tu fais office de « pompier », tu structures le process en agence, mais plus concrètement ? Un défi en particulier à surmonter actuellement ?

Kelly Suter :

En ce moment, au milieu de tous nos petits défis quotidiens, mon principal enjeu, c’est la mobilisation de l’équipe autour de la documentation, sans la rendre rébarbative. Lorsqu’un client, comme l’équipe, est enthousiaste, c’est dur d’obtenir leur adhésion pour documenter (je ne cherche pas à vendre l’objet du podcast, mais c’est vrai !). L’idée c’est de ne pas casser l’élan, de ne pas tout ralentir, mais quand même de documenter, et de tout « templater » pour sécuriser l’essentiel. Ce n’est pas obligé d’être fastidieux, mais il faut acquérir cette habitude pour ne pas tout perdre quand quelqu’un change d’équipe ou de poste. J’ai vu beaucoup de cas où les équipes réinventent la roue à chaque fois, que ce soit pour la conception ou la documentation ; elles surconçoivent parfois ce qui pourrait être simplement standardisé, ou plus efficace.

La documentation, c’est la clé, et c’est ce que je fais en ce moment pour des éléments dont la dernière trace date de 2014… Ça a convenu au client jusque-là, mais on ne veut pas que ça dure. Et puis, lors d’un audit, c’est vraiment plus simple d’avoir tout bien documenté.

Ben Aston :

Donc tu jongles pas mal avec structuration du process, documentation… Pour tout ça, tu utilises des outils particuliers, qui te facilitent la vie ?

Kelly Suter :

Pour la documentation pure, je ne réinvente pas la roue : j’utilise Google Suite, tant qu’il n’y a pas de contraintes lourdes côté confidentialité chez le client. Les Docs de Google permettent de partager, de gérer les permissions (visualisation, commentaire…) que ce soit en interne ou externe.

Ça évite les problèmes de versions, et à la fin on exporte en PDF et ça devient un document formalisé à faire signer. Pour l’écriture même, c’est ce qu’on utilise. InVision est aussi un outil formidable pour le suivi créatif, commentaires, etc. Les designers y déposent leurs maquettes ou wireframes, et les clients/parties prenantes peuvent annoter intuitivement ; très utile car la documentation visuelle aide toujours. Si InVision est trop cher, Sketch peut dépanner, c’est gratuit et pratique pour annoter simplement ses designs. On y importe ses fichiers, on ajoute numéros ou lettres selon son système d’annotation, et c’est réglé.

Je ne complique pas : j’importe mes visuels, j’annote, je documente, puis je rédige simplement. Voilà les outils qui me servent.

Ben Aston :

Intéressant, revenons un peu sur ton parcours. Maintenant, tu es PM technique, mais tu portes plusieurs casquettes : chef de projet, business analyst, SCRUM master… Qu’est-ce qui différencie le rôle de PM technique d’un PM digital classique ? Comment gères-tu ces multiples rôles ?

Kelly Suter :

Bonne question. Dans mon cas précis, j’ai une situation particulière : j’exerce deux types de gestion de projet chez BIW, la partie événementielle et la création de contenus pédagogiques (environ un quart de mon temps). Les trois autres quarts sont sur du management technique. Mais selon les missions, on voit les intitulés changeants : PM digital, technique, agile… Au final, on reste chef de projet, mais la vraie différence entre mon ancien rôle (DPM) et le poste actuel (TPM : technical PM), c’est surtout le niveau de compréhension technique requis. Avant, je pilotais le projet assez globalement : contenus, arborescence, wireframes, créa… En dev, je savais quoi auditer (les données, les exports, etc.), mais je n’entrais pas dans le détail.

Comme TPM, je suis aujourd’hui bien plus plongée dans la technique. Je gère toujours la créa, la strat’ digitale, la QA, mais côté dev, il m’arrive de participer de très près : lors des revues de code, des releases, je suis à côté du dev principal pour vérifier que les exigences que j’ai rédigées sont bien respectées dans le code avant validation. Autre différence : c’est moi qui écris ces spécifications techniques. Plus on est proche des exigences, et plus on est responsable si souci ensuite !

Donc, en DPM, j’encadrais la gestion des exigences… En tant que TPM, je les rédige et je vais bien plus dans le détail sur la partie dev.

Ben Aston :

Pour ceux pour qui les notions d’exigences fonctionnelles ou de business requirement design sont floues : en pratique, cela consiste bien à concevoir ces deux types d’exigences (business et fonctionnelles) ? C’est souvent une zone grise en équipe : côté dev, on pense que c’est le job du PM ou du business analyst, alors que côté PM/BA, certains estiment manquer de visibilité. Comment fais-tu pour être au milieu ?

Kelly Suter :

Au début d’un projet, ou quand on débarque dans une équipe ou une nouvelle boîte, il faut bien comprendre qui fait quoi. Même si c’est défini, parfois les rôles évoluent selon le client. On gère parfois des intégrations (inventaire, base produits, etc.), je peux dire « il me faut ces données en direct, mises à jour à telle heure, avec info sur stock XS, S, M, L… ». Mais parfois, le dev doit plonger à un niveau que je ne maîtrise pas. Plutôt que prétendre comprendre, je préfère dire : « J’assure la rédaction jusqu’à ce point, peux-tu m’aider sur les détails techniques ? », quitte à user de la méthode des cinq pourquoi (« Pourquoi faire cela ? Parce qu’on veut tel comportement utilisateur, etc. »).

Il faut savoir où s’arrêter, et demander de l’aide, pour qu’aucune exigence ne passe à la trappe.

C’est un équilibre : clarifier à l’avance qui fait quoi, et assumer les limites de chacun. Et puis il y a toujours la question du budget : qui va faire ce travail, à quel coût, quelle efficacité. Il faut que la répartition joue sur les forces de chacun, et que la communication soit claire sur ce point.

Ben Aston :

Pour ceux qui entendent parler de business requirement design ou exigences fonctionnelles sans trop savoir, ils se disent parfois « on fait des maquettes puis les devs s’en occupent ». Mais tu parles de documentation… N’est-ce pas contraire à l’esprit agile/flexible ?

Quelle est la nature de ces documents et à quoi servent-ils vraiment ?

Kelly Suter :

Concrètement, la documentation des exigences métier (BRD pour « Business Requirement Document ») peut s’apparenter à un cours d’introduction : ce sont les grandes lignes, du style « il faut une version espagnole et chinoise », « livrer 10 modules », « être prêt en avril », « supporter 6000 utilisateurs ». Le BRD, c’est s’assurer que tout le monde part dans la même direction, c’est le point d’accord. Mais il précise bien qu’on raffinera au cours du projet (si on sort du périmètre ou du budget, on s’adapte).

L’exigence fonctionnelle (FRD pour « Functional Requirement Document ») arrive après : chaque point du BRD est développé à fond (on traduit en espagnol et chinois, via prestataire, via automatisation, saisie manuelle CMS ? Etc.). On détaille tout, et parfois on met de côté un point devenu hors budget pour une V2 par exemple. Le FRD devient alors le véritable plan de construction.

Donc, le BRD cadre l’objectif business au début, et le FRD précise, pour chaque fonctionnalité, tout ce qu’il y a à prévoir (par exemple la localisation pour un public chinois…).

Ben Aston :

Mais du coup, l’approche agile – certains développeurs réclament des exigences détaillées, d’autres se plaignent qu’on « documente trop », qu’il faudrait être plus flexible, « tester & learn »... Comment trouver un juste milieu entre documentation et itératif/agile ?

Kelly Suter :

Tout tient à la compréhension préalable du mode de fonctionnement. Il faut, dès le début, cadrer et dire « voilà la démarche agile, voici ce que ça implique chez le client et en interne », puis organiser le projet : lancement, partage des objectifs, etc. Par exemple, en ce moment, nous développons un logiciel associant points et apprentissage : l’utilisateur progresse, engrange des points, qui seront échangeables dans une marketplace. Le client a confiance (projets antérieurs) et veut une livraison en janvier. On n’a pas le temps pour une documentation exhaustive, mais il nous faut néanmoins définir l’objectif final. Semaine après semaine, on fait du standup, chacun avance sur sa partie (« badges », « certificats », « leaderboard », « parcours d’achat »).

On fait une démo toutes les deux semaines, même si ce n’est pas finalisé visuellement. L’important, c’est la fonctionnalité (API, logique des points, etc.). Le rôle du PM, c’est de documenter ces points-clefs en cours de route : ce qui a été fait la semaine précédente, les questions pour le client, les retours…

Ainsi, lors des réunions clients, tout le monde peut exprimer ses questions et on ajuste pour la suite. Il faut constamment observer le cap jusqu’à la livraison, et s’adapter, prioriser les fonctionnalités si besoin (enlever temporairement les certificats, etc.). La communication permanente, c’est la clef, en documentant à mesure et en entretenant la confiance.

Ben Aston :

Oui, car souvent on bloque un projet parce qu’on attend d’avoir tout défini… alors que ça prendrait trop de temps. Ce qui est bien, c’est d’avancer en définissant les exigences au fur-et-à-mesure, pour donner les moyens au dev, au client, à la QA de travailler efficacement. L’important c’est de garder la dynamique.

Mais tout ça prend du temps : comment gérez-vous la documentation concrètement ? JIRA ? Quel workflow ?

Kelly Suter :

Bonne question ! Ce n’est pas fait en solo, j’informe l’équipe à l’avance que je poserai beaucoup de questions pour éclaircir tous les points (bonnes pratiques, décisions prises en meeting…).

Quand le FRD est finalisé (et validé par tous puis le client), je procède de deux manières. Certains devs veulent que le PM crée les tâches pour eux, d’autres préfèrent les gérer eux-mêmes. Après avoir revu le FRD, souvent ils acceptent que je crée les tâches : je découpe par typologie de page (inscription, accueil, page produit…), avec sous-tâches pour chaque besoin sur cette page, puis j’attribue le tout dans JIRA et chacun estime sa durée (le dev en charge, idéalement !).

Cela permet d’avoir un meilleur alignement avec les estimations. On utilise JIRA (Atlassian) pour le suivi, tout est préparé dans le backlog, chacun estime, je priorise dans des sprints sur la base d’environ 30h/semaine (quand il n’y a qu’un dev). En mode agile, j’inclus un volet QA dans chaque ticket, pour indiquer les critères de réussite/échec à tester.

Ben Aston :

Justement, sur l’estimation : c’est un défi croissant dès qu’on fait des projets techniques. Le client veut un coût global très tôt, alors qu’on ne connaît pas toute la fonctionnalité. Comment gères-tu cette question ? Tu évoquais le mode agile et l’estimation au fil des exigences… Mais comment faites-vous pour estimer au début d’un projet ? Quelle méthode pour le pré-chiffrage, avant les requirements techniques détaillées ?

Kelly Suter :

Très bonne question ! En général, 90 à 95% du temps, je n’ai pas la main sur l’estimation, hormis un avis de passage du style « à ton avis, on peut livrer d’ici mars ? ». Je pose alors plein de questions. Quand je peux donner un avis (ou en support de la team dev), je commence par voir ce qu’on a déjà fait de similaire dans l’entreprise, pour calibrer (taille utilisateur, type de produit…), ou alors par rapport à d’anciens sites eCommerce (par exemple du Magento), durée-type 6-8 semaines avec deux devs, quasi standard. On fait rarement un devis précis à cette étape : c’est du relatif/comparatif.

Je dis toujours aux commerciaux que tant qu’il n’y a pas d’intégration, pas de spécificité, c’est la fourchette standard. Sinon, c’est là qu’un lead dev (ou PM technique dans mon cas) joue ce rôle de référent. Il faut avoir quelques « fiches » de référence à sortir selon le contexte et ajuster. (Je sais, ce n’est pas une réponse très normée, mais le sujet est complexe !)

Ben Aston :

Oui, tu pratiques donc l’estimation analogique : quand on doit sortir un chiffre « à la louche » alors qu’on n’a pas de spec détaillée, on compare avec trois projets précédents semblables, « voilà la fourchette ». On explique bien que définir les exigences fait partie de la phase de découverte, et qu’en affinant, on pourra mieux estimer par la suite.

Kelly Suter :

Exactement ! Deux exercices rapides que je pratique : déjà, le triangle classique (périmètre, planning, budget), et je demande au client de classer ces trois éléments de 1 à 3 en importance. Tous répondent « tout est prioritaire » mais je les oblige à choisir. Cette priorisation évoluera peut-être, mais elle oriente la gestion de l’incertitude.

Le deuxième exercice, c’est le « bon, mieux, excellent » : si le client a un certain budget, je lui montre ce que permet ce budget, mais si une intégration coûteuse ou une surcouche design arrive, je dis « ok, voilà ce que ça coûte, voilà ce qu’on enlève si on veut rester dans le budget, ou alors trouvons un compromis entre les deux ». Ça aide à ne pas être celui qui « pose des interdits » et implique le client dans la décision.

Ces deux approches sont très bénéfiques pour maîtriser planning, scope et budget, et donner au client la sensation d’une vraie collaboration.

Ben Aston :

Exactement ! Et c’est une vraie collaboration, ce qui permet de ne pas se retrouver coincé sur une estimation figée alors qu’on aborde une technique ou des intégrations inédites. On adapte alors l’estimation/le périmètre selon les vraies priorités du client.

Pour finir : pour quelqu’un qui débute dans la rédaction d’exigences, qui a l’habitude de ne livrer que wireframes/designs puis de passer au dev, quels conseils donnerais-tu pour s’y mettre ?

Kelly Suter :

Déjà, j’ai souvent dit : si vous débutez comme PM digital, vous savez sans doute plus que vous ne pensez. On est tous d’une génération numérique, on a acquis des réflexes, des usages, et même inconsciemment on sait déjà beaucoup.

Plutôt que de foncer sur un template trouvé en ligne et de remplir au hasard (je l’ai fait !), prenez du recul : qu’est-ce qu’on livre au client ? Un site d’inscription à un événement avec une homepage et un formulaire ? Listez chaque élément, demandez-vous « que fait cet élément, sur mobile et desktop ? ». Expliquez-le simplement, à la façon d’une grand-mère qui a encore un vieux téléphone Nokia. Puis validez vos hypothèses auprès d’un développeur : il appréciera la démarche, même si ce sont des questions basiques, car ça clarifie le cadrage.

Donc, pour débuter la rédaction des exigences, segmentez selon vos livrables, expliquez, puis allez demander confirmation. Votre première spec sera sûrement un peu maladroite, mais ce n’est pas grave : ça s’améliore très vite, tant dans la consistance que dans la précision. Le client n’a souvent jamais fait ce genre de projet ; vous êtes leur expert ! Impliquez-les et dédramatisez : vous en savez déjà plus que vous pensez car vous vivez dans cet univers.

Ben Aston :

Tout à fait, au fond, c’est surtout l’art de poser des questions et d’obtenir les réponses ! Rien n’est évident, il faut juste se mettre à la place du client (ou d’une mère ou d’une grand-mère) pour vulgariser…

Et toujours se rappeler que la documentation des exigences, c’est un outil de communication. Super clair, pour que tout le monde sache précisément ce qui doit être réalisé, moins de malentendus, moins de perte de temps et d’énergie. C’est chronophage, mais tellement rentable, car ça évite le rework et les clients déçus !

Merci beaucoup Kelly d’avoir partagé tous ces conseils.

Kelly Suter :

Merci à toi, Ben.

Ben Aston :

Et pour rappel, en tant qu’experte DPM, Kelly participe aussi à notre formation Mastering Digital Project Management. Si vous avez besoin de formation en gestion de projet digital, rendez-vous sur dpmschool.com pour un bootcamp de sept semaines : vidéos interactives, travaux, discussions de groupe, webinars… Notre prochaine session débute en février ! Pour participer à la discussion autour des exigences, rendez-vous sur resources ou rejoignez notre équipe Slack ! Merci d’avoir écouté et à bientôt.