Cela fait de nombreuses années que je travaille avec des développeurs, et j’ai pu observer chez eux certaines réactions et certains tics récurrents.
La relation entre le client et le développeur est souvent complexe, capable de passer d’un dialogue de quelques secondes à parfois une discussion s’étalant sur plusieurs années.
Et surtout, tant la forme que le fond des échanges peuvent dérouter le néophyte.
Voici donc un florilège de quelques conversations que j’ai pu avoir, à prendre évidemment avec humour.
Toute ressemblance avec des personnages ayant réellement existé serait purement fortuite, et bien sur l’ensemble des situations est issue de mon imagination (ou pas).
Je peux t’expliquer mais cela va être long
Le développeur est un hyper technicien, il maîtrise les tenants et les aboutissants du sujet, et souvent sa réponse « Non » sans plus de commentaires sous-entend que les explications ou les justifications sont hors de portée de l’esprit obtus de son client.
Non, ce n’est pas possible
C’est le non définitif, tellement évident pour le développeur que ce n’est pas la peine d’expliquer pourquoi. Client, ôtes toi de l’idée qu’il n’a juste pas envie de le faire…
L’effet de bord ou la régression fonctionnelle
Deux termes diamétralement opposés pour un seul point : la correction ou la modification sensée résoudre un problème ou améliorer un fonctionnement ne se passe pas comme prévu. Du point de vue du développeur : le changement appliqué a un effet sur autre chose. Celui du client : cela marche moins bien qu’avant.
Ok, il me faut 2 semaines
Et pourtant on y est en encore un an plus tard. Il s’agit ici d’une erreur d’analyse…Allez, quelques mises au point et c’est bon ! Il y a des fois où il ne faut pas persister.
L’effet « waterbed »
Le développeur ne maîtrise pas son code, une correction génère de nouveaux bugs, corrigés dans la foulée mais qui reviennent à la prochaine correction d’un autre point.
Spatch 30’
Bug détecté, bug corrigé, aussitôt livré. Une bonne et une mauvaise chose, on peut douter des tests et bien évidement le patch est livré « non regression tested ».
Pour la doc, va voir sur …
Un grand classique, plutôt que de documenter l’utilisation par un client, on l’envoi sur une page web qui explique la technologie utilisée ou bien directement vers le PDF de 400 pages de la norme correspondante.
Va te plaindre à Bill (ou Linus)
Ou comment renvoyer vers les créateurs du système pour un comportement inexpliqué, et pourquoi pas un bug du système, comme si les systèmes avaient des bugs ! ou un de ces étranges « behavior by design » que les développeurs nous servent quand ils ne savent pas expliquer un comportement illogique.
Ca marche dans 90% des cas
Celui là est redoutable, et donc dans les 10% qui restent le client s’est planté ? oui, il n’avait qu’a lire la doc (cf. plus haut).
J’ai fini mais je ne te l’ai pas dit
Celle-là est ma préférée, le job est fini mais pourquoi le dire au client ?
Ces articles pourraient vous intéresser :
Le logiciel est en panne, que faire ?
Le développeur et le testeur
Olivier Piochaud, Président Directeur Général d’Apsynet
