Personne n'aime rédiger de la documentation, mais tout le monde en a besoin, en particulier dans les projets gouvernementaux. Il n'est pas facile pour les startups de trouver un équilibre entre le monde de l'innovation, qui évolue rapidement, et les exigences formelles de la documentation gouvernementale. Examinons les défis communs aux deux parties - ce à quoi les organisations sont confrontées et ce que les équipes gouvernementales attendent - et proposons les meilleures pratiques pour les relever, tout en restant agile et gérable.
Pourquoi la documentation est-elle importante dans les projets gouvernementaux ?
La documentation n'est peut-être pas très glamour, mais dans les projets avec les ministères et les autorités, elle est aussi essentielle que le produit ou le logiciel lui-même. Les agences gouvernementales ont besoin d'une documentation claire, accessible et détaillée pour répondre aux exigences légales, assurer la longévité du projet et avoir la capacité de tenir les citoyens informés jusqu'à un certain point. Pour les startups, le passage d'un travail rapide et itératif à des documents longs et formels est un défi. Avez-vous déjà eu l'impression d'essayer d'atteindre une cible mouvante en matière de documentation ? Vous n'êtes pas le seul !
Voici une anecdote amusante (et un peu humiliante) :
Après avoir déployé des efforts considérables pour peaufiner un manuel de l'utilisateur, nous l'avons soumis, assez fiers de nous. Les commentaires que nous avons reçus ? "C'est très bien, mais pourriez-vous ajuster le ton pour qu'il corresponde au style plus formel des autres documents ?" Nous avons dû rire : parfois, la clarté n'est pas la seule priorité en matière de documentation !
Les défis et la manière dont nous les avons relevés
Défi A : Amener les gens à travailler sur la documentation
Pour les startups agiles, la documentation peut sembler être une réflexion après coup. Avec des délais serrés et la construction de fonctionnalités, qui a envie de s'arrêter pour écrire un document de 30 pages ?
Comment nous avons abordé le problème :
Nous avons intégré la documentation dans nos cycles de sprint. En créant des mises à jour progressives tout au long du projet, la rédaction est devenue une partie intégrante du flux de travail plutôt qu'une tâche finale redoutée. Nous avons également réattribué régulièrement le rôle de "champion de la documentation", ce qui a permis de répartir les responsabilités et de garder les choses fraîches.
Défi B : Comprendre les exigences gouvernementales
Les membres des startups travaillent rapidement, mais les exigences gouvernementales se présentent souvent sous la forme de longs documents formels qui peuvent être difficiles à assimiler.
Comment nous l'avons relevé :
Au lieu de passer directement à un retour d'information formel, nous avons d'abord cherché à obtenir des informations informelles. Nous partagions une version préliminaire dès le début, ce qui permettait aux partenaires gouvernementaux de nous donner une idée de ce qu'ils attendaient et de la manière dont ils aborderaient l'examen du document. Cela nous a permis de procéder à des ajustements précoces et de mieux nous aligner sur leurs normes avant de nous lancer dans des révisions officielles.
Défi C : Maintenir la documentation à jour (avant que quiconque ne se plaigne)
Les environnements agiles évoluent rapidement, et le temps que vous écriviez quelque chose, il se peut que ce soit déjà dépassé.
Comment nous l'avons relevé :
La cohérence était essentielle. Nous avons consacré du temps à la mise à jour des documents au cours de chaque sprint, afin de garantir l'actualité des informations. Nous avons également veillé à obtenir régulièrement un retour d'information de la part du gouvernement, afin que les changements ne s'accumulent pas. Le fait de garder les choses petites et gérables a permis d'éviter les bousculades de dernière minute.
Défi D : Manque de retour d'information de la part des utilisateurs
Souvent, les personnes qui examinent la documentation ne sont pas celles qui utilisent le produit. Par conséquent, ces commentaires peuvent ne pas refléter la façon dont les utilisateurs se servent de Wire et des documents d'appui.
Comment nous l'avons résolu :
En travaillant en étroite collaboration avec nos partenaires gouvernementaux, nous avons compris l'intérêt d'ajouter un "guide de démarrage rapide" simplifié au manuel. Leurs commentaires nous ont aidés à comprendre que les gens - qui ne sont pas forcément des experts techniques - bénéficieraient d'un guide plus court et plus digeste. Cette collaboration a débouché sur une solution qui, de l'avis des deux parties, améliorerait l'expérience de l'utilisateur sans compromettre les détails requis.

Bonnes pratiques - Ce qu'il faut faire et ce qu'il faut éviter
Ce qu'il faut faire
-
Diviser les tâches de documentation en parties gérables au cours de chaque sprint.
-
Obtenir un retour d'information informel avant les révisions formelles afin de repérer rapidement les problèmes majeurs.
-
Maintenir la documentationà jour, plutôtque d'attendre la fin du projet
-
Rester en contact avec le gouvernement pour éviter tout décalage.
Ce qu'il faut éviter
-
Ne pas commencer à documenter à la dernière minute
-
Ne pas partir du principe que les évaluateurs gouvernementaux sont les personnes qui utilisent le produit au quotidien - adapter la documentation en conséquence
-
Ne pas oublier que l'accessibilité et la clarté sont aussi importantes que le contenu.
Conclusion - Ce que nous avons appris
La documentation gouvernementale est rarement une partie de plaisir, mais elle peut être gérable. Grâce à une bonne communication, à une bonne planification et à la collecte précoce de commentaires informels, nous avons réussi à concilier flexibilité et formalisme. La prochaine fois, nous commencerons la documentation plus tôt et nous veillerons à être plus proactifs en matière de retour d'information.
Car, en fin de compte, personne ne souhaite rédiger de la documentation, mais tout le monde en a besoin, en particulier les gouvernements !