Cómo redactar el brief para una agencia de desarrollo software

Al terminar este artículo tendrás un brief sobre el que un estudio de desarrollo software puede presupuestar sin adivinar. No una especificación técnica. No una lista de funcionalidades. Un documento breve que nombra el problema, traza el alcance, indica una franja de presupuesto y explica cómo valorarás las propuestas. Bien escrito, convierte cuatro presupuestos vagos que no puedes comparar en cuatro precisos que sí puedes.

Importa porque la mayoría de los proyectos software fracasan en el brief, no en la construcción. En los datos de fracaso recopilados de los informes CHAOS del Standish Group, los requisitos poco claros son la causa más citada de fracaso de proyectos software, por delante del scope creep y de la planificación débil (Gitnux, 2026). Un estudio no puede presupuestar lo que no ve. Cuando el brief es escaso, o infla la estimación para cubrir lo desconocido o gana el trabajo y reajusta el precio después. Las dos salidas te cuestan a ti.

Qué necesitas antes de empezar

No necesitas una especificación técnica. Necesitas claridad sobre unas pocas cosas que ya sabes:

• El problema de negocio en una frase, con un número al lado si lo tienes.
• Una franja de presupuesto aproximada que estés dispuesto a gastar, aunque sea amplia.
• Tu fecha límite real y qué la impone.
• Las herramientas y sistemas con los que el software tiene que hablar.
• Quién en tu empresa puede decidir y aprobar el trabajo.

Si no puedes responder a los dos primeros puntos, no estás listo para dar el brief a un estudio. Estás listo, en todo caso, para una fase de discovery.

Paso 1: describe el problema, no la funcionalidad

El error más común en un brief es describir la solución que imaginaste en vez del problema que tienes. "Queremos un portal de clientes" es una funcionalidad. "Nuestro equipo de soporte dedica cerca del 40% de la semana a responder correos de actualización de estado" es un problema. La primera frase encierra al estudio en tu suposición. La segunda le deja proponer algo mejor y presupuestarlo con honestidad (Toptal).

Escribe un párrafo por problema. Di quién lo sufre, con qué frecuencia y cuánto te cuesta hoy en tiempo o dinero. Un estudio que lee un problema real sabe dimensionar el trabajo. Un estudio que lee una lista seca de funcionalidades adivina todo lo que hay detrás.

Paso 2: explica por qué este proyecto y por qué ahora

El contexto le dice al estudio cuáles son tus prioridades. Un brief que dice "perdemos dos acuerdos enterprise por trimestre porque no tenemos SSO" se lee de forma muy distinta a "nos gustaría el SSO en algún momento". Indica el detonante: una ronda de financiación, una fecha de compliance, un competidor, una renovación que estás a punto de perder. El detonante fija la urgencia, y la urgencia da forma al plan.

Paso 3: traza el alcance con MoSCoW

El alcance es donde los presupuestos comparables viven o mueren. Si tres estudios asumen cada uno un alcance distinto, sus precios no son comparables y no puedes elegir. Resuélvelo priorizando cada requisito con MoSCoW: Must have, Should have, Could have, Won't have. El método lo creó en 1994 Dai Clegg en Oracle y luego pasó al marco ágil DSDM, y sobrevive porque obliga a una pregunta honesta: qué hace que la versión uno sea un fracaso si falta (método MoSCoW).

Pon cada funcionalidad en uno de los cuatro cubos. Sé implacable con los "Must have". Si todo es imprescindible, nada lo es. La lista de "Won't have" cuenta tanto como el resto: le dice al estudio qué dejar fuera de la estimación, y así el número se mantiene honesto.

Paso 4: da una franja de presupuesto y una fecha real

Los fundadores esconden el presupuesto por miedo a que se lo presupuesten entero. Pasa lo contrario. Sin una franja, los estudios no distinguen si quieres un prototipo de 15k o una plataforma de 150k, así que sobredimensionan o se retiran. Basta un intervalo: "tenemos entre 40k y 60k para la versión uno". Aclara si esa cifra incluye el soporte tras el lanzamiento y si es con o sin IVA. Para la fecha, da la que de verdad importa y qué la impone, no un optimista "cuanto antes" (Numiko).

Paso 5: enumera el stack y cada integración

Las integraciones son donde las estimaciones se tuercen. Pagos, autenticación, CRM, correo, analítica y cualquier sistema heredado del que el software deba leer o escribir son riesgo que el estudio necesita presupuestar. Enumera lo que usas hoy: Stripe, Supabase, HubSpot, lo que sea. Si hay que hacer una integración, nómbrala. Un solo "también tiene que sincronizarse con nuestro sistema contable" no mencionado puede mover un presupuesto en semanas.

Paso 6: nombra quién decide y quién posee el contenido

Un estudio avanza a la velocidad de tu aprobación más lenta. Di quién firma, cuántas personas intervienen y con qué rapidez devuelves el feedback. Después cierra el contenido: quién escribe los textos, quién aporta los datos, quién entrega los recursos de marca. Los proyectos se atascan más por contenido que falta que por código que falta.

Paso 7: di cómo valorarás las propuestas

Explica a los estudios cómo vas a decidir. Pesas el precio, el trabajo relevante, los plazos o la calidad de las preguntas que te devuelven? Declarar tus criterios hace dos cosas: descarta a los estudios que encajan mal y te trae propuestas más afiladas de los que se quedan. Si llevas un proceso formal, este es también el momento de remitir a tu RFP.

Cómo comprobar que el brief está listo

Haz tres pruebas antes de enviarlo:

1. La prueba del desconocido. Dáselo a alguien que no estuvo en la sala. Si puede explicarte de vuelta lo que quieres, está claro. Si no, reescribe la parte turbia.
2. La prueba del alcance. Cada requisito está en un cubo MoSCoW y la lista de "Won't have" no está vacía.
3. La prueba de la comparación. Dos estudios que lo lean presupuestarían más o menos el mismo alcance. Si adivinarían de forma distinta, hay un hueco que cerrar.

Errores comunes en el brief y cómo corregirlos

• La especificación de 40 páginas. Un brief describe el problema; una especificación describe la solución. Si el tuyo parece un manual de construcción, le has quitado al estudio la opción de proponer un camino mejor. Recórtalo a problema, alcance y restricciones.
• La lista de funcionalidades sin contexto. "Auth, dashboard, informes" no dice nada sobre la complejidad. Añade el porqué detrás de cada línea.
• Sin presupuesto, sin plazo. Produce presupuestos que no puedes comparar y una lista corta en la que no confías. Un intervalo y una fecha real lo arreglan en dos frases.
• Todo es un Must have. El scope creep empieza aquí. Fuerza al menos un tercio de la lista por debajo de "Must". La expansión descontrolada del alcance provoca un desvío de presupuesto medio en torno al 27% (Stop Scope Creep, 2026).

Para ir más allá

Una vez que sale el brief, las decisiones siguientes son comerciales: cómo es un presupuesto justo y a quién enviárselo. Cubrimos ambas en coste de la fase de discovery y cómo contratar un estudio de producto e ingeniería.