Puedes usar los Documentos de ClickUp para comunicar los requisitos del producto con tu equipo de ingeniería y las partes interesadas.
Sigue leyendo para descubrir cómo Sam resolvió un importante problema de comunicación para su equipo Ágil.
Conoce a Sam
Sam es gerente de producto en una empresa de software basado en la nube. Están trabajando en una función particular de su producto con un equipo dedicado que incluye:
-
Un diseñador
-
Dos promotores
-
Un ingeniero de QA
El desafío
El equipo se lleva bien, pero Sam nota que el equipo pasa la mayoría de las reuniones diarias de puesta al día haciendo preguntas a Sam sobre la función y cómo debería funcionar.
Sam decide dar orientación al equipo fuera de las puestas al día usando Documentos de ClickUp.
La solución
Sam decide que cada función debe tener su propio documento. Cuando el equipo trabaja en una función, toda la información relevante debe estar en un solo lugar.
Usar páginas dentro de un Documento permite al equipo encontrar respuestas relevantes rápidamente sin tener que buscar y explorar Documentos separados.
Sam crea algunas páginas dentro del Documento para estructurar el resumen del producto basado en lo que el equipo necesita saber y podría estar buscando.
-
Carta del equipo de características
-
Requisitos de diseño
-
Requisitos funcionales
-
Requisitos de UX
Consejo: ¡Busca páginas o contenido específico dentro de un documento utilizando la función de búsqueda!
Sam agrega encabezamientos y otros elementos de formato a cada página para comunicar su visión de la función.
Sam comparte el documento con el equipo de funciones. Colaboran juntos para redactar y acordar el estatuto.
Sam invita al equipo a hacer preguntas agregando comentarios en el Doc para que todos puedan ver las preguntas y las respuestas.
Retrospectiva
Unos cuantos Sprints pasan volando, y el equipo agradece el documento que ayuda a guiarlos. Las reuniones de puesta al día ahora son mucho más eficientes y efectivas.
Se envía y añade una mejora de función al producto. Desafortunadamente, esto provoca un nuevo error en otra parte de la función que no se actualizó en la versión.
Los desarrolladores solucionan rápidamente el error y en su próxima retrospectiva, el equipo de características discute cómo esto podría haberse evitado.
Un ingeniero de QA sugiere algún tipo de criterios de aceptación para que no se envíen cambios a producción a menos que se cumplan todos los criterios de prueba.
¡El equipo está de acuerdo! Sam añade una nueva página al documento de descripción de la función para documentar los criterios de aceptación de la función.
Sam usa Bloques de Código ( /co ) para formatear sus requisitos de criterios de aceptación, ya que el equipo ya está familiarizado con Gherkin, y ClickUp lo admite para bloques de código!
El resultado
A medida que el equipo de funciones implementa más mejoras y soluciona errores, los clientes están adoptando cada vez más la función. El equipo de funciones se amplía para incluir a dos desarrolladores más y otro ingeniero de QA.
¡Los nuevos miembros del equipo se adaptan rápidamente y comienzan a contribuir con la ayuda del documento de características de Sam!
Sam también comparte la plantilla Doc del reporte de características con otros jefes de producto para que puedan adaptarla a sus equipos basados en características.
¡Es un gran triunfo para el equipo de Sam y para otros también!