Libérer d'abord ou documenter d'abord?

Je travaille sur un projet depuis quelques années maintenant, et je commence à rassembler une base d'utilisateurs décente. J'ai créé une page de projet avec une documentation de base, mais ce n'est vraiment pas beaucoup plus qu'une FAQ à ce stade. Je sais que je dois l'améliorer afin qu'il soit plus informatif pour les nouveaux utilisateurs et les utilisateurs avancés, et c'est le prochain sur ma liste de tâches pour la prochaine version.

Cependant, la prochaine version présente des fonctionnalités que la base d'utilisateurs est impatiente d'obtenir. Je suis prêt à le publier dès maintenant, il est emballé et prêt à l'emploi. J'ai juste besoin de le déployer sur les services de distribution appropriés.

Jusqu'au point. Les fonctionnalités sont importantes pour mes utilisateurs, mais la documentation est importante pour moi. Dois-je attendre la publication avant d'avoir réécrit la documentation? Ma base d'utilisateurs actuelle est suffisamment avertie pour comprendre comment utiliser les nouvelles fonctionnalités, donc ce n'est pas ce qui m'inquiète. Cela peut prendre quelques semaines pour terminer les documents, car j'ai un temps libre limité pour travailler sur ce projet, mais la communauté me rôtirait à la broche si je les faisais attendre plus longtemps.

Le client a-t-il raison dans ce scénario? Une fonctionnalité simple et fantastique pour les utilisateurs existants devrait-elle avoir priorité sur une documentation robuste pour les nouveaux utilisateurs?

Mise à jour: Wow, tant de bonnes réponses de haute qualité! Vous m'avez vraiment aidé à mieux comprendre comment je devrais interagir et soutenir à la fois le projet et ses utilisateurs. Merci mille fois!

Simple: lancez une version bêta! Ensuite, lorsque la documentation est terminée, effectuez la version finale de la nouvelle version.

Si vous avez des utilisateurs prêts à essayer les nouveaux trucs, alors profitez-en. Vous obtiendrez des rapports de bogues, vous obtiendrez probablement des questions de la communauté sur les points difficiles afin que vous sachiez où vous concentrer sur la documentation, etc. Vous pouvez également modifier certaines choses en fonction des commentaires des utilisateurs, ce qui peut affecter la documentation.

Fondamentalement, tout le monde gagne.

Une raison de ne pas faire de publication anticipée est que si vous pensez que vos utilisateurs ne seront pas réceptifs à une "version bêta", alors vous devriez réfléchir à deux fois avant de le faire, mais d'après ce que vous écrivez, on dirait qu'ils seraient heureux.

Une autre raison serait, s'il y a des difficultés techniques à faire une version bêta en utilisant les canaux de version que vous utilisez. Ensuite, cela pourrait être plus compliqué que cela ne vaut de faire des versions bêta et finales distinctes. Si vous pensez que votre logiciel est complet, dans ce cas, je m'appuierais sur une version précoce, mettez à jour la documentation une fois terminée. Sinon, il y a un risque que la documentation soit retardée, puis la version entière soit retardée ou que vous finissiez par sortir sans documentation finale de toute façon, alors faites-le maintenant.

Si je vous comprends bien, vous faites ce projet sur votre temps libre et sans argent . Si tel est le cas, alors faites ce qui vous fait vous sentir mieux (les utilisateurs attendent, documentent votre temps). Vous ne devriez pas ressentir la pression de vos «utilisateurs». Beaucoup de gens ont écrit à ce sujet sur Internet (grands auteurs et contributeurs de FLOSS qui ont ressenti la pression).

Mais, si vous êtes payé ou que vous obtenez des avantages, faites ce que veulent vos utilisateurs. Cela signifie faire tout ce qui est le mieux pour vos clients ou utilisateurs , dans ce cas, il suffit de le publier et de documenter votre temps. Vous avez dit qu'ils trouveraient leur chemin, donc ça ne devrait pas être un gros problème.

