SNCF Connect: l’exemple à ne pas suivre

Épisode de Tech Rōnins par Julien Déray et Pierre Féray-Ferrand · 11 octobre 2022 · 56 min

Principe Agile du mois d’Octobre

https://agilemanifesto.org/iso/fr/principles.html

“Accueillez positivement les changements de besoins, même tard dans le projet. Les processus Agiles exploitent le changement pour donner un avantage compétitif au client.”

Pierre:

De facon passive, pas pro-active.

Julien:

Oui, mais non. Je me bats contre trop de changement pendant le dev.

SNCF Connect

App la plus utilisée en France

Lancé en Jan 2022 (Anciennement OUI SNCF)

Devait faciliter la vie des usagers, mais tellement buggée qu’elle a été immédiatement détestée.

Résultat

Beaucoup de bugs ont été fixés depuis MAIS beaucoup de fonctionnalités de base ne sont toujours pas présentes:

On peut faire un arrêt sur les long trajets, mais pas plus (ce qui n’était pas le cas dans l’ancienne appli)

Aberration dans la barre de recherche: la destination est en premier! (UX)

Phase de test

Plus d’un an de dev, le beta test a commencé 2 mois avant le lancement.

Les tests ont débuté très tard (Novembre) — vacances de Noel, aucun beta testeur n’était focus sur l’application.Très peu de retours

SNCF voulait la plus grande confidentialité autour de l’application durant les phases de développement.

Fonctionnalités

Exemple de fonctionnalité manquante:

ajouter le billet dans le wallet Apple/Google

absence de filtres pour les trajets

→ Regression par rapport à OUI SNCF

Step back

Pourquoi avoir lancé le dev d’une nouvelle app? Arrivée d’un nouveau dirigeant.

Comment: débauché quelques personnes d’Accenture pour tout dev en interne, encore pour une raison de confidentialité…

Approche non itérative assumée:

Approche Big Bang.

Aucune gestion du changement pour les utilisateurs: juste lancé une mise à jour Majeure sur les téléphones (l’ancienne appli a été remplacée du jour au lendemain par la nouvelle).

Aucune modularité.

→ probablement dans une volonté de booster l’adoption. Si on remplace, personne ne pourra rester sur l’ancienne appli, donc la nouvelle ne peut pas être un échec.

Too many cooks in the kitchen? On pense que ça va être compliqué, donc on monte une grosse équipe (plusieurs centaines de gens).

Pas d’objectif clair, vision non communiquée.

Problématiques actuelles

Pierre:

Nouveau quarter, nouveaux problemes = 1 gros projet (money maker) d’une squad dripping dans les autres - manque de logique dans le split des Key Results

Etre de plus en plus EM > TL - mais dur a realiser avec une team qui n’est pas encore autonome = mise en place de petits processes (DoD, DoR, captain) pour aider l’equipe a maturer

Julien:

Beaucoup de choses qui se passent en perso, ça fait relativiser le pro.

Prise de recul.

Outils de l’épisode

Julien:

Le livre de Pierre-Henri Chuet, dit “Até”: Au-delà du cockpit (Chef de patrouille dans la Marine)

Autres épisodes de « Tech Rōnins »

À propos du podcast

Le podcast francophone du leadership technologique où, toutes les deux semaines, on vous partage nos conversations et réflexions pour vous aider à maximiser votre impact et propulser vos équipes vers de nouveaux sommets. Animé par Julien Déray (http://julien.deray.fr) et Pierre Feray-Ferrand…

Tech Rōnins

Épisodes similaires

Tous les épisodes de Tech Rōnins · Plus de podcasts Business