Le concept est rarement contredit. Dans la pratique, cependant, il y a plus de résistance à cette idée que de mise en œuvre réussie…

Talking to customers is not a waste of a developer’s time par Jeff Gothelf

https://jeffgothelf.com/blog/talking-to-customers-is-not-a-waste-of-a-developers-time/

J’ai souvent plaidé en faveur d’une pratique large et inclusive consistant à parler à vos clients. Le concept est rarement contredit. Dans la pratique, cependant, il y a plus de résistance à cette idée que de mise en œuvre réussie de celle-ci. L’argument principal ?

Faire des recherches sur les clients est une perte de temps pour un développeur. (N’hésitez pas à remplacer « développeur » par cadre exécutif, Analyste Qualité, etc.).

L’argument se poursuit avec

Nous avons embauché nos développeurs pour écrire du code et que tout ce qui les éloigne de cette tâche est une distraction à minimiser.

Un bon code est bien plus que des bogues ou des performances

Cet état d’esprit trahit une croyance organisationnelle selon laquelle fournir du code est la même chose que fournir de la valeur aux clients. Il n’y a que deux choses que la livraison de code vous garantit d’obtenir : (1) plus de code et (2) plus de dette technique. Chaque ligne de code écrite par un développeur vivra pour toujours dans les systèmes que vous construisez. Le code nécessitera de la maintenance. Il accumulera de la dette au fil du temps. Si nous ne pouvons pas garantir que chaque ligne apportera quelque chose de valeur à nos utilisateurs et à l’entreprise, nous ne devrions pas l’écrire. À tout le moins, nous ne devrions pas la pousser en ligne.

Bien sûr, nous avons besoin que le code soit exempt de bogues, performant, sécurisé et évolutif. Un bon code devrait avoir toutes ces qualités. Mais toutes ces qualités ne valent rien si la fonctionnalité que nous avons livrée n’améliore pas l’expérience de l’utilisateur. Trop souvent, nous poussons les fonctionnalités précisément pour la croyance organisationnelle que les développeurs doivent livrer quelque chose à un moment donné. Mais avec un petit investissement de temps, nous pouvons considérablement améliorer les chances que le code de haute qualité que nous expédions ait réellement un impact significatif sur nos clients.

Les développeurs qui parlent aux clients écrivent un meilleur code

Les ingénieurs qui ont des contacts réguliers avec les clients comprennent les problèmes qu’ils résolvent pour leur public. Ils ont une idée claire de ce qui empêche les utilisateurs de réussir en ce moment. Ils peuvent même apprendre ce que nos clients font en ce moment pour atteindre cet objectif particulier. Toutes ces informations donnent un sens et un but au code écrit par ces développeurs. Cela les pousse à créer des logiciels qui vont bien au-delà du « fonctionne tel que conçu ». Les informations obtenues en écoutant les clients incitent les développeurs à affiner une expérience à un niveau supérieur à celui du code qui n’a pas bénéficié de la connaissance utilisateur.

Comprendre ce qu’un utilisateur essaie d’accomplir signifie que les fonctionnalités que vous livrez ont plus de chances de réussir. Cela se traduit directement par moins de refactorisation, moins de refonte et une utilisation et un succès accrus pour ces idées. Les développeurs impliqués dans ces fonctionnalités réduisent en fait le codage inutile en ne créant pas de fonctionnalités dont personne ne veut ou qui ne résolvent pas le problème réel de nos utilisateurs.

Davantage de connaissance des clients signifie un meilleur code, moins de gaspillage

Les principes Lean nous apprennent à éliminer les déchets du processus. Tout ce que vous faites qui ne génère pas de valeur pour le client doit être retiré du processus. Écrire du code pour des fonctionnalités dont personne ne veut est du gaspillage. Maintenir des fonctionnalités que personne n’utilise est du gaspillage. Ajouter de l’embonpoint à un produit est du gaspillage. Passer du temps à négocier des priorités sans contexte fondé sur des données probantes est du gaspillage. Tout cela peut être minimisé si vous amenez votre développeur à parler aux clients car c’est la voie de la moindre résistance.

Ce n’est pas un concept difficile à mettre en œuvre, mais il faut un changement fondamental de mentalité dans ce qu’un développeur devrait faire au travail et ce que l’organisation définit comme « valeur ».