ENFR

Expérience professionnelle | iOS, Android et web

PepPsy

PepPsy est une plateforme de santé mentale au travail et de prévention des risques psychosociaux qui combine interventions sur le terrain, formation des managers et application mobile pour améliorer le bien-être des salariés et la performance sociale.

  • Feuille de route produit
  • Backlog
  • User story
  • Tests d’utilisabilité
  • UX
  • Agile
Logo de l’app PepPsy au-dessus de quatre écrans de téléphone : l’accueil (« Bonjour Marie »), la bibliothèque, un exercice de respiration de 2 minutes et le score bien-être.

✨ Aperçu

Rôle

Cheffe de projet

Plateforme

iOS, Android et web.

Calendrier

2022 - 2024

Livrables

Backlog produit, User stories, Critères d’acceptation, Tests d’utilisabilité, Tableau Kanban, Tableau de bord RH (analytique), Raccourci podcast, Validation des releases

Aperçu

PepPsy est une plateforme de santé mentale que les entreprises proposent à leurs collaborateurs. PepPsy vend à l’entreprise, généralement via les DRH, et ce sont les salariés qui utilisent l’application au quotidien. À l’époque où je dirigeais le produit, l’application comptait 65 000 utilisateurs.

Cela créait deux publics aux besoins différents. Les équipes RH, qui achètent le produit, doivent voir qu’il apporte de la valeur. Les salariés doivent avoir la certitude que ce qu’ils font dans l’application reste privé, faute de quoi ils ne l’utiliseront pas. La plupart de mes décisions produit devaient fonctionner pour les deux.

Le produit était construit par une petite équipe : le directeur de l’entreprise, trois développeurs et moi. Les ventes remontaient ce que les acheteurs demandaient, et les données d’usage montraient ce que les salariés faisaient réellement dans l’application.

Outils

  • Trello
  • Vercel
  • Figma
  • Make
  • Notion
  • Pipedrive

✨ Le défi

Comme toute startup, PepPsy disposait de peu de temps, d’argent et de développeurs, donc rien de ce que nous livrions ne pouvait être gaspillé. Chaque release devait compter et rester dans le budget.

Cela impliquait trois choses :

Prioriser selon les besoins de l’entreprise. Avec trois développeurs, nous ne pouvions pas tout construire. Les fonctionnalités devaient mériter leur place en fonction des besoins de l’entreprise, en tenant compte de la direction donnée par le directeur, des demandes des ventes et des signaux issus des données d’usage.

Garder une vision produit claire. L’équipe devait comprendre où allait le produit et pourquoi, afin que chaque travail s’inscrive dans la feuille de route et pas seulement dans la dernière demande en date.

Gérer le backlog pour qu’il soit livrable. Une bonne vision n’est utile que si elle se transforme en travail que les développeurs peuvent construire, tester et livrer en toute confiance. Je gérais le backlog, validais chaque release et faisais chaque semaine le point avec le directeur sur la feuille de route, le budget et les jalons.

Cadrage du problème

  1. Un contenu qui ne correspondait pas à la façon de travailler de certains utilisateurs : les clients du transport n’affichaient presque aucun engagement sur les vidéos, car leurs utilisateurs passent la journée sur la route et ne peuvent pas regarder un écran.
  2. Deux utilisateurs aux besoins opposés : les équipes RH, qui achètent le produit, ont besoin d’en voir le retour sur investissement. Les salariés, qui l’utilisent, ont besoin de confidentialité pour s’engager, donc offrir plus de visibilité à l’un risquait de nuire à la confiance de l’autre.
  3. Les besoins des acheteurs parvenaient au produit de seconde main : l’équipe commerciale parlait aux acheteurs, pas l’équipe produit, donc les exigences devaient être recueillies via les ventes avant de pouvoir devenir des éléments du backlog.
  4. La direction et la livraison étaient difficiles à relier : la feuille de route, le budget et les jalons étaient fixés avec le directeur, mais trois développeurs avaient besoin que cela soit traduit en travail clair et testable, chaque release étant validée avant d’atteindre 65 000 utilisateurs.

✨ La solution

J’ai introduit la méthodologie Kanban avec Trello, afin que tout le monde puisse voir ce qui était en cours de développement, ce qui venait ensuite et ce qui était terminé. Le tableau est devenu la vue partagée du développement produit entre moi, le directeur et les trois développeurs.

Chaque élément du tableau était une user story, rédigée du point de vue de l’utilisateur, avec des critères d’acceptation définissant quand le travail était terminé. Cela donnait aux développeurs un objectif clair et me donnait une checklist claire pour valider chaque release avant la mise en production.

Cela a facilité la communication au sein de l’équipe et rendu la livraison plus prévisible.

Objectifs généraux

  • Adapter le contenu à la façon de travailler des utilisateurs

    Proposer aux clients du transport un raccourci podcast dédié, afin que le contenu convienne aux personnes qui ne peuvent pas regarder un écran.

  • Montrer la valeur aux RH sans exposer les salariés

    Construire un tableau de bord RH anonyme basé uniquement sur les données d’usage, sans aucune information personnelle sur les salariés.

  • Placer la confiance des salariés au cœur de chaque fonctionnalité

    Traiter la confidentialité comme une règle de conception, afin qu’une visibilité accrue pour les acheteurs ne coûte jamais l’engagement des personnes qui utilisent l’application.

  • Intégrer les besoins des acheteurs au produit

    Recueillir les exigences auprès de l’équipe commerciale, qui entend ce que demandent les acheteurs, et s’en servir pour décider des indicateurs que le tableau de bord affiche.

  • Transformer la feuille de route en travail livrable

    Gérer le backlog et rédiger des user stories, y compris à partir de trois tests d’utilisabilité, afin que les trois développeurs aient toujours un travail clair et testable.

  • Livrer avec confiance et prévisibilité

    Valider chaque release avant la production et utiliser les pratiques Agile et Kanban pour maintenir une communication et une livraison régulières.