Dans le domaine du développement logiciel, particulièrement sur mesure, il arrive très fréquemment que des débats émanent entre les développeurs et les clients. Ces débats constructifs portent généralement sur comment devrait être développé un module ou une spécification précise. Dans ces situations est-ce que le client a toujours raison?
Le client est celui qui paie la facture du développeur...donc à la fin c'est lui qui aura le dernier mot.Toutefois, tant le client que le développeur peut apporter des pistes importantes à prendre en considération.
Voici quelques exemples de cas types dans ce genre de débat:
1 - Le développeur veut développer la solution la plus simple
Ceci est très fréquent. Si on demande à un développeur comment il compte faire une telle fonctionnalité, il arrivera fréquemment que celui-ci nous présentera la solution la plus simple "techniquement". Bien que cette solution est peut être moins coûteuse, elle peut être moins efficace et amener des coûts autres aux clients.
Ce genre de comportement a mener a de bonnes conceptions logiciels d'un aspect ingénierie mais horribles en terme d'expérience utilisateur et en terme d'efficacité.
Un bon exemple de ce type de conception logiciel orienté par les développeurs sont les systèmes d'exploitation des téléphones. Avant le IPhone, les téléphones avaient des fonctions évoluées mais tellement nulles au point de vue utilisation qu'elles étaient à peine exploitées. Pourquoi? Parce que ceux qui les ont conçu ont d'abord pensé à la fonctionnalité avant de penser à l'utilisation. Apple a complètement changé la donne en offrant des appareils extrêmement ergonomiques.
D'ailleurs, Apple a révolutionner cette façon de penser en terme de développement technologique. Un appareil offrant une même fonctionnalité qu'un autre mais avec une interface plus ergonomique pourra être bien plus profitable.
2- Le client n'est pas conscient de l'importance de l'intégrité des données
C'est évident que le développeur n'a pas toujours tort. Prenons un exemple que je rencontre très fréquemment: la gestion des clients. Peu importe le logiciel, ceux-ci contiennent souvent la gestion de clients (ajouter, modifier, supprimer un client, etc.). Dans un tel logiciel, le client est rattaché à d'autres entités (ex: les commandes, les factures, etc.). Une des spécifications que demandera le client est de pouvoir supprimer un client. C'est possible mais qu'arrive-t-il à toutes les entités qui y sont rattachés? Est-ce que ça veut dire que les commandes ou factures doivent se retrouver sans client? Évidemment pas. Autrement on se retrouverait avec un logiciel à données non-intègres. Ce qui est la chose la plus importante à éviter.
Pour un développeur ce genre de conséquence en cascade est évidente. Toutefois il est normal qu'elle ne l'est pas pour le client. Il faut donc trouver un moyen de "supprimer un client" sans toutefois affecter le reste de l'application. Dans ce cas précis, la solution est souvent de permettre d'archiver un client. Ceci ne supprime pas le client complètement du système mais le retire là où il n'est plus nécessaire de le voir. C'est un exemple bien simple mais qui peut être évidemment bien plus complexe dans des logiciels évolués.
3- Le client n'est pas conscient de tout ce qui cascade des changements demandés
"Tout ce que je veux c'est une liste des clients". Ca parraît bien simple en effet. Toutefois mille questions peuvent en découler: Peut-on la trier? Peut-on la filtrer cette liste? Combien de clients veut-on voir par page? Tous? Et s'il y en a 50 000? Quelles informations du client veut-on y voir? Est-ce que je veux pouvoir exporter cette liste en Excel ou dans un autre format? Etc.
Une fonctionnalité qui peut parraître la plus simple au monde peut être très complexe. Dans ces circonstances il faut pouvoir discuter de ce qui est désiré et ce qu'il est possible de faire. Parfois, le développeur, en expliquant ce qu'il peut faire, va donner des idées au client pour amener le logiciel à un autre niveau.
C'est un peu comme demandé à un concessionnaire automobile: "je veux une voiture". Une voiture peut coûter si peu que 10 000$ mais peut également valoir plus de 100 000$.
4- Le développeur ne se met pas dans la peau des utilisateurs
En développant un logiciel, on l'utilise d'une certaine façon. Puisqu'on l'a conçu, on l'utilise comme il doit être utilisé. Toutefois un utilisateur pourra l'utiliser différemment. Lui ne sait pas exactement comment il a été conçu donc il va tester les limites du logiciel pour tenter de l'utiliser comme bon lui semble. C'est normal et c'est désiré.
Le développeur devrait toujours prendre le temps de penser aux différentes méthodes d'utilisation d'un logiciel et d'essayer de guider l'utilisateur dans sa bonne utilisation. Il est presque impossible de tout prévoir dès le départ mais il faut prévoir du temps pour s'asseoir avec les clients et observer leur utilisation du logiciel.
Ce qu'il faut retenir de tout ça est que la communication entre le client et le développeur est primordial. Ce genre de débat n'est pas nocif. Au contraire, il doit prendre place. Le résultat sera souvent très constructif.
Le UX (User Experience) est une spécialité qui est justement né de ce
genre de débat. Le spécialiste UX travaille avec le client et le
fournisseur pour trouver la conception logicielle la plus efficace pour le client en
prenant en compte les contraintes techniques. Celui-ci va permettre au client d'obtenir le logiciel le plus efficace en terme d'ergonomie tout en permettant au développeur de respecter les règles d'intégrité du logiciel.
