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?
- ¿Existe un marco de especificación de producto para gerentes de producto?
- ¿Cuál es la diferencia entre el gerente de producto y el CTO?
- Tengo un concepto de aplicación de alto potencial, pero el desarrollador que tengo no es el mejor. Tiene que aprender ciertas características en el camino. A este ritmo, podría tomar 3 meses más para completar el V1 (ya llevamos 2 meses en desarrollo). ¿Qué tengo que hacer?
- ¿Cuántas personas necesitan probar un producto antes de que se considere listo para uso público?
