Briefing: Toma de requisitos de un proyecto

0
291

Qué es un briefing

Un briefing es un documento que se utilizará al comienzo de un proyecto para establecer los objetivos, alcance, recursos y cualquier otro aspecto relevante que guíe la ejecución del proyecto. Este documento describe qué diseñarás, el porqué y cómo, y sirve como un marco de referencia para alinear a todas las partes interesadas y garantizar una comprensión clara y común de lo que se espera lograr. Su objetivo es articular de manera clara y sin ambigüedades el propósito del producto, sus características, funcionalidad y comportamiento. Vamos a ver cómo realizar un briefing inicial efectivo.

Antes de empezar siquiera a pensar cómo resolverás el problema, es de vital importancia que redactes una buena toma de requisitos.

Principales beneficios

Al igual que la investigación no es negociable para poder comprender el problema, este documento se debe tener siempre presente para tener un punto de partida común, rebajar expectativas y allanar el camino que recorreremos todos.

Los principales beneficios de un briefing de inicio de proyecto incluyen:

  1. Claridad y alineación: Ayuda a garantizar que todas las partes interesadas comprendan claramente los objetivos del proyecto, el alcance del trabajo y los roles y responsabilidades de cada uno.
  2. Establecimiento de expectativas: Permite establecer expectativas realistas sobre lo que se puede lograr dentro de los límites de tiempo y recursos disponibles.
  3. Reducción de riesgos: Identifica y aborda posibles desafíos, riesgos y obstáculos desde el principio, lo que ayuda a minimizar sorpresas desagradables más adelante en el proyecto.
  4. Eficiencia y coherencia: Proporciona una hoja de ruta clara y coherente para guiar el trabajo del equipo a lo largo del proyecto, lo que ayuda a minimizar la pérdida de tiempo y recursos en direcciones incorrectas.
  5. Mejora de la comunicación: Facilita la comunicación efectiva entre todas las partes interesadas, lo que fomenta la colaboración y el trabajo en equipo.

Qué puedo preguntar

MVB o Briefing mínimo viable

No puedo resolver un problema sin tener algo de información. Como digo muchas veces «Sin contexto, no contesto»?. En mi caso, siempre utilizo una estructura «mínima» para entender lo que se pide y poder dar la mejor solución al problema planteado por un usuario, negocio o cualquier persona interesada en el proyecto.

Los puntos mínimos para poder resolver un problema son:

    1. Contexto actual: Necesitas conocer el entorno en el que se desarrollará el producto, el problema que vas a resolver y las razones para solucionarlo.
    2. Soluciones anteriores: Enumera las soluciones que ya se hayan llevado a cabo o mira las existentes en el mercado que aborden problemas similares, destacando sus fortalezas, debilidades y áreas de oportunidad.
    3. Objetivos y métricas: Define los objetivos específicos que se espera lograr con la solución, así como las métricas que se utilizarán para medir el éxito y el rendimiento de la misma.
    4. Roadmap: Proporciona una visión general del plan del diseño y desarrollo, incluyendo hitos importantes, fechas clave y entregables esperados a lo largo del tiempo.
    5. Mapa de actores: Identifica a todas las partes interesadas relevantes que estarán involucradas en el desarrollo y uso del producto, incluyendo clientes, usuarios finales, socios comerciales y otros stakeholders.
    6. Aspectos técnicos y equipo: Describe los aspectos técnicos clave del producto, como la plataforma tecnológica utilizada, requisitos de infraestructura y recursos necesarios. Además, identifica al equipo responsable del desarrollo y mantenimiento del producto, incluyendo roles y responsabilidades específicas.

Plantilla

Una plantilla de briefing típica incluirá secciones para recopilar información sobre el contexto del proyecto, los objetivos y metas, el público objetivo, los requisitos creativos, los plazos, el presupuesto y cualquier otra consideración importante. Vamos a ver los puntos y algunos ejemplos de preguntas que podemos hacer para rellenar la plantilla.

1. Planteamiento del problema

Describe de manera clara y concisa cuál es el problema que se busca resolver con el producto. Esto puede incluir una breve descripción del problema, su impacto en los usuarios o en el mercado, y por qué es importante abordarlo. En esta sección, también se pueden enumerar los desafíos específicos que se enfrentan al intentar resolver el problema.

2. Estado del proyecto

Si el proyecto ya está empezado, ¿cuál es el estatus?

  • ¿En qué puntos del proceso se encuentra?
  • Áreas involucradas
    • ¿Qué áreas están o deberían estar involucradas en el proyecto?
    • ¿Qué personas son fundamentales en el desarrollo del proyecto?
  • Personas clave
  • Prototipos
  • Soluciones anteriores y Resultados

3. Usuarios o público objetivo

