Développeurs : 5 raisons de rechercher une expérience utilisateur proche du monde réel

 Dans le meilleur des cas, la dynamique du monde de l'informatique d'entreprise peut être déroutante. C'est ce que j'ai pu constater lors d'une visite en Israël il y a quelques années. Il se trouve que je travaillais sur un produit d'automatisation, dont une partie a été développée à Tel-Aviv.

Entre mes entretiens avec les clients, j'avais également prévu du temps pour rencontrer les ingénieurs - à la fois pour ma propre formation et pour partager les commentaires des utilisateurs. Au fur et à mesure que nous parlions, il m'est apparu clairement que les ingénieurs n'avaient aucune idée de la façon dont notre produit était réellement utilisé.

Il n'est pas déraisonnable de penser que les génies qui conçoivent les applications que nous connaissons et aimons tous aimeraient savoir exactement comment elles sont utilisées. Dans le monde du logiciel d'entreprise, cependant, cette transparence n'est pas toujours présente.

Les gens ont une idée du développeur solitaire et « rockstar », qui construit un outil pour chacun de ses besoins. Ce n'est pas complètement erroné, les programmeurs solitaires existent, mais pas dans le monde de l'entreprise. Presque par définition, ces développeurs indépendants construisent avec leurs propres besoins en tête, au moins pour commencer, et sont généralement eux-mêmes de gros utilisateurs de leur propre produit.

Quand il s'agit de produits très étendus et puissants utilisés par les entreprises, cela ne se vérifie presque jamais, et le lien entre les utilisateurs et les développeurs est ténu et indirect. Ils ont rarement l'occasion d'interagir avec les clients. Alors comment les développeurs peuvent-ils surmonter ce fossé et découvrir ce que les utilisateurs vivent réellement ?

Ce n'est clairement pas uniquement la faute des développeurs. Je doute que beaucoup de gens codent un CRM ou un progiciel d'analyse financière comme un projet passion dans leur temps libre, donc vous n'obtenez pas le genre d'investissement personnel que les gens mettent dans leurs projets passion. Il est courant que les produits d'entreprise soient en développement depuis des décennies, au point qu'aucun développeur ne peut jamais être familier avec le tout. En raison de ces deux facteurs, les développeurs ont normalement tendance à se spécialiser dans des caractéristiques ou des domaines de code particuliers, comme le frontend, le backend, l'interface graphique ou le réseau.

Tout cela signifie que le cas d'utilisation global pour lequel le logiciel est développé est si éloigné de leur monde que la plupart des développeurs pourraient ne jamais voir un produit fini s'exécuter. Ils codent leur propre partie, exécutent les tests unitaires et la transmettent à d'autres équipes pour l'intégration et l'acceptation par l'utilisateur - un peu comme une chaîne de montage de codage.

Ne vous méprenez pas : cette séparation n'est pas nécessairement négative car elle permet une spécialisation profonde dans des fonctionnalités réellement différenciantes. Le champ d'utilisation du produit final peut aussi être quelque chose (encore une fois, comme un CRM) qui n'est pas évident pour les développeurs, et qui est trop complexe pour que des 'power users' en prennent en charge le développement.

Cela étant dit, il est toujours utile de s'assurer qu'il y a de bons canaux de communication entre les utilisateurs et les développeurs.

Une autre raison pour laquelle ce fossé apparaît au sein de l'informatique d'entreprise est la même qui est à l'origine de nombreux autres aspects de ce monde déroutant : les utilisateurs finaux des produits interagissent très rarement avec les fournisseurs. Prenez par exemple ma visite à Tel-Aviv. Nous savons pertinemment que mes collègues n'avaient aucune idée de la façon dont leur produit était utilisé et par qui. C'est tout simplement parce que les administrateurs système qui utilisaient ce produit tous les jours n'avaient jamais eu de relation avec le fournisseur.

