Créer un produit logiciel : quelles méthodes favoriser?

8 minutes de lecture
1 tag Entrevue
Créer un produit logiciel : quelles méthodes favoriser?

C’est lundi matin, et les employés de GSoft qui travaillent sur les produits logiciels de l’entreprise rentrent au travail la tête déjà pleine d’idées. Alors que les équipes d’Officevibe, de ShareGate et du GLab cohabitent au quotidien, on pourrait se réjouir d’avoir enfin trouvé la recette magique pour concevoir des produits technologiques de classe mondiale. Or, bien que les experts produits de GSoft s'entendent sur les grandes lignes constituant les meilleures pratiques pour développer des logiciels, les avis divergent quand vient le temps de prioriser certaines d’entre elles. Car la question que tous se posent au quotidien est : « comment être le plus efficace possible? ». On s'entretient avec différents experts de GSoft afin de découvrir quelles sont, selon eux, les meilleures façons d’aborder le développement de produits technologiques.

L’agilité, mais pas à tout prix

Le manifeste pour le développement Agile de logiciels prône certains principes, qui sont de plus en plus populaires dans les organisations. Par exemple, les interactions entre les individus sont davantage mises en valeur; la communication face à face est donc encouragée. Ou encore, la collaboration avec les clients est priorisée sur la négociation de contrats. Finalement, on recommande de s’adapter aux changements plutôt que de suivre le plan coûte que coûte. « Il est vraiment important d'avoir une réflexion constante pour s’assurer que nous sommes en train de créer de la valeur qui répond à un réel besoin de nos clients, tout en s’harmonisant à notre vision », affirme Adam Dubé, directeur de produit à ShareGate. Ce n’est pas la pratique, mais bien la philosophie et les principes de l'agilité qui guident Adam chaque jour dans sa démarche.

En revanche, Audrée Lapierre, responsable du design pour Officevibe, aborde l’agilité avec retenue : « On prône beaucoup l’agilité et la vélocité, mais, en pratique, ça peut donner aux équipes une vision à très court terme. » Pour elle, une des clés consiste donc à prendre du recul régulièrement afin de réfléchir aux enjeux à court terme, mais aussi à long terme. Passer du micro au macro constamment l’aide donc à demeurer critique quant à l’incidence de son travail sur le produit.

Travailler en mode Agile ne garantit pas le succès d'un projet

Travailler en mode « Agile » ne garantit pas le succès d’un projet. La communication reste un des principaux facteurs d’échec dans les équipes agiles (en anglais seulement), d’autant plus lorsqu’il s’agit de travailler avec des équipes externes, qui, elles, ne sont pas en mode agile. « L’enjeu réside principalement dans la collaboration des différents domaines d’expertises », rappelle Adam Dubé. Pour surmonter cette difficulté, les équipes de produits à ShareGate ont mis en place un cycle de développement du produit (Software Development Lifecycle) pour spécifiquement prendre soin des étapes d’idéation et des aspects créatifs d’un projet. Paradoxalement, un cycle de développement du produit (en anglais seulement) ressemble à une structure assez rigide dans un contexte d’agilité.

« Je n'aime pas dire que nous avons mis en place une procédure. Je considère plutôt que ce sont des lignes directrices de notre cycle de développement. En équipe, nous avons identifié les étapes clés, les objectifs et les conditions à leur succès. Et pour chacune de ces étapes, nous avons établi une liste de livrables. », explique-t-il. L'objectif principal est donc d’harmoniser les différents domaines d’expertise, dans le but de mettre de la valeur le plus rapidement possible entre les mains des clients, tout en respectant le niveau de qualité exigé par GSoft.

Le rythme détermine la méthode, et non l’inverse

« Il existe une multitude de pratiques, mais il faut savoir laquelle est la meilleure selon le contexte », rappelle Adam Dubé, directeur de produit à ShareGate. Car même au sein de GSoft, bien que les équipes des trois entités (ShareGate, Officevibe et GLab) se rencontrent régulièrement pour former des communautés de pratiques, les différences restent notables. La réalité du GLab, dont la mission principale consiste à lancer des produits en moins de trois mois, est foncièrement différente de celle d’Officevibe, qui vient tout juste de lancer une nouvelle version de sa plateforme d’engagement des équipes de travail.

C’est souvent plus facile de se lancer dans le développement de solutions et de prioriser des fonctionnalités instinctivement, mais c’est la mauvaise approche.

