¿Liberar primero o documentar primero?

He estado trabajando en un proyecto durante un par de años y estoy empezando a reunir una base de usuarios decente. He creado una página de proyecto con documentación básica, pero en este momento no es mucho más que una pregunta frecuente. Sé que necesito mejorarlo para que sea más informativo para los usuarios nuevos y avanzados, y eso es lo siguiente en mi lista de tareas pendientes para el próximo lanzamiento.

Sin embargo, la próxima versión tiene características que la base de usuarios está ansiosa por obtener. Estoy preparado para lanzarlo ahora, está empaquetado y listo para funcionar. Solo necesito implementarlo en los servicios de distribución apropiados.

Al punto. Las características son importantes para mis usuarios, pero la documentación es importante para mí. ¿Debo esperar para liberar hasta después de reescribir la documentación? Mi base de usuarios actual es lo suficientemente inteligente como para entender cómo usar las nuevas funciones, así que eso no es lo que me preocupa. Puede llevar un par de semanas terminar los documentos, ya que tengo un tiempo libre limitado para trabajar en este proyecto, pero la comunidad me asaría rápidamente si los hiciera esperar más.

¿Tiene razón el cliente en este escenario? ¿Debería una característica fantástica y directa para los usuarios existentes tener prioridad sobre la documentación sólida para los nuevos usuarios?

Actualización: ¡ Guau, tantas respuestas excelentes y de alta calidad! Realmente me has ayudado a comprender mejor cómo debería interactuar y apoyar tanto el proyecto como a sus usuarios. ¡Un millón de gracias!

Simple: ¡lanza una versión beta! Luego, cuando finalice la documentación, realice el lanzamiento final de la nueva versión.

Si tiene usuarios dispuestos a probar las cosas nuevas, entonces aproveche todo eso. Obtendrá informes de errores, probablemente recibirá preguntas de la comunidad sobre los puntos difíciles para que sepa dónde concentrarse en la documentación, etc. También es posible que desee modificar algunas cosas en función de los comentarios de los usuarios, que pueden afectar la documentación.

Básicamente, todos ganan.

Una razón para no hacer un lanzamiento anticipado es que, si cree que sus usuarios no serán receptivos a una "versión beta", entonces debería pensarlo dos veces antes de hacerlo, pero siguiendo lo que escribe, parece que estarían contentos con eso.

Otra razón sería, si hay dificultades técnicas para hacer una versión beta utilizando cualquier canal de versión que utilice. Entonces podría ser más complicado de lo que vale la pena hacer versiones beta y finales por separado. Si cree que su software está completo, entonces en este caso me inclinaría por la versión temprana, actualice la documentación cuando esté listo. De lo contrario, existe el riesgo de que la documentación se retrase, y luego se retrase la publicación completa o termine lanzando sin la documentación final de todos modos, así que hágalo ahora.

Si te entendí bien, estás haciendo este proyecto en tu tiempo libre y sin dinero . Si este es el caso, haga lo que lo haga sentir mejor (los usuarios esperan, documenten su tiempo). No debe sentir la presión de sus "usuarios". Muchas personas escribieron sobre esto en Internet (grandes autores y colaboradores de FLOSS que sintieron la presión).

Pero, si le pagan o recibe algún beneficio, haga lo que sus usuarios quieren. Esto significa hacer lo que sea mejor para sus clientes o usuarios , en ese caso, simplemente libérelo y documente en su tiempo. Dijiste que encontrarían su camino, así que no debería ser un gran problema.

En general, hay dos tipos de documentación: la técnica que documenta su código (clases, unidades, etc.) y cómo las nuevas funciones pueden operar e implementarse en el código y la documentación del usuario. En mi opinión, la documentación técnica es imprescindible, especialmente si el desarrollo de software no es su trabajo a tiempo completo. Dedico mucho tiempo a esto, ya que puedo tener grandes brechas en los períodos de escritura del código debido a compromisos de por vida.

Es bueno tener documentación del usuario, pero no es esencial, creo. Por supuesto, depende de la complejidad de la aplicación, la familiaridad de la base de usuarios con el uso de computadoras y sistemas en el área temática en discusión; en su caso, parece que sus clientes pueden comprender cómo funcionan las nuevas funciones. Existe una escuela de pensamiento argumentando que una buena experiencia de usuario y una buena interfaz de usuario requieren una documentación mínima del usuario.

Además, si su tiempo es limitado y realmente siente la presión de desarrollar la documentación que sugiere, puede hacer un par de videos breves que solo presentan las nuevas funciones. Esto le dará algo de tiempo para escribir la documentación real y luego podrá completar los detalles menos importantes.

Algunos consejos de marketing pueden permitirle equilibrar las expectativas de los usuarios y aún así impulsar su marca. Realmente depende del tipo de aplicación y el flujo de trabajo que ha creado hasta ahora, pero podría tener una pantalla de bienvenida a su nueva versión y dentro de la aplicación puede mostrar los videos ya sea proporcionando enlaces o reproduciendo los videos dentro de la aplicación.

Solo para agregar algo no solo para este ejemplo específico sino también para el flujo de trabajo general:

La documentación puede ser suya definition of done, pero la mayoría de las veces va más allá de un producto viable mínimo (MVP).

No solo el cliente siempre tiene la razón. Si se trata de un producto comercial, la liberación puede ser un gran valor comercial y es una prioridad absoluta.

El propietario define el valor comercial (que creo que es usted), entonces, ¿qué es más valioso como producto para sus clientes?

¿También hay algún riesgo de liberación sin documentación?

Por ejemplo competencia ; Si la competencia lanza esta súper función antes que usted, es posible que pierda algunos usuarios.

Hágase estas preguntas o al propietario del producto y su respuesta será clara.

Las nuevas funciones hacen felices a los viejos usuarios. Buena documentación invita a nuevos usuarios. En lo que debe concentrarse depende de lo que más necesita. Usted indicó que la base de usuarios estaba en buen estado para que las nuevas funciones puedan esperar. Hablando como un viejo usuario, también me gusta la buena documentación. Lo bueno del código abierto: los antiguos usuarios agregan sus propias características.

No ha aclarado en su pregunta y probablemente no a sus usuarios las consecuencias de estas elecciones. ¿Cuánto tiempo pasas en soporte al usuario? ¿La documentación adicional disminuirá la cantidad de tiempo que dedica al soporte o aumentará las ventas? ¿Cuál es la ventaja para usted de hacer documentación?

Sus usuarios desean nuevas funciones sobre la documentación, pero ¿se dan cuenta de que podría haber una disminución en su disponibilidad para proporcionar soporte, corregir errores, liberar parches, etc.?

Si no me molesté en leer las instrucciones cuando todo lo que tengo que hacer es enviarle un correo electrónico con mi pregunta, ¿por qué querría alguna vez documentación sobre las nuevas funciones?

Si el paquete está listo para su lanzamiento, suéltelo al cliente / cliente y comience a trabajar en la documentación. Es bueno comunicarse con el cliente, cuando compartirá la documentación que lo ayuda a comprender las características implementadas.