Le product, fer de lance de l'efficacité du "delivery"

Le product, fer de lance de l'efficacité du "delivery"

Product Owner

Tech Organisation

Process Owner

Secteur :

Logistique

Entreprise :

Start-up

ContextE:

ContextE:

Dans le cadre de notre projet, notre équipe technique, composée de seulement trois personnes, était confrontée à un défi de taille : chargée de la maintenance du système SAS, de l'évolution des fonctionnalités existantes, ainsi que de la conception et du déploiement de nouvelles fonctionnalités. Ce contexte de travail intense et multitâche a eu un impact considérable sur la qualité et la cohérence de notre produit. Les clients se plaignaient d'un problème de performance d'affichage des données et du manque d'ajout fonctionnel.

Dans le cadre de notre projet, notre équipe technique, composée de seulement trois personnes, était confrontée à un défi de taille : chargée de la maintenance du système SAS, de l'évolution des fonctionnalités existantes, ainsi que de la conception et du déploiement de nouvelles fonctionnalités. Ce contexte de travail intense et multitâche a eu un impact considérable sur la qualité et la cohérence de notre produit. Les clients se plaignaient d'un problème de performance d'affichage des données et du manque d'ajout fonctionnel.

Mission :

Mission :

  • Augmenter la capacité du "Delivery" pour délivrer plus rapidement des fonctionnalités

  • Augmenter la qualité des développements

  • Fluidifier la communication interne entre Tech et Ops

  • Augmenter la capacité du "Delivery" pour délivrer plus rapidement des fonctionnalités

  • Augmenter la qualité des développements

  • Fluidifier la communication interne entre Tech et Ops

Équipes engagées :

Product, Tech, Ops

Livrables :

Blueprint workflow

Méthodes :

Blueprint, Commitologie Agile

Comment j’ai mené la mission !

Comment j’ai mené la mission !

Mon analyse met en évidence plusieurs problèmes clés dans le processus de développement :

  • La description claire des fonctionnalités : L'absence d'un aspect fonctionnel bien défini entraîne une confusion et une mauvaise direction dans le développement.

  • Problèmes d'organisation : Les difficultés rencontrées par les techniciens pour s'organiser indiquent un besoin de structuration plus claire des tâches et des responsabilités.

  • Mauvaise compréhension et communication : Les malentendus entre les équipes ops et de développement soulignent le besoin d'une meilleure communication.

  • Absence de QA (Assurance Qualité) : L'absence de QA entrainait de nombreux aller-retours

    —————————————————————————

J'ai commencé d'abord par structurer le produit en étayant une vision sur 12 mois des chantiers permettant de hiérarchiser les besoins de développement : les évolutions de l'existant + les bugs versus le nouveau "build". Ensuite, j'ai travaillé sur la formalisation et sur la structuration des spécifications fonctionnelles :

  • L'écriture fonctionnelle

  • Le workflow 

  • Les écrans 

  • Les aspects techniques

  • Les processus internes qui changent

Tous les départements de l'entreprise sont concernés et sont donc au courant de la fonctionnalité. J'intègre un RACI et un sponsor (Des personnes qui nous aideront pour la QA).
J'ai mis en place la méthode agile de deux semaines, en intégrant des réunions quotidiennes et hebdomadaires. Une nouveauté a été d'impliquer le “Tech “lead” sur la partie discovery dans l'élaboration des fonctionnalités majeures. Il intervient d'abord pour comprendre et discuter des aspects techniques et de la faisabilité potentielle.

Une fois les spécifications écrites, il y a une phase active technologique où le tech lead collabore avec les techniciens spécialisés. L'équipe procède ensuite à la décomposition en user stories, leur intégration dans la planification JIRA, et enfin au développement. À la fin de chaque sprint, une démonstration est réalisée. Si la qualité est jugée suffisante par le product owner, les développements passent en phase de déploiement. Sinon, ils sont retravaillés. Le déploiement se fait d'abord dans un environnement de test pour le PO, puis dans un environnement staging pour la QA interne, et enfin en production pour un test par un nombre limité de clients avant un déploiement général.

