Méthodes agiles : 50 conseils pratiques (épisode III)

Cet article est le troisième d’une série de cinq épisodes intitulée Méthodes Agiles : 50 conseils pratiques.

21.      Mettez fin à la confusion entre la notion de client et celle d’utilisateur

Etre client est une chose. Etre utilisateur une autre. Si vous êtes bancarisée à titre personnel au LCL, rien ne vous empêche d’utiliser un distributeur de billets de la Société Générale ou de la Poste. Vous serez alors l’utilisateur d’un service proposé par la Société Générale ou par la Poste, sans en être pour autant le client. C’est encore plus vrai pour le web. Vous êtes utilisateur de Google sans jamais lui verser un euro, vous n’en êtes donc pas le client. Idem pour Hotmail, Twitter, Facebook, Instagram et consorts. L’existence de cette confusion est suffisamment importante pour que nous insistions. Lorsque vous développez un nouveau service web, gardez à l’esprit qu’il y a aura vraisemblablement plus d’utilisateurs que de clients et que les besoins des premiers ne concordent pas nécessairement avec les besoins des seconds. Exemple : un directeur commercial sera client de la solution Salesforce mais n’en aura pas la même utilisation que ses équipes de commerciaux. Gardez à l’esprit que vos équipes seront souvent tiraillées entre ce que le client exige et ce qu’il convient de développer effectivement pour les utilisateurs.

22.      Soyez radins, pas tout le temps, mais tout de suite

Si la phase amont d’analyse et de cadrage d’un projet est difficile et tout comme un business plan, par nature condamnée à être erronée, il n’empêche qu’elle peut être néanmoins intelligemment utilisée pour identifier le plus tôt possible les dépendances, les pans du projet parallèlisables, les impacts sur les autres services de l’entreprise, les effets de bord, la nécessaire implication de ressources et de services non IT. Faites l’exercice le plus tôt possible et avec le plus grand soin. Comme Gartner le précisait dès 2010, sur l’ensemble d’un cycle de vie d’un projet, 40% des économies (de temps et d’argent) peuvent être réalisées au moment de la phase amont.

23.      Organisez les tests en guérilla

Dans la philosophie du développent agile, l’utilisateur est le roi. C’est à lui qu’il reviendra d’adopter ou non votre produit, votre service, votre site web, votre appli mobile. L’expérience utilisateur a considérablement évolué et la moindre petite erreur en ce domaine peut être lourde de conséquence. Ne laissez pas traîner les petites imperfections susceptibles de pénaliser l’expérience client. Formez très tôt une équipe de testeur destinés à réaliser régulièrement des Users Acceptance Tests et à fournir des feedbacks. Aider les en les outillant et en leur expliquant comment faire remonter leurs remarques de sorte que les codeurs en soient avertis le plus vite possible et mis en situation de pouvoir corriger très rapidement. Recrutez en interne. Les nouveaux entrants (avec leur œil neuf) et les stagiaires peuvent s’avérer de précieux contributeurs.

24.      Ne traitez pas les codeurs comme des exécutants

Souvent très concentrés, silencieux et les yeux rivés sur leurs écrans, les développeurs peuvent finir par donner l’impression d’avoir toujours été là, de faire partie des meubles, au point qu’on en oublie de considérer combien ils savent penser… au-delà de leur propre expertise. Exposez leurs la stratégie globale de l’entreprise au projet de laquelle ils contribuent. Les grandes orientations de cette dernière auront un impact, tôt ou tard, sur ce qu’ils développent aujourd’hui. Et réciproquement. Exemple, le choix d’une technologie de paiement, couvrira l’essentiel du besoin des utilisateurs français aujourd’hui mais deviendra largement insuffisante le jour où l’entreprise voudra étendre son activité digitale en Allemagne. Laissez vos développeurs anticiper. Ils savent et ils aiment.

25.      Ecoutez bien les dialogues de sourds

