Cet article est la troisième partie d’une série sur : La fin du monde Agile n’est pas arrivée. Lisez la partie 2 ici.

Bien, regardons la deuxième valeur fondamentale du manifeste agile :

[…] Nous valorisons un logiciel fonctionnel plutôt qu’une documentation exhaustive.

Honnêtement, j’ai même hésité à écrire un article dédié pour argumenter sur celui-ci.

• Quelqu’un nie-t-il préférer utiliser un produit plutôt que lire un manuel d’utilisation ?
• Qui n’a jamais directement commencé à utiliser son nouveau téléphone sans oser regarder le guide ?
• Qui a quelques heures à perdre de nos jours, avant de pouvoir vraiment faire quelque chose ?

Bien sûr, la documentation doit toujours être là comme backup. Encore une fois, elle est là pour aider là où les humains échouent.

Mais essayons de disséquer cette valeur. Bien sûr, vous pouvez voir la documentation comme un support aux utilisateurs internes (l’équipe de développement), et comme un support aux utilisateurs externes (les utilisateurs finaux). Je l’écrirai davantage depuis la deuxième perspective, mais je dirais que mes points de vue peuvent être tout aussi valides pour les deux.

Pour moi, ça signifie :

1. L’expérience utilisateur finale devrait permettre une prise en main intuitive / L’architecture devrait permettre à un nouveau développeur de rejoindre l’équipe intuitivement (merci les frameworks !)
2. Aucun bug majeur ne devrait altérer ou interrompre cette expérience utilisateur (oui, il n’existe pas de logiciel sans bug dans notre monde) / La dette technique devrait être aussi limitée que possible
3. Il ne devrait pas y avoir de section “FAQ” sur votre site web / de cookbooks dans votre documentation développeur (limitée)
4. L’objectif et les exigences du logiciel que vous développez doivent être cristallins pour tout utilisateur (valable tant pour les usages internes qu’externes)
5. L’équipe de support devrait être constituée des personnes qui ont créé le produit

Là où les 2 premiers points sont assez évidents, même s’il y a malheureusement souvent des désaccords d’opinion dans une équipe à leur sujet, regardons les trois derniers.

Il ne devrait pas y avoir de FAQ sur votre site

Pourquoi ? Parce qu’une question fréquemment posée, qui reçoit une réponse par écrit, est manifestement un cas d’usage que vous n’avez pas réussi à gérer selon le point 1 !

Voilà.

L’objectif et les exigences doivent être cristallins

J’ai déjà un peu écrit sur la façon de trouver le bon problème utilisateur. Non seulement il doit être clair pour vous, ce que vous cherchez à résoudre, mais il doit aussi être clair pour l’utilisateur.

Combien de fois ai-je entendu : “Ça ne marche pas pour moi”, alors que l’utilisateur essayait de faire quelque chose avec un produit qui ne servait pas cet objectif ? C’est facile de dire “Eh bien, ce gars est stupide”. Moi je dis : le créateur de ce produit est stupide. S’il ne peut pas rendre suffisamment clair à quelqu’un ce que son produit est censé faire, et ne pas faire, alors il devrait immédiatement arrêter de travailler sur la technologie, et commencer à se demander ce qu’il a créé.

Bien sûr, le corollaire est que vous devez être fidèle à votre proposition de valeur.

L’étape suivante est de s’assurer que l’utilisateur ne commencera jamais aucune configuration ou utilisation avant de savoir avec certitude que le produit peut réellement fonctionner dans son environnement. Cela peut sembler tordre un peu la valeur du “logiciel fonctionnel”. En effet, en cherchant à atteindre cette valeur, votre logiciel devrait fonctionner dans n’importe quel environnement. Et dans une certaine mesure, vous auriez raison. Mais aujourd’hui, nous le constatons tous, le monde du logiciel est si ramifié qu’il est pratiquement impossible de packager des solutions pour tous. Pensez aux distributions OS, mais aussi aux navigateurs, aux services tiers, etc.

Et même ici, écrire les exigences dans un document est quelque chose d’obligatoire, ce n’est pas la seule option :

• quand c’est possible, vous devriez détecter l’environnement de l’utilisateur avant qu’il ne fasse quoi que ce soit et l’informer s’il peut continuer
• sinon, quand votre produit nécessite une configuration, la toute première étape devrait être pour lui de sélectionner l’environnement sur lequel la configuration sera faite, et cela devrait conditionner toute autre interaction.
• l’objectif devrait inclure un périmètre clair d’exigences
• et en mentionnant la première valeur agile “individus et interactions” : si vous avez une équipe commerciale, assurez-vous qu’elle ne puisse jamais vendre involontairement un produit sans savoir que le client ne remplit pas les exigences requises. La communication, bébé.

Équipe de support = designers + développeurs

C’est peut-être l’un des points les plus difficiles à adopter. Parce qu’aucun développeur ni designer n’acceptera dès le premier jour cette tâche “peu attrayante, à faible valeur ajoutée”. Ils sont plus intelligents que ça.

Note : les designers pour moi sont les UX designers, les UI designers, les product managers, les product owners, et tous ceux qui pourraient être impliqués dans la réflexion sur la façon dont le produit devrait être / faire.

Eh bien, s’ils acceptent, vous avez de la chance, et vous êtes sur la voie du meilleur support imaginable.

Qui peut mieux répondre aux questions ou résoudre des problèmes que les personnes qui ont construit le truc ? Et surtout, quelle leçon est meilleure pour un designer/développeur que d’être confronté au fait difficile et à la réalité des utilisateurs ? Exit les opinions, nous savons maintenant comment les utilisateurs se sentent face à notre produit bogué ! Et c’est la boucle la plus courte pour obtenir un logiciel fonctionnel.

Bonus : les utilisateurs finaux se sentiront toujours importants en sachant qu’ils ont parlé directement aux gens qui ont construit le truc. Ils n’auront jamais à faire face à une personne lisant et essayant de déterminer quels mots-clés de la demande de l’utilisateur correspondent le mieux à sa liste de FAQs sur papier, et ratant complètement l’essentiel. Et la satisfaction s’ensuit.

Un logiciel fonctionnel plutôt qu’une documentation exhaustive est une valeur clé et évidente. Et comme nous l’avons vu, c’est plus que simplement développer un produit sans bugs. Ça implique tout le monde dans l’organisation.

Lire la partie 4 : Collaboration avec les clients plutôt que négociation contractuelle.

Image de une par Dustin Gaffke