¿Cómo hace un gerente de producto un resumen de revisión?

Muchas empresas (incluida la mía) exigen que los empleados presenten a tiempo: resumen de trabajo diario, resumen de trabajo semanal, informe de trabajo mensual, informe de trabajo trimestral, informe de trabajo semestral y informe de trabajo anual. Por lo tanto, cada uno de nosotros realiza revisiones todos los días. De algunos de ellos somos conscientes, pero la mayoría son reflejos de los que no podemos darnos cuenta.

1. En primer lugar, qué es la revisión

Un proyecto, ya sea 0 a 1 o una iteración de versión, incluirá básicamente las siguientes etapas centrales (consulte la figura a continuación). La revisión del producto consiste en desglosar el trabajo específico en cada etapa, analizar si cada trabajo avanza sin problemas, dónde están los problemas y cómo optimizarlo mejor.

2. En segundo lugar, por qué revisar

En el artículo anterior, expresé un punto de vista: "La ruta natural de los gerentes de producto es avanzar hacia la gestión". Como primer paso hacia la gestión, debe poder resumir las ganancias y pérdidas. Desde el principio hasta el final de cada proyecto, ocurrirán emergencias no planificadas más o menos durante el proceso. La revisión es una excelente oportunidad para reflexionar. Al enumerar las ganancias y pérdidas del producto una por una, puede continuar pensando profundamente y mejorar su capacidad de resumen.

Una de las habilidades principales de un gerente de producto es la capacidad de resumir y organizar las sugerencias de demanda recopiladas, las ventajas competitivas del producto, etc., y luego combinar las diferencias del proyecto en sí para formar sus propias ideas de demanda. .

3. Finalmente, cómo hacer una revisión

Como se mencionó anteriormente, la revisión es desglosar el trabajo específico, analizar los puntos problemáticos y cómo mejorarlo. Revise después de desglosar la tarea. Haga un balance y explique.

1 Revisión del objetivo del proyecto

1.1 Revisión del progreso del proyecto

1.1.1 ¿Se entrega según el tiempo de entrega planificado original?

1.1.2 ¿Cuántos de los puntos de demanda originalmente planificados se han logrado? ¿Qué puntos de demanda no se cumplieron según lo previsto? ¿Cuáles son las razones del retraso en cada punto de demanda?

1.1.3 ¿Qué hitos se retrasan y cuáles son los motivos del retraso?

1.2 Revisión de resultados del proyecto

1.2.1 ¿Qué accidentes ocurrieron en el proyecto? ¿Por qué ocurren estos accidentes?

1.2.2 ¿La aceptación por parte del usuario de nuevos puntos funcionales es consistente con el plan del proyecto?

2 Revisión de la etapa de requisitos

2.1 Revisión de la definición de requisitos:

2.1.1 Si se proporciona el resultado completo de los requisitos, incluidos: prototipo, MRD, PRD, UML, etc.

2.1.2 Los diseñadores, los ingenieros de interacción y los desarrolladores determinan respectivamente si los requisitos son claros: si los requisitos no son claros, afectará seriamente el progreso y la calidad del proyecto.

2.1.3 ¿Existe una descripción clara de los usuarios típicos y los escenarios de uso?

2.2 Revisión de los cambios en la demanda

2.2.1 Número de cambios en la demanda: el desarrollo ágil ha minimizado el impacto de los cambios en la demanda, pero menos cambios en la demanda aún hacen que el proyecto avance sin problemas. instalaciones.

2.2.2 ¿Qué cambios de requisitos afectaron el progreso real del proyecto?

2.2.3 El motivo de cada cambio: ¿intervención del liderazgo? ¿Falta de consideración temprana? ¿No puedes cumplir con el requisito? Analizar los motivos de cada cambio para que puedan evitarse razonablemente en proyectos posteriores.

2.2.4 Si cada miembro del proyecto comprende claramente cada cambio: solo cuando cada miembro del proyecto comprende claramente cada cambio de requisitos y se comunica plenamente se puede garantizar el progreso y la calidad del proyecto.

2.2.5 Si los miembros del proyecto pueden aceptar cambios en la demanda: esto requiere que cada vez que cambie la demanda, deben comunicarse con el personal relevante.

