Programmation orientée objet dans WordPress : comprendre les attentes des clients
Alors que nous continuons à faire avancer la discussion sur la programmation orientée objet dans WordPress, il est important que nous nous assurons de ne pas prendre d’avance sur nous-mêmes lorsqu’il s’agit de créer un produit pour quelqu’un d’autre.
Très souvent, il est facile de :
- entendre ce que dit un client,
- construire quelque chose sur la base de ce que nous avons entendu,
- le remettre audit client.
Mais il y a tellement plus que cela. J’ai dansé un peu autour de lui dans les articles précédents de cette série; cependant, je veux commencer à approfondir ce que signifie entendre :
- Ce que dit un client,
- Élaborer un cahier des charges,
- Et puis créez des boucles de rétroaction autour de cela.
En fin de compte, nous voulons nous assurer que les personnes pour lesquelles nous travaillons et les solutions que nous construisons sont vraiment des solutions et non des obstacles ou des obstacles qu’ils doivent franchir.
De plus, je ne pense pas qu’il suffise qu’un client apprécie simplement l’expérience de son produit final, mais qu’il travaille également avec celui (ou ceux) qui construit la solution.
Cela dit, examinons ce que signifie écouter ce qu’ils disent et partons de là.
Comprendre les attentes des clients
Chaque fois que vous lisez des livres ou d’autres documents sur ce genre de choses, cela fait souvent de l’une des deux parties le "méchant". Pas toujours, mais parfois ça fait :
- le client semble ignorant de quoi il parle,
- ou cela donne l’impression que le développeur est un imbécile pour avoir agi comme quelqu’un qui en sait plus sur le sujet traité.
Qu’en est-il d’une troisième option où le client a une idée claire de ce qu’il veut, le ou les développeurs sont prêts à écouter et à travailler en collaboration avec le client pour construire quelque chose ?
Bien sûr, il y aura des clarifications en cours de route, et il y aura des termes qui devront être définis, et un «recalibrage» du calendrier de développement pourrait même en faire partie.
Mais l’essentiel est le suivant: aucune des parties ne devrait travailler contre l’autre. Au lieu de cela, il s’agit de travailler ensemble pour trouver la solution. Bien sûr, cela nécessite une communication (pour laquelle les développeurs ne sont pas toujours doués, d’après mon expérience, mais il n’y a aucune raison pour que cela ne puisse pas être mieux).
Que dit un client ? (Que dit le développeur ?)
Chaque fois que vous vous rencontrez, vous pensez probablement la même chose parce que vous parlez chacun une langue différente et chacun de vous pense que ce que l’autre dit est du jargon.
Et ce n’est pas faux.
Les clients ont une façon de parler de ce qu’ils veulent, et les développeurs ont une façon de parler de la façon dont ils vont livrer.
Les termes que nous utilisons
Mais il peut y avoir un objectif commun.
Visez une description du problème que vous essayez de résoudre. Essayez de le faire en termes simples afin que la conception corresponde à l’objectif et à la fonctionnalité de la solution.
Je ne pense pas que cela fonctionnera pour tout le monde, mais c’est la première chose que je recommande de faire chaque fois que vous êtes assis avec votre client.
Comme vous le verrez plus loin dans ces articles, il est utile de développer quelques phrases que vous pouvez utiliser au début de votre énoncé de travail et auxquelles vous pouvez vous référer chaque fois que vous avez une décision à prendre.
En d’autres termes, vous (et eux) pouvez demander :
Est-ce que ce sur quoi je travaille contribue à l’objectif commun ?
Et c’est là que vous pouvez déterminer l’ensemble des exigences de base.
"Il faut que…"
Lorsqu’il s’agit d’acheter quelque chose, de construire quelque chose, de demander quelque chose, de vouloir quelque chose, ou quoi que ce soit, il est assez facile de commencer la phrase en disant "Je veux que ça…"
Mais il y a une grande différence entre "Je veux qu’il fasse [faire quelque chose]" et "J’en ai besoin [pour faire quelque chose]", et lorsque vous travaillez dans un logiciel, il est généralement prudent de dire que les choses nécessaires sont essentielles à la candidature. Et les choses qui sont recherchées sont ce qui vient après que la base de l’application a été construite.
C’est-à-dire qu’il s’agit d’une conversation sur le "must-have" et le "vouloir avoir". Et il est important d’avoir des conversations afin que vous puissiez arriver à cette déclaration finale de l’objectif commun de l’application.
Une fois que cela est en place, vous pouvez commencer à planifier votre logiciel autour du problème du client. Et c’est là que la collecte des besoins entre en jeu.
Élaboration des exigences
Si vous et le client avez une solide compréhension de ce qui doit être construit, il est temps de définir les exigences.
Cette partie peut être plus amusante qu’il n’y paraît. Je sais, je sais : cela ressemble à un devoir ou à un devoir, n’est-ce pas ? Mais ce n’est pas. Au lieu de cela, il s’agit de prendre ce qu’ils veulent, ce que vous avez compris, de le traduire dans un langage commun, puis de rédiger un document expliquant ce que le logiciel fera.
Selon votre expérience, cependant, cela peut être ennuyeux. Et par ennuyeux, je veux dire l’une des pires parties de votre travail. De plus, les exigences changent toujours, n’est-ce pas ?
Pas toujours.
Si vous prenez le temps de comprendre ce qu’ils veulent dès le début, les exigences ne doivent pas nécessairement être un document de 50 pages décrivant le fonctionnement de chaque module.
De nombreux livres le documentent comme disant que c’est ainsi que cela doit être. Mais en près d’une décennie de travail, je n’ai jamais eu quelque chose d’aussi long et les clients ont généralement été incroyablement reconnaissants de voir une courte liste qui peut être modifiée par e-mail ou Google Docs, signée, puis appelée le projet se déplace vers l’avant.
J’en parlerai plus à l’avenir, mais quelle que soit la mauvaise expérience que vous avez, vous craignez ou vous craignez, vous n’avez pas à rester assis. Et nous continuerons à en parler à travers cette série.