Au GLab, le défi consiste à allier une grande vélocité avec une attention particulière accordée aux comportements des utilisateurs et aux problèmes auxquels ils sont confrontés. Les membres du laboratoire d’innovation de GSoft confirment qu’il est parfois laborieux de prendre le temps de faire une recherche utilisateur en profondeur. C’est souvent plus facile de se lancer dans le développement de solutions et de prioriser des fonctionnalités instinctivement, mais c’est la mauvaise approche. Dans un contexte de lancement rapide comme celui du GLab, l’équipe s’inspire, entre autres, de deux approches populaires : les Jobs to Be Done et le Lean Canvas.

La méthodologie des Jobs to Be Done se rapporte notamment à une philosophie qui consiste à comprendre les circonstances dans lesquelles un utilisateur prend des décisions, plutôt que de segmenter par persona, en fonction des attributs et caractéristiques. Comprendre la dimension sociale et émotionnelle des utilisateurs, plutôt que de faire des liens de causalité entre des types de profils, permet ainsi de créer des expériences qui ont plus de valeur aux yeux d’une diversité d’utilisateurs. Cette approche permet de se détacher de la notion de fonctionnalité technologique pour laisser plus de place à l’analyse des raisons intrinsèques qui poussent les utilisateurs à prendre certaines décisions. Ceci permet de créer de la valeur à plus long terme.

Le Lean Canvas, quant à lui, est ce fameux tableau de neuf cases, développé par Ash Maurya, qui permet de résumer très rapidement les grandes lignes d’un modèle d’affaires. Guillaume Chalifoux, Directeur, Innovation de Produit et Commercialisation du GLab, rappelle cependant qu’un Lean Canvas peut prendre trente minutes à remplir, mais que c'est dans la validation de son contenu qu'on en retire toute la richesse.

Les yeux rivés sur l’utilisateur

Finalement, il ressort une volonté commune à toutes les équipes de mettre l’utilisateur au cœur de leurs démarches. La recherche prend donc une place de plus en plus importante dans les projets de développement de produits. Par exemple, pour Guillaume Chalifoux, l’utilisation de la cartographie du parcours utilisateur (User Journey Mapping) est indispensable au GLab. Cette méthodologie permet en fait d’illustrer ce que le chercheur comprend de l’utilisateur et de partager ses découvertes avec l’intégralité de l’équipe pour bâtir une solution cohérente avec la réalité de celui-ci. « Dans le passé, j’ai souvent assisté à la mise en route de projets sans même que des entrevues en profondeur ou bien des séances d’observation aient été conduites », explique Matthew Gardner, designer, expérience utilisateur, au GLab. Utiliser la cartographie du parcours utilisateur est donc utile seulement si elle reflète les résultats d’analyses qualitatives ou quantitatives effectuées auprès d’usagers. Concrètement, des tests utilisateurs sont effectués pendant l’itération d’une plateforme produit, directement sur les maquettes conceptuelles afin de tester les comportements de navigation ainsi que la compréhension des messages. « Ces tests sont effectués sur des groupes utilisateurs précis; il est donc indispensable de bien connaître l’auditoire auquel on s’adresse », précise Matthew.

Offrir aux utilisateurs exactement ce qu’ils demandent est un piège qu’il faut éviter, car c’est parfois l’ennemi de l’innovation.

En contrepartie, Audrée Lapierre, responsable du design à Officevibe, rappelle qu’il est facile de tomber dans la lecture des tests utilisateurs. « Offrir aux utilisateurs exactement ce qu’ils demandent est un piège qu’il faut éviter, car c’est parfois l’ennemi de l’innovation. Il faut avoir confiance dans le design et dans notre capacité à trouver des solutions qui ne sont pas nécessairement évidentes. » La responsabilité du designer est donc de défendre sa vision et d’utiliser les tests utilisateurs de façon informée, mais pas comme une prescription.

Finalement, il est important de réaliser que c’est bien plus bénéfique si la recherche utilisateurs ne reste pas qu’entre les mains des chercheurs et des développeurs d’expérience utilisateur. « On a demandé aux membres de l’équipe d’Officevibe, dont les développeurs, si certains d’entre eux étaient intéressés à assister à la collecte d’information et à contribuer à l’analyse de données. Les participants ont été surpris à quel point c’est riche en information d’être en contact direct avec des utilisateurs, de ressentir leur réalité et de comprendre leur contexte à travers leur propre regard. Ça permet de mieux saisir les subtilités comportementales qu’ils n’auraient pas perçues en lisant simplement les résultats de la recherche. Le niveau de confiance en leur décision augmente grandement! », explique Marie-France St-Pierre, à la tête du service de recherche utilisateurs d’Officevibe. « Avoir une profonde curiosité pour l’humain aide toujours à créer des produits qui rejoignent vraiment les gens », conclut-elle.