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

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.

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.

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.

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.

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?

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.

Desliza la tabla para ver todas las columnas.

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.