En général, il existe deux types de documentation: la technique qui documente votre code (classes, unités, etc.) et comment les nouvelles fonctionnalités peuvent fonctionner et être implémentées dans le code et la documentation utilisateur. OMI, la documentation technique est un must, surtout si le développement de logiciels n'est pas votre travail à temps plein. J'y passe beaucoup de temps car je peux avoir de grandes périodes d'écriture de code en raison d'engagements de la vie.

La documentation utilisateur est bonne mais pas indispensable je crois. Bien sûr, cela dépend de la complexité de l'application, de la familiarité de la base d'utilisateurs avec l'utilisation d'ordinateurs et de systèmes dans le domaine en discussion - dans votre cas, il semble que vos clients puissent comprendre le fonctionnement des nouvelles fonctionnalités. Il existe une école de pensée qui soutient qu'une bonne expérience utilisateur et une bonne interface utilisateur nécessitent une documentation utilisateur minimale.

De plus, si votre temps est limité et que vous ressentez vraiment une pression pour développer la documentation comme vous le suggérez, vous pouvez faire quelques courtes vidéos présentant uniquement les nouvelles fonctionnalités. Cela vous fera gagner du temps pour rédiger la documentation réelle et vous pourrez alors remplir les détails les moins importants.

Certains conseils marketing peuvent vous permettre d'équilibrer les attentes des utilisateurs tout en renforçant votre marque. Cela dépend vraiment du type d'application et du flux de travail que vous avez créé jusqu'à présent, mais vous pouvez avoir un écran de bienvenue dans votre nouvelle version et dans l'application, vous pouvez afficher les vidéos en fournissant des liens ou en lisant les vidéos dans l'application.

Juste pour ajouter quelque chose non seulement pour cet exemple spécifique mais pour le flux de travail général:

La documentation peut être la vôtre definition of done, mais la documentation dépasse la plupart du temps un produit viable minimal (MVP).

Non seulement le client a toujours raison. S'il s'agit d'un produit commercial, la libération peut avoir beaucoup de valeur commerciale et est une priorité absolue.

Le propriétaire définit la valeur commerciale (qui est vous, je pense), alors qu'est-ce qui a le plus de valeur en tant que produit pour vos clients?

Y a-t-il également des risques de publication sans documentation?

Par exemple, la concurrence ; Si la concurrence sort cette super fonctionnalité avant vous, vous risquez de perdre certains utilisateurs.

Posez-vous ces questions au propriétaire du produit et votre réponse sera claire.

Les nouvelles fonctionnalités rendent les anciens utilisateurs heureux. Une bonne documentation invite de nouveaux utilisateurs. Ce sur quoi vous devez vous concentrer dépend de ce dont vous avez le plus besoin. Vous avez indiqué que la base d'utilisateurs était saine pour que les nouvelles fonctionnalités puissent attendre. Parlant en tant qu'ancien utilisateur, j'aime aussi une bonne documentation. Une bonne chose à propos de l'open source: les anciens utilisateurs ajoutent leurs propres fonctionnalités.

Vous n'avez pas précisé dans votre question et probablement pas à vos utilisateurs les conséquences de ces choix. Combien de temps passez-vous sur le support utilisateur? La documentation supplémentaire réduira-t-elle le temps que vous consacrez au support ou augmentera-t-elle les ventes? Quel est l'avantage pour vous de faire de la documentation?

Vos utilisateurs souhaitent de nouvelles fonctionnalités par rapport à la documentation, mais réalisent-ils qu'il pourrait y avoir une diminution de votre disponibilité pour fournir un support, corriger des bugs, publier des correctifs, etc.?

Si je n'ai pas pris la peine de lire les instructions alors que tout ce que j'ai à faire est de vous envoyer un e-mail avec ma question, pourquoi aurais-je besoin de documentation sur les nouvelles fonctionnalités?

Si le package est prêt à être publié, libérez-le au client / client et commencez à travailler sur la documentation. Il est bon de communiquer avec le client, lorsque vous partagerez la documentation qui les aidera à comprendre les fonctionnalités déployées.