SAND-framework/data/doc-prince-book-generation/doc/tome1/Contents/func-impliquez-les-parties-prenantes.md

5.7 KiB

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