Titre du slide
Collaboration en équipe Produit
Partie 1 : Culture Projet versus Culture Produit
Les caractéristiques du pr...
Titre du slide
Les caractéristiques du projet IT
Partie 1 – Diapositive 3
Un projet se caractérise par :
Un ou plusieurs objectifs (les livrables)
Une date de début et une...
Partie 1 – Diapositive 4
Un projet IT se caractérise par un besoin et un produit cible
Client (demandeur)
client interne o...
Partie 1 – Diapositive 5
Un projet IT se caractérise par une multitude d’équipes
Multi-Métiers Multi-Sites
Multi-Cultures ...
Partie 1 – Diapositive 6
Un projet IT se caractérise par une succession de phases
Phase Acteurs clés Livrables
Cadrage
(av...
Titre du slide
Les projets IT se caractérisent aussi souvent par leurs échecs
Partie 1 – Diapositive 8
Même le plus simple des projets IT peut échouer
http://projectcartoon.com
Partie 1 – Diapositive 9
Au final, entre 25% et 75% des projets IT sont concernés
Entre 25% et 75% * des projets IT réalis...
Partie 1 – Diapositive 10
Les raisons de l’échec sont connues à plusieurs niveaux
Métier Technologie
Organisation Humain
M...
Partie 1 – Diapositive 11
Les symptômes des projets IT en échec sont reconnaissables
« Organisation en silos »
?
??
« Effe...
Titre du slide
Pour réussir, les projets IT doivent adopter des bonnes pratiques
Partie 1 – Diapositive 13
L’histoire des projets IT est riche en publications structurantes
1970 – Modèle en cascade (« wa...
Partie 1 – Diapositive 14
Modèles et outils sont indispensables à tout projet IT
Les modèles et outils de gestion et de su...
Partie 1 – Diapositive 15
Ces modèles et outils s’inscrivent dans une stratégie IT globale
2
2
Stratégie IT
Référencement ...
Partie 1 – Diapositive 16
Ces modèles et outils sont promus par des autorités reconnues
Organismes de standardisation, édi...
Partie 1 – Diapositive 17
Exemples pour définir les étapes, rôles, et indicateurs…
Développement
Spécifications détaillées...
Partie 1 – Diapositive 18
…et exemples pour accroître la collaboration et la valeur
Modèle Scrum
Kanban board
Code
source
...
Titre du slide
Aujourd’hui, les projets IT ont une obligation de réussite
Partie 1 – Diapositive 20
Baisse des budgets, explosion des besoins
2008 2010 2014
Explosion
des besoins :
e-commerce,
mob...
Partie 1 – Diapositive 21
Les clients exigent un retour sur l’investissement rapide
La crise économique dans un contexte d...
Titre du slide
Les pratiques Agiles à la rescousse des projets IT
Partie 1 – Diapositive 23
Les pratiques Agiles sont d’abord et surtout un Manifeste
4 préceptes du Manifeste Agile, févrie...
Partie 1 – Diapositive 24
Le modèle Scrum en fer de lance des pratiques Agiles
Stand-up meeting
Product Backlog Sprint Pla...
Partie 1 – Diapositive 25
Les pratiques Agiles sont bien plus que des modèles et outils
Utiliser le modèle et les outils S...
Partie 1 – Diapositive 26
Les pratiques Agiles doivent être maîtrisées et personnalisées
Bien choisir les initiatives qui ...
Partie 1 – Diapositive 27
Dans le giron des pratiques Agiles : les pratiques Lean et XP
Lean XP (« Extreme Programming »)
...
Titre du slide
La nécessaire évolution de la collaboration dans les organisations IT
Partie 1 – Diapositive 29
La vraie Agilité requiert une organisation IT décomplexée
Agilité niveau 1 Agilité niveau 2
©Pok...
Partie 1 – Diapositive 30
L’organisation IT doit se remettre en cause continuellement
L’organisation et son écosystème
Ent...
Partie 1 – Diapositive 31
Abattre les murs des équipes, toujours dans l’intérêt du produit
Au final, le produit peut être ...
Partie 1 – Diapositive 32
Les « grands acteurs du numérique » montrent la voie
Les logos sont la propriété de leurs détent...
Titre du slide
Principes d’une culture de collaboration autour du produit
Partie 1 – Diapositive 34
Culture Produit = Culture + Produit
CULTURE, nf (définition UNESCO) : ensemble des traits distin...
Partie 1 – Diapositive 35
Centrer les objectifs de l’équipe sur le produit (pas le projet)
Produit
viable,
désirable et
ré...
Partie 1 – Diapositive 36
Impulser de la créativité et tester ses hypothèses avec le client
Découverte
Interroger les clie...
Partie 1 – Diapositive 37
Itérer en mesurant et en apprenant continuellement
DELIVRER
Produit
MESURER
Données
APPRENDRE
Id...
Partie 1 – Diapositive 38
Livrer continuellement des versions de qualité
Version
SNAPSHOT
« Produit
Minimum
Viable »
(MVP)...
Partie 1 – Diapositive 39
Communiquer de manière visuelle et transparente
A faire En cours Fait
Partager les
points de
blo...
Partie 1 – Diapositive 40
Réunir les talents requis au sein d’une équipe pluridisciplinaire
Représentant
UX Représentant
B...
Partie 1 – Diapositive 41
Forger l’identité et la confiance de l’équipe
Les photographies sont la propriété
de leurs déten...
Partie 1 – Diapositive 42
En résumé, les 7 fondements d’une équipe produit sont…
1. L’objectif d’un produit « Viable, Dési...
Titre du slide
Structure-type d’une équipe produit
Partie 1 – Diapositive 44
La démarche historique : réalisation d’un produit en mode projet
Equipe des
Concepteurs
Equipe d...
Partie 1 – Diapositive 45
Passage de N équipes projet à 1 équipe produit
Les rôles historiques gagnent en
responsabilité e...
Partie 1 – Diapositive 46
Des concepteurs qui se focalisent sur les spécifications utiles
Le concepteur décrit la solution...
Partie 1 – Diapositive 47
Des développeurs proactifs, rigoureux et communicants
Le développeur implémente techniquement la...
Partie 1 – Diapositive 48
Des exploitants rapprochés pour une mise en production rapide
L’exploitant est responsable de la...
Partie 1 – Diapositive 49
Des architectes accessibles et proches du terrain
L’architecte est responsables des choix de cou...
Partie 1 – Diapositive 50
Un chef de projet qui va au-delà de la coordination
Le chef de projet est responsable de la coor...
Partie 1 – Diapositive 51
Participation accrue des « UX », Testeurs et Utilisateurs
Le référent « UX » (pour « User eXperi...
Partie 1 – Diapositive 52
Le « Product Manager » comme nouveau représentant du produit
Le « Product Manager » est l’interf...
Partie 1 – Diapositive 53
Le « Technical Leader » comme nouveau référent des développeurs
Le « Technical Leader » est le r...
Partie 1 – Diapositive 54
Comment réaliser un produit avec une culture de collaboration
Utilisateurs
(heureux !)
Conceptio...
Titre du slide
Pour aller plus loin
Partie 1 – Diapositive 56
Bibliographie
 Marty Cagan, 2008, Inspired: How To Create Products Customers Love
 Eric Ries, ...
Prochain SlideShare
Chargement dans…5
×

Collaboration en Equipe Produit - Partie1

1 471 vues

Publié le

Première partie du cours sur la culture produit, pour la formation MIDO M2 SITN de l'Université Paris Dauphine.

Cette partie présente ce qu'est un projet et la nature des problèmes que rencontre généralement un projet, avant d'introduire les solutions - notamment issues des pratiques agiles - ayant mené à la promotion de la culture produit dans le domaine de l'IT.

Plan de la partie :
- Les caractéristiques du projet IT
- Les projets IT se caractérisent aussi souvent par leurs échecs
- Pour réussir, les projets IT doivent adopter des bonnes pratiques
- Aujourd’hui, les projets IT ont une obligation de réussite
- Les pratiques Agiles à la rescousse des projets IT
- La nécessaire évolution de la collaboration au sein des organisations IT
- Principes structurants d’une culture de collaboration autour du produit
- Structure-type d’une équipe produit
- Pour aller plus loin

Publié dans : Technologie
0 commentaire
1 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
1 471
Sur SlideShare
0
Issues des intégrations
0
Intégrations
18
Actions
Partages
0
Téléchargements
72
Commentaires
0
J’aime
1
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive
  • Un projet se caractérise par :

    1. OBJECTIFS : livrables qui peuvent être des logiciels, sites web, documents, etc

    2. DATES DE DEBUT ET DE FIN : peuvent être très espacées dans le temps

    3. CONTRAINTES : budget, temps, ressources humaines et matérielles, structure organisationnelle, qualité (performance, ergonomie, facilité d’utilisation, etc)

    Un projet est un PROCESSUS UNIQUE dans tous les cas (échec, succès) : processus qui n’est pas voué à se répéter continuellement

    Cette définition est commune à tous les projets (normes internationale ISO et norme française AFNOR), pas seulement aux projets IT
  • 1. Un projet se caractérise initialement par le besoin d’un client

    2. Dans le jargon des projets IT, le client est le demandeur :
    c’est celui qui exprime le besoin
    ce n’est pas nécessairement celui qui paie
    Ce n’est pas non plus nécessairement l’utilisateur final
    A titre d’exemple, le client peut être un client interne (souvent une direction métier ou une direction marketing) ou un client externe

    3. Le besoin exprimé par le client est ensuite traité par les différentes équipes projet (cf. slide)

    4. Le produit fini et déployé est mis à disposition des utilisateurs : il peut s’agir d’un logiciel, d’un site web
  • Un projet IT se caractérise par une multitude d’équipes
    Ces équipes représentent…

    2. Une multitude de Métiers : Plusieurs responsabilités, compétences, technologies, domaines métier…

    3. Une multitude de Sites : Plusieurs bâtiments, villes, régions, pays…

    4. Une multitude de Cultures : Plusieurs nationalités, langues, parcours personnels, tranches d’âge, …

    5. Une multitude d’Expériences : Plusieurs formations, projets antérieurs, anciennetés, niveaux de séniorité, …
  • 1. Un projet IT se caractérise par une succession de phases

    2. Le cas présenté ici est le plus complexe : il concerne de grandes organisations avec des processus détaillés et de nombreuses équipes

    3. Présentation des phases (cf. slide)

    4. D’autres phases peuvent s’ajouter, par exemple l’étude d’opportunité en phase de cadrage.
  • Même le plus simple des projets IT peut échouer !

    Cf. slide
  • Cf. slide
  • Mauvaise compréhension des besoins
    Mauvaise spécification ou absence de spécifications
    Mauvaise estimation des charges ou planification
    Absence ou mauvaise utilisation de modèles et d’outils
    Collaboration absente ou insuffisante entre les équipes
    Manque d’engagement des participants
    Défaut de compétences pour les besoins du projet
    Choix technologiques non adaptés au besoin (« Technology push »)
    ADAPTABILITE INSUFFISANTE : les équipes n’arrivent pas à s’adapter au changement
  • Les symptômes des projets IT en échec sont souvent les mêmes

    Deux symptômes principaux :

    1. ORGANISATION EN SILOS
    Les équipes se parlent rarement
    Les communications se font par email et par envois de documents
    Les équipes gardent des informations
    Les équipes sont éloignées
    Les équipes sont sur la défensive
    Les formalités sont nombreuses
    Il y a peu de transversalité

    2. EFFET TUNNEL
    L’état d’avancement du projet n’est pas certain pour les participants
    La date de fin bouge continuellement, les échéances ne sont pas tenues
    Les équipes ne sont pas confiantes sur le résultat du projet
  • Cf. slide
  • Bonnes pratiques :
    Etape du projet : mise en œuvre des phases décrites précédemment
    Indicateurs : principe d’un tableau de bord de suivi
    Logiciels de gestion de documents et de sources : knowledge management et stratégie de gestion des sources applicatives (parties 2 et 3)
    Rituels d’équipe et comités : par exemple comité de direction
    Gouvernance : équipes transverses
  • STRATEGIE IT : découle de la stratégie de l’entreprise
    Les bonnes pratiques impactent toutes les couches du modèle d’urbanisation
  • AUTRES EXEMPLES :
    - Matrice de risques
  • AUTRES EXEMPLES :
    - LEAN
  • 2008 : crise des subprimes
    2010 : crise économique en Europe (Grèce)
  • INSISTER SUR LE « sans dépendance aucune à un modèle ou à un outil »
    DETAILLER LES POINTS 1 A 4
  • En particulier si le projet conserve :
    des clients peu impliqués dans l’exécution des projets
    des équipes en « silo » ou trop géographiquement éloignées
    des processus projet internes trop longs
    des outils limités ou des participants réfractaires au changement
  • Keynote de Alistair Cockburn (co-auteur du Manifeste Agile), ScrumDay 2014 :
    « The Agile Manifesto invites wimpy-ness »

    Ne pas en déduire par exemple que l’agilité n’implique pas de documentation !
  • Rapprochement des participants : inclut le client
  • Question à se poser pour CHAQUE PRODUIT
    Réponses évolutives dans le temps
  • Changer les équipes
    Revoir les modes de collaboration
  • Produit-centric = Consumer-centric
  • Design Thinking
    Business = besoins du marché, besoins du métier, modèle économique ; offre freemium, premium ?
    Usage = UX, tarification, différenciation, ergonomie, performance
    Techno = plateformes, appareils, expertise requise, évolutivité, maintenance

    Objectifs SMART = mesurables, etc
  • Design Thinking
  • KPIs = Key Performance Indicators
  • MVP alias POC (Proof of concept)

    Livraison d’incréments de produit qui augmentent la valeur du produit

    War time versus Peace time
  • Vision fine + tableau de bord global
  • Equipe pluridisciplinaire et auto-organisée (alias « Feature Team »)

    Salle dédiée

    ATTENTION, c’est beaucoup plus difficile qu’il n’y paraît (surtout dans de grandes organisations déjà bien établies)

    Note : pas de chef de projet représenté ici, pas forcément nécessaire
  • Culture Hacking : Exemple de Zappos
    Rituels et jeux
    Jargon
    Notions de team, family, tribe
  • Vue complète valable pour les grandes organisations
    Démarque séquentielle avec N équipes projet
  • Concepteur fonctionnel ou technique
    Pas de diagrammes UML qui servent à rien !
  • Software Craftmanship
  • Architecte logiciel
    Architecte production
    Intégré à N équipes
    Il serait un dev senior faisant partie d’un groupe transverse
    Création ET croissance
  • Testeurs : TDD ou Test Driven Development
  • Vue complète valable pour les grandes organisations
  • Collaboration en Equipe Produit - Partie1

    1. 1. Titre du slide Collaboration en équipe Produit Partie 1 : Culture Projet versus Culture Produit Les caractéristiques du projet IT Les projets IT se caractérisent aussi souvent par leurs échecs Pour réussir, les projets IT doivent adopter des bonnes pratiques Aujourd’hui, les projets IT ont une obligation de réussite Les pratiques Agiles à la rescousse des projets IT La nécessaire évolution de la collaboration au sein des organisations IT Principes structurants d’une culture de collaboration autour du produit Structure-type d’une équipe produit Pour aller plus loin Alexandre Estela (alexandre@estela.fr) Université Paris Dauphine Management & coaching d’équipes Produit Cours MIDO M2 SITN
    2. 2. Titre du slide Les caractéristiques du projet IT
    3. 3. Partie 1 – Diapositive 3 Un projet se caractérise par : Un ou plusieurs objectifs (les livrables) Une date de début et une date de fin Des contraintes de moyens et de qualité Norme ISO et AFNOR, s’appliquant notamment aux projets IT de développement logiciel DEBUT FIN ESTIMEE FIN REELLE Retard (ou abandon) Exécution Cadrage (avant- projet) Qu’il soit un succès ou un échec, tout projet est un processus UNIQUE. Un projet IT se caractérise comme un projet au sens ISO
    4. 4. Partie 1 – Diapositive 4 Un projet IT se caractérise par un besoin et un produit cible Client (demandeur) client interne ou externe, directions métier, marketing, … Equipes projet Expression du besoin Déploiement des programmesUtilisation du produit fini (logiciel, site web, …) Transformation du besoin en exigences Rédaction des spécifications Codage des programmes Test et Recette des programmesUtilisateurs
    5. 5. Partie 1 – Diapositive 5 Un projet IT se caractérise par une multitude d’équipes Multi-Métiers Multi-Sites Multi-Cultures Multi-Expériences Multi-Equipes
    6. 6. Partie 1 – Diapositive 6 Un projet IT se caractérise par une succession de phases Phase Acteurs clés Livrables Cadrage (avant-projet) Client, Chef de projet Liste des exigences, Planning, Estimation des coûts Conception Concepteurs fonctionnels, Concepteurs techniques, Architectes Spécifications fonctionnelles, Spécifications techniques, Dossier d’architecture Développement Développeurs Programmes, Guides d’exploitation Recette Testeurs Cahiers de recette, Procès-verbal de recette Mise en production Exploitants Produit finalisé, testé et déployé Suivi de la production (exploitation) Exploitants Utilisation Utilisateurs Maintenance (corrective et évolutive) Chef de projet, Concepteurs, Architectes, Développeurs, Testeurs, Exploitants ExécutionduProjet
    7. 7. Titre du slide Les projets IT se caractérisent aussi souvent par leurs échecs
    8. 8. Partie 1 – Diapositive 8 Même le plus simple des projets IT peut échouer http://projectcartoon.com
    9. 9. Partie 1 – Diapositive 9 Au final, entre 25% et 75% des projets IT sont concernés Entre 25% et 75% * des projets IT réalisés sont considérés en échec, c’est-à-dire qu’ils sont concernés par au moins l’une des affirmations suivantes : Livraison en retard Dépassement des estimations de coût Abandon en cours de développement ou de recette * Les statistiques dépendent des domaines d’activité, de la taille des sociétés et du périmètre des projets IT, mais toutes les études rapportent en conclusion un nombre inquiétant d’échecs. Sources : Gartner, IBM, McKinsey, Standish Group, …
    10. 10. Partie 1 – Diapositive 10 Les raisons de l’échec sont connues à plusieurs niveaux Métier Technologie Organisation Humain Mauvaise compréhension Collaboration insuffisante Manque d’engagement Mauvaise spécification Défaut de compétences Choix technologiques non adaptés Adaptabilité insuffisanteMauvaise estimation Mauvaise utilisation de modèles et d’outils
    11. 11. Partie 1 – Diapositive 11 Les symptômes des projets IT en échec sont reconnaissables « Organisation en silos » ? ?? « Effet tunnel » Si vous constatez ces symptômes, le projet est probablement en voie d’échec…
    12. 12. Titre du slide Pour réussir, les projets IT doivent adopter des bonnes pratiques
    13. 13. Partie 1 – Diapositive 13 L’histoire des projets IT est riche en publications structurantes 1970 – Modèle en cascade (« waterfall ») 1975 – Livre « The Mythical Man-Month » 1980 – Modèle du Cycle en V 1986 – Première mention des principes de « Scrum » 1996 – Principes de XP (« Extreme programming ») et d’intégration continue 1999 – Popularisation conjointe du modèle RUP et du langage UML 1994 – Livre « Design Patterns : Elements of Reusable OO Software » 2003 – Principes du « Lean Software Development » 2001 – Manifeste Agile 1991 – Débuts du modèle CMMI pour les fournisseurs de logiciels 1989 – Débuts du modèle ITIL pour le management du Système d’Information 2009 – Manifeste du « Software Craftsmanship »
    14. 14. Partie 1 – Diapositive 14 Modèles et outils sont indispensables à tout projet IT Les modèles et outils de gestion et de suivi de projet augmentent significativement les chances de réussite du projet IT en se basant sur des bonnes pratiques issues de nombreux retours d’expérience : Définition d’étapes du projet à dérouler de manière successive Utilisation d’indicateurs pour le suivi Utilisation de logiciels de gestion de documents et sources du projet Mise en place de rituels d’équipe et de comités projet Mise en place de gouvernance et d’éléments transverses aux projets
    15. 15. Partie 1 – Diapositive 15 Ces modèles et outils s’inscrivent dans une stratégie IT globale 2 2 Stratégie IT Référencement des modèles et outils des projets Equipes métier Equipes fonctionnelles Equipes applicatives Equipes infrastructure : : : :: :
    16. 16. Partie 1 – Diapositive 16 Ces modèles et outils sont promus par des autorités reconnues Organismes de standardisation, éditeurs de logiciels ou bien sociétés de conseil, fournissent de la documentation, des formations et des certifications sur ces modèles et outils aux équipes des projets. Les logos et illustrations sont la propriété de leurs détenteurs respectifs.
    17. 17. Partie 1 – Diapositive 17 Exemples pour définir les étapes, rôles, et indicateurs… Développement Spécifications détaillées Spécifications générales Exigences Tests unitaires Tests d’intégration Recette Modèle du Cycle en V Matrice RACI Client Chef de projet Concepteur Développeur Exigences R A C I Conception I A R I Développement I A C R Test I A C R Recette I A R C Diagramme de Gantt
    18. 18. Partie 1 – Diapositive 18 …et exemples pour accroître la collaboration et la valeur Modèle Scrum Kanban board Code source Produit INTEGRATION AUTOMATISEE Plateforme d’intégration continue Pratiques dites « Agiles » propagées dans les années 2000 :
    19. 19. Titre du slide Aujourd’hui, les projets IT ont une obligation de réussite
    20. 20. Partie 1 – Diapositive 20 Baisse des budgets, explosion des besoins 2008 2010 2014 Explosion des besoins : e-commerce, mobile apps, Big Data, Internet of things… Baisse et stagnation des budgets des projets IT
    21. 21. Partie 1 – Diapositive 21 Les clients exigent un retour sur l’investissement rapide La crise économique dans un contexte de nouveaux usages technologiques, exige des équipes projet de « faire davantage avec moins de moyens ». Les clients demandent des produits avec uniquement les fonctionnalités utiles, livrées pour moins cher et plus rapidement. Les projets IT se sont donc focalisés sur des modes de travail privilégiant : Une meilleure prise en compte des besoins réels du client et du marché Une livraison accélérée de versions viables du produit Une amélioration du « time-to-market », c’est-à-dire la capacité à être réactif pour fournir des évolutions et des corrections du produit Une réduction des coûts des projets à travers la simplification des processus internes et du mode de fonctionnement des équipes
    22. 22. Titre du slide Les pratiques Agiles à la rescousse des projets IT
    23. 23. Partie 1 – Diapositive 23 Les pratiques Agiles sont d’abord et surtout un Manifeste 4 préceptes du Manifeste Agile, février 2001 : Les individus et leurs interactions avant les processus et les outils Du logiciel qui fonctionne avant une documentation exhaustive La collaboration avec les clients avant la négociation contractuelle L’adaptation au changement avant le suivi d’un plan Les pratiques Agiles sont l’application de ces préceptes qui ont pour objectif, sans dépendance aucune à un modèle ou à un outil, d’apporter : 1. Plus de collaboration 2. Plus de valeur au produit 3. Plus de satisfaction au client 4. Plus de réactivité
    24. 24. Partie 1 – Diapositive 24 Le modèle Scrum en fer de lance des pratiques Agiles Stand-up meeting Product Backlog Sprint PlanningSprint (Itération) Burndown chart # User Story Story points 1 En tant que client, je veux pouvoir trouver les voitures classées par prix 5 2 En tant que client, je veux pouvoir voir la fiche détaillée d'une voiture 5 3 En tant que client, je veux pouvoir acheter une voiture 8 4 En tant qu'administrateur, je veux pouvoir voir la liste des clients 3 Rétrospectives
    25. 25. Partie 1 – Diapositive 25 Les pratiques Agiles sont bien plus que des modèles et outils Utiliser le modèle et les outils Scrum (ou Kanban, etc) ne signifie pas nécessairement travailler selon les préceptes du Manifeste Agile !
    26. 26. Partie 1 – Diapositive 26 Les pratiques Agiles doivent être maîtrisées et personnalisées Bien choisir les initiatives qui conviennent au contexte du projet, de l’équipe et de l’organisation, en les adaptant si nécessaire, au risque de mettre en péril le projet !
    27. 27. Partie 1 – Diapositive 27 Dans le giron des pratiques Agiles : les pratiques Lean et XP Lean XP (« Extreme Programming ») Mesure de la valeur à travers le code « Pair programming » Tests complets et systématiques Intégration et livraison continue Refactoring et re-design continu Outillage automatisé « Pas de gaspillage » « Build – Mesure – Learn » Démarche Incrémentale Indicateurs de performance Amélioration continue Vision d’ensemble Valeurs et leviers de l’Agilité
    28. 28. Titre du slide La nécessaire évolution de la collaboration dans les organisations IT
    29. 29. Partie 1 – Diapositive 29 La vraie Agilité requiert une organisation IT décomplexée Agilité niveau 1 Agilité niveau 2 ©Pokemon Pratiques Agiles reposant sur… Pyramides & silos Participants dispersés Responsabilités isolées Processus segmentés Equipe(s) projet Pratiques Agiles reposant sur… Organisation horizontale Participants rapprochés Responsabilités partagées Processus minimaux Equipe produit
    30. 30. Partie 1 – Diapositive 30 L’organisation IT doit se remettre en cause continuellement L’organisation et son écosystème Entités Métier, Marketing, RH, Légal… Entités Design, Technique, Qualité… Concurrence & Partenaires Acheteurs & Utilisateurs Quelle collaboration pour délivrer le meilleur produit au jour d’aujourd’hui ? Par fonctionnalité ? Par expertise ? Par localisation ? Par affinité ? Par influence ?
    31. 31. Partie 1 – Diapositive 31 Abattre les murs des équipes, toujours dans l’intérêt du produit Au final, le produit peut être un logiciel commercialisé autant qu’un service de support technique interne.
    32. 32. Partie 1 – Diapositive 32 Les « grands acteurs du numérique » montrent la voie Les logos sont la propriété de leurs détenteurs respectifs.
    33. 33. Titre du slide Principes d’une culture de collaboration autour du produit
    34. 34. Partie 1 – Diapositive 34 Culture Produit = Culture + Produit CULTURE, nf (définition UNESCO) : ensemble des traits distinctifs, spirituels et matériels, intellectuels et affectifs, qui caractérisent un groupe social ou société. PRODUIT, nm (définition e-marketing.fr) : objet matériel, service (…) conçu, créé et offert à la consommation dans le but de satisfaire un besoin identifié. Chaque culture produit est unique en fonction du produit et de l’équipe. Grandes sources d’inspiration dans le cadre du développement logiciel : Pratiques Agiles, Lean, XP « Design Thinking » « Lean Startup » « Feature Teams »
    35. 35. Partie 1 – Diapositive 35 Centrer les objectifs de l’équipe sur le produit (pas le projet) Produit viable, désirable et réalisable Objectif de Business Satisfaire un besoin réel avec un modèle économique viable Objectif d’Usage Proposer une expérience utilisateur (UX) tangible et unique Objectif de Technologie Choisir les langages et plateformes adaptés et disponibles (Design Thinking)
    36. 36. Partie 1 – Diapositive 36 Impulser de la créativité et tester ses hypothèses avec le client Découverte Interroger les clients et comprendre les attentes Définition du problème Formuler le besoin de manière simple Idéation « Brainstormer » et imaginer plusieurs solutions Prototypage Implémenter une solution répondant au besoin Validation Obtenir du feedback sur la solution auprès des clients (Design Thinking)
    37. 37. Partie 1 – Diapositive 37 Itérer en mesurant et en apprenant continuellement DELIVRER Produit MESURER Données APPRENDRE Idées (Lean Startup)
    38. 38. Partie 1 – Diapositive 38 Livrer continuellement des versions de qualité Version SNAPSHOT « Produit Minimum Viable » (MVP) Version SNAPSHOT « Release » Version 2 Version SNAPSHOT « Release » Version 3 Livraison incrémentale avec assurance qualité (Lean Startup)
    39. 39. Partie 1 – Diapositive 39 Communiquer de manière visuelle et transparente A faire En cours Fait Partager les points de blocage Annoncer ce qui sera accompli aujourd’hui Rappeler ce qui a été accompli hier 1 2 3
    40. 40. Partie 1 – Diapositive 40 Réunir les talents requis au sein d’une équipe pluridisciplinaire Représentant UX Représentant Business ClientEquipe Produit Représentant Architecture Production Utilisateurs Non- participants aux objectifs du produit : ils restent en-dehors ! Développeurs Concepteur Testeur
    41. 41. Partie 1 – Diapositive 41 Forger l’identité et la confiance de l’équipe Les photographies sont la propriété de leurs détenteurs respectifs.
    42. 42. Partie 1 – Diapositive 42 En résumé, les 7 fondements d’une équipe produit sont… 1. L’objectif d’un produit « Viable, Désirable et Réalisable » 2. La créativité couplée à la possibilité de valider des hypothèses 3. Les itérations, la mesure avec des KPIs et l’amélioration continue 4. Les livraisons régulières d’incréments de valeur et de qualité 5. La communication permanente, transparente et visuelle 6. L’équipe pluridisciplinaire et auto-organisée 7. La culture de l’équipe forgée par ses membres
    43. 43. Titre du slide Structure-type d’une équipe produit
    44. 44. Partie 1 – Diapositive 44 La démarche historique : réalisation d’un produit en mode projet Equipe des Concepteurs Equipe des Développeurs Equipe des Testeurs Equipe des « UX » Equipe des Exploitants Equipe des Architectes Utilisateurs Conception Développement Test Production Coordination par le chef de projet
    45. 45. Partie 1 – Diapositive 45 Passage de N équipes projet à 1 équipe produit Les rôles historiques gagnent en responsabilité et en autonomie : Concepteur Développeur Exploitant Architecte Chef de projet « UX » Testeur Utilisateur De nouveaux rôles apparaissent pour faire croître la culture recherchée : « Product Manager » « Technical Leader »
    46. 46. Partie 1 – Diapositive 46 Des concepteurs qui se focalisent sur les spécifications utiles Le concepteur décrit la solution pour satisfaire le besoin exprimé par le client : les spécifications fonctionnelles décrivent les fonctionnalités attendues, tandis que les spécifications techniques décrivent leur implémentation. Avant Maintenant  Fournit le minimum nécessaire pour permettre aux développeurs de commencer leur travail  Dispose d’un contact privilégié avec le client et/ou les utilisateurs afin de décrire uniquement ce qui est utile  Produit des spécifications qui ne sont pas toujours utiles, maintenables ou comprises par les développeurs  Ne dispose pas d’une proximité avec le client et a du mal à bien décrire la solution requise pour le besoin
    47. 47. Partie 1 – Diapositive 47 Des développeurs proactifs, rigoureux et communicants Le développeur implémente techniquement la solution sur la base des spécifications fonctionnelles et techniques. Il réalise des morceaux (« incréments ») du produit qu’il teste de manière unitaire. Avant Maintenant  Est intéressé de comprendre en profondeur la finalité du produit  Fournit des incréments testés et de qualité (« Software Craftsmanship »)  Propose des idées pour améliorer techniquement le produit : performance, maintenabilité, …  Ne dispose pas d’une proximité avec les concepteurs pour poser librement ses questions sur les spécifications  Ne teste pas systématiquement les incréments de produit qu’il délivre  N’est pas dans une démarche d’amélioration du produit
    48. 48. Partie 1 – Diapositive 48 Des exploitants rapprochés pour une mise en production rapide L’exploitant est responsable de la mise en production et du suivi quotidien du produit déployé auprès des utilisateurs. Il surveille les activités, et remonte les incidents aux équipes de développement pour des corrections de bug. Avant Maintenant  Est intégré à l’équipe de réalisation et communique en amont ses besoins de surveillance, monitoring, sécurité, …  Echange facilement avec les développeurs pour déployer et suivre en production des versions viables (organisation en « Devops »)  Ne participe quasiment pas à la conception technique ou à l’architecture de la solution  Intervient toujours en fin de projet  « Sanctuarise » les environnements de Production en limitant les accès, y compris pour l’identification des bugs
    49. 49. Partie 1 – Diapositive 49 Des architectes accessibles et proches du terrain L’architecte est responsables des choix de couches et solutions applicatives, de frameworks, d’infrastructure, de configuration logicielle… Ses choix peuvent concerner aussi bien la phase de développement que la phase de production. Avant Maintenant  Est intégré à N équipes produit  Participe à la création et à la croissance du squelette du produit  Fournit des recommandations en fonction des besoins du produit  Tend à se confondre avec le rôle de développeur sénior  Suit N équipes projet  Fournit des exemples de code  Fournit des recommandations indépendamment de l’avancée produit  Est considéré plus important que le développeur (« Syndrome de la tour d’ivoire »)
    50. 50. Partie 1 – Diapositive 50 Un chef de projet qui va au-delà de la coordination Le chef de projet est responsable de la coordination des différentes équipes intervenant sur un projet IT. Il tient à jour les plannings et autres tableaux de bord permettant de suivre l’avancée du projet. Avant Maintenant  Joue le rôle de facilitateur en cas de blocage  Tend à voir ses responsabilités redispatchées au sein de l’équipe produit unifiée et auto-organisée, non pas sur une durée projet mais continuellement  Est l’interface entre les différentes équipes participant à un moment donné au projet  Informe le client sur l’avancée du projet et ses points de blocage
    51. 51. Partie 1 – Diapositive 51 Participation accrue des « UX », Testeurs et Utilisateurs Le référent « UX » (pour « User eXperience ») a la responsabilité de formaliser les usages des produits par les utilisateurs. Il guide l’équipe produit sur les parcours des utilisateurs, les interfaces utilisateur (« UI »), la maniabilité, l’ergonomie, la performance attendue, etc. Le testeur est en charge de la définition et de l’exécution de différents types de test de « bout-en-bout ». Dans une équipe produit, ces travaux se déroulement continuellement, et pas seulement une fois le produit « jugé terminé ». Les tests sont ainsi définis dés la conception et utilisés en phase de développement. Un panel d’utilisateurs accessible en permanence (ou une représentation des utilisateurs) est important pour une équipe produit car il permet de valider des hypothèses à n’importe quel moment, par exemple en effectuant des démonstrations, et pas seulement une fois le produit « jugé terminé ».
    52. 52. Partie 1 – Diapositive 52 Le « Product Manager » comme nouveau représentant du produit Le « Product Manager » est l’interface entre l’équipe Produit et les autres parties prenantes : client(s), RH, légal, marketing, finance, etc. Il est responsable de la vision et la feuille de route du produit.  Dispose de la double vision de la stratégie produit et des contraintes de réalisation  Priorise les fonctionnalités à ajouter dans le produit, après négociation avec les autres parties prenantes et évaluation de la faisabilité avec l’équipe produit  Peut être assimilé au « Product Owner » du modèle Scrum  Est responsable de la performance du produit au travers d’indicateurs publics  Peut également être responsable de l’équipe produit (au sens RH)
    53. 53. Partie 1 – Diapositive 53 Le « Technical Leader » comme nouveau référent des développeurs Le « Technical Leader » est le référent principal au sein de l’équipe produit sur les aspects techniques. Il s’agit d’un développeur sénior, responsable de la définition des bonnes pratiques de développement et de livraison continue.  Définit les bonnes pratiques techniques (normes de codage, outillage de développement, processus de livraison, gestion des versions de produit, …)  Encadre et forme les développeurs, effectue des relectures de code  Est le responsable principal de la qualité et de la maintenabilité des sources  Il peut assumer les responsabilités de « Scrum Master » du modèle Scrum  Peut également être responsable des développeurs (au sens RH)
    54. 54. Partie 1 – Diapositive 54 Comment réaliser un produit avec une culture de collaboration Utilisateurs (heureux !) Conception Développement Test Production Coordination par le « Product Manager » (ou un chef de projet) Concepteurs « UX » Développeurs « Technical Leader » (ou Architecte) Panel d’utilisateurs Testeurs Exploitants Equipe produit auto-organisée
    55. 55. Titre du slide Pour aller plus loin
    56. 56. Partie 1 – Diapositive 56 Bibliographie  Marty Cagan, 2008, Inspired: How To Create Products Customers Love  Eric Ries, 2011, The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses  Mike Cohn, 2009, Succeeding with Agile: Software Development Using Scrum  Gojko Adzic, 2012, Impact Mapping: Making a Big Impact with Software Products and Projects  Jeff Gothelf, 2013, Lean UX: Applying Lean Principles to Improve User Experience

    ×