Les méthodes de développement agiles privilégient les interactions fréquentes et régulières entre les différents contributeurs du projet. Il n’est pas rare que les développements aient commencés le travail depuis plusieurs semaines, voire plusieurs mois, sans que les donneurs d’ordres (souvent le marketing produit) et les équipes de développement ne se soient véritablement compris sur ce qui était attendu. La succession ininterrompue des interactions, formulées sous formes de tickets par les utilisateurs, dans des logiciels de développement agile, pris en compte par les développeurs au fil de l’eau devient alors le moyen pour les uns et pour les autres de tenter de se comprendre, donnant l’illusion que tout avance bien pour autant. C’est faux ! Réagissez !

26.      Regardez par la fenêtre

Ne négligez pas de continuer à observer sans relâche les concurrents. Surtout ceux qui n’étaient pas là au début de votre projet et qui depuis sont apparus. Peut-être ont-ils pris un temps d’avance sur ce que vous envisagiez de lancer, changer la donne du marché en y introduisant une nouveauté qui pourrait devenir désormais incontournable, eu des bonnes idées à répliquer… Envisagez cette veille davantage comme une source de stimulation, d’émulation que comme des occasions de découragements.

27.      Attribuez le lead technologique aux équipes techniques

Il est primordial que les choix techniques soient clairs et assumés. Cela n’interdit pas le dialogue ou l’échange à leurs sujets entre marketing produit et équipe de développement. Ce qui compte est que la décision de la solution technologique retenue et des choix techniques qui suivront soient attribués plutôt aux équipes de développement, qu’au marketing produit et encore moins au client, qu’il soit interne ou externe (sauf s’il l’impose). Les frustrations que créé le fait d’imposer une technologie aux équipes technique (si elle n’est pas leur spécialité) ne se voient pas de prime abord mais peuvent s’avérer très pénalisantes par la suite.

28.      Entraînez l’équipe projet à affronter les HIPPOs.

Un projet sera rarement préservé de l’intervention d’un des membres de la C-suite de l’entreprise : son CTO (Chief Technical Officer), son CDO (Chief Digital Officer), son second CDO (Chief Data Officer), son CFO (Chief Financial Officer). HIPPO signifie Highest Paid Person Opinion ou opinion de la personne la mieux payée en français (autant dire quelqu’un de haut placé dans la hiérarchie). Les HIPPOs ne manqueront pas de montrer le bout de leurs nez et l’équipe projet aura peine à ne pas tenir compte de leurs remarques, sauf à ce qu’elle soit soudée, complètement focalisée sur le projet et prête à ne rien lâcher pour ne pas mettre en danger le projet. Encouragez, préservez et protégez cette cohésion d’équipe et cette posture. Votre projet ne s’en portera que mieux.

29.      Respectez la règle BSHC

L’expérience montre que le meilleur enchaînement est Brainstorming > Sketching > HTML > Coding (BSHC). Le brainstorming doit ne pas s’interrompre tant que ce qui doit être développé n’est pas suffisamment clair pour rendre possible la phase de sketching (dessins des écrans du site web). Arrive alors la phase de montage des pages (en HTML) qui rendra tangible le site et permettra aux utilisateurs de se figurer à quoi ressemblera l’expérience qu’ils auront du service. La phase de coding, ou de développement informatique arrivera ensuite.

30.  Acceptez de revoir votre copie

L’essentiel en développent agile et de mettre en ligne un Minimal Viable Product (MVP) qui permettra au service d’être live, aux utilisateurs de s’en emparer, au marketing produit d’orienter en fonction des usages observés les évolutions futures du produit. Exemple, un service imaginé pour permettre aux petites entreprises de mieux gérer leur comptabilité, pourra s’avérer après observation être davantage et spontanément utilisé par des experts comptables. Tout l’art consistera alors à descoper, c’est-à-dire à retirer du scope (périmètre) initial des fonctionnalités qui s’avèrent moins prioritaires. L’exercice peut s’avérer difficile. Mais il faut s’y plier.