Collaboration en Equipe Produit - Partie1

56
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 lexandre Estela ([email protected]) Université Paris Dauphin anagement & coaching d’équipes Produit Cours MIDO M2 SITN

Transcript of Collaboration en Equipe Produit - Partie1

Page 1: Collaboration en Equipe Produit - Partie1

Titre du slideCollaboration en équipe Produit

Partie 1 : Culture Projet versus Culture Produit

Les caractéristiques du projet ITLes projets IT se caractérisent aussi souvent par leurs échecsPour réussir, les projets IT doivent adopter des bonnes pratiquesAujourd’hui, les projets IT ont une obligation de réussiteLes pratiques Agiles à la rescousse des projets ITLa nécessaire évolution de la collaboration au sein des organisations ITPrincipes structurants d’une culture de collaboration autour du produitStructure-type d’une équipe produitPour aller plus loin

Alexandre Estela ([email protected]) Université Paris DauphineManagement & coaching d’équipes Produit Cours MIDO M2 SITN

Page 2: Collaboration en Equipe Produit - Partie1

Titre du slide

Les caractéristiques du projet IT

Page 3: Collaboration en Equipe Produit - Partie1

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

Page 4: Collaboration en Equipe Produit - Partie1

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 programmes

Utilisation du produit fini

(logiciel, site web, …)

Transformation du besoin en exigences

Rédaction des spécifications

Codage des programmesTest et Recette des

programmesUtilisateurs

Page 5: Collaboration en Equipe Produit - Partie1

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

Page 6: Collaboration en Equipe Produit - Partie1

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 UtilisateursMaintenance(corrective et évolutive)

Chef de projet, Concepteurs, Architectes,Développeurs,Testeurs,Exploitants

Exéc

utio

n du

Pr

ojet

Page 7: Collaboration en Equipe Produit - Partie1

Titre du slide

Les projets IT se caractérisent aussi souvent par leurs échecs

Page 8: Collaboration en Equipe Produit - Partie1

Partie 1 – Diapositive 8

Même le plus simple des projets IT peut échouer

http://projectcartoon.com

Page 9: Collaboration en Equipe Produit - Partie1

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, …

Page 10: Collaboration en Equipe Produit - Partie1

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é insuffisante

Mauvaise estimation

Mauvaise utilisation de modèles et

d’outils

Page 11: Collaboration en Equipe Produit - Partie1

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…

Page 12: Collaboration en Equipe Produit - Partie1

Titre du slide

Pour réussir, les projets IT doivent adopter des bonnes pratiques

Page 13: Collaboration en Equipe Produit - Partie1

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 continue1999 – 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 logiciels1989 – Débuts du modèle ITIL pour le management du Système d’Information

2009 – Manifeste du « Software Craftsmanship »

Page 14: Collaboration en Equipe Produit - Partie1

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 successiveUtilisation d’indicateurs pour le suiviUtilisation de logiciels de gestion de documents et sources du projetMise en place de rituels d’équipe et de comités projetMise en place de gouvernance et d’éléments transverses aux projets

Page 15: Collaboration en Equipe Produit - Partie1

Partie 1 – Diapositive 15

Ces modèles et outils s’inscrivent dans une stratégie IT globale

22

Stratégie ITRéférencement des modèles et outils des projets

Equipes métier

Equipes fonctionnelles

Equipes applicatives

Equipes infrastructure :: : : : :

Page 16: Collaboration en Equipe Produit - Partie1

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.

Page 17: Collaboration en Equipe Produit - Partie1

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éveloppeurExigences R A C IConception I A R IDéveloppement I A C RTest I A C RRecette I A R C

Diagramme de Gantt

Page 18: Collaboration en Equipe Produit - Partie1

Partie 1 – Diapositive 18

…et exemples pour accroître la collaboration et la valeur

Modèle Scrum

Kanban board

Codesource

ProduitINTEGRATION AUTOMATISEE

Plateforme d’intégration

continue

Pratiques dites « Agiles » propagées dans les années 2000 :

Page 19: Collaboration en Equipe Produit - Partie1

Titre du slide

Aujourd’hui, les projets IT ont une obligation de réussite

Page 20: Collaboration en Equipe Produit - Partie1

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 stagnationdes budgetsdes projets IT

Page 21: Collaboration en Equipe Produit - Partie1

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 produitUne amélioration du « time-to-market », c’est-à-dire la capacité à être réactif pour fournir des évolutions et des corrections du produitUne réduction des coûts des projets à travers la simplification des processus internes et du mode de fonctionnement des équipes

Page 22: Collaboration en Equipe Produit - Partie1

Titre du slide

Les pratiques Agiles à la rescousse des projets IT

Page 23: Collaboration en Equipe Produit - Partie1

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 outilsDu logiciel qui fonctionne avant une documentation exhaustiveLa collaboration avec les clients avant la négociation contractuelleL’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 collaboration2. Plus de valeur au produit3. Plus de satisfaction au client4. Plus de réactivité

Page 24: Collaboration en Equipe Produit - Partie1

Partie 1 – Diapositive 24

Le modèle Scrum en fer de lance des pratiques Agiles

Stand-up meeting

Product Backlog

Sprint Planning Sprint (Itération)

