YouTrack
Powerful project management for all your teams
Administre los requisitos del producto con la base de conocimiento de YouTrack
Muchos equipos de proyectos, de producto, de marketing y de desarrollo ya usan YouTrack para crear grandes productos. Esto requiere un proceso eficaz para gestionar los requisitos de los productos. El proceso habitual conlleva crear historias y épicas para los usuarios, utilizar una vista general de proyecto con diagramas de Gantt, realizar un seguimiento de solicitudes de funcionalidades de forma pública e interna, solucionar errores y colaborar con otros equipos en incidencias.
Ahora hay otro modo. Puede gestionar los requisitos del producto directamente en la Base de conocimiento, utilizando YouTrack para crear, administrar y efectuar el seguimiento de la documentación de requisitos de su producto.
¡Veamos como funciona!
¿Por qué necesita un documento de requisitos del producto?
Si es usted el propietario de un producto, está lanzando un producto o forma parte del equipo que trabaja en un proyecto y desea saber qué hace el producto y cómo funciona, el documento Requisitos del producto casi siempre será su fuente de información más habitual.
Los requisitos del producto describen y definen el objetivo general del producto, su comportamiento, sus funcionalidades y sus características de funcionamiento desde el principio del proyecto, incluso antes de que el producto en sí se materialice. Pero no basta con redactar esta información. La visión del producto suele cambiar a lo largo del tiempo, y los requisitos del producto se someten a numerosos ajustes y modificaciones. Puede que tenga que invertir mucho tiempo en asegurarse de que su producto se mantiene al día con los requisitos más recientes.
Por eso es importante disponer de un proceso de gestión de requisitos bien configurado. Si se organiza correctamente, puede ayudarle a efectuar un seguimiento de todos los aspectos importantes y a mantener el control de los requisitos en continuo cambio.
Aquí le indicamos algunos puntos a tener en cuenta para gestionar los requisitos de su producto sin problemas.
Recopile todas las fuentes de sus futuros requisitos
Comenzar un proyecto de cero puede ser un gran reto. Asegúrese de recopilar todo el material posible relacionado con su futuro producto: investigación, comentarios de usuarios potenciales, y cualquier planificación o lluvia de ideas que ya haya realizado. Ahora, al principio, basta con reunirlo todo en un cajón de sastre. Más adelante ya tendrá ocasión de eliminar lo inservible y quedarse con lo útil.
Dependiendo de su proceso, estas pueden ser algunas fuentes de requisitos:
- Materiales actuales relacionados con su estrategia de empresa y objetivos del producto.
- Información del equipo de producto.
- Resultados de los estudios, como investigación estratégica o análisis de la adecuación del producto para un mercado.
- Comentarios de usuarios potenciales. Hable con su equipo de asistencia. Es probable que tengan mucha información útil que compartir.
- Análisis de la competencia. Puede que otros ya hayan caído en trampas que usted puede tratar de evitar.
- Información procedente del cliente potencial, como entrevistas, encuestas y demos.
- Su sistema de seguimiento de incidencias público, si tiene uno.
- Su propia visión sobre cómo debería funcionar el producto. ¡No subestime su instinto!
El principal objetivo ahora mismo es recopilarlo todo en un solo lugar. Cree un borrador en la Base de conocimiento de YouTrack y enlace sus documentos utilizando una o varias de las opciones disponibles: incruste documentos de Google con estudios de investigación, pegue enlaces en incidencias con comentarios de los usuarios, y adjunte archivos con su análisis de estrategia de producto.
Ahora que hemos recogido toda la información posible, es el momento de cribar los requisitos y hacer que resulten fáciles de manejar.
Aquí llega el primer borrador
No existen normas ni reglas en lo que a la redacción de requisitos de productos se refiere. Pero vamos a contarle algunos trucos que a nosotros nos han funcionado y nos han ayudado a la comprensión común:
- Describa brevemente el objetivo general del producto o funcionalidad.
- Indique quiénes son los responsables, para que quede claro inmediatamente quién es la persona de contacto en cada una de las fases principales (como el control de calidad o el diseño).
- Especifique la fecha de lanzamiento o de vencimiento, de modo que todos los miembros del equipo tengan claro el alcance, el calendario y las estimaciones de tiempo del proyecto.
- Enlace las épicas o historias de usuarios correspondientes, para mantener la conexión entre los requisitos y el avance real (hablaremos de las épicas en detalle más adelante).
- Determine los puntos principales de diseño, infraestructura y especificaciones de comportamiento.
Trate de mantener las ideas simples y directas. Todo el mundo debe ser capaz de comprenderlas a la primera. Utilice tablas y listas ordenadas para estructurar bien esta información.
Usa la estructura, Luke
Ha llegado el momento de hacer que los requisitos queden claros y que resulte fácil navegar por ellos.
La búsqueda de texto completo puede salvar a los usuarios cuando no saben dónde buscar exactamente; solo tienen que introducir una palabra clave y buscar entre los artículos resultantes. No obstante, no los forcemos a tener que buscar, y asegurémonos de que cualquiera puede navegar por los requisitos con facilidad para encontrar lo que necesita.
Una estructura de vista de árbol clara puede ayudarle a evitar requisitos repetitivos o contradictorios, y puede ayudar al lector a encontrar rápidamente artículos relevantes. En esta fase, ya es normal contar con un nivel de estructura única: el propio documento de requisitos del producto más algunos archivos relacionados que contengan material estratégico. Sin embargo, a medida que se desarrolla el producto, es probable que esta estructura crezca bastante con la incorporación de nuevos materiales, como información recopilada en entrevistas a los clientes, o conclusiones de reuniones del equipo, entre otros. En este momento, una buena práctica es mantener una estructura clara desde el principio, incluso aunque al principio parezca que no la necesita en absoluto. Por ejemplo, puede crear subartículos ficticios para documentos que espera que se añadan después, para ir consolidando ya la estructura.
A continuación, puede mover sus artículos de requisitos entre árboles de distintas páginas y crear una jerarquía que se adapte a las necesidades de su organización.
Es hora de colaborar
¿Listo para escuchar otras opiniones y puntos de vista? Anime a sus compañeros de equipo y a todos los interesados mencionándolos en comentarios para que puedan unirse a la discusión. Otorgue a los participantes permisos de edición para que puedan añadir sus sugerencias sobre la marcha, o mantenga una conversación en los comentarios para que la discusión sea más transparente. Se le notificará cada uno de los cambios de cada artículo.
Es importante implicar a las personas correctas en el momento correcto. Por ejemplo, quizá desee organizar una reunión en la que todos los interesados puedan revisar los requisitos y debatir cara a cara cualquier punto que les preocupe.
Un requisito debe cumplir varios criterios para que se considere “bueno”: debe ser conciso, comprensible, verificable, coherente y factible. Navegue por sus artículos y actualice los requisitos si fuese necesario. Una buena práctica es establecer un modo uniforme de marcar cada requisito que ya se haya revisado y aprobado, por ejemplo dejando el comentario correspondiente o añadiendo una nota a la tabla de básicos.
Asimismo, recomendamos mantener los resultados de las reuniones (también denominados actas de reunión) en subartículos específicos. Esto le ayudará a recuperar datos sobre qué temas se han tratado, qué decisiones se han tomado y qué preguntas se han pospuesto.
Sea ágil (o no)
Dependiendo de su proceso, puede que espere que los requisitos de su producto cambien dinámicamente a lo largo de su desarrollo, o puede que espere que los cambios se establezcan antes de que comience cada nueva etapa del desarrollo. Si se espera que se produzcan cambios a lo largo del proceso de desarrollo, tendrá que asegurarse de que todos comprendan todas las tareas en todo momento. Si se realizan cambios antes de que comience una nueva etapa de desarrollo, los requisitos deben ser aprobados por todas las partes implicadas antes de que comience la implementación.
Al emplear un proceso de Agile, es mejor ajustar los requisitos tan pronto como se produzca el cambio. Esto significa que tiene que mantenerse al día de todos los cambios más recientes. Recomendamos realizar entrevistas a los clientes después de cada iteración para asegurarse de que todavía están en la misma onda. También sugerimos prestar atención a la priorización de los trabajos pendientes para asegurarse de que las cosas más importantes están en los primeros puestos. Es más, no lo haga solo. Implique a los miembros del equipo adecuados en las discusiones y reuniones con los clientes.
Si utiliza el modelo Waterfall, le recomendamos que lleve a cabo varias sesiones para revisar los requisitos del producto, invitando a todas las partes relevantes a participar antes de pasar a fases posteriores del desarrollo. Esto le ayudará a evitar requisitos contradictorios y a asegurarse de que todos están en la misma onda.
Siga el proceso que siga, siempre podrá revisar y restaurar cualquiera de las versiones anteriores de sus páginas.
Complete la historia
¿Listo para comenzar el proceso de implementación? Utilice los tipos de incidencias de YouTrack y los enlaces para crear épicas y dividirlas en tareas más reducidas para su equipo.
Transformar sus requisitos en funcionalidades e incidencias reales es un paso crucial en el desarrollo de su producto. Ahora, puede que se dé cuenta de que es necesario revisar y ajustar de nuevo alguno de los requisitos, y no pasa nada. Recomendamos realizar varias iteraciones de las revisiones para asegurarse de que los requisitos se parecen lo máximo posible a la realidad.
Para los procesos en cascada, no se pierda otra funcionalidad de planificación de YouTrack: el diagrama de Gantt. Los diagramas de Gantt tienen en cuenta sus posibles fechas de inicio y dependencias entre tareas, y le ayudan a estimar fechas de vencimiento del proyecto.
Para procesos de Agile, pruebe los paneles de Agile de YouTrack, con su práctica vista general que muestra todas sus épicas y tareas divididas en una sola pantalla. Mientras que una épica puede representar una funcionalidad completa, las tareas deberían ser lo suficientemente pequeñas como para poder ser realizadas en entre uno y tres días. Priorice tareas, establezca dependencias entre ellas y efectúe un seguimiento del progreso directamente desde su panel. Creemos que este es uno de los modos más eficaces de mantenerse totalmente sincronizado con su producto.
Cree un registro de trabajo pendiente a partir de sus tareas (reordénelas manualmente para priorizarlas por orden de importancia si fuese necesario) e intégrelo en la página de requisitos. El trabajo pendiente se expandirá directamente en el artículo para ahorrarle tener que estar cambiando constantemente entre el sistema de seguimiento y la base de conocimiento.
Láncese y desarrolle
Esperamos que estos consejos le ayuden a organizarlo todo de un modo que le funcione y le ayude a conseguir un producto genial.
Tenemos algunas ideas sobre cómo mejorar todavía más la Base de conocimiento de YouTrack. Pero ¿usted qué cree? Cuéntenoslo para que podamos avanzar con nuestros requisitos de producto en la dirección correcta y asegurarle la mejor experiencia posible.
El equipo de YouTrack
Subscribe to YouTrack Blog updates
