La joie de la découverte

Comment nous aidons les entreprises IBM i à comprendre leurs besoins en appli Web

En tant que membre de l’équipe de développement d’applications Web de Fresche, nous sommes souvent appelés à examiner une nouvelle application métier et à estimer le coût de sa mise au point. Avec la quantité de détails que nous avons généralement à ce stade (en fait, presque aucun), nous pouvons simplement suggérer que cela coûtera plus cher qu'une boîte à pain et moins que l'Étoile de la mort (à notre avis). D'où la phase de découverte d'application d'un projet.

Qu’est-ce qu’une découverte?

Les différentes découvertes que nous pouvons entreprendre : une découverte de modernisation stratégique et une découverte d'applications Web. Le premier est une évaluation stratégique complète de l’infrastructure, des applications et de la vision commerciale d’une entreprise IBM i. Le deuxième est un effort beaucoup plus ciblé, répondant à un besoin spécifique. Nous allons discuter de la découverte d'applications Web dans cet article. Pour plus d'informations, vous pouvez cliquer ici.

La phase de découverte d'applications Web vise à comprendre ce qui est nécessaire et à estimer le coût de sa création. Une fois que cela est fait, la décision de procéder ou non est prise. L’objectif est de comprendre suffisamment les besoins des utilisateurs pour pouvoir faire une estimation raisonnable des coûts de construction. Les estimations ne sont pas vraiment censées être exactes (en fait, les mots estimation et exactes signifient différentes choses), mais ils peuvent être plus ou moins proches de la marque et le processus de découverte d’application nous aide à nous rapprocher de cette marque.

La clé du processus consiste à comprendre les besoins des utilisateurs et la valeur apportée par la réponse à ces besoins. Il s’agit vraiment de se rapprocher des utilisateurs finaux de l'application et vivre dans leur monde. Pour se faire efficacement, nous devons cultiver une certaine façon de penser.

L’esprit du découvreur

Le découvreur relève un défi intéressant, soit celui de connaître les besoins réels du client et proposer une solution qui réponde à ces besoins.

Pourquoi dit-on « besoins réels » ? Après de nombreuses années en développement de logiciels, nous avons trop souvent été confrontés à la situation dans laquelle le client déclare « nous avons besoin de x, y et z », souvent sans même pouvoir expliquer la provenance de ces besoins en premier lieu. À la consternation de tout le monde plus tard, ils se rendent compte que certains de ces désirs ne servaient pas les besoins qu’ils avaient vraiment. Nous voulons donc décompresser ce dont ils ont besoin et la valeur que cela leur procure.

Pour vraiment comprendre leurs besoins, nous devons être dans leur monde. Nous devons abandonner nos idées préconçues sur ce que nous pensons en savoir et faire preuve d'empathie pour leurs problèmes. Pour envisager une découverte sous différents angles, essayez de rechercher certains synonymes de « découverte » : détection, divulgation, rencontre, introduction.

Nous avons beaucoup d'expérience dans la création de logiciels et nous pensons en savoir beaucoup à ce sujet. Et pourtant, avec cette expertise, il y a le risque de croire que « nous savons exactement ce qu’il faut ». Le concept zen de Shoshin, ou « esprit de débutant », peut être utile dans ce cas. Bien que nous ayons plusieurs années d'expérience dans le développement de logiciels et de solutions, nous devons essayer de penser comme un débutant et s'imprégner du monde de nos clients. Nous devons être vigilants pour ne pas « tailler prématurément l'arbre de décision ».

La boîte à outils du découvreur

Les découvreurs d’applications Web disposent de nombreux outils et stratégies. En voici quelques unes :

La mise en scène

Découvrir un nouveau monde, comprendre les besoins clés et, éventuellement, proposer des solutions n'est pas une tâche banale. Partir du bon pied est l’impératif du succès. Nous commençons les choses avec deux questions très simples mais néanmoins importantes.

• Quels sont vos objectifs ?

• Comment allez-vous mesurer le succès ?

Ces deux questions sont parfaites pour former la base des activités de découverte à venir. Ils aident tout le monde à comprendre clairement les objectifs principaux et les mesures clés de la réussite (Measures of Success, MOS).

À ce stade-ci, n'ayez pas peur. Sautez dedans et mettez-les sur un tableau blanc avec un abandon insouciant. Vous ne les écrivez pas dans la pierre, car il s’agit d’une découverte, et vous ne faites que commencer! Presque toutes les activités d'une découverte doivent se terminer par un examen des objectifs et de la note de service afin de déterminer si nous sommes toujours alignés ou si nous devons procéder à des ajustements.

Il est également important de prendre en compte le public cible lors de la définition des objectifs et de la mesure du succès. Nous voulons identifier les vrais utilisateurs de l'application. Nous voulons donc vraiment trouver les bonnes personnes.

Personnage, histoires d'utilisateurs et entrevues

Nous avons maintenant des objectifs de haut niveau et une mesure du succès. Ensuite, qui utilisera cette chose ? Qui sont-ils ? Est-ce que nous parlons aux bonnes personnes, les vrais utilisateurs du produit proposé ?