Au lieu de cela, ils passaient par l'acheteur au sein de leur propre entreprise - la personne qui détenait le budget et, surtout, le pouvoir d'achat. Lorsque les relations sont établies de cette manière, il est très difficile pour des développeurs comme mes collègues ingénieurs en Israël de s'engager - ce qui signifie que les deux parties perdent un précieux feedback de première main.

Qui plus est, le résultat de ce processus d'achat déconnecté a, comme on pouvait s'y attendre, de faibles niveaux de satisfaction des utilisateurs. Il est rare qu'un produit d'entreprise choisi de cette manière soit adopté volontairement par ses utilisateurs. Au lieu de cela, les utilisateurs finaux se prépareraient à ce que le patron revienne tout étoilé d'une conférence pleine des dernières idées brillantes (L4G ! Tout dans le Cloud ! Agilité !).

En ce qui concerne l'adoption volontaire, il était (et est) beaucoup plus probable que le trafic soit dans l'autre sens, les outils des consommateurs étant adoptés dans l'entreprise à partir de la base.

Heureusement, les choses ont évolué. Ce mécanisme descendant de sélection des outils logiciels évolue rapidement, et il y a des signes prometteurs d'un cycle de feedback.

Les dirigeants informatiques sont toujours en charge d'engager les dépenses stratégiques, mais grâce à la « génération des créateurs roi » - une époque où les entreprises reconnaissent l'importance des développeurs - les utilisateurs ont une voix beaucoup plus forte dans le processus. En fait, alors qu'auparavant, le premier contact entre l'utilisateur et le fournisseur aurait pu être une présentation de vente professionnelle à un cadre, de nos jours, cette présentation est presque la *fin* du processus.

Au moment où quiconque ayant le terme « ventes » dans son titre est impliqué, les personnes au sein de l'organisation cliente potentielle ont probablement vérifié le logiciel d'une certaine manière depuis des mois, voire des années. Ce sont eux qui iront aux services des achats avec une décision technique déjà prise, demandant de l'aide pour négocier les termes d'un contrat de support avec des vendeurs externes.

Ce modèle donne aux deux parties la possibilité de créer des boucles courtes de feedback avec les utilisateurs existants. Les produits logiciels construits autour de ce type de modèle d'adoption ont beaucoup plus de chances de répondre aux besoins des nouveaux utilisateurs potentiels, qui peuvent alors commencer à partager leurs propres commentaires et à orienter les développements futurs.

L'aspect le plus important à retenir est que ces boucles de feedback ne doivent pas reposer sur le un simple hasard autour d'une discussion avec des ingénieurs. Au lieu de cela, les développeurs devraient prendre leurs responsabilités et s'assurer qu'ils sont en contact direct avec les utilisateurs. Ils doivent intégrer cela dans le processus de développement du produit lui-même. Cela peut sembler évident mais ce n'est pas encore assez le cas aujourd'hui.

Les groupes d'utilisateurs ne devraient pas être utilisés uniquement pour le marketing auprès d'un public captif. Un processus collaboratif impliquant les utilisateurs, les développeurs et les gestionnaires de produits a les meilleures chances de concevoir et de faire évoluer avec succès un produit que les gens voudront réellement utiliser. Les méthodologies modernes de développement d'applications facilitent ce processus, en divisant les anciennes versions monolithiques en versions ponctuelles plus fréquentes.

Cette approche agile permet d'intégrer beaucoup plus facilement les commentaires dès le début, avant que trop de temps de développement ne soit consacré à une approche qui n'est pas en phase avec les exigences des utilisateurs.

Vous ne voulez pas être comme ces ingénieurs avec qui j'ai parlé il y a tant d'années - dans le noir et sans savoir à quel point leur travail peut être bon (ou mauvais). Vous ne voulez pas non plus être comme leurs clients, forcés à accepter passivement un produit dont les caractéristiques et la feuille de route sont décidées sans leur avis.

Le monde de l'informatique d'entreprise est un puzzle, et comprendre comment votre produit est utilisé est la meilleure façon de le résoudre.

Dominic Wellington, Director, Field Initiative & Readiness, EMEA - MongoDB.