Recomendados
Recomendados
Más contenido relacionado
Similar a Xebicon - Comment réussir son projet data à la BNPP
Similar a Xebicon - Comment réussir son projet data à la BNPP (20)
Último
Último (20)
Xebicon - Comment réussir son projet data à la BNPP
- 1. Comment réussir son projet Big Data à la BNPP en étant agile C-view
- 2. Jérôme Dinnat Nelson DufosséTomas Rodriguez
- 3. C-VIEW Un produit à destination des collaborateurs corporate Pour mieux connaître le client
- 4. C-VIEW Une nouvelle démarche de co-construction
- 5. C-VIEW Un nouvel environnement technologique
- 6. 2016, la réalité opérationnelle des chargés d’affaires CRM ? SP BI Excel sheets
- 7. 2017, Cview – Vision client 360° Corporate Restitution d’une vision 360° du client corporate Préparer la visite Client / Prospect
- 19. Préparer le terrain Septembre 2016, le démarrage du projet et ses prérequis ▼ Converger vers une organisation acceptée de tous ▼ Comprendre le backlog et son produit ▼ Mettre en place du cadre projet
- 20. Notre organisation : Une équipe gagnante CONNAÎTRE LES RÔLES CADRE BIENVEILLANT RÉUNIR LES ÉQUIPIERS
- 21. Management visuel ▼ Management visuel physique ▼ Jira pour base de référence Réunir les équipes
- 22. Comprendre le backlog et son produit De la vision au backlog
- 23. Cadrage de projet, affinage de l’embryon de backlog Objectifs ▼ Avoir un backlog raisonnable pour une V1 ▼ Aligner le backlog avec la stratégie Comment ▼ Faire collaborer les métiers et experts techniques plutôt que confronter Comprendre le produit Priorisation des usages IntérêtbusinessIntérêtbusiness InnoverLivrer tôt 1 2 3 I/O ▼ Input : 160 idées ▼ Outputs : env. 50 idées prioritaires et stratégiques
- 24. Préparer le terrain Septembre 2016, le démarrage du projet et ses prérequis ▼ Converger vers une organisation acceptée de tous ▼ Comprendre le backlog et son produit ▼ Mettre en place du cadre projet
- 25. Préparation du projet ▼ Kanban de maturation du backlog ▼ Scrum pour les développements Organisation Kanban de maturation Idée Analyse Biz Analyse Tech Design Ready to dev Livraison En inté En qualif En prod Cycle Scrum TODO En cours Revue Dev done 2 semaines
- 26. Préparation du projet ▼ Co-construire le produit avec les sachants ▼ Bâtir sur une boucle de feedback ▼ Favoriser l’adoption par les ambassadeurs Focus sur les utilisateurs finaux MONTPELLIER PARIS ROUEN
- 27. Fin octobre 2016, quel est le contenu de notre release ?
- 28. Construire notre première version R 1 2 3 5 8 13 Estimer le backlog ▼ Stratégie : Livrer au plus tôt des fonctionnalités apportant un gain opérationnel
- 29. ▼ Backlog complet = 180 pts ▼ Vélocité moyenne = 14 ▼ Date souhaité de livraison : Février 2017 ▼ Temps restant : 9 sprints ▼ Capacité de l’équipe : environ 130 pts Construire notre première version Estimer le backlog 1 2 3 5 8 13 = 180 pts
- 30. Construire notre première version Converger vers une première version ▼ Projection de la capacité de l’équipe avant livraison : 130 pts ▼ Conversion de la capacité en euros (pour l’atelier) : 1300 € ▼ Argent distribué : 1000 € ▼ Exigences non fonctionnels : 300€
- 31. Construire notre première version Projeter Livraisonsouhaitée Scope V1 : 90 - 170 story points Buy a feature Priorisation en 3 lignes
- 34. Full stack
- 36. Big Data
- 38. DEV INT KLIF PRD ● Droits admin ● Donnée de tests ● Droits admin ● Donnée anonymisées ● Recette en cours de Sprint ● Environnement “cassable” ● Pas admin ● Données anonymisées ● Recette version N-1 ● Pas admin ● Données réels ● Version N
- 39. Collaboration pour une usine logicielle
- 42. Le chemin vers l’objectif Whatyouwant Whattheywant Win / Win
- 44. Reste à faire
- 45. Une réussite 3.4 / 4 3.6 / 4 3.8 / 4 Ergonomie Fiabilité des données Utilité 70% de taux d'utilisation sur les 6 premiers mois (Mai à Octobre)
- 47. Merci beaucoup !
Notas del editor
- [Jerome] Pitch Projet : Outil de DataVizualition permettant pour les conseillers coprorate de façon rapide et ergonomique d’avoir une vision synthétique du client (Vs vision produit des outils existants actuels) Enrichissement de la Connaissance client pour le conseiller corporate pour 1er UC adressé => Préparation de visite Donnees de la banque (et extérieur) mais difficileent exploitable
- [ALL]
- [Jerome] Pour vous resituer le contexte, BNP Paribas : c’est environ 200 000 collaborateurs dans le monde répartis en 3 entités Memo interne : Domestic Markets (DM), Corporate & Institutional Banking (CIB) et International Financial Services (IFS) Vous l’avez surement constaté, au travers de l’actualité ou très probablement en tant que client, le secteur bancaire est en plein bouleversement. La banque a donc besoin de se réinventer. L’objectif du projet était d’apporter rapidement aux collaborateurs du corporate un produit moderne et répondant à un besoin fort de connaissance client en quelques instants
- [Jerome] La population d’utilisateur corporate cible du produit, ce sont des banquiers, et cela faisait un moment qu’il n’avaient pas eu de nouvel outil informatique pour les accompagner dans leur business Pour répondre aux mieux à leurs attentes et pour leur livrer une version opérationnelle du produit assez rapidement, nous avions besoin de travailler autrement Une volonté forte et commune de co-construire l’outil est apparue dès les premiers instants du projet, de même qu’est apparue le besoin de livrer une première version rapidement puis l’enrichir progressivement Cette construction est une vraie rupture dans les habitudes des utilisateurs et de l’équipe projet. Cela a nécessité une forte insertion de la démarche pour expliquer et fédérer autour du produit et éviter un premier déploiement qui aurait pu être perçu comme déceptif mais a été une vraie clé de réussite du projet en apportant tout de suite un produit avec de la valeur (voulue par les utilisateurs) et dont la promesse d’enrichissement a été tenue. Nelson vous expliquera plus en détail la mise en place de cette organisation pour permettre cette co-construction en méthode Agile sur un projet « Data » avec des équipes habituées à travailler en cycle en « V » et silotées par expertises (Utilisateurs finaux, Métier, IT, Exploitation). Sachez toutefois que cela a impliqué une refonte des habitudes de travail de construction des outils et une collaboration forte des différents équipes à tout les niveaux (Managers / Opérationnels)
- [Jerome] Pour réussir ce challenge, nous avons également fait un deuxième choix fort en partant sur environnement technologique nouveau qui était au démarrage de la construction. Cet environnement « Big Data », qui s’inscrit dans la stratégie digitale de la banque, C-VIEW à participer à sa construction en forte collaboration avec les équipes en charge du programme « Big Data » et avec les équipes d’exploitations proposant l’environnement technique. Ce choix nous a permis : - de désiloter les données corporate et d’en restituer une vision de synthèse (identification, analyse data, récupération des données auprès des fournisseurs => challenge du projet - d’intégrer de fonctionnalités nouvelles au sein de notre produit (type search) - d’enrichir cet environnement pour les futurs outils corporate (CRM, …) - d’apprendre avant Tomas vous parlera plus en détail de l’environnement technologique du projet et des
- Concrètement avant C-view, les outils existants pour les conseillers corporate n’étaient pas adaptés à la restitution d’informations centrées sur le client - l’accès à l’information du client y était difficile - Quel outil restitue quelle donnée (partielle ou globale), X outils pour une vue consolidée client (certains outils peu ou mal connu des utilisateurs) - Ergonomie datée : nombreux clics pour accéder à l’information - Temps de réponse non optimisés - Les informations n’étaient pas toujours disponibles : informations externes, Rentabilité groupe Cela constitue une perte de temps pour le collaborateur sans être sur d’obtenir une vision conforme du client
- C-VIEW s’est donc un produit de Data Visualisation (Restitution de données uniquement) permettant d’avoir une vision 360 du client (ou prospect) corporate Le 1er UC adressé est la préparation de visite client pour un gain opérationnel très significatif et une qualité de l’information accrue C-VIEW a participé à la construction et l’enrichissement du DataHub (v1) A titre d’information, nous avons à date collectés plus de 70 flux représentant une 15aine de source environ Cette collecte de données va bénéficier directement à un autre produit pour le corporate « le CRM opérationnel » C’est un de nos défis de 2018 qui va nécessiter entre autre une adaptation
- Timing : 5:00 Présentation de la page accueil : Promesse (prepa visite en qq minutes) Moteur de recherche (Tolerant, Proposition, …) A l’écoute de l’utilisateur (Suggestion d’amélioration / Remontée de bugs / Ratings sur critères) 2) Présentation de la page synthèse GA : 1) Périmètre première version déployée (et enrichissements mensuel) 2) Informations agrégées en provenance de plusieurs sources (sa typologie de client, sa renta, ses engagments, son activité, sa composition), contacts (montrer fiche contact) 3) rapide sur la synthèse EJ => Vision Interlocuteurs et Google Maps 3) Présentation des pages détaillés : 1) Renta => Dynamisme de stdb + passage en représentation graphique 2) Engagements => Charts avec filtres dynamiques et resizing des graphs 4) Parler des next features (news externes, mobilités, nouvelles données)
- Pourquoi collecter le bugs ? Etre à l’écoute des utilisateurs. Demarche de co-construction
- Recherche à la Google avec une tolérance de 1 caractère
- Montrer la construction de l’application au fur et à mesure qu’on a intégré les différents sources de données
- Montrer la construction de l’application au fur et à mesure qu’on a intégré les différents sources de données
- Montrer la construction de l’application au fur et à mesure qu’on a intégré les différents sources de données
- Montrer la construction de l’application au fur et à mesure qu’on a intégré les différents sources de données
- Timing : 7min
- On vous a parlé du pourquoi (stratégie), le quoi (le produit fini) Voyons maintenant comment nous y sommes arrivés.
- Timing : 9:00 Démarrer un nouveau produit, qui plus est innovant, dans une grande entreprise, il est possible de rencontrer des difficultés organisationnelles et méthodologiques, techniques Préparer notre futur fonctionnement. -> Cette première phase doit être réfléchi avec toutes les parties prenantes. Terreau fertile
- Septembre, J-10 avant l’arrivée de l’équipe > Obtenir le terreau fertil D’un projet à un autre, d’un contexte à un autre, les préparation peuvent être différentes. Ici nous avons axés notre travail sur 3 sujets.
- Avoir les meilleurs profils = non suffisant -> S’organiser Connaître les rôles : /!\ problèmes de gouvernance. Trop de têtes = perte d’informations - avis divergents - tensions => Besoin de repères. -> Qui fait quoi Réunir les membres Colocalisée - S’entir à l’aise - espace dédié : s’exprimer en toute liberté => Fonctionner au mieux -> Telle une startup Management visuel Pas de dérangement ou critiquer le fonctionnement. Afficher les métriques bons ou mauvais Cadre Bienveillant Respect des expertises : Personnes présentes sont les bonnes personnes. PERMET: proposer, d’expérimenter et si besoin de se planter. - Le droit à l’erreur Pourquoi ? s’améliorer ou nous affranchir de murs techniques ou organisationnels. Beaucoup n’ont pas marché mais ce n’était pas grave, le tout est de rebondir pour à la fin trouver notre fonctionnement.
- Timing : 12 min Réunir les expértises : Comprendre le besoin et les difficultés Toutes les idées sont bonnes <> faisabilité technique En sortie: backlog regroupé sous des grands thèmes ou epics. Que nous pourrons consommer… Encore faut-il connaître la stratégie voulu par rapport au produit !
- Les utilisateurs, chargés d’affaires, ont besoin de préparer leurs entretien plus rapidement. La fameuse valeur ici = temps opérationnel (préparation de rendez-vous) Aligner le backlog avec la stratégie Qu’appelle-t-on l’effort technique alors que l’équipe n’est pas encore arrivée -> Jérome
- seconde étape : comprendre notre cible et donner de la visibilité à tous. => Pour cela il faut créer le backlog
- Kanban CDC voulu -> Backlog juste à temps + Kanban de maturation Théorie des contraintes Risque : 10 ans / Courir après la donnée Imaginer des choses qui ne seront jamais développées. Scrum : Démarrage le jeudi, fin le mercredi Ensemble des participants + les keyusers en démo Pourquoi avoir séparé la livraison du cycle scrum ? Tout simplement, les environnement pas disponibles, le blocker était identifié et en cours de résolution et Tomas l’expliquera. Revenons aux utilisateurs
- Notre équipe complète Grands groupes -> quand on veut on peut valider les hypothèses : ex idée de fonctionnalité non voulue Statistiques des fonctionnalités non utilisées, co-construire avec les principaux intéressés. Créer la boucle de feedback par un maximum de possibilité: Les utilisateurs au centre du projet. (Vacances de Noël) Formulaire de feedback (n’attendons pas le mercredi) Produit en production pas suffisant => Organiser la distribution Proposer un produit qui leur convient : réduire considérablement la préparation, intuitif... Applaudissement = flatteur et non commun
- Timing : 17 min Fin octobre 2016, 3 sprints Depuis 1 mois et demi : les rôles sont clairs, le cadre est en place et l’environnement est propice. Mais Backlog toujours conséquent Nelson, qu’est-ce qu’on livre en février ?
- EXTREME QUOTATION QUI ESTIME ? Ceux qui font sont ceux qui savent, ou en tout cas plus que de manager de projet
- BUY A FEATURE Donner des informations claires à l’équipe sur la V1 Donner une compréhension large sur la v2
- Nelson, qu’est-ce qu’on livre en février ? Où sommes nous Scope évolutif Projection -> idée de la V1 + arbitrage toujours possible Nous avons une organisation, une vision, un product backlog, un cadre. Le projet démarré (3 sprints) - Savons : Où et quand nous arrivons Mais technique, comment notre projet est réalisé ?
- Timing : 25 min
- Stack déployé sur chaque environnement
- Stack déployé sur chaque environnement
- Timing : 31
- Clés: Création des environnements de façon agile : au fur et à mesure qu’on a le besoin co construction de l’environnement avec les équipes BNP Pourquoi différents environnements ? Comment l’artifact passe d’un environnement à l’environnement suivant Les environnements n’existaient pas au début du projet Parler de la qualité de la donnée sur les différents envs Agilite dans la partie tech aussi Inte: validation en cours du Sprint Volumétrie des données Ou sont faits les démo dans les différents environnements ?
- Timing : 35 Difficultés rencontrées sur une plateforme mutualisé Strategie de construction d’une nouvelle plateforme en parallèle
- Timing : 31 Différence de culture (pas de documentation vs trop procédurier)
- Différence de culture (pas de documentation vs trop procédurier) Minimiser les procédures Premier pas vers le DevOps
- Clés du succès: Automatiser une petite partie de la livraison permet de gagner beaucoup Donner des packages autoportants Se rapprocher des équipes de prod (se déplacer) Autogénérer la documentation
- Limiter l’intervention humaine => limiter les erreurs humains
- Timing : 36 Passage de relai vers l’interne : Bascule vers le RUN Automatisation DevOps Automatisation tests non régression Pensée : Nouveaux usage très facile assez magique Réalité : Enorme stack technique, Récupération et qualification des données complexes,
- [Nelson] Co construction : Intégration des utilisateurs finaux dès le début : bonnes fonctionnalités, facilité à distribuer. [Tomas] Environnement incrémental : Ne pas se bloquer sur la disponibilité des environnements, notre premier but dans la conception logiciel est de récupérer de l’expérience et du feedback [Jérôme] : Xebia/BNPP : 2 mondes différents, 2 cultures. S’avoir cohabiter est nécessaire, comment: Objectif commun partagé Limiter les procédures à ce qui est importants Faire l’effort de documenter Afterwork Il est important de faire les démo avec les contraintes de qualité plutôt que non faire et entrer dans un effet tunnel
- Timing : 40