# Cómo crear un brief de proyecto que evite revisiones inútiles

https://techy.eus/recursos/crear-brief-proyecto
Actualizado: 2026-09-20

Un brief útil no es una presentación bonita. Es un acuerdo breve que permite a las personas implicadas tomar decisiones sin adivinar qué se pretendía conseguir.

Techy · Copia editable sin conexión. Los ejemplos son ilustrativos, no resultados de clientes. Revisa las limitaciones de la guía antes de aplicarla.

## Escribe el resultado antes que la lista de tareas

Empieza por una frase que describa el cambio esperado: qué debería ser distinto cuando el proyecto termine y para quién. Si solo se enumera lo que hay que hacer, cada participante interpretará el éxito a su manera.

Añade una forma sencilla de comprobarlo. No hace falta inventar métricas complejas: puede ser una decisión tomada, una página publicada, un proceso entregado o una reducción concreta de pasos.

## Delimita qué entra y qué no

Anota el alcance y, con la misma claridad, lo que queda fuera. Esta segunda parte evita que una petición razonable se convierta poco a poco en otro proyecto.

Cuando aparezca una idea nueva, no hace falta rechazarla: decide si sustituye algo, se apunta para una siguiente fase o necesita un brief propio.

- Objetivo y persona a la que ayuda.
- Entregable o decisión esperada.
- Límites del alcance.
- Responsables, fecha y punto de revisión.

## Alinea responsables y decisiones

No basta con una lista de asistentes. Indica quién prepara, quién decide, quién revisa y a quién hay que informar. Si dos personas creen que la decisión pertenece a la otra, el proyecto se detiene sin que nadie lo vea.

Comparte el brief en un lugar único y revísalo cuando cambie una condición importante. Así sigue siendo una guía de trabajo y no un documento olvidado.

## Brief resuelto: una página de reservas

Caso ficticio: un taller recibe solicitudes incompletas. Objetivo del proyecto: publicar una página donde se pueda solicitar una fecha indicando servicio y forma de contacto. Entregable: página responsive, formulario y confirmación de recepción. Quedan fuera pagos, asignación automática de citas y acceso de clientes.

Criterio de aceptación: una persona puede enviar una solicitud válida desde móvil; el taller recibe los campos acordados; un envío fallido muestra un error y no afirma que la solicitud se recibió. La pantalla debe decir «solicitud recibida», no «reserva confirmada», porque el taller todavía decide la disponibilidad.

Responsables: una persona del taller valida campos y textos; quien implementa prueba el recorrido; una única persona autoriza publicar. Dependencias: acceso al dominio, dirección de recepción verificada y contenido aprobado. La fecha de entrega se revisa si esas dependencias no llegan a tiempo, en lugar de ocultarlas en una lista de tareas técnicas.

## Cómo tramitar una petición fuera del alcance

Si a mitad del trabajo se pide cobrar una señal, registra el cambio y su efecto: pagos, estados de devolución, textos y pruebas adicionales. Ofrece decidir entre mantener la entrega original, sustituir otra parte o planificar una fase nueva. No llames «pequeño ajuste» a algo que altera el criterio de aceptación.

- ¿Quién usará el resultado y para qué?
- ¿Qué prueba demuestra que está terminado?
- ¿Qué no estamos construyendo?
- ¿Quién decide y qué falta para poder empezar?

## Decidir si una petición corrige un fallo o amplía el alcance

Caso ficticio: el brief aprobado pide un formulario de solicitud con validación, confirmación visible y recepción por el equipo. No incluye agenda de reservas ni cobros. Llegan tres comentarios durante la revisión; tratarlos todos como errores impide discutir plazos con claridad.

Para la ampliación, registra qué entregable cambia, quién decide, coste y fecha propuesta. En el ejemplo de la herramienta, pasar implementación de 16 a 24 horas, manteniendo 4 de descubrimiento, 4 de revisión, 75 por hora, 100 de gastos y 10 % de contingencia, lleva el total de 2.090 a 2.750: una diferencia de 660 en la moneda elegida.

Ejercicio resuelto · datos ficticios

| Comentario | Clasificación frente al brief | Siguiente acción |
| --- | --- | --- |
| Acepta un correo sin formato válido | Incumple la validación acordada | Corregir y repetir la prueba |
| Añadir cobro con tarjeta | Prestación expresamente excluida | Estimar una ampliación separada |
| Cambiar el texto de confirmación | Depende del texto y revisiones acordadas | Revisar la versión aprobada antes de decidir |

## Comprueba el resultado y resuelve la excepción

Si el criterio original era ambiguo, resuélvelo con quien aprueba antes de clasificar el comentario como trabajo adicional. No inventes una exclusión después de haber prometido la prestación.

- Cada aceptación describe algo observable, como rechazar un correo inválido.
- El cambio aprobado queda enlazado a una nueva versión del brief.
- Una estimación no se presenta como factura ni como contrato firmado.

## Descarga de apoyo

[Descargar brief de proyecto (.md)](https://techy.eus/plantillas/brief-proyecto.md)

Guarda también este archivo si quieres reproducir el ejercicio sin conexión.

## Tu hoja de trabajo — rellena en tu dispositivo

Situación y fecha: ____________________

Datos de partida y procedencia: ____________________

Decisión / cálculo: ____________________

Resultado esperado: ____________________

Comprobación real y referencia a la evidencia: ____________________

Excepción y siguiente acción: ____________________

Responsable y fecha de revisión: ____________________

No incluyas contraseñas, datos de pacientes u otra información sensible en una hoja compartida. Descargarla o marcar una casilla no verifica el cumplimiento en un caso real.