Liberar primeiro ou documento primeiro?

Estou trabalhando em um projeto há alguns anos e estou começando a reunir uma base de usuários decente. Criei uma página de projeto com alguma documentação básica, mas, na verdade, não é muito mais que uma FAQ neste momento. Sei que preciso aprimorá-lo para torná-lo mais informativo para usuários novos e avançados, e isso é o próximo na minha lista de tarefas para o próximo lançamento.

No entanto, a próxima versão possui recursos que a base de usuários deseja obter. Estou preparado para lançá-lo agora, está empacotado e pronto para começar. Eu só preciso implantá-lo nos serviços de distribuição apropriados.

Ao ponto. Os recursos são importantes para meus usuários, mas a documentação é importante para mim. Devo esperar para liberar até reescrever a documentação? Minha base de usuários atual é experiente o suficiente para entender como usar os novos recursos, por isso não é com isso que estou preocupado. Pode levar algumas semanas para terminar os documentos, pois eu tenho tempo livre limitado para trabalhar nesse projeto, mas a comunidade me assaria no espeto se eu os fizesse esperar mais.

O cliente está certo nesse cenário? Um recurso fantástico e direto para usuários existentes deve ter prioridade sobre documentação robusta para novos usuários?

Atualização: Uau, tantas ótimas respostas de alta qualidade! Você realmente me ajudou a entender melhor como eu deveria estar interagindo e apoiando o projeto e seus usuários. Graças um milhão!

Simples: libere uma versão beta! Então, quando a documentação estiver pronta, faça o lançamento final da nova versão.

Se você tem usuários dispostos a experimentar o novo material, tire proveito disso. Você receberá relatórios de erros, provavelmente terá perguntas da comunidade sobre os pontos difíceis, para saber onde se concentrar na documentação etc. Você também pode querer ajustar algumas coisas com base no feedback do usuário, o que pode afetar a documentação.

Basicamente, todo mundo ganha.

Uma razão para não fazer o lançamento antecipado é que, se você acha que seus usuários não receberão uma "versão beta", pense duas vezes antes de fazê-lo, mas seguindo o que escreve, parece que eles ficarão felizes com isso.

Outro motivo seria, se houver dificuldades técnicas em fazer uma versão beta usando os canais de versão que você usa. Então pode ser mais complicado do que vale a pena fazer versões beta e final separadas. Se você acha que seu software está completo, nesse caso, eu me inclinaria para a liberação antecipada, atualize a documentação quando terminar. Caso contrário, há o risco de que a documentação seja adiada e, em seguida, toda a liberação seja adiada ou você acaba liberando sem a documentação final, então faça isso agora.

Se eu entendi direito, você está fazendo este projeto no seu tempo livre e sem dinheiro . Se for esse o caso, faça o que você se sentir melhor (os usuários esperam, documentam seu tempo). Você não deve sentir a pressão dos seus "usuários". Muitas pessoas escreveram sobre isso na Internet (grandes autores e colaboradores do FLOSS que sentiram a pressão).

Mas, se você está sendo pago ou obtém algum benefício, faça o que seus usuários desejam. Isso significa fazer o que for melhor para seus clientes ou usuários ; nesse caso, basta liberá-lo e documentar seu tempo. Você disse que eles iriam encontrar o caminho de volta, então não deve ser grande coisa.

Em geral, existem dois tipos de documentação: a técnica que documenta seu código (classes, unidades, etc.) e como os novos recursos podem operar e ser implementados na documentação do código e do usuário. Na IMO, a documentação técnica é essencial, especialmente se o desenvolvimento de software não for seu trabalho em período integral. Eu passo muito tempo nisso, pois posso ter grandes lacunas durante a escrita do código devido a compromissos de vida.

A documentação do usuário é boa, mas não essencial, acredito. Obviamente, depende da complexidade do aplicativo, da familiaridade da base de usuários com o uso de computadores e sistemas na área de assunto em discussão - no seu caso, parece que seus clientes podem ter uma idéia de como os novos recursos funcionam. Existe uma escola de pensamento por aí argumentando que uma boa experiência do usuário e uma boa interface do usuário exigem documentação mínima do usuário.

Além disso, se o seu tempo for limitado e você realmente sentir pressão para desenvolver a documentação conforme sugerido, poderá fazer alguns vídeos curtos apresentando apenas os novos recursos. Isso economizará tempo para você escrever a documentação real e preencher os detalhes menos importantes.

Algumas dicas de marketing podem permitir que você equilibre as expectativas do usuário e ainda melhore sua marca. Realmente depende do tipo de aplicativo e do fluxo de trabalho que você criou até agora, mas você pode ter uma tela de boas-vindas na sua nova versão e, no aplicativo, pode exibir os vídeos fornecendo links ou reproduzindo os vídeos dentro do aplicativo.

Apenas para adicionar algo não apenas para este exemplo específico, mas para o fluxo de trabalho geral:

A documentação pode ser sua definition of done, mas na maioria das vezes a documentação está além de um produto mínimo viável (MVP).

O cliente não apenas está sempre certo. Se for um produto comercial, a liberação pode ter muito valor comercial e é uma prioridade absoluta.

O proprietário define o valor comercial (qual é você, eu acho); então, o que é mais valioso como produto para seus clientes?

Também existem riscos de liberação sem documentação?

Por exemplo concorrência ; Se a competição lançar esse super-recurso antes de você, você poderá perder alguns usuários.

Faça a si mesmo ou ao proprietário do produto essas perguntas e sua resposta será clara.

Novos recursos tornam os usuários antigos felizes. Uma boa documentação convida novos usuários. Em que você deve se concentrar depende do que você mais precisa. Você indicou que a base de usuários estava em boas condições para que novos recursos possam esperar. Falando como usuário antigo, também gosto de boa documentação. O legal do código aberto: usuários antigos adicionam seus próprios recursos.

Você não esclareceu em sua pergunta e provavelmente não para seus usuários as consequências dessas escolhas. Quanto tempo você gasta em suporte ao usuário? A documentação adicional diminuirá o tempo gasto em suporte ou aumentará as vendas? Qual é a vantagem para você fazer documentação?

Seus usuários desejam novos recursos sobre a documentação, mas eles percebem que pode haver uma diminuição na sua disponibilidade para fornecer suporte, corrigir bugs, liberar patches etc.?

Se eu não me incomodei em ler as instruções quando tudo o que tenho a fazer é enviar um e-mail com a minha pergunta, por que eu iria querer documentação sobre novos recursos?

Se o pacote estiver pronto para o lançamento, libere para o cliente / cliente e comece a trabalhar na documentação. É bom se comunicar com o cliente, quando você compartilhará a documentação que os ajuda a entender os recursos implantados.