Souvent, les besoins sont fournis par un intermédiaire, tel qu'un membre de l'équipe informatique ou un responsable. Nous sommes dans la position malheureuse de voir un intermédiaire nous dire qu'il ne veut pas donner la parole aux utilisateurs, car ceux-ci demanderont la lune. Nous avons vraiment besoin que les utilisateurs nous parlent de leur monde et de ce qu’ils font.

Parfois, on nous dit qu'une application servira l'utilisateur A uniquement pour découvrir plus tard qu'il y a le gestionnaire B et le client C dont personne n'a envisagé. Nous devons être conscients de tous les types d'utilisateurs, quel que soit leur niveau d'interaction avec une application. Une activité simple que nous pouvons faire ici est de définir le flux de travail typique des « tâches » ou des « opérations » à exécuter. Cela nous aide à identifier les types d'utilisateurs, ou les rôles.

Maintenant que nous connaissons nos différents types d'utilisateurs (personnages), nous pouvons creuser plus profondément pour les comprendre. Alors, comment pouvons-nous comprendre cela ? Écoutons l’histoire directement de la source : pour notre prochaine activité de découverte, nous interrogeons des utilisateurs.

Cela permet de mieux comprendre ce qu’ils doivent faire et pourquoi (les histoires). Au cours de ces entretiens, il est important de garder un esprit ouvert et sans prétention. Nous cherchons à identifier les nuances ou les choses subtiles qu'un utilisateur fait. Ce n’est pas seulement le « quoi » ou le « comment » qu’un utilisateur fait quelque chose, c’est aussi le « pourquoi ».

Interroger les réponses

Considérez les « cinq pourquoi », rendus célèbres par son utilisation chez Toyota. Bien que cette méthode d’enquête soit généralement utilisée comme stratégie de dépannage, il n’y a aucune raison pour que vous n’adoptiez pas cette façon de penser lorsque vous en apprendrez davantage sur les besoins des utilisateurs.

Par exemple, nous faisions une découverte pour une application dans laquelle les répartiteurs attribuaient des travaux à des sous-traitants. Le besoin déclaré était : devoir savoir comment les tâches sont attribués aux contracteurs.

De la part des gestionnaires, nous avons entendu :

1. Pourquoi ? Pour avoir une meilleure idée du nombre de tâches complétées dans une journée

2. Pourquoi ? Pour pouvoir maximiser le nombre de tâches par contracteur

3. Pourquoi ? Pour donner des opportunités aux contracteurs de maximiser leurs paies

4. Pourquoi ? Afin de mieux planifier les contrats ou tâches pour la journée

5. Pourquoi ? Pour pouvoir mieux servir nos clients

Des répartiteurs, nous avons entendu :

1. Pourquoi? Pour avoir une meilleure idée du nombre de tâches complétées par jour

2. Pourquoi? Pour maximiser le nombre que chaque contracteur reçoit

3. Pourquoi? Nous voulons être justes envers nos contracteurs

4. Pourquoi? Parce que nous voulons des contracteurs heureux

5. Pourquoi? Cela nous aide à mieux servir nos clients

Notez qu'il existe de légères variations dans les raisons entre les groupes d'utilisateurs. C'était nouveau et éclairant. Armés de ces informations clés, ils nous ont aidés à identifier les métriques clés que nous avons incluses dans l'interface utilisateur. Tout le monde y gagne!

Wireframing (parce qu'une image vaut mille mots)

Avant de commencer à se lancer dans le code, nous souhaitons valider les pensées et la vision de nos clients avec une structure filaire. En tant que représentation visuelle simple du fonctionnement d'une application proposée, une structure filaire peut être aussi simple que des esquisses sur papier ou aussi interactive qu'un squelette HTML de l'application proposée. L'essentiel est d'illustrer ce que les utilisateurs vont faire et comment cela résout leurs problèmes.

Nous utilisons une structure filaire pour partager fréquemment nos opinions avec le client et nous assurer que nous allons dans la bonne direction et que nous parlons la même langue. À l'instar des objectifs et des mesures de succès, la structure filaire est un autre artefact auquel nous pouvons souvent faire référence et que nous pouvons modifier de manière organique au fur et à mesure que la découverte se poursuit.

Bien qu'il existe de nombreux outils et stratégies concernant les structures filaires, ils partagent tous les mêmes « moments de zen » :

• Échouez rapidement et souvent

• Obtenez les commentaires des utilisateurs tôt et souvent

• Cultivez le fil de fer ensemble

• « Un designer a atteint la perfection, non pas lorsqu'il ne reste plus rien à ajouter, mais lorsqu'il ne reste plus rien à retirer ».

La route continue

Il y a une satisfaction, voire une joie à apprendre ce que les gens font. Il n'y a rien de tout à fait comme le moment « eurêka ! » où nous comprenons vraiment quelque chose, surtout quand une chose simple est forée et jugée plus nuancée qu'elle n'y paraissait. Et cela peut aller dans les deux sens : les utilisateurs savent qu'ils ont été entendus et compris. Rien ne facilite l'engagement de l'utilisateur, à l'instar de la compréhension partagée créée lors de la découverte. Maintenant, ils ont un peu de peau dans le jeu, qui est exactement comment terminer la phase de découverte et passer aux étapes suivantes.