📃Flujo de Trabajo: Req Task (Equipo de Requerimientos / Producto)
🎯 Objetivo del Flujo
Definir un proceso claro para tareas funcionales relacionadas a documentación de requerimientos, refinamiento, entrevistas, definición de criterios y redacción de historias de usuario desde el equipo de producto o requerimientos.
Este flujo aplica específicamente al tipo de issue:
📄 Req Task
📊 Estados del Flujo de Req Task
Open
Tarea creada, pendiente de análisis. Prioridad y objetivo aún sin detallar.
En Análisis
El analista o PO está trabajando en entender la necesidad, alcance y contexto.
En Validación
El requerimiento está siendo revisado con stakeholders, PM o CEO.
Validado
Requerimiento aprobado. Listo para ser trasladado a diseño o desarrollo.
Canceled
La tarea fue descartada o anulada por decisión interna.
🖼️ Diagrama Visual del Flujo
🔁 Transiciones y Reglas
START → OPEN → EN ANÁLISIS → EN VALIDACIÓN → VALIDADO
↘
OPEN (si hay ajustes)Se puede volver a Open en cualquier momento si se detectan ambigüedades o falta de información.
Desde cualquier estado se puede mover a Canceled.
📌 Consideraciones Clave
En En Análisis se pueden adjuntar referencias, capturas, entrevistas, enlaces a herramientas de investigación (Notion, FigJam, etc.).
En En Validación, debe incluirse confirmación de aprobación por stakeholders clave (PM, CEO, etc.).
El estado Validado indica que el requerimiento está listo para ser consumido por diseño o equipo técnico.
🛠 Buenas Prácticas
Usar lenguaje funcional y centrado en el usuario.
Adjuntar user stories, criterios de aceptación, casos de uso o mockups si existen.
Asignar etiquetas como
prioridad-alta,modulo-x,dependencia, etc. para clasificar.
🧭 Próxima sección
Se podrá documentar el flujo correspondiente a User Stories, que cruza los tres equipos (req, diseño, dev), permitiendo observar su transición completa desde la definición hasta la implementación.
Last updated