¿Existe un marco de especificación de producto para gerentes de producto?

La metodología ágil tiene un enfoque muy simple y exitoso para la especificación de productos para gerentes de productos y propietarios de productos.

  1. Comience especificando lo que desea que haga un producto solo desde el punto de vista del usuario (en este punto, evite los requisitos no funcionales y las “tareas de limpieza”).
  2. Encuadre cada requisito de producto como una historia de usuario en esta sintaxis: Como [tipo de usuario / persona], quiero [tomar alguna acción] para [objetivo].
  3. Cada historia de usuario debe ser el caso de uso atómico más pequeño al que pueda reducirlo. Puede ser necesario definir un conjunto de historias de usuarios individuales (por ejemplo, para crear, actualizar y eliminar) para describir una capacidad de valor completa para su usuario. Si no se puede completar en un día o dos, la historia es demasiado grande y debe dividirse en historias más pequeñas.
  4. Clasifique continuamente las historias de los usuarios y solicite al equipo de implementación que tome de la lista algunas de las historias de los usuarios de mayor prioridad para trabajar.
  5. Junto con el equipo de implementación (especialmente los evaluadores) definen los criterios de aceptación para cada historia que se toma. Los criterios de aceptación son las declaraciones que serían verdaderas sobre el producto resultante que nos permiten saber que la historia se ha implementado correctamente. Por ejemplo, si la historia del usuario tiene que ver con agregar un número de teléfono a un contacto, un criterio de aceptación es que el número de teléfono correcto aparece de manera persistente cada vez que recupero el contacto.
  6. Dimensione la historia del usuario en términos de horas (o puntos si está trabajando con un equipo ágil)
  7. Determine cuántas de las historias pueden caber en el cuadro de tiempo (de una semana a un mes) que tiene disponible, y dibuje una línea divisoria para las historias comprometidas. (Una vez que el equipo de Implementación se haya comprometido con un conjunto de historias, no cambie esas prioridades, sino que siga clasificando continuamente las otras historias de usuarios que no se han comprometido).
  8. Permita que el equipo de Implementación enumere y asigne las tareas técnicas que deben realizarse para implementar la historia, por ejemplo, configurar un campo en la base de datos, presentar una pantalla de IU para capturar la entrada del usuario, escribir la entrada del usuario en la base de datos después transformando los datos a un formato estándar y visualizando el resultado.
  9. Comience a trabajar en la parte comprometida del producto y responsabilice al equipo de implementación por el progreso diario en la acumulación de historias de usuarios. (Por lo general, esto se hace en una reunión de scrum diaria).
  10. Repita para el siguiente cuadro de tiempo, varios días antes del final del cuadro de tiempo actual.

Hay mucha buena literatura sobre Agile y SCRUM, y le animo a que lo investigue.

Esto es lo que sigo:

  1. ¿Cuál es el problema?
  2. ¿Por qué es importante?
  3. ¿Quién es el usuario objetivo?
  4. ¿Cuáles son sus casos de uso?
  5. Priorizar casos de uso
  6. Requisitos para cada uno de esos casos de uso
  7. ¿Qué son los KPI?
  8. Plan de experimento / medida

No debe tener más de 3 páginas. El objetivo de esta plantilla es alinearse con varias partes interesadas (en particular, ing).

Par de consejos adicionales:

  1. Cree un resumen (principalmente un PPT) que resuma el problema, el usuario objetivo, la solución, el plan de implementación de los KPI, los plazos, el marketing y las comunicaciones. Fácil de compartir. Los requisitos pueden ser demasiado detallados.
  2. Cree un diario: que capture todas las preguntas y decisiones abiertas que haya tomado. Esto ayudará a reducir la rotación y hablar sobre lo mismo una y otra vez. Te permite concentrarte solo en preguntas abiertas.

Existen muchos marcos y enfoques diferentes para crear productos. He creado un recurso que cura diferentes marcos de productos utilizados por las empresas aquí:

La guía definitiva para los marcos de desarrollo de productos y las mejores prácticas para crear productos.

Al crear esta lista, hay algunos temas comunes que se destacan:

  1. Comience con el cliente y concéntrese en sus problemas.
  2. Valide y comprenda el problema del cliente profundamente. Esto implica hablar con los clientes, observarlos y comprender los datos de su producto actual o del mercado.
  3. Haga una lluvia de ideas sobre cómo puede mejorar su situación actual. Es importante considerar una variedad de soluciones, ya que generalmente existen múltiples enfoques para resolverlo.
  4. Concéntrese en entregar valor lo más rápido posible. Aquí es donde a menudo se usan términos como ‘Producto mínimo viable’ (MVP). Pero la clave es que desea probar y validar su solución con clientes reales lo más rápido posible para aprender. Hay muchas formas de validar una solución.

Yo simplificaría todo a tres bloques:

  1. ¿Está haciendo un producto correcto: todos los problemas de validación del producto, estudios de usuarios. ¿Que producto? ¿Por qué? ¿Qué grupo objetivo?
  2. ¿El producto está bien hecho: verificación, metodología ágil aplicada, revisiones, controles y métricas. De lo contrario, corre el riesgo de producir un producto que ya no es necesario.
  3. ¿Se gestiona correctamente su producto: rastree la velocidad del proyecto, el sprint o libere el estado de quemado? ¿Dónde se necesita acción? ¿Qué mejorar regularmente?

¿Qué es un marco de especificaciones de producto? ¿Alguien te ha pedido uno?

Si quiere decir cómo debe escribir los requisitos un gerente de producto, entonces puede consultar muchos recursos.
Por lo general, los gerentes de productos deben mantener una cartera de productos (lista de cosas que hacer). Cada elemento en el trabajo atrasado debe escribirse como una historia de usuario para que quede clara la función y cuál es el beneficio para el usuario.

Entonces aquí está la jerarquía
La cartera de productos contiene una lista de Epics (características grandes) que se desglosan en historias de usuarios más pequeñas (subfunciones)

Ver:
http://www.romanpichler.com/blog

–Anubhav
https://techpmblog.com

More Interesting

Estoy interesado en crear un nuevo producto electrónico para un nicho en particular. Sería similar a otros productos disponibles, pero para un caso de uso diferente. ¿Cómo puedo averiguar quién fabrica estos otros productos para abordarlos y trabajar en mi producto también?

¿Cuál es su definición de liderazgo de categoría? ¿Qué líderes de opinión y libros has leído que describen el liderazgo de categoría y cómo obtenerlo?

¿Qué es un lanzamiento de producto?

¿Cómo concibió Trello su idea?

¿Cómo se hace para fijar el precio de un producto físico?

¿Qué debo hacer como desarrollador cuando el gerente de producto ya no cree en el producto?

¿Cómo son las responsabilidades típicas de un pasante de gestión de productos?

Cómo limitar el contexto de un producto

¿Qué habilidades debería centrarme en desarrollar en el lado de la tecnología para hacerme más atractivo para la contratación de gerentes?

¿Dónde puedo encontrar ejemplos de documentos de requisitos de software en la nube (SaaS)?

¿Cómo se escribe una hoja de especificaciones para desarrolladores web?

¿Qué debe hacer un gerente de producto?

¿Cuál es la diferencia entre el gerente de producto y el CTO?

¿Qué herramientas en línea hacen la gestión de recursos Y la planificación de la hoja de ruta?

En un trabajo mecánico básico, ¿qué departamento o campo tiene un crecimiento rápido y bueno (producción, calidad, ingeniería, scm, PPC o desarrollo de nuevos productos)?