Directeur de produit

Le rôle de "client" dans Scrum s'appelle Product Owner. Je l'ai traduit jusqu'à maintenant par propriétaire de produit. Je joue ce rôle sur des projets, je le connais bien, mais le terme propriétaire ne m'a jamais bien plu. Client ne convient pas non plus. Je viens de lire How to be a Product Director de Brian Marick. Il propose d'appeler ce rôle directeur de produit. Il justifie pourquoi. Je trouve ça très bien, je vais l'adopter.
Rappel : dans Scrum il n'y a que 3 rôles : l'équipe, le ScrumMaster et donc le directeur de produit. C'est lui qui est responsable d'alimenter le Backlog avec les user stories, à destination de l'équipe.

Commentaires

1. Le lundi 24 avril 2006, 11:18 par Avangel

Je suis complètement d'accord avec cette dénomination. En effet, cela colle davantage avec les concepts de Scrum, et notamment que le client est au coeur de l'équipe. Alors que "Propriétaire de produit" laisse encore sous-entendre la barrière Client/Fournisseur, "Directeur de produit" induit l'unité Client-Fournisseur et le fait que le client dirige les besoins traités, et donc le développement.

2. Le lundi 24 avril 2006, 16:29 par Bernard

Dans le cadre d'une relation client / fournisseur (nos chers MOA MOE)
il y a un chef de projet chez le fournisseur. Son rôle est clair.
Chez le client, il y a des "utilisateurs". Mais, au delà, et en laissant de côté les informaticiens, il faut chez le client un rôle fort, chargé notamment d'orienter le produit, et son déploiement (appro s'il y a lieu, formations, etc.). Est-ce un Directeur de Projet, ou un Directeur de Produit ? Dans tous les cas, le terme "Directeur" me semble adéquat.
Personnellement, et hors contexte Scrum, j'aime bien utiliser, côté client, les termes "Directeur de Projet" et "Responsable Produit".

3. Le lundi 24 avril 2006, 18:50 par claude aubry

Mon avis est qu'il est souhaitable se débarrasser des notions de MOA MOE si on veut être vraiment agile. Sinon on risque d'avoir du mal pour changer les habitudes.

Le directeur de produit (Product Owner dans Scrum officiel) est certes le représentant des clients, mais il est très impliqué dans le projet. Il fait partie de l'équipe "étendue" (équipe + ScrumMaster + Product Owner). Il travaille pendant le sprint : il dialogue avec l'équipe, il met à jour le backlog de produit, en plus de participer aux revues. Il devrait spécifier les tests de recette des user stories sélectionnées. Je préconise qu'il s'assigne explicitement ces tâches de test dans le backlog du sprint (le plan d'itération)

J'ai joué ce rôle dans la première partie du projet IceScrum sans m'impliquer autant notamment sur la spécification et les tests, faute de temps. Résultat, le produit est correct mais pas vraiment utilisable. Depuis le lancement de la suite du projet, ma participation est plus grande et c'est bien plus satisfaisant, en attendant les résultats.

4. Le mardi 25 avril 2006, 11:49 par Bernard

Si j'ai qualifié de "chers" dans mon message précédent les notions de MOA et MOE, c'était par référence à ce que j'ai l'habitude d'entendre, et en voulant dire que cela faisait partie des quelques concepts très utilisés par les différents partenaires, qui en ont une interprétation claire (?).
Ce ne sont peut-être pas les bonnes responsabilités qui ont été confiées respectivement à chacun
Et peut être faut-il en effet un grand coup de pied dans les habitudes...
Pas facile..., comme cela n'a pas été facile de faire passer des informaticiens de l'état "coder" à l'état "faire coder" (j'allais écrire "travailler" à l'état "faire travailler", là encore par précipitation...)
Et pourtant, il faut des informaticiens chez les donneurs d'ordre, non ?
J'ai souvent trouvé très intéressant l'implication du client (ou de délégués du client) dans l'élaboration d'une spécification technique ou de logiciel (élaboration, et pas seulement contrôle). Mais cela demande souvent un recul important, une autre interprétation du concept de projet que celle qu'un client perçoit en général, notamment dans le cas d'obligation contractuelle de résultats (mais, là encore, il faudrait peut être progresser)

5. Le mardi 25 avril 2006, 17:32 par claude aubry

Un directeur de produit doit avoir comme objectif d'obtenir le meilleur produit possible, pas le respect d'un contrat. De toutes façons les changements sont inévitables. Le directeur de produit en est souvent à l'origine.