L’impact positif des méthodes Agile et de la livraison continue sur le cycle de développement sont nombreux et connus. Je ne vais pas rentrer dans le détail des avantages pour les développeurs et les managers, la question a déjà été abondamment abordée par des gens qui s’y connaissent bien mieux que moi.
Dans cet article, je vais plutôt aborder Agile en tant que rédactrice technique, et expliquer pourquoi, à mon humble avis, ce type de développement mène à une aide utilisateur de bien meilleure qualité.
Martine fait du développement en cascade : une tragédie en deux actes
Le logiciel sur lequel je travaille utilisait historiquement le développement en cascade. Une sortie de version majeure avait lieu tous les deux ou trois ans, la nouvelle version contenant toutes les nouveautés créées depuis la version précédente.
Dans l’idéal, les nouveautés auraient dû être testées et documentées dans le dernier tiers du développement.
Notez l’expression ‘dans l’idéal’.
Dans la pratique, nous avions deux cas courants :
1. l’équipe de développement ne se rendait pas compte à temps à quel point un projet peut accumuler de retard en trois ans. Ils finissaient le développement environ six secondes avant la deadline, les tests et l’aide utilisateur étaient faits à la dernière minute en retenant difficilement des cris de marcassin
2. l’équipe de développement prenait en compte les retards à venir, généralement après avoir appris la leçon à coups de cris de marcassin. Elle mettait l’équipe de QA et de doc dans la boucle le plus tôt possible pour mitiger l’impact des retards, et obtenait en échange des retours gratuits sur l’utilisabilité de l’interface ainsi qu’un sachet occasionnel de croissant
Je ne blâme en aucun cas les développeurs du cas n°1, ils étaient les victimes de longues années de mauvaises habitudes de gestion.
Je chéris les développeurs de l’équipe n°2 du plus profond de mon cœur.
A la surprise générale, cette atmosphère de travail donnait un produit fini qui laissait quelque peu à désirer. Les nouvelles versions avaient tendance à être instables à la sortie, à requérir d’énormes patchs dans les jours et les semaines suivantes. Les équipes de correction et de tests étaient totalement débordées et avaient généralement besoin de se mettre en PLS sous une table pendant une semaine ou deux pour se calmer les nerfs, une fois la vague passée.
Le problème était récurrent et hautement visible pour les utilisateurs, qui refusaient systématiquement d’utiliser les nouvelles versions. Il fallait donc continuer à maintenir les versions N-1, N-2 voire N-3 et 4, ce qui en plus d’être ridicule demandait un temps et une énergie folle aux équipes.
Ce temps et cette énergie ne pouvaient pas être consacrés à la future version, et le serpent se mordait la queue.
Evidemment, tout cela avait un impact sur l’aide utilisateur.
Pendant la majorité du cycle de version, les développeurs et les experts soit n’avaient rien à me fournir soit n’étaient vraiment pas pressés de le faire, ce qui empêchait le chantier de doc de commencer. Je devais donc trouver moi-même de quoi m’occuper, généralement en sélectionnant une option déjà existante qui n’était pas encore documentée et en me faisant les dents dessus.
Précisons qu’avant le début de mon contrat en 2014, le logiciel concerné avait déjà deux décennies d’histoire et quasiment aucune aide utilisateur. Des masses incroyables d’information existaient, mais elles étaient soigneusement cachées dans des dossiers personnels ou dans des classeurs papiers épais comme la cuisse, stockés dans des placards divers sans logique particulière. Si, comme moi, vous ne saviez pas déjà où chercher, bon courage (et même si vous saviez, il fallait attraper une pelle et creuser).
Dans un nombre impressionnant de cas, il était juste impossible de comprendre ce que faisait la fenêtre à documenter juste en l’utilisant, et la seule personne qui l’avait jamais su était partie à la retraite en 2005.
Fouiller dans de vieux PowerPoint n’aidait généralement pas, et je devais donc aller demander à un développeur, trop gentil pour m’envoyer paître, de jeter un œil au code pour essayer de décrypter quelque chose d’exploitable. Ce genre de chose occupait probablement 95% de mon temps.
Les 5% restant concernaient le mois avant la date de sortie, au cours duquel trois douzaines de nouvelles options à documenter m’étaient lancées à la figure à grande vitesse, généralement accompagnées d’un petit mot qui disait “ça marche pas pour l’instant donc on peut pas fournir de captures 🙂 ”.
Inutile de dire que la qualité du résultat me satisfaisait rarement.
Libérée, délivrée
Un jour radieux, quelqu’un à la direction décida que tout ce cirque nuisait à l’image de marque du produit et que tout le monde devait passer en mode Agile. Une nouvelle version serait livrée tous les trois mois à l’aide d’un pipeline de livraison continue.
Nous avions six mois pour faire la transition.
Un chœur angélique résonna, accompagné d’une petite vague de panique causée par le fait que six mois n’est vraiment pas très long, surtout quand on part de loin.
Un an plus tard, la première version ‘livraison continue’ du logiciel sortait enfin, et elle sortait stable.
Elle marchait, sans blocage, sans plantage, sans cascade de messages d’erreurs qui recouvraient tout l’écran en quelques secondes.
Et l’aide utilisateur était bonne.
Comme chaque version n’avait qu’une poignée de nouveautés, les développeurs et les experts étaient beaucoup moins obligés de jongler et pouvaient se concentrer sur chaque option. Le niveau de stress était plus bas, et l’atmosphère de travail plus plaisante. Chacun avait plus de bande passante à dédier à des choses considérées, jusque-là, comme non-essentielles, comme par exemple la doc ou créer des interfaces utilisables par de vrais humains.
Soudain, j’étais invitée à des réunions d’avancement, et mes retours étaient souhaités et appréciés. Je pouvais suivre les évolutions des options existantes pour maintenir la doc à jour au fur et à mesure. Je n’étais plus obligée de faire les mises à jour de manière anarchique, quand je tombais par hasard sur un changement dont personne ne m’avait prévenue.
Les experts ont commencé à me contacter directement pour me proposer des démos et de discuter de l’aide utilisateur. Je n’avais même plus besoin de leur courir après, parce qu’ils avaient du temps à me consacrer. Ils relisaient la doc et me faisaient des retours réfléchis et pertinents. Ils me donnaient des captures d’écran sans même avoir besoin de réclamer.
(Certains d’entre eux faisaient tout ça, en tout cas. Il y a et aura toujours un contingent de personnes qui ont tendance à oublier que j’existe ou qui ne sont pas intéressés, mais cette histoire est positive donc ignorons-les pour cette fois.)
Cerise sur le gâteau, comme les experts passaient plus de temps avec moi, ils devenaient curieux. Ils voulaient savoir s’ils pouvaient rédiger de l’aide utilisateur eux-mêmes. Ils hochaient la tête quand j’expliquais l’importance du guide de style et pourquoi je reprendrais probablement leur travail. Ils demandaient à être formés sur l’outil de création d’aide utilisateur, et ils s’en servaient même une fois le premier élan de curiosité passé.
Ce dernier point était aidé par le fait que nous venions tout juste de changer d’outil de rédaction dont je chantais les louanges à quiconque avait la malchance de se tenir trop près de moi pendant plus de cinq secondes.
(Cet outil est toujours en place, je l’aime d’un amour vrai et pur, vous pouvez demander une démo ici.)
Avant, je devais me débrouiller seule, armée d’une pelle et d’une incapacité très pratique à ne pas me rendre compte qu’on me demandait de ficher le camp. Après, j’avais l’équivalent d’une équipe entière de rédacteurs techniques en herbe et une place de choix dans le processus de développement.
La bascule a eu lieu il y a maintenant quatre ans, ou peut-être cinq, honnêtement le temps a perdu toute signification. J’ai plus de cinquante utilisateurs enregistrés dans l’outil de création d’aide. Ils ne sont pas tous très actifs, mais ils ont tous été assez intéressés pour au moins essayer, et ça ne serait jamais arrivé si nous n’étions pas passés aux méthodes Agile.
Pour conclure un article qui aurait pu être nettement plus court
Même le rédacteur technique le plus aguerri ne peut pas travailler seul.
Pour créer une aide utilisateur de qualité, il aura besoin de plusieurs éléments : des informations, la participation des experts et du temps :
- Sans information, l’aide ne sera pas complète
- Sans participation, elle ne sera pas pertinente
- Sans temps, elle ne sera ni l’un ni l’autre.
Plus l’équipe dans son entier est sous pression, plus ces trois ressources sont rares. L’impact sur l’aide utilisateur ne peut être que négatif, et une aide de basse qualité donne une mauvaise image du produit auquel elle est attachée.
Un utilisateur perdu n’y trouvera pas ce dont il a besoin et appellera la hotline, ce qui fait augmenter les coûts.
Si la frustration s’accumule suffisamment, l’utilisateur risque d’abandonner et d’utiliser un autre logiciel.
Avoir une aide de qualité est dans l’intérêt de tout éditeur logiciel, et cette mission est grandement facilitée par la méthode Agile.
L’utilisation d’un outil de rédaction conçu pour encourager cette transversalité et cette collaboration est alors un plus indéniable.
