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.
- 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”).
- 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].
- 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.
- 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.
- 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.
- Dimensione la historia del usuario en términos de horas (o puntos si está trabajando con un equipo ágil)
- 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).
- 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.
- 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).
- 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.
- ¿Se les da a los graduados de IIM trabajos solo en administración o se los ubicará también en el desarrollo de productos (I + D) en una industria?
- ¿Qué es exactamente un gerente de producto en una startup tecnológica?
- ¿Cuál sería un posible JD para el rol de 'hacker de crecimiento' de una empresa de desarrollo de productos que busca a alguien con experiencia en ingeniería y excelentes habilidades de codificación?
- ¿Cuáles son las mejores prácticas para que nuestro equipo de desarrollo de productos cree la aplicación web más segura posible?
- ¿Qué tan efectivo es Stage-Gate para el desarrollo de nuevos productos? Y sin un grupo de I + D, ¿quién típicamente impulsaría el desarrollo de productos en una organización?