3 Revisión de la etapa de diseño

3.1 ¿Está determinado el revisor final del diseño visual?

3.2 ¿El resultado del diseño de la interfaz de usuario cumple con estándares unificados?

3.3 ¿El trabajo de diseño afecta el progreso del trabajo de desarrollo? ¿Cuáles son las causas?

3.4 ¿Cuándo se completó el trabajo de diseño del producto y por quién?

4 Revisión de la etapa de desarrollo

4.1 Revisión de la evaluación del período de construcción

4.1.1 Antes de la implementación del desarrollo, ¿hay tiempo suficiente para estimar el período de construcción? : Evaluación del período de construcción Por un lado, permite a los miembros del proyecto prepararse para el progreso general del proyecto y también es un proceso de clasificación detallada de los requisitos del proyecto.

4.1.2 ¿Existe alguna diferencia entre el período de construcción estimado y el tiempo de desarrollo real, y análisis de las razones de la diferencia?

4.2 Revisión de los documentos de desarrollo

4.2.1 ¿Se proporciona documentación de desarrollo?

4.2.2 Si los documentos de desarrollo cumplen con las especificaciones

4.3 Revisión de emergencias

4.3.1 ¿Existe una situación en la que los requisitos no se pueden cumplir? ¿Cuál es la razón?

4.3.2 ¿Hay algún cambio en los miembros del equipo? ¿Cómo afrontar los cambios de membresía? ¿Cómo evitarlo después?

4.3.3 ¿Existen inconsistencias entre los módulos funcionales y los requisitos? ¿Cuál es la razón?

Revisión de código 4.4

Cómo se realiza 4.4.1: incluye cómo dividir el trabajo, cómo revisar, etc.

4.4.2 ¿Cuáles son los resultados de la revisión del código?

4.4.3 ¿Se implementan estrictamente las especificaciones del código? ¿Cómo lidiar con el código irregular?

5 Revisión de la fase de prueba

5.1 Revisión del plan de prueba

5.1.1 ¿Existen casos de prueba completos y precisos?

5.1.2 ¿Existe un plan de pruebas? ¿Funciona tal plan?

5.1.3 ¿Cómo prueba y rastrea el equipo los resultados del desarrollo de productos?

5.2 Revisión de herramientas de prueba

5.2.1 ¿Qué herramientas de prueba se utilizan para ayudar con las pruebas? ¿Se puede utilizar de forma continua?

5.2.2 ¿Son suficientes el tiempo, la mano de obra y los recursos de software/hardware para las pruebas?

5.3 Revisión de los resultados de las pruebas

5.3.1 ¿Qué módulo funcional generó? La mayoría de los errores, ¿por qué?

5.3.2 ¿Qué ERRORES se revierten y cuáles son los motivos?

6 Revisión de la etapa en línea

6.1 Revisión de aceptación

6.1.1 ¿Se ha realizado una aceptación formal en línea?

6.1.2 ¿Hay algún problema durante el proceso de lanzamiento oficial? ¿Cómo evitarlo en el futuro?

6.1.3 ¿Existe suficiente comunicación con operaciones y redactores antes de conectarse?

6.1.4 ¿Se han verificado los puntos de enterramiento de datos y cumplen con los requisitos operativos?

6.2 Revisión de los efectos después de conectarse

6.2.1 ¿Aparecieron errores importantes después de conectarse? ¿Por qué no se descubrieron durante la fase de prueba?

6.2.2 ¿Existe un proceso para los canales de retroalimentación después del lanzamiento del producto?

6.2.3 ¿Qué comentarios se han recopilado después del lanzamiento del producto? ¿Qué tipos son? ¿Cómo mejorar?

Cada revisión de proyecto es una tortura y un temple para uno mismo. Los productos iterativos se revisan cada 3 versiones. En circunstancias normales, el ritmo de lanzamiento es una versión por mes, por lo que la revisión se puede realizar a 3. -ritmo de meses.

Finalmente, los resultados de cada revisión deben quedar registrados por escrito, ¡lo cual será un acumulado importante para tu crecimiento!