La documentación puede ser una de esas cosas que pasa por alto las brechas en términos de responsabilidad del área funcional y, por lo tanto, se convierte en algo que la administración del producto debe ver hasta su finalización de muchas maneras para garantizar el éxito en el mercado. Entonces esa es la respuesta de alto nivel.
Detalles específicos en las etapas del ciclo de vida del producto:
Diseño: idealmente, si ha hecho un buen trabajo definiendo las personas objetivo del usuario, sus problemas y objetivos, modelos mentales y capacitación preexistentes, e iterado a través del diseño con comentarios del mercado, no debería necesitar ninguna documentación. Sin embargo, ese es el ideal. En realidad, todo generalmente necesita alguna explicación. Pero debe ser el objetivo al que aspira cuando establece diseños, requisitos y planes.
Desarrollo: creo que es importante definir en los criterios de aceptación que las fuentes (por ejemplo, los desarrolladores que trabajan en una función) han proporcionado la documentación de referencia necesaria para actividades posteriores posteriores. Una historia o característica del usuario no debe considerarse completa si es solo el código de trabajo y no hay una explicación de cómo usarla o darle sentido, especialmente si algo ha cambiado. La idea es sacar de la cabeza de las personas todo lo que otras personas necesitarán para meterse en sus cabezas. Esto puede hacerse convenientemente con imágenes fijas / instrucciones escritas o capturas de pantalla de video / comentarios en los criterios de aceptación, durante las revisiones y demostraciones de sprint. Es probable que los clientes vuelvan a hacer preguntas a las personas en el transcurso del desarrollo, por lo que debe capturarlas.
Escritura técnica: esta es una habilidad funcional de buena fe, por lo que no es correcto si las personas de la organización piensan que escribir un correo electrónico o para uso interno es lo mismo que escribir documentación clara y efectiva para los seres humanos que le pagan dinero. Es posible que tenga que hacer algunos cambios internos de ventas / clientes potenciales para adquirir recursos en esta área. Un escritor técnico experto mejora no solo la escritura, sino también la eficiencia de los esfuerzos relacionados, como el uso de mapas DITA u otras técnicas de gestión de contenido, otras áreas funcionales no son expertos o no tienen tiempo para hacerlo. Thrash se reduce significativamente y otras áreas funcionales pueden centrarse en sus tareas principales. De lo contrario, corre el riesgo de que las personas traten la documentación como una idea posterior o acumulen una enorme deuda técnica para pagar más adelante con “basura adentro, basura afuera”.
Proporcionar contenido / escalado: PM puede tener que aportar su conocimiento de los usuarios objetivo, cómo debería funcionar la funcionalidad, cómo relacionarla con la resolución de problemas comerciales específicos, ya que puede tener la mejor perspectiva de espectro completo. Esta es la misma actividad de generación de contenido de línea de base / estándar que la creación de capacitación o material de ventas en productos nuevos o modificados, o tener un conocimiento profundo de cómo una pieza de funcionalidad resuelve un problema del mercado. Al igual que con otras herramientas para garantizar el éxito del mercado, PM debe pensar en cómo crear un sistema escalable que pueda resolver muchos problemas para muchas personas con el menor costo de recursos.
En resumen, creo que PM necesita asegurarse de que la documentación se considere en cada etapa de desarrollo para garantizar el éxito del mercado. PM no necesariamente tiene que estar involucrado en la ejecución (idealmente), sino que, como propietario, debe crear controles y equilibrios para garantizar que se obtengan los resultados deseados. Por ejemplo, un nuevo usuario que no esté familiarizado con el producto puede lograr un resultado particular sin soporte directo o capacitación, o hay una reducción cuantificable en las métricas de soporte y capacitación.