J’interviens actuellement dans un certain nombre d’entreprises afin de les aider à mieux s’organiser et porter efficacement leurs projets, et la façon de “gérer” leurs clients. Je me suis aperçu à cette occasion à quel point des notions de bases sont pourtant peu connues. Voici quelques règles que j’ai pu donner lors de ces missions, en vrac.

Règle n°1 : vos cahiers des charges ne sont pas payés au poids ! Je sais que je ne donne pas le bon exemple sur ce blog, mais des gros blocs d’écritures bien verbeux n’est pas l’idéal pour forger un document de travail qui se doit d’être utilisé tout au long de la vie du projet.

Règle n°2 : impliquez vos clients ! On est entre nous, donc on peut le dire : clore une réunion client et repartir peinard sur son poste de travail est un vrai bonheur pour le développeur lambda…Et pourtant, trop espacer les réunions, perdre de vue le client, faire des “tunnels” de développement sans visibilité est la meilleure recette pour dévier, perdre du temps à implémenter un truc sur la base d’une incompréhension. Bref, le client, il faut qu’il soit là, même si c’est un peu lourd, même s’il faut le traîner par la peau du cou !

Règle n°3 : dessinez ! On n’a rien inventé de mieux que le schéma, le croquis, pour que le client se sente “chez lui”, qu’il comprenne ce que sera sa future application ou son futur site web, et ce, le plus tôt possible, avant de rédiger un lourd cahier des charges, avant de se lancer dans des maquettes.

Beaucoup ont encore trop souvent tendance à dégainer leur Photoshop pour concevoir ces premières maquettes. La maquette est en effet utile, mais elle n’est là que pour concevoir le look de l’application, mais certainement pas ses fonctionnalités ou son ergonomie !

Règle n°4 : livrez souvent ! Je suis étonné de voir le nombre de boîtes qui continuent à travailler sur des cycles “en cascade” (waterfall), où l’on va du début à la fin du projet selon une belle ligne droite, avec le postulat qu’il n’y aura aucun coup de théâtre pendant le développement. Les méthodes dites “agiles” étaient autrefois réservées aux projets dangereux et aux specs “glissantes”, on les voit aujourd’hui utilisées avec succès dans des environnements très divers.

Règle n°5 : pensez aux tests le plus tôt possible ! On sait tous que les tâches les plus rébarbatives (l’intégration du travail de différentes équipes, les tests, le débuggage…) sont le plus souvent reculées sur la toute fin des plannings… et sont donc fatalement bâclées, puisque les plannings étant quasiment tous “glissants”, les tâches ultimes sont souvent sacrifiées sur l’autel du livrable “dans les temps”.

Les méthodos “test driven” proposent une approche originale : pour ne pas bâcler les tests, concevons les dès le début du projet, et utilisons les comme documentation et “trame” à part entière. J’ai vu plusieurs cas de projets avec des règles métiers bien tordues sauvés par des tests écrits en amont, permettant d’avoir une transmission du savoir métier “par l’exemple”, et un outil de validation à la fois pour le codeur (qui va pouvoir vérifier l’exactitude de ses algos sans avoir à relancer le client) et pour le client (qui aura une base de tests toute prête lorsqu’il aura ses livrables).

La maquette n’est pas le prototype n’est pas le document client

Ne confondez pas ces éléments de base qui sont les amorces indispensables d’un projet informatique :

• le cahier des charges, qu’il faut bien sur conserver, tout en lui faisant perdre au maximum son côté “verbeux”. certaines méthodos préconisent des “users stories” sur des feuilles au format A5. Bon moyen de faire au plus court…et souvent au plus précis !
• la maquette : conçue par le designer, elle permet de concevoir le look de l’appli. Livrable : un .jpg ou un .psd, ou, mieux, une version imprimée et collée sur un carton au format A3
• le prototype : c’est une première version du livrable des techniciens, des développeurs. A ce stade, le look de l’interface importe peu, le but est de vérifier la faisabilité de certaines fonctions techniques, avec un affichage pur texte.
• et enfin, le mockup. Le mockup, c’est un “rough”, un dessin fait à la va vite de l’interface, mais qui va servir de document de travail pour concevoir l’interface utilisateur.

Souvenez vous : une maquette d’avion, c’est peint à la main, c’est joli, et ça se pose sur une étagère ! Un prototype d’avion, c’est moche, mais ça vole !

Le mockup est une vraie base de travail :

• il permet au client de se représenter sa future application, de la manière la plus concrète qui soit
• il permet au concepteur d’application de concevoir l’interface détail par détail, avec des logiciels permettant de concevoir et d’éditer ces fameux mockups
• il disjoint complètement le travail de conception d’interface de celui de son look. Cela permet d’éviter les grands classiques du client se focalisant sur la couleur d’un bouton alors qu’on cherche à valider une liste de fonctionnalités.

Bref, usez et abusez du mockup !

Dernière notion, le wireframe : ce concept est une déclinaison du mockup, mais qui permet de représenter l’enchaînement d’un écran à l’autre (du style : “lorsqu’on clique sur ce bouton, on va sur tel écran).

Des logiciels à découvrir : Balsamiq Mockups, Protoshare.

Mon support de cours sur la conduite de projets informatiques.

Pour terminer : je n’invente bien entendu rien dans cet articles, les “best practices” qui y sont présentés étant tirées de quelques méthodologies populaires, à juste titre : eXtreme Programming, Scrum