- Table des Matières
- Avant la conception
- Résumé
Il y a quelques étapes préliminaires avant de concevoir une application, en effet, il ne faut pas se lancer dans la réalisation de diagramme dès que vous recevez un projet, il existe une flopée d'étapes qui peuvent paraître évidentes. Mais qui feront la différence entre un développeur de base, et un concepteur sérieux. Cet article vous donnera les étapes clés vous permettant de lancer un projet de la meilleure des façons.
Durant la lecture de cette section, posez-vous les questions suivantes :
- Quel est l'objectif d'un développeur ?
- En quoi consiste être un bon concepteur ? (Bien que celle-ci puisse paraître anodine de prime abord)
La première chose à faire pour un concepteur est de comprendre le besoin du client.
Cette étape est absolument cruciale pour tout le reste de la vie de votre projet. Si vous ne comprennez pas ce dont votre client a besoin, vous ne pouvez entreprendre aucune réalisation. Pourquoi ? Car si vous comprennez de travers et que le client ne trouve pas une solution à ses problématiques en votre réalisation, vous risquez d'avoir perdu et fait perdre :
- Du temps
- De l'énergie
- De l'argent
- De la confiance (De la part du client envers votre entreprise, de votre entreprise et vos collègues envers vous, de vous-même envers vous-même, ce qui est selon moi la pire des choses qui puissent vous arriver)
Notez qu'on parle ici de besoin et non de demande client. C'est ce qui fera la différence entre un développeur qui écoute la demande du client, et un concepteur qui cherche le besoin du client.
Pour vous donnez une image, prenons un exemple :
Admettons que vous soyez au restaurant et que vous commandiez un Couscous.
Le serveur revient une 20 aine de minute plus tard avec une Entrecôte.
Il est plus que probable que vous ne retournerez pas dans ce restaurant, n'est-ce pas ?
Maintenant, prenons un autre cas de figure :
Admettons que vous soyez au restaurant et que vous commandiez un Couscous.
Le serveur revient une 20 aine de minute plus tard avec votre Couscous,
mais vous vous rendez-compte que ce n'était pas exactement ce que vous vouliez.
Le serveur s'est comporté en bon développeur, il vous a servi ce que vous aviez demandé.
Et pour achever le raisonnement :
Admettons que vous soyez au restaurant et que vous commandiez un plat
avec de la viande et des frites, mais qu'en même temps, vous aimeriez avoir quelque chose qui ne soit pas sec,
mais vous ne savez pas exactement quoi.
Le serveur vous écoute et enregistre ce dont vous avez envie.
Il revient une 20 aine de minute plus tard avec un Burger, des frites et une salade. Vous finissez votre plat et remerciez
le serveur de vous avoir apporté exactement ce dont vous aviez besoin.
Le serveur s'est comporté en concepteur, vous ne saviez pas vous même ce que vous vouliez, mais il a trouvé exactement ce dont vous aviez besoin.
Être un concepteur ce n'est pas se contenter d'écouter ce qu'un client vous demande, c'est avant tout, comprendre les problématiques qu'il rencontre et essayer de les résoudre.
Dans la grande, très grande majorité des cas, le client connait certaines problématiques qu'il rencontre, c'est d'ailleurs la raison qui le pousse à prendre contact. Mais il n'a pas conscience de tous les besoins qu'il a. Le travail du concepteur est avant tout de se projeter à la place du client, comprendre la couche métier du client, évaluer les différents aspects de cette dernière, prendre conscience de toutes les problématiques et d'y apporter des solutions.
Il n'est pas rare de rencontrer un client qui n'a pas démarré son activité et qui vient vous voir à cette fin. Dans ce cas, c'est encore mieux, le client n'a aucune contrainte et vous partez sur une base complétement neuve.
Il arrive cependant qu'un client soit très ferme sur les limites d'un projet, il se peut que vous rencontriez des clients qui préfèrent parler avec des développeurs, plutôt qu'avec des concepteurs (ils veulent un couscous et rien d'autre qu'un couscous). Dans ce cas, vous savez ce qu'on dit : Le client est roi.
Les problématiques ayant étés evaluées, il ne reste plus qu'à trouver des solutions à chacune d'entre elles, et croyez-le ou non, la partie la plus simple du processus, c'est celle là.
Il est recommandé de dresser une liste des problématiques dans un document évolutif. Au sein d'un dépôt GitHub au format Markdown par exemple, c'est une des meilleures solutions pour ce genre de travaux. Mais ne vous cantonnez pas à ça, cette solution est viable pour un travail évolutif, ou sur une session d'élaboration, préférez d'autres formats pour la livraison de document (comme PDF).
Pour chaque problématique, trouvez une solution simple, pas simpliste, simple. Il ne faut pas qu'une solution résolvant une seule problématique engage des efforts démesurés, faites preuve de bon sens. Il peut être difficile de prendre du recul sur ce genre de réalisation, c'est pourquoi demander l'avis d'un tiers (qui peut être un collègue qui n'a rien à voir avec le projet, ou une personne non technique) peut être utile afin de vous rendre compte de ce que vous produisez.
Une fois que vos solutions ont suffisamment étés éprouvées en terme de simplicité, de pertinence, et de réflexion, vous pourrez consignez votre réalisation dans un document présentable au client.
Avant toute chose, il est judicieux de savoir que si vous travaillez en méthode Agile, le terme Cahier des charges est un gros mot, si vous ne savez pas pourquoi, je vous invite à lire cet article.
Pour établir un dossier présentable au client, il est fondamental que ce dossier suive quelques codes afin d'être pris au sérieux. Tous les éléments présents dans cet article devraient figurer ou être succintement abordés dans votre document de projet.
Une section de contexte est essentielle dans un document de cette nature, pour une raison assez simple :
Vous témoignez au client de l'intérêt que vous portez à ce projet, vous démontrez au client que vous avez pris connaissance de ses problématiques en donnant des informations sur soit :
- Son entreprise
- Son secteur d'activité
En lisant cette section, le client lit est une section sur son entreprise ou son secteur d'activité, ce qui vous mâche une partie du travail pour la suite, il sera plus enclin à prendre connaissance du document s'il comprend d'entrer de jeu que le projet tourne autour de lui, et que votre équipe et vous, avez pris le temps de vous renseigner sur des aspects plus généraux.
On ne parle pas ici d'un exposé de 12 pages sur la vie personnelle du client. Mais d'une mise en contexte du projet, en incluant si possible des informations sur l'entreprise de votre client. Pour vous aider à comprendre, nous allons prendre un exemple :
Admettons qu'un client dans le secteur Automobile demande un site Web permettant de prendre des rendez-vous en ligne. Une section contextuelle pourrait être formattée dans un style comme celui-ci :
L'entreprise Cars&Motors est une entreprise familliale
qui a pour objectif de fluidifier son contact avec ses clients.
L'entreprise Cars&Motors existe depuis plus de 20 ans et atteint des objectifs
de 10 rendez-vous journaliers...
L'idée est de montrer au client que vous êtes impliqués et que vous ferait le nécessaire pour proposer la solution la plus adaptée à ses besoins. En adoptant cette section dans vos documents, vous fluidifierez les échanges avec le client. Car quoi de mieux pour un client de se sentir compris et de sentir qu'on s'intéresse à ses problématiques ?
Voyez cette section comme une mise en abîme du projet, ou un moyen de ferrer le poisson si vous préférez.
Cette section est importante, elle présente les membres de l'équipe en charge du projet, il n'est pas question ici de présenter personnellement les membres, mais d'expliquer qui aura quelle fonction au sein du projet. Par exemple :
- Monsieur B : Développeur de la solution
- Monsieur N : Développeur de la solution
- Monsieur C : S'occupera de la bonne mise en œuvre de la méthodologie de travail
- Monsieur B : S'occupera de la communication entre l'équipe et le client.
...
Voilà un exemple concret, il peut être judicieux d'être succint. Le client ne cherche pas à devenir ami avec l'équipe, il souhaite seulement savoir et comprendre ce pour quoi il paye. Cette section est là pour lui montrer que vous vous soucier de cet aspect, et permet aussi d'expliquer tacitement les coûts d'un projet en montrant au client l'effectif employé à la réussite de son projet.
Cette section n'est pas absolument essentielle mais il est fortement recommandé de l'inclure. Dans un document qui a pour vocation d'établir un projet, mieux vaut que le client ait plus d'informations qui l'intéresse plutôt qu'un document qui ne trouverait grâce à ses yeux. (C'est à prendre avec des pincettes, ne commençait pas à mettre vos horraires de pause déjeuner non plus). Gardez à l'esprit que vous devez rester pertinent dans votre démarche.
Cette section est absolument essentielle, en effet, elle ne paie pas de mine mais croyez moi, cela pourrait avoir des conséquences catastrophiques d'omettre cette section.
Avant de vous expliquer plus en détail, nous allons prendre un exemple :
Imaginons que vous alliez chez le garagiste pour changer vos pneus,
et que le garagiste ne vous dit pas comment il va procéder.
Vous revenez 1 heure plus tard et là ! Stupéfaction,
votre voiture est en pièce détachées.
Vous n'êtes pas garagiste et ne savez donc absolument pas si c'est normal.
Mais le garagiste vous dit qu'il fait toujours comme ça.
Résultat il vous dit de revenir dans 2 semaines le temps de le laisser faire son travail.
Et rajoute que la facture sera sacrément salée.
Vous auriez aimé que votre garagiste vous dise comment il aller travailler afin de prendre vos dispositions (Et accesoirement d'aller voir un vrai garagiste plutôt qu'un escroc). Dans ce type de projet c'est la même chose. Le client ne connait absolument pas les coutûmes du domaine, ça tombe bien, ce n'est pas son rôle. En revanche, votre rôle à vous est d'expliquer sommairement la façon dont le travail sur le projet sera achevé.
Mais gardez à l'esprit que vous n'êtes pas là pour lui faire un cours complet sur la méthodologie que vous adopterez. Est-ce que vous voudriez que votre garagiste vous explique chaque étape qu'il va effectuer pour changer vos pneus dans les moindres détails ? (Gardez cette image, elle pourrait s'avérer salvatrice). L'idée est de rassurer le client et surtout d'expliquer la façon dont la collaboration se passera, et qu'il n'ait pas de mauvaise surprise une fois le projet démarré.
Maintenant que le client a eu un petit aperçu de votre sérieux, il est temps de lui parler du coeur du projet, les problèmes. Mais surtout, les solutions, éviter de mettre trop en avant les problèmes, mettez plutôt en avant les solutions.
L'idée derrière l'idée (héhé) est de montrer que vous avez bien pris conscience des enjeux du projet, vous avez pris la mesure du projet et avez identifié des problématiquea auxquelles le client n'avait pas pensé. (N'allez pas créer des problèmes là où il n'y en a pas malgré tout).
Préférez opter pour une approche plus visuelle pour cette section de mise en lumière des solutions. Par exemple un tableau affichant les problèmes, qui sont decoupés en problématiques et à droite les solutions associées résumées en une phrase succinte. Cette approche permet de faire lire en premier lieu les problèmes, puis les problématiques qui en découlent et en point d'orgue (à la manière d'un deus ex machina) vos solutions, le lecteur termine sa lecture sur une note positive. Ce qui présente quelques avantages :
- Ne pas laisser au client une amère sensation après avoir parcouru votre tableau.
- Lire des informations très succintes et qui donc permet une comprèhension rapide et claire des solutions.
- Ne pas avoir à faire d'effort de compréhension et de concentration pour récupérer des informations dans une melasse de texte.
Une fois que vous avez présenté succintements :
- Les problèmes
- Les problématiques
- Les solutions
Vous pouvez aller dans le détail de chaque solution dans des sous sections dédiées à chaque problématique et solution.
Une étape qui semble être plus que bienvenue est celle de présentation des cibles du projet. Ou en d'autres termes : Qui sont les cibles de l'activité du client ?
Le termes "cible" peut-être perçu comme étant réducteur, on parlera alors de persona. Un persona est simplement un terme désignant les différents profils des utilisateurs du projet fini. Il est intéressant de dresser une liste de personas afin de :
- Montrer au client quel public est visé par son produit.
- Vérifier avec le client que les personas sont en accord avec son expérience ou sont pertinentes.
Et plus productivement ça vous permettra d'axès le produit du client en fonction de ses cibles par exemple :
Les services d'un garagiste visent
les personnes qui conduisent des voitures.
Les services d'un concepteur visent
les personnes ayant besoin de développer des produits numériques.
Bien que cela puisse paraître absurde, en pratique, c'est une étape qui demande une certaine réflexion et temoigne d'une certaine rigueur.
Faire un document de la sorte est bénéfique pour plusieurs raisons :
- Vous témoignez au client votre engagement dans le projet.
- Vous établissez une valeur étalon solide sur laquelle vous pourrez vous appuyer.
- Vous déclarer clairement ce que vous avez pris en compte dans vos réflexions.
Il y a d'autres bonnes raisons, comme le fait de permettre au client d'apporter des correctifs sur les points avec lesquels il n'est pas d'accord dès le début, plutôt qu'après la réception d'une première version fonctionnelle. Mais ce sont les trois principales.
Puis de toutes façons, c'est obligatoire d'établir un dossier de début de projet avec le client, voyez simplement ça comme une partie, certes peu amusante mais très enrichissante du métier.
Selon votre méthodologie, l'appélation d'un tel document peut changer, sa fonction en revanche elle, est gravée dans le marbre, vous devez donner envie au client de vous donner le projet, avec un document comme celui-là, disons que vous partez dans une bonne direction.
En ce qui concerne la structure de ce document, nous vous conseillons une structure qui suit l'ordre de parution de cet article (à savoir) :
- Mise en Contexte
- Présentation de l'équipe
- Présentation des problèmes, problématiques et solutions
- Sous section concernant la solution 1
- Sous section concernant la solution 2
- Sous section ...
- Identification des personas
- Conclusion
Il ne faut pas strictement respecter cette structure, mais elle semble intéressante en terme d'agencement, cependant, faites une structure qui vous semble pertinente / fluide.
En ce qui concerne le format de votre document, en général, lorsque vous travaillez sur le document, que vous n'avez pas encore de version finie ou pas suffisamment éprouvée, nous vous recommandons de travailler au format Markdown, il est rapide, léger et peu verbeux.
En revanche, lorsque vous souhaiterez distribuer votre document, préférez un format largement répandu comme le PDF par exemple.
- Être concepteur c'est chercher à comprendre le besoin du client.
- Être développeur c'est se contenter d'écouter la demande du client.
- Produire un document de début de projet complet présente de nombreux avantages pour le client et pour vous.
- Il est beaucoup plus important de mettre l'accent sur les solutions que sur les problématiques.
- Une structure fluide est plus que nécessaire, trouvez celle qui vous semble la plus efficace.
- Pour travailler sur un document : Utilisez Markdown; pour le distribuer : Un format plus répandu comme PDF