Cómo escribir un brief que no descarrile tu proyecto
El 80% de los proyectos que se pasan de tiempo y presupuesto arrancaron con un brief flojo. Qué debe llevar el tuyo para no ser uno de esos.
22 de enero de 2026 · 7 min de lectura
El brief es el documento que le dice al proveedor que quieres. Suena aburrido, pero es la pieza que mas dinero te ahorra o te cuesta. Un brief flojo garantiza malentendidos, retrabajos y esa frase fatal a mitad del proyecto: eso no era lo que yo pedi.
Qué debe llevar un buen brief
- 01El problema, no la solución: describe el dolor, no dictes como programarlo.
- 02Quién lo va a usar y en qué momento de su día.
- 03Qué debe LOGRAR el sistema, medible: menos horas, menos errores, mas ventas.
- 04Qué NO entra en esta etapa (tan importante como lo que sí).
- 05Con qué sistemas debe hablar y de dónde salen los datos.
- 06Presupuesto y fecha reales: sin eso el proveedor cotiza a ciegas.
| Brief flojo | Brief que sí sirve |
|---|---|
| Quiero un sistema para mi negocio | Quiero dejar de recapturar pedidos que llegan por WhatsApp |
| Que sea moderno y bonito | Que el vendedor cargue un pedido en menos de 2 minutos |
| Como el de mi competencia | Que conecte con mi facturación actual (menciono cuál) |
| Lo necesito ya | Lo necesito operando antes de temporada alta en noviembre |
| El presupuesto lo vemos | Tengo un rango de X a Y para esta primera etapa |
El costo de un brief ambiguo
Cada punto sin definir en el brief se convierte en una suposición del proveedor. Si suponen distinto a lo que tenias en la cabeza, el retrabajo llega — y el retrabajo se paga en tiempo y dinero. Definir cuesta horas; no definir cuesta semanas.
Si no tienes brief, lo armamos contigo
En NovaLab la fase de descubrimiento existe justo para esto: no esperamos que llegues con un brief perfecto. Nos sentamos, entendemos el dolor y lo escribimos juntos antes de tocar una linea de codigo. Asi lo que entregamos funcionando es lo que de verdad necesitabas.
Un buen brief no tiene que ser largo ni tecnico. Tiene que ser claro en una cosa: que problema resolvemos, para quien, y como sabremos que quedó bien.
Referencias
- — Standish Group — CHAOS Report: requisitos incompletos como causa número uno de fracaso.
- — McKinsey — la definición de alcance como factor de sobrecosto en proyectos digitales.
- — Gartner — buenas prácticas de levantamiento de requisitos.
Software
¿Lo quieres resuelto, no solo leído?
Sistemas, apps y automatizaciones hechos para tu proceso real. Te los entregamos funcionando, no en presentación.
Ver software