# Impliquez les parties prenantes


## Un projet est comme un Film

Drôle de titre, n'est-ce pas ? Pourtant on peut le dire, un projet
informatique, c'est un peu comme un film : on peut prendre plaisir à le
tourner, y apprendre des choses, mais l'essentiel reste que ce film voit
le jour.

Faisons un jeu : quel est le point commun à tous les films, films
d'animation, court-métrages ? Tic-tac, tic-tac... Driiing ! Réponse :
ils ont tous un générique, c'est à dire une liste des différentes
personnes qui y ont travaillé, classées par rôle.

Et bien dans un projet informatique c'est pareil, il existe des rôles.
Il peut arriver que certaines personnes aient plusieurs rôles, selon la
taille du projet, mais il est indispensable de définir les domaines de
compétence nécessaires à la bonne tenue de votre projet.

En général, voici les rôles qui seront associés à votre projet :


1.  Le **Propriétaire du produit** :
    Personne qui fournit la Vision du produit. Est souvent celui qui finance
    le projet.

2.  Les **Alliés du produit** :
    Personnes qui soutiennent et aident fonctionnellement le Propriétaire du
    produit. Elles peuvent avoir un impact sur le Produit

3.  Les **Analystes fonctionnels** :
    Personnes qui déterminent les solutions fonctionnelles à apporter pour
    répondre à la Vision du Propriétaire dur Produit

4.  Les **Ergonomes** :
    Personnes qui déterminent l'ergonomie la plus adaptée pour mettre en
    place les solutions fonctionnelles auprès des utilisateurs ciblés par le
    Produit

5.  Les **Graphistes** :
    Personnes en charge d'améliorer l'aspect visuel ou d'appliquer des
    solutions proposées par les Ergonomes

6.  Les **Testeurs** :
    Personnes en charge de la recette applicative de premier niveau


7.  Les **Développeurs** :
    Personnes en charges de l'implémentation technique des solutions
    proposées par les Analystes fonctionnels



Bien, ça, c'est dit. Bien entendu, il est fréquent que certains de ces
rôles se chevauchent, le plus souvent pour des raisons de coût ou de ressources :
l'ergonome est graphiste, l'analyste fonctionnel est propriétaire du
produit, etc.



Dans tous les cas, ces rôles doivent dialoguer entre eux, puisque chacun
a son rôle à jouer dans la réalisation du Produit. Gardez ce découpage
en tête, il est important pour la suite.



> Les Partie-prenantes sont au Produit ce que les acteurs sont au Film :
chacun joue un rôle différent, mais tous mettent en scène la Vision de
ce qu'ils produisent

## Devenez spectateur un instant

Votre produit est destiné à être vendu, que ce soit financièrement
auprès de vos clients, ou commercialement auprès de vos utilisateurs. En
général, c'est vous qui présenterez votre Produit, par le biais de
réunions commerciales, de plaquettes publicitaires, ou que sais-je
encore.



Mais avez-vous pensé à laisser vos développeurs faire cette présentation
? Pas de panique, **je ne vous parle pas d'envoyer un geek barbu auprès
de vos prospects et investisseurs**, non. Non, je vous propose de
laisser vos développeurs vous faire une présentation à vous, le
propriétaire du produit.



L'idée est la suivante : on l'a vu, il est plus pratique de travailler
par itérations successives pour votre projet. À la fin de chaque
itération, vos collaborateurs doivent être capables de vous fournir une
version exploitable de votre produit. **Pourquoi dans ce cas ne vous
feraient-ils pas la démonstration de ce qu'ils ont à vous livrer ?**



C'est assez classique dans les préceptes agiles : à la fin de chaque
cycle l'équipe technique va vous présenter ce qu'elle vous propose, et
ce pour différentes raisons :

+ cela vous permet de valider votre demande initiale
+ cela permet d'impliquer l'équipe technique dans la bonne marche fonctionnelle de votre produit
+ cela permet aux acteurs de votre projet d'éprouver régulièrement de la satisfaction personnelle en réussissant à vous livrer dans les temps quelque chose qui fonctionne

Une simple présentation d'une heure, pourquoi pas un vendredi sur deux,
par l'équipe technique, vous permet donc d'impliquer dans votre projet
les plus réfractaires : les développeurs. Pourquoi ne pas l'adopter ?

Bien entendu, encore une fois, ce n'est pas une recette miracle. Mais
l'accumulation des ces instants d'échange et de dialogue ne peut que
faciliter votre projet.



> Laissez l'équipe technique vous faire une démonstration à chaque
cycle.


## Tous les acteurs ont des bonnes idées

Un film, c'est avant tout un réalisateur, qui insuffle l'âme du film, sa
Vision. Pourtant il est très fréquent que de bonnes idées proviennent
d'acteurs : des improvisations, des échanges, des contestations, des
propositions... 


Les bonnes idées peuvent venir de partout. Qu'elles soient
fonctionnelles, ergonomiques, esthétiques... vous devez écouter ces
idées, les assimiler et, si certaines vous semblent pertinentes et en
accord avec votre vision, les implémenter.


Après tout, votre spécialité c'est la connaissance du domaine
fonctionnel. Votre produit peut répondre à un besoin de bien des
manières, et même d'une façon que vous n'avez pas encore imaginée.


Vos développeurs ne connaissent pas à la base votre besoin fonctionnel,
mais leur métier les amène à observer et comprendre une multitude de
manières de répondre à un problème. Chaque site internet qu'ils visitent
répond à une problématique, chaque site a une approche différente des
problèmes, et eux-mêmes sont utilisateurs de produits. 


Restez maître de votre Produit, mais, après tout, ce qui compte c'est de
rendre service, au mieux, à vos utilisateurs. Prenez les bonnes idées là
où elles sont...

> Imprégnez vos développeurs de votre besoin pour leur laisser l'occasion de trouver de bonnes idées