Mon analyse met en évidence plusieurs problèmes clés dans le processus de développement :

  • La description claire des fonctionnalités : L'absence d'un aspect fonctionnel bien défini entraîne une confusion et une mauvaise direction dans le développement.

  • Problèmes d'organisation : Les difficultés rencontrées par les techniciens pour s'organiser indiquent un besoin de structuration plus claire des tâches et des responsabilités.

  • Mauvaise compréhension et communication : Les malentendus entre les équipes ops et de développement soulignent le besoin d'une meilleure communication.

  • Absence de QA (Assurance Qualité) : L'absence de QA entrainait de nombreux aller-retours

    —————————————————————————

J'ai commencé d'abord par structurer le produit en étayant une vision sur 12 mois des chantiers permettant de hiérarchiser les besoins de développement : les évolutions de l'existant + les bugs versus le nouveau "build". Ensuite, j'ai travaillé sur la formalisation et sur la structuration des spécifications fonctionnelles :

  • L'écriture fonctionnelle

  • Le workflow 

  • Les écrans 

  • Les aspects techniques

  • Les processus internes qui changent

Tous les départements de l'entreprise sont concernés et sont donc au courant de la fonctionnalité. J'intègre un RACI et un sponsor (Des personnes qui nous aideront pour la QA).
J'ai mis en place la méthode agile de deux semaines, en intégrant des réunions quotidiennes et hebdomadaires. Une nouveauté a été d'impliquer le “Tech “lead” sur la partie discovery dans l'élaboration des fonctionnalités majeures. Il intervient d'abord pour comprendre et discuter des aspects techniques et de la faisabilité potentielle.

Une fois les spécifications écrites, il y a une phase active technologique où le tech lead collabore avec les techniciens spécialisés. L'équipe procède ensuite à la décomposition en user stories, leur intégration dans la planification JIRA, et enfin au développement. À la fin de chaque sprint, une démonstration est réalisée. Si la qualité est jugée suffisante par le product owner, les développements passent en phase de déploiement. Sinon, ils sont retravaillés. Le déploiement se fait d'abord dans un environnement de test pour le PO, puis dans un environnement staging pour la QA interne, et enfin en production pour un test par un nombre limité de clients avant un déploiement général.

Résultat :

Résultat :

Cette nouvelle structure organisationnelle a significativement amélioré la communication entre les équipes opérationnelles, commerciales et technologiques. Elle a également renforcé la compréhension des développeurs sur le métier et mettre un peu la tête dans le système pour comprendre les besoins des utilisateurs, qui diffèrent parfois des perspectives habituelles des développeurs. De plus, une meilleure organisation et une vision du produit plus claire ont apporté un apaisement et un sentiment de tranquillité. Fini le ruch ! 

  • Le delivery a augmenté de 75% ( une fonctionnalité tous les 1,5 mois contre 1 pour 6 mois)

  • La qualité a progressé de 40% sur les évolutions et 25% sur le build

  • Un processus produit mise en place adapté au processus agile de l'équipe dev

  • Un processus QA qui rétribué aux différents départements de l'entreprise

Cette nouvelle structure organisationnelle a significativement amélioré la communication entre les équipes opérationnelles, commerciales et technologiques. Elle a également renforcé la compréhension des développeurs sur le métier et mettre un peu la tête dans le système pour comprendre les besoins des utilisateurs, qui diffèrent parfois des perspectives habituelles des développeurs. De plus, une meilleure organisation et une vision du produit plus claire ont apporté un apaisement et un sentiment de tranquillité. Fini le ruch ! 

  • Le delivery a augmenté de 75% ( une fonctionnalité tous les 1,5 mois contre 1 pour 6 mois)

  • La qualité a progressé de 40% sur les évolutions et 25% sur le build

  • Un processus produit mise en place adapté au processus agile de l'équipe dev

  • Un processus QA qui rétribué aux différents départements de l'entreprise

MY

Skill is

yours

MY

Skill is

yours

MY

Skill is

yours

Product MANAGEMENT

Product DESIGN

Product Marketing

Transformation digitale

tECH oRGANISATION

Chefferie de projet

innovation