Brief de proyecto de software: qué incluir antes de contratar al proveedor

Una empresa envía al proveedor una página de texto, recibe un presupuesto con colchón y después vive entre extras interminables y discusiones sobre qué estaba «incluido». El remedio rara vez es una especificación de cuarenta páginas. Basta un documento corto, y un brief de proyecto de dos o tres páginas lo puede escribir alguien que no sea técnico. Esta guía da la estructura lista para rellenar.

Brief de proyecto: por qué lo necesitas si el proveedor «lo entiende todo»

Las agencias saben asentir. Sin un brief escrito, cada parte imagina un producto distinto y la diferencia llega después en forma de facturas extra. Una plantilla de brief también hace comparables las ofertas: cuando tres empresas contestan las mismas preguntas, ves la diferencia real de precio y enfoque y no tres suposiciones. No es un contrato, pero será su base, así que escríbelo antes de pedir cualquier presupuesto. El proveedor ajusta el alcance con más precisión cuando el brief es claro desde el principio, y con ese brief puedes elegir una empresa de desarrollo de software comparando respuestas. Los briefs de proyecto más útiles caben en dos páginas.

Objetivo y métricas de éxito: el resultado de negocio que buscas

Empieza por el resultado y no por la lista de funciones. Escribe qué debe cambiar para el negocio: más pedidos online, menos consultas a soporte, un presupuesto más rápido. Añade una o dos cifras que demuestren el éxito y la fecha en que las revisarás. «Una web mejor» no da nada a qué apuntar, mientras que «reducir el tiempo de emitir un presupuesto de dos días a dos horas» permite al equipo elegir las herramientas adecuadas.

Qué incluye el brief del proyecto y qué queda fuera de forma expresa

Un brief para un proyecto de software no necesita jerga: enumera las partes principales del trabajo con palabras sencillas y escribe después una lista breve de lo que no entra. La segunda lista evita la mayoría de las disputas: redacción de contenidos, migración de datos, hosting, soporte tras el lanzamiento, integraciones para más adelante. En un brief de un proyecto, la lista de exclusiones y el alcance del proyecto de software van juntos, y un brief de proyecto que nombra las exclusiones es tan útil como el que nombra las funciones. Marca cada función como imprescindible, deseable o posible, para que el precio siga las prioridades.

Una estructura de dos páginas que puedes copiar

Sección	Qué escribir	Ejemplo
Objetivo	Resultado y cifra	Presupuesto en dos horas
Usuarios	Quién y qué hace	El comercial crea un presupuesto
Incluye	Partes principales en lenguaje llano	Formulario, PDF, enlace con el CRM
No incluye	Lo que excluyes	Migración de datos, app móvil
Integraciones	Sistemas y datos	CRM, servicio de pago
Aceptación	Cómo se comprobará	Diez escenarios superados
Personas	Quién decide y en cuánto tiempo	Un responsable, respuesta en dos días

Usuarios, escenarios e integraciones con tus sistemas

Describe dos o tres escenarios reales: quién hace qué, en qué orden y qué debe hacer el sistema en cada paso. Nombra todos los sistemas que toca el proyecto, como el CRM, la contabilidad o el servicio de pago, e indica quién gestiona los accesos, algo clave en un área de clientes, porque casi todo portal de clientes depende de esos enlaces. Las integraciones ocultas son una causa frecuente de que el documento de requisitos de software crezca tras el presupuesto, así que inclúyelas pronto en el brief del proyecto y adjunta capturas del proceso actual. Si todavía dudas entre web y móvil, lee qué construir primero.

Requisitos de datos, seguridad y RGPD, además de accesibilidad

Escribe con qué datos trabaja el producto y dónde deben almacenarse. Si hay datos personales de personas de la UE, el proveedor que los trata por ti necesita un contrato por escrito, como exige el artículo 28 del RGPD. En seguridad, nombra una base en lugar de «debe ser seguro», por ejemplo el OWASP Application Security Verification Standard. En accesibilidad, pide el cumplimiento de WCAG 2.2 en un nivel concreto. Estas líneas casi no cuestan nada en el brief y cuestan mucho si se añaden tarde.

Plazos, etapas de aceptación y quién decide

Para una app móvil sirve el mismo esquema, con un brief para app que añada pantallas y plataformas. El proveedor entiende mejor el alcance si el brief incluye ejemplos.

Divide el trabajo en etapas y escribe para cada una los criterios de aceptación, con ejemplos de documento de requisitos de software si los tienes, de modo que «terminado» sea una comprobación y no una opinión. Nombra a una persona que decide e indica en cuánto tiempo responde, porque esperar respuesta es la causa oculta de muchos retrasos.

1. Escribe qué se mostrará en cada etapa.
2. Define la prueba: escenarios, dispositivos, datos.
3. Acuerda quién firma y en cuántos días.
4. Decide cómo se valoran y aprueban los cambios.

Para elegir el formato de colaboración, mira nuestra guía de outsourcing o equipo propio.

Qué preguntas hace un buen proveedor y qué significa que no las haga

Un buen equipo pregunta antes de presupuestar. Espera estas:

• ¿Qué resultado de negocio quieres y cómo lo medirás?
• ¿Quiénes son los usuarios y quién decide de tu lado?
• ¿Con qué sistemas hay que conectar y quién tiene el acceso?
• ¿Cuál es el rango de presupuesto y la fecha límite, si la hay?
• ¿Qué no puede cambiar y qué puede esperar a la versión dos?

Son señales de alarma un presupuesto en un día sin preguntas, un precio cerrado sin alcance y el silencio sobre pruebas y soporte. Si el proveedor nunca pregunta por el objetivo, el presupuesto se gastará en suposiciones, y ninguna plantilla salvará algo así. Cuando necesitas un equipo dentro de tu propio proceso, mira los servicios de staff augmentation, donde las prioridades siguen en tus manos.