Rebonjour,
En relisant mon message, en effet, je ne suis pas forcément clair dans ma démarche. Ce que je voulais dire, c’est que le processus que j’utilise est celui ci-dessous. J’en profite pour ajouter des serious games en exemple, des liens externes seront présents en fin de message.
Remarque initiale: tout ce qui est dit dans le reste de la réponse est un modèle générique, à adapter selon les situations et dont plusieurs « parties » peuvent être regroupées. Si je sépare ainsi, c’est pour expliquer une démarche itérative et les questions à se poser.
Pour les fainéants, vous pouvez lire les gros titres, puis vous arrêter uniquement là où ça vous intéresse. ;)
Processus générique
Rechercher LE besoin principal (le « pourquoi » du projet)
L’objectif de cette première approche est de savoir ce qu’il veut faire du nouveau système.
- Est-ce que c’est changer un processus (ou ensemble de processus) de son entreprise ?
- Est-ce que c’est enregistrer les informations dans son système (catalogue) ?
- Est-ce que c’est un système e-commerce ?
- Autre ?
Souvent, cette première partie, le client connait déjà la réponse, mais parfois, il est nécessaire de le confirmer (exemple: j’aimerai un site vitrine pour afficher les produits que je vends. => site vitrine ou site e-commerce ?).
A ce niveau, on est dans la discussion simple, rapide.
Serious game: mind mapping, brainstorming, QQOQCCP
Itérer pour définir les grands besoins (les « quoi »)
Cette partie permet de trouver les grandes parties de la solution (pas forcément des modules, mais des fonctions ou branches métier). Cette partie va permettre d’identifier les vrais besoins (et envies) du client et définir le périmètre du projet.
- Quels sont les éléments à prendre en compte (les « catalogues » existants et à implémenter) ?
- Qu’est-ce qui ne va pas dans le fonctionnement actuel ?
- Qu’est-ce qu’on aimerai pouvoir faire (le « quoi », pas le « comment ») ?
A ce niveau, on utilise des serious games pour trouver les besoins de toutes les parties prenantes (si possible de faire toutes).
Je parle d’itération, car il peut être nécessaire de réaliser plusieurs fois l’opération pour faire le tour, selon la taille du projet, la liste des parties prenantes à prendre en compte, etc.
Les informations issues de cette partie sont :
- Les fonctions principales ;
- Les contraintes fortes ;
- Les processus actuels et futurs.
Les données nécessaires au macro-chiffrage sont alors présentes.
Serious game: mind mapping, brainstorming, speed boat, rebondissement d’idée, dessins, recherche des dépendances (pour faire ça, qu’est-ce qu’il faut faire ?)…
Itérer pour définir des solutions (les « comment »)
Enfin cette partie va permettre de trouver la liste des fonctionnalités et transformer les besoins en solutions. C’est à ce niveau que les wireframes peuvent intervenir, car on sait tout ce que l’on veut.
- Comment on gère ces données ?
- Comment est-ce qu’on réalise cette fonction ?
- Quelles sont les contraintes ?
A ce niveau, on peut encore utiliser des serious games pour tenter de trouver des moyens sur comment on peut réaliser la fonction, avec le client, l’équipe (ou partie) et les utilisateurs (ou partie). Ainsi, les idées vont se confronter et on pourra trouver des solutions simples à mettre en place et utiliser.
Je parle d’itération, car à ce niveau, on est vraiment dans le comment. On va essayer de trouver des idées sur comment réaliser l’application petit à petit en fonction de ce qu’il est déjà développé (du moins, dans un projet itératif). Ainsi, si on a une idée en milieu de projet, on peut l’inclure dans les développements futurs, sans devoir modifier tous les wireframes.
serious games: ceux de la partie précédente à un niveau plus concret…
Remarques supplémentaires
Comme dit précédemment, ce processus est générique et ne s’adapte pas à tous les projets et personnes.
Dans ton cas, tu me demandais pourquoi ne pas utiliser des wireframes dès le début. La réponse est tout simplement car cela met des œillères pour trouver les vrais besoins ou besoins dépendants, car une fonction peut être logique pour le client et non pour le développeur et que l’absence du wireframe ne va pas le lui faire penser.
Par exemple pour un site e-commerce (pour rester dans le thème), tu fais un wireframe pour la liste des produits possibles, modifiable, avec les prix, les réductions, la durée de livraison. C’est bon, il y a tout ! Sauf qu’ici, on a oublié la gestion de l’inventaire et savoir si le produit est en stock, disponible chez le fournisseur, quand il sera livrable, etc.
De même, ne faire aucun wireframe n’est pas forcément une solution. La preuve est que je parle de dessins (le wireframe en est un) comme idée de serious games. Il faut juste savoir ne pas se focaliser dessus pour prendre de la hauteur et se poser des questions sur « Qu’est-ce qu’on oublie ».
Enfin, le processus décrit ci-dessus n’est pas en cascade pur, il peut être plus souple et faire des allers-retours entre les phases 2 et 3, mais attention à ne pas dépasser le périmètre.
Pour ton cas
Pour ton cas, je te conseille de créer tous les processus utilisateurs du site et fonctionnels de l’entreprise (impactant le site), les dépendances entre chaque fonction (mind mapping). Ça pourra peut-être montrer des parties non prises en compte dans la solution.
Sinon, je laisse la communauté parler. :)
Désolé pour le pavé, mais j’espère qu’il en aidera plus d’un.
Liens externes
- Liste de jeux agiles:
- Mind mapping:
- Brainstorming:
- Speed Boat:
