No necesitas un documento de cuarenta páginas para pedir una app. De hecho, los documentos enormes suelen esconder el problema: describen cada botón, pero nunca dicen para qué sirve la app.
Un buen brief cabe en una hoja y lo escribe quien conoce el negocio, no quien programa. Su trabajo es uno solo: que dos proveedores distintos entiendan lo mismo.
1. Qué problema resuelve
Escríbelo en una frase y sin mencionar la app.
- Mal: "Queremos una app con inicio de sesión, mapa y notificaciones".
- Bien: "Nuestros repartidores llaman a la oficina para confirmar cada entrega y perdemos cerca de una hora por ruta".
La segunda frase le permite a un buen proveedor proponerte algo que no se te había ocurrido, o decirte que no necesitas una app.
2. Quién la va a usar y en qué situación
Describe personas, no "usuarios". "Un repartidor con guantes y prisa, en un Android de gama media y con mala señal" lleva a una app muy distinta de "un gerente en su oficina".
Lista cada tipo de persona y qué necesita hacer. Cada rol adicional mueve bastante el presupuesto, así que vale la pena ser honesto sobre cuáles son indispensables.
3. Qué existe hoy
Cuenta cómo se resuelve actualmente, aunque te dé pena. Excel, cuadernos, un grupo de WhatsApp o un sistema de hace quince años. Es la mejor fuente de reglas de negocio que nadie ha escrito nunca.
Si puedes, adjunta capturas o una foto del proceso real. Vale más que cualquier descripción.
4. Con qué debe conectarse
Enumera lo que ya usas y lo que la app tendrá que tocar:
- Sistema administrativo, ERP o punto de venta.
- Pasarelas de pago.
- Facturación.
- Inicio de sesión corporativo.
- Hardware, como lectores o impresoras.
Basta con el nombre y si tiene API o no. Si no lo sabes, dilo: es información valiosa. Las integraciones son una de las principales causas de retraso.
5. Cómo sabrás que funcionó
Elige una métrica antes de empezar. "Reducir las llamadas a oficina a la mitad" o "que el 60% de los pedidos frecuentes se hagan por la app". Sin ella, nadie podrá decir si el proyecto salió bien, y cada funcionalidad nueva parecerá igual de urgente.
Lo que también ayuda (si lo tienes)
- Fecha límite real y por qué existe. Una feria es una fecha real; "lo antes posible" no.
- Rango de presupuesto. No te debilita al negociar: permite proponerte algo que quepa en él.
- Quién decide y quién puede dedicar tiempo a revisar avances.
- Quién es dueño de las cuentas de las tiendas. Si no lo sabes, lee tu cuenta o la de un publisher.
- Dos apps que te gusten, y qué te gusta de cada una.
La plantilla
Copia esto en un documento:
PROBLEMA: (una frase, sin mencionar la app)
QUIÉN LA USA: (rol, situación, tipo de teléfono)
CÓMO SE HACE HOY: (herramientas y capturas)
CON QUÉ SE CONECTA: (sistemas, pagos, hardware)
CÓMO SABREMOS QUE FUNCIONÓ: (una métrica)
FECHA Y POR QUÉ:
PRESUPUESTO APROXIMADO:
QUIÉN DECIDE:Lo que no hace falta
No necesitas diseñar pantallas, elegir un lenguaje ni decidir entre nativo y multiplataforma. Esa parte le toca a tu proveedor, y deberías pedirle que justifique lo que recomienda.
¿Ya lo tienes? Mándanoslo. Aunque esté a medias, lo revisamos en la primera consulta sin costo y te decimos qué falta aclarar.