Burndown chart

# User Story Story points

1En tant que client, je veux pouvoir trouver les voitures classées par prix

5

2En 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

4En tant qu'administrateur, je veux pouvoir voir la liste des clients

3

Rétrospectives

Page 25: Collaboration en Equipe Produit - Partie1

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 !

Page 26: Collaboration en Equipe Produit - Partie1

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 !

Page 27: Collaboration en Equipe Produit - Partie1

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ématiquesIntégration et livraison continueRefactoring et re-design continu

Outillage automatisé

« Pas de gaspillage »« Build – Mesure – Learn »Démarche Incrémentale

Indicateurs de performanceAmélioration continue

Vision d’ensemble

Valeurs et leviers de l’Agilité

Page 28: Collaboration en Equipe Produit - Partie1

Titre du slide

La nécessaire évolution de la collaboration dans les organisations IT

Page 29: Collaboration en Equipe Produit - Partie1

Partie 1 – Diapositive 29

La vraie Agilité requiert une organisation IT décomplexée

Agilité niveau 1 Agilité niveau 2

© P

okem

on

Pratiques Agiles reposant sur…Pyramides & silos

Participants dispersésResponsabilités isoléesProcessus segmentés

Equipe(s) projet

Pratiques Agiles reposant sur…Organisation horizontaleParticipants rapprochés

Responsabilités partagéesProcessus minimaux

Equipe produit

Page 30: Collaboration en Equipe Produit - Partie1

Partie 1 – Diapositive 30

L’organisation IT doit se remettre en cause continuellement

L’organisation et son écosystème

EntitésMétier,

Marketing,RH, Légal…

EntitésDesign,

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 ?

Page 31: Collaboration en Equipe Produit - Partie1

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.

Page 32: Collaboration en Equipe Produit - Partie1

Partie 1 – Diapositive 32

Les « grands acteurs du numérique » montrent la voie

Les logos sont la propriété de leurs détenteurs respectifs.

Page 33: Collaboration en Equipe Produit - Partie1

Titre du slide

Principes d’une culture de collaboration autour du produit

Page 34: Collaboration en Equipe Produit - Partie1

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 »

Page 35: Collaboration en Equipe Produit - Partie1

Partie 1 – Diapositive 35

Centrer les objectifs de l’équipe sur le produit (pas le projet)

Produitviable,

désirable etré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)

Page 36: Collaboration en Equipe Produit - Partie1

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)

Page 37: Collaboration en Equipe Produit - Partie1

Partie 1 – Diapositive 37

Itérer en mesurant et en apprenant continuellement

DELIVRER

Produit

MESURER

Données

APPRENDRE

Idées

(Lean Startup)

Page 38: Collaboration en Equipe Produit - Partie1

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)

Page 39: Collaboration en Equipe Produit - Partie1

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

Page 40: Collaboration en Equipe Produit - Partie1

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

Page 41: Collaboration en Equipe Produit - Partie1

Partie 1 – Diapositive 41

Forger l’identité et la confiance de l’équipe

Les photographies sont la propriété de leurs détenteurs

respectifs.

Page 42: Collaboration en Equipe Produit - Partie1

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èses3. Les itérations, la mesure avec des KPIs et l’amélioration

continue4. Les livraisons régulières d’incréments de valeur et de qualité5. La communication permanente, transparente et visuelle6. L’équipe pluridisciplinaire et auto-organisée7. La culture de l’équipe forgée par ses membres

Page 43: Collaboration en Equipe Produit - Partie1

Titre du slide

Structure-type d’une équipe produit

Page 44: Collaboration en Equipe Produit - Partie1

Partie 1 – Diapositive 44

La démarche historique : réalisation d’un produit en mode projet

Equipe des Concepteurs

Equipe des Développeur

sEquipe des

Testeurs

Equipe des « UX »

Equipe des Exploitants

Equipe des Architectes

Utilisateurs

Conception Développement Test Production

Coordination par le chef de projet

Page 45: Collaboration en Equipe Produit - Partie1

Partie 1 – Diapositive 45

Passage de N équipes projet à 1 équipe produit

Les rôles historiques gagnent en responsabilité et en

autonomie :

ConcepteurDéveloppeur

ExploitantArchitecte

Chef de projet« UX »Testeur

Utilisateur

De nouveaux rôles apparaissent pour faire croître

la culture recherchée :

« Product Manager »« Technical Leader »

Page 46: Collaboration en Equipe Produit - Partie1

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

Page 47: Collaboration en Equipe Produit - Partie1

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

Page 48: Collaboration en Equipe Produit - Partie1

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

Page 49: Collaboration en Equipe Produit - Partie1

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 »)

Page 50: Collaboration en Equipe Produit - Partie1

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

Page 51: Collaboration en Equipe Produit - Partie1

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é ».

Page 52: Collaboration en Equipe Produit - Partie1

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)

Page 53: Collaboration en Equipe Produit - Partie1

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)

Page 54: Collaboration en Equipe Produit - Partie1

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

ExploitantsEquipe produit auto-organisée

Page 55: Collaboration en Equipe Produit - Partie1

Titre du slide

Pour aller plus loin

Page 56: Collaboration en Equipe Produit - Partie1

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