Brief de desarrollo - 15 preguntas al cliente

Un buen brief de desarrollo ahorra semanas de idas y vueltas y protege el presupuesto de "y también esto". Sin respuestas a preguntas básicas, el equipo adivina requisitos y el cliente se sorprende con plazos y precio. Abajo - 15 preguntas que conviene hacer antes del presupuesto y del kick-off. Las respuestas convierten una idea en un alcance claro, no en una lista de deseos.

• Para qué el brief - fijar objetivo, límites y criterios de éxito
• Cuándo preguntar - antes de la propuesta comercial y antes del kick-off
• Quién responde - el decisor y el product owner, no "un poco todos"
• Qué obtienes - alcance claro, plazo realista y presupuesto transparente
• Regla - sin respuesta = riesgo de retrabajo y costes ocultos

Por qué recopilar el brief antes de empezar

Desarrollar un sitio, un servicio o una integración casi siempre se atasca en la incertidumbre, no en el código. Si el objetivo es difuso, las prioridades cambian cada semana y el "must-have" aparece al final - crecen plazos y coste.

El brief no es burocracia. Es un contrato corto sobre el sentido del proyecto: qué hacemos, para quién, hacia qué resultado, bajo qué restricciones. Cuanto antes se cierren estas preguntas, más precisa es la estimación y más tranquilas ambas partes.

15 preguntas al cliente

1. ¿Qué problema de negocio resolvemos?

No "hace falta una web", sino qué duele ahora: pocas leads, caos en solicitudes, procesos manuales, catálogo obsoleto. El problema define arquitectura y prioridades de funciones.

2. ¿Quién es la audiencia objetivo y cuál es su escenario principal?

Quién es el usuario: comprador B2B, cliente retail, empleado, partner. Un escenario principal importa más que diez secundarios.

3. ¿Cómo sabremos que el proyecto fue un éxito?

Hacen falta criterios medibles: número de leads, conversión, tiempo de gestión de pedidos, menos errores, velocidad de publicación. Sin KPI, "listo" sigue siendo subjetivo.

4. ¿Cuál es el plazo y hay una fecha límite dura?

Un lanzamiento para feria, temporada o release de producto cambia el plan: MVP ahora o alcance completo después. Un deadline sin prioridades suele significar retrabajo.

5. ¿Qué rango de presupuesto es realista?

Un corredor presupuestario ayuda a cortar un alcance irreal desde el inicio. Un rango honesto vence a "barato orientativo" sin cifras.

6. ¿Qué existe ya: sitio, CRM, ERP, API, contenido?

El inventario ahorra dinero. Integrar un CRM vivo y migrar un catálogo son volúmenes aparte, no "un detalle al final".

7. ¿Qué integraciones son obligatorias en el arranque?

Pagos, almacén, 1C/ERP, correo, analítica, mensajería. La lista de integraciones afecta más al plazo que la elección del framework.

8. ¿Hay restricciones de stack, hosting y seguridad?

Estándares corporativos, on-premise, requisitos de seguridad, prohibición de nube - todo debe estar en el brief antes de la estimación, no después de elegir proveedor.

9. ¿Quién decide y quién aprueba las etapas?

Un solo decisor acelera el proyecto. Si la aprobación pasa por cinco departamentos sin dueño - reserva buffer para esperas y cambios de criterio.

10. ¿Qué es must-have en la v1 y qué puede esperar?

Separa "necesario para lanzar" de "deseable después". Un MVP con núcleo claro da resultado antes y cuesta menos que "todo de golpe".

11. ¿Hay referencias de "cómo sí" y anti-ejemplos de "cómo no"?

Enlaces a sitios y productos ahorran horas de debate sobre UX y tono. Los anti-ejemplos también ayudan: marcan límites de gusto y expectativas.

12. ¿Quién prepara contenido, textos, fotos y accesos?

El contenido suele ser el cuello de botella. Si textos y accesos llegan tarde - diseño y desarrollo se detienen.

13. ¿Qué roles de usuario y niveles de acceso se necesitan?

Invitado, cliente, manager, admin, partner - paneles y permisos distintos. Describe el modelo de roles antes de diseñar pantallas.

14. ¿Hay requisitos legales, de datos personales o sectoriales?

GDPR / leyes locales, salud, finanzas, sector público - cambian arquitectura de almacenamiento, consentimientos, logs y contratos. No se pueden "añadir después".

15. ¿Quién da soporte al producto tras el lanzamiento?

Actualizaciones, monitorización, edición de contenido, respuesta a incidentes. Si el soporte no está en el plan - el producto en producción envejece rápido.

Cómo usar las respuestas en la práctica

Resume las respuestas en una página:

Con esta tabla es fácil armar la propuesta y el roadmap. Si una celda está vacía - no es "detalle para después", es un riesgo abierto.

Errores típicos en el brief

• Confundir un deseo ("que quede bonito") con un resultado ("subir leads un 30%").
• Tratar las integraciones como "un botón", no como un trabajo aparte.
• No nombrar un product owner del lado del cliente.
• Construir el must-have con todo el backlog sin priorizar.
• Ignorar el soporte: lanzar sin owner de soporte = deuda desde el día uno.

Conclusión

Un brief de desarrollo son 15 preguntas cortas pero firmes sobre objetivo, audiencia, KPI, plazos, presupuesto, integraciones, restricciones, roles y soporte. Cuanto más completas sean las respuestas antes de empezar, más precisa será la estimación y menos sorpresas habrá en el camino.

Si necesitas ayuda para armar el brief, priorizar el MVP o estimar el desarrollo con tus respuestas - contacta conmigo.

Preguntas frecuentes

¿Cuánto tiempo lleva completar el brief?

Suele ser 1-2 días laborables si hay un decisor y acceso a datos básicos. Es más difícil cuando las decisiones están repartidas entre departamentos: entonces un taller corto de 1-2 horas gana a semanas de correos.

¿Se puede estimar un proyecto sin brief?

Se puede dar un rango de-hasta, no una cifra precisa. Sin objetivo, integraciones y criterios de éxito, la estimación casi siempre flota. El brief reduce la incertidumbre y protege a ambas partes de expectativas falsas.

¿El brief sustituye la especificación técnica?

No: el brief es la entrada a la especificación. Fija sentido y límites. La especificación describe pantallas, datos, API, roles y criterios de aceptación. Sin brief, la especificación suele hincharse y cambiar a mitad de camino.

¿Qué hacer si el cliente no conoce el presupuesto?

Propón un corredor y opciones de alcance: MVP / estándar / ampliado. Así es más fácil elegir un scope realista. "Presupuesto ilimitado" en la práctica casi siempre significa que las prioridades aún no están alineadas.

¿Hay que actualizar el brief durante el desarrollo?

Sí, si cambian el objetivo, el deadline o el must-have. El brief es un documento vivo de límites. Cualquier ampliación de alcance debe cambiar de forma explícita el plazo o el presupuesto; si no, el equipo trabaja a crédito.