partagez une citation

Partagez votre citation, proverbe ou dicton favoris:

Se préparer à écrire les spécifications d'un projet

le 29/09/2010 dans Gestion de projet
La table ronde d'un projet

Ecrire les spécifications d'un projet, ici web, pour le chef de projet n'est pas un exercice facile. Il faut trouver un juste équilibre entre la qualité et la quantité des informations à fournir en prévoyant pour cela de nombreux cas et en envisageant tous les cas que l'on n'a pas pu prévoir. Avant de rédiger ces spécifications techniques et/ou fonctionnelles, il faut auparavant recueillir toute une série d'informations de multiples personnes.

Recueillir ces informations et parfois ces "révélations" demande un certain temps en amont. Voici selon moi quelques éléments qui peuvent permettre de s'assurer de ne rien oublier avant d'écrire le cahier des charges et de répondre ainsi à tous les besoins...

 

1-Adopter le point de vue marketing (en incluant ici le SEO)

En tant que chef de projet, il est important de se placer à la croisée de trois mondes bien différents : le business, le client et la technique; pour répondre à une demande sous toutes ses perspectives. Ici c'est le point de vue du business ou marketing qui est analysé en premier.

Qu'est-ce-que l'on me demande ?, Quel est le projet ?, Comment les différents blocs inter-agissent ?
Pourquoi on me le demande ?, Qu'est ce que ce projet vient apporter ?, En quoi est-il générateur de revenus ?
Comment je vais le mesurer ?, Comment mesurer le retour sur investissement (ROI) du projet ?, Quels sont les paramètres de tracking à configurer ?

A la fin de cette analyse, une première liste de "requirements" ou de fonctionnalités/besoins, peut être établie.

 

2-Adopter le point de vue du client

Avoir assez de recul pour se placer dans la peau du client ou utlisateur n'est pas une chose facile. Une réelle coupure est nécessaire et demande de s'imaginer à la tête d'un site similaire au client ou alors simple utlisateur de celui-ci. Parfois cette perspective intervient à un tout autre moment qu'au travail.

Comment mon système va s'interfacer avec ce projet ?
Est-ce que cela est générateur de valeur ajoutée ?
Est-ce conforme avec mon audience ?
Qu'est ce que j'aimerais avoir en plus ?

Ces questions permettent d'affiner la liste des besoins initiaux.

 

3-Adopter le point de vue du développement

Du côté obscure de la force...ou du côté technique des choses. On exclut ici l'intégration développée ci-dessous, pour se concentrer sur le back end, c'est-à-dire la livraison des informations.

Est-ce-qu'une telle solution a déjà été développée ?
Vis-à-vis de ma plateforme où je vais implémenter cette demande ?, Est-ce que je dois développer un produit sur-mesure ? Etendre une API existante ? Ajouter une fonctionnalité à un précédent développement ?
Quels sont les différents cas possibles d'intégration ?,  Comment la solution va-t-elle être installée ?, Comment est-elle appelée, quittée ?, Partage-t-elle des données avec d'autres applications ?, D'où viennent ces données ?
Puis-je dégager un vague algorithme ?, Un storyboard ?, Une séquence utilisateur, reprenant les différentes étapes sous forme de diagramme ?

Une fois la collecte des informations et leur livraison analysées, un schéma simple (storyboard, powerpoint, dessin) permet de communiquer efficacement l'idée et de centraliser la discussion en meeting autour de ce premier schéma.

 

4-Adopter le point de vue de l'intégrateur (le design étant déjà founi au début du projet)

L'intégration ou le front end fait ici référence à la restitution des informations via une interface; et leurs intéractions.

Vis-à-vis de design qui m'a été fourni, est ce que j'entrevois des problèmes quelconques ? Les éventuelles internationalisations révèlent toujours des surprises en terme de taille tout comme les messages d'erreur à afficher...
De quelles données vais-je avoir besoin pour afficher ces informations?, Les ai-je toutes ?

Les différentes intéractions suggérées par le design impliquent quelles composants ?

 

5-Retour au point de vue marketing

Une fois l'ensemble de ces informations récoltées, on peut revenir sur le besoin initial et vérifier ainsi que toutes ses fonctionnalités ont été parcourues et discutées.

Le projet implanté de cette façon répond-t-il à la demande ?
La première estimation de temps, à ce stade très vague, rentre-t-elle dans le budget ?

 

Ce tour des différents intervenants a permis d'entrevoir pas mal de points de vues différents et aussi parfois d'aboutir à pas mal de solutions différentes. A partir de là, il peut s'avérer intéressant de demander à chaque acteur de s'engager autour d'une réunion dont l'objectif est la validation du "scope" du projet et des différentes solutions proposées qui seront ensuite analysées avec quelques prototypes.

Cela a peut-être l'air abstrait mais prenons le cas d'une application Facebook développée par et pour un même site. Ces questions permettent de recouvrir quelques points importants comme l'intégration de l'application dans le système d'information de l'entreprise, le partage des données utilisateurs (comment lier un utilisateur de Facebook à ceux de mon site ?), la livraison des informations à une interface qui doit s'utiliser via Facebook et donc avec ses contraintes,...

En répondant à ces questions, j'ai pris pour habitude d'utiliser le template suivant. Dans une partie je liste l'ensemble des requirements un par un avec une liste numérotée. Ces requirements doivent être énoncés de manière courte et concise et reprendre un scénario utilisateur (exemple : au chargement de la page, le nouvel utilisateur voit une pop up mais pas un précédent utilisateur...).
Puis dans une autre partie. Je dresses les éléments techniques entrevus pour chacun des requirements énoncés (exemple : si l'utilisateur a déjà vu la pop up, un cookie est ...). Ensuite avec les différents échanges, je liste les questions en suspend toujours par requirements (en séparant comme précédemment les détails techniques ou fonctionnels). Mon objectif est alors de répondre à toutes ces questions avant de commencer l'écriture des spécifications.

Et vous, comment procédez-vous ? Je n'ai pas inclus la partie "test" de la solution car celle-ci dépend pour moi de cette dernière. Si vous l'intégrez, comment faites-vous ?

Retrouvez plus d'informations dans le livre de Scott Berkun, "Making Things Happen". A ce jour mon livre préféré en gestion de projet web/informatique !

Réagir

Post new comment

Votre adresse e-mail ne sera pas publiée.
Si vous possédez un site Internet, entrez son adresse ici (précédée de http://), les visiteurs de cette page pourront y accéder ensuite
ex: http://www.labonnecitation.com
un site Hipponoos