Es importante tener claro qué le supone ese cambio al usuario, por qué y… si realmente es lo que necesita.

  • ¿Quiénes son nuestros usuarios?
  • ¿Por qué lo necesitan los usuarios?
  • ¿En qué contexto y situación será utlizado?
  • ¿Cuáles son los principales problemas a los cuales se enfrentan los usuarios?
  • ¿Qué objetivos quiere lograr el usuario?
  • ¿Qué estamos resolviendo?¿Qué necesitan?

4. ¿Qué características tiene o tendrá?

Aquí hay que listar y describir qué características tendrá el diseño (o rediseño) del producto. Aquí es importante que cada característica quede enlazada al objetivo. Es decir, que se vea que afectan a su consecución. De este modo podemos blindarnos con posibles cambios futuros y argumentar por qué no se debe quitar esa característica en concreto.

⚠️ Estas primeras características pueden cambiar después de realizar la fase de investigación. 

De estas características acabará saliendo las tareas a realizar, que posteriormente habrá que priorizar (must-havehigh-wanted y nice-to-have) e ir añadiendo en un proceso de Scrum o Kanban para irlas sacando poco a poco.

  • ¿Cómo funciona el producto o servicio?
  • ¿Cuál es la función principal?
  • ¿Qué otras funcionalidades son accesorias?
  • ¿Qué tipo de proceso o mecanismo da vida al servicio?

5. Contexto de uso y tiempo

  • ¿En qué contextos se usa tu servicio? ¿En casa, en el metro, momento del día, etc…?
  • ¿Es un uso único o recurrente?
  • ¿Se va a a trabajar sobre el servicio de principio a fin o sólo un punto de contacto específico?

6. Riesgos y áreas de ignorancia

Es importante tener una previsión de qué podría ir mal en el proyecto y definir cómo se solucionará.

  • ¿Qué factores podrían impactar de forma negativa al proyecto?
  • ¿Qué puede frenar el desarrollo de esta iniciativa?
  • Personal / presupuesto / otras iniciativas /
  • ¿Qué es lo que no sabemos?
  • ¿Sobre qué tenemos dudas?
  • ¿Qué necesitamos saber?

7. Palancas

  • ¿Qué factores pueden impulsar el desarrollo del proyecto?
  • ¿En qué o quién nos debemos apoyar para la conclusión exitosa del proyecto?

8. Métricas y criterios de aceptación

El objetivo debe tener asociada alguna métrica que permita ver si se cumple o no con el objetivo marcado. Todo el trabajo realizado y las preguntas anteriores no sirven de nada si al finalizar el proyecto no hay una visión de si ha funcionado y qué aprendizajes se han obtenido.

  • ¿Qué necesitamos para medir correctamente los datos? ¿Hay que añadir herramientas de tracking, clases…?
  • ¿Cómo se medirá el éxito o el fracaso del proyecto? ¿Altas? ¿Registros? ¿Obtención de correos? ¿Incremento del tiempo de la visita en la página?
  • ¿Cuál es el criterio más importante?
  • ¿Cómo visualizamos el éxito?
  • ¿Cómo lo vamos a medir?

9. Alcance

Conocer el alcance de un proyecto te permite estructurar y organizar mejor tu tiempo, porque serás plenamente consciente de las horas que tendrás que dedicarle y qué podrás dedicar a otras tareas.

  • ¿Cuándo debe estar listo?
  • ¿Qué se espera que sea el entregable? ¿Sketch? ¿Assets exportados? ¿Prototipo animado?
  • ¿Hay entregas intermedias? ¿Qué se espera de ellas?
  • ¿En qué plataformas? ¿Móvil o web? ¿O ambas? ¿Versiones?
  • ¿Qué restricciones técnicas hay?
  • ¿Se pueden mostrar X o Y datos? ¿O no está preparada la infraestructura?

10. Propuesta de valor

  • ¿Por qué es mejor que otros servicios o productos que ya existen?
  • ¿Qué funcionalidad o detalle lo hace destacar?
  • ¿Qué lo hace inusualmente bonito y divertido de usar?

11. Implementación

  • ¿Cuál es el reto central para poder implementarlo?
  • ¿Cuál es el reto principal de tecnología?
  • ¿Cuál es el reto principal para negocio?

Conclusión

? En resumen, un briefing es una herramienta fundamental para la gestión efectiva de proyectos, ya que ayuda a garantizar que se recopile toda la información necesaria y que se establezcan expectativas claras desde el principio. Esto puede contribuir a un proceso de trabajo más eficiente y a la entrega de resultados satisfactorios para todas las partes involucradas.

 

DEJA UNA RESPUESTA

Por favor ingrese su comentario!

He leído y acepto la política de privacidad

Por favor ingrese su nombre aquí

Información básica acerca de la protección de datos

  • Responsable:
  • Finalidad:
  • Legitimación:
  • Destinatarios:
  • Derechos:
  • Más información: Puedes ampliar información acerca de la protección de datos en el siguiente enlace:política de privacidad