¿Cómo realiza PM la gestión de requisitos y la planificación de versiones?
Ya sea un individuo o una empresa, habrá objetivos y planes de dirección cada año o trimestre. De hecho, lo mismo ocurre con los productos, que también necesitan objetivos como guía.
Ya sea que esté trabajando en un proyecto o en un producto, debe comprender claramente el "objetivo" y utilizar el "objetivo" como guía definitiva para descomponer los objetivos de cada etapa y trabajar hacia la dirección, solo como la persona que se dirige hacia la luz en la noche oscura. Una luz, incluso si el camino tiene curvas y vueltas, mientras haya dirección, no te perderás.
Los objetivos del producto se dividen en [objetivos a largo plazo] y [objetivos a corto plazo]:
Los objetivos a largo plazo del producto están vinculados al posicionamiento y estrategia y qué presenta finalmente el producto al usuario. ¿Qué es y qué problemas puede resolver para los usuarios?
Los objetivos a corto plazo pueden entenderse como la división de los objetivos a largo plazo, los objetivos mensuales se pueden dividir según el tiempo o se pueden dividir en objetivos de versión en un nivel más detallado. objetivos a corto plazo, es necesario asegurarse de que la dirección esté dentro del alcance de los objetivos a largo plazo.
Creo que muchos PM saben esto durante su trabajo, por lo que no entraré en detalles aquí solo para enfatizar el importante papel de las "metas", ya sea analizando un requisito o haciendo planes. En este momento, es necesario tener una escala de "objetivos", pensar en ella de vez en cuando y preguntarse: ¿Está esto en línea con el objetivo actual? ¿Tiene sentido lograr el objetivo?
El trabajo de PM no es solo investigar y analizar los requisitos del producto y diseñar productos, sino que también dedica más tiempo a la gestión de versiones/demanda. Por lo tanto, me gustaría centrarme en la gestión de versiones y la gestión de la demanda. experiencia.
¿Cuándo necesitas iniciar la gestión de versiones? ¿Cómo gestionarlo? ¿Qué se debe hacer exactamente antes y después de la versión? Debe ser un punto de duda específico. Combinando mi propia experiencia laboral y un resumen, resumí personalmente las especificaciones del proceso de planificación de la versión del producto. Para obtener más información, puede consultar la siguiente figura:
Para garantizar la coherencia. de recursos de desarrollo de versiones, necesidades de desarrollo de versiones Entrar en el estado paralelo no provocará recursos inactivos. Cuando se desarrolla una versión, el desarrollo de la siguiente versión debe realizarse inmediatamente. Por lo tanto, la tarea de diseño de requisitos de la nueva versión debe completarse antes de que se complete el desarrollo de la versión anterior.
En términos generales, una vez completada y enviada con éxito al desarrollo una versión del análisis de requisitos (que incluye creación de prototipos, revisión de requisitos y redacción de documentos de requisitos), comenzará la tarea de planificación de una nueva versión.
1. Determinación de los objetivos de la versión: qué funciones del módulo deben procesarse en esta versión o qué usuarios deben ser compatibles
2. Libro de planificación de versiones: qué funciones específicas se deben realizar y lo que implica En términos generales, una versión tiene grandes funciones + funciones pequeñas + muchos errores
3. Reunión de planificación de la versión (reunión interna del departamento para determinar la versión y determinar la asignación de recursos): cuando todos Agrega combustible, las llamas son altas y la fuerza y las ideas individuales Después de todo, es limitada, y la tecnología y las operaciones también tendrán sus propios planes e ideas para la versión, por lo que es necesario revisar juntos el plan de la versión planificada para que. todas las partes entienden cuál es el plan a hacer y también preparan y realizan evaluaciones de tiempo con anticipación.
En mi opinión, la gestión de versiones es en realidad un proceso de gestión de la demanda.
Muchos estudiantes se preguntarán: ¿Cuáles son entonces los requisitos para cada versión? ¿Dónde está la fuente? Personalmente, creo que gestionar bien los requisitos es la fuente de las versiones de planificación.
Los requisitos se pueden dividir en requisitos no aprovechados, requisitos por planificar y requisitos en proceso de planificación y desarrollo. Las fuentes incluyen comentarios de usuarios externos, comentarios de colegas, líderes internos, equipos de operaciones, equipos de proyectos y análisis de la competencia. necesidades de productos, ideas derivadas de su propia investigación de productos, etc.
Entonces la gestión de la demanda se puede resumir en tres puntos según el tipo de demanda: 1. Gestión de registros de comentarios de los usuarios 2. Gestión del grupo de demanda 3. Seguimiento de las tareas de desarrollo actuales
En vista de los tres aspectos anteriores, he resumido una lista de administración de listas de tres niveles (existen muchas herramientas para establecer y administrar grupos de demanda, incluidas Excel, X-mind, trello, oBridge y ZenTao. Las más adecuadas y uno intuitivo para las personas es Puede usar Excel):
Lista de comentarios de los usuarios, que recopila diversas quejas, sugerencias de optimización y nuevas ideas creativas (no se pueden dejar de lado los comentarios de los usuarios. Si los investiga, puede obtener nuevas ideas y creatividad)
Instrucciones de uso:
Siempre que haya comentarios sobre el producto, no importa cuán grande o pequeño sea, es necesario registrarlo como el más original. y muchos PM suelen ignorar la retroalimentación directa.
Califique oportunamente los comentarios. Los problemas fatales deben arreglarse rápidamente en la versión o repararse con urgencia. Esto también puede ejercitar la perspicacia del primer ministro.
La lista de características de demanda, el registro de demanda y la lista de gestión diaria se denominarán colectivamente grupo de demanda (la más importante de estas tres listas)
Instrucciones de uso:
Esta lista tiene dos propósitos:
(1) Seguimiento del progreso de los requisitos actualmente en desarrollo, incluido el progreso del análisis y desarrollo de requisitos, qué requisitos aún se encuentran en la etapa de diseño de la interfaz de usuario y qué terminal Desarrollado, etc., se puede ver claramente en una lista. Depende del posicionamiento de los PM de la empresa. Algunas empresas posicionarán a los PM como gerentes de proyectos.
(2) Se utiliza como pool de demanda para gestionar las necesidades a planificar y asignar versiones de solución, es decir, determinar qué demanda se debe procesar en qué versión.
El equipo requiere esta lista. Todos deben actualizarla y mantenerla de manera oportuna, por lo que las especificaciones son muy importantes.
En términos generales, PM es responsable de ingresar al grupo de demanda, incluida la determinación de prioridad, fuente, tipo, etc. (área amarilla). Antes de planificar cada versión, debe actualizar los requisitos funcionales que se implementarán en la siguiente versión de esta lista (generalmente se actualiza después de que se lleva a cabo la reunión del departamento de planificación de versiones y todos están de acuerdo en que es correcto).
El equipo de desarrollo y el equipo de diseño actualizarán y mantendrán el estado actual del requisito (área roja). El tiempo de actualización suele ser antes de la reunión regular del departamento todos los viernes, y el trabajo se verificará de acuerdo con el estado durante la reunión regular. Y al asignar tareas laborales el lunes, también puedes asignarlas junto con la lista.
Los errores y puntos de optimización que encuentras en tu experiencia diaria con el producto (esta lista es para entrenarte para mantener la frecuencia de uso del producto)
Instrucciones de uso:
Esta lista es en realidad para sus propios registros. Como PM calificado, debe utilizar los productos que diseña todos los días, experimentar los productos desde la perspectiva del usuario y descubrir áreas que necesitan mejorar. Así que hice esta lista por mí mismo.
También quiero hablar del trabajo diario de PM. Se rumorea que los gerentes de producto necesitan dominar muchas habilidades, incluida la capacidad de dibujar prototipos, analizar el mercado, discutir las necesidades y coordinar el trabajo en todos los aspectos del ciclo de vida del producto. También quiero compartir mi vida diaria como gerente de producto:
1. Experiencia diaria del producto (lista de errores)
Necesito lidiar con muchos asuntos complicados sobre el producto todos los días. pero todos los días también dejaré al menos media hora para experimentar repetidamente mis propios productos y los productos de la competencia, y anotar los puntos de demanda obtenidos durante la experiencia. Esto puede mantener el sentido del producto como PM y también permitirme volver a experimentar y pensar en productos para los usuarios.
2. Recopilación de comentarios de los usuarios y revisión repetida (Lista de comentarios)
Verifique periódicamente el backend de comentarios de los usuarios del producto todos los días, los canales creados por usted mismo incluyen grupos de usuarios y si hay quejas de los usuarios y comentarios en las redes sociales Después de aclarar el problema, escriba los puntos de demanda. Si se trata de un error o una demanda que debe resolverse con urgencia, se informará al equipo de desarrollo de inmediato. demanda urgente, se incluirá en el plan de iteración de la versión.
3. Análisis de datos (baja viabilidad, productos finales)
4. Reuniones diarias para comprender la situación actual, coordinar e identificar riesgos
El equipo se organizará para mantener una reunión permanente de unos 10 minutos todos los días. El tema es muy claro. Cada persona hablará sobre el contenido de su trabajo de ayer y lo que planea hacer hoy, y específicamente involucrará la coordinación y la comunicación. Después de la reunión se llevarán a cabo los detalles. Es una buena manera de entender el progreso actual sin retrasar el tiempo de trabajo de todos.