Este es el brief que pedimos a los clientes antes de la llamada de introducción. Calcula de 20 a 30 minutos. No tiene que estar pulido, y “todavía no lo sé” es una respuesta perfectamente válida.
Las frases cortas funcionan mejor que las largas. Si una sección pasa de unas pocas líneas, probablemente estás describiendo la solución antes de que el problema esté claro.
El brief no es un contrato y nadie lo califica. Sirve para poner los datos útiles en una sola página, de modo que la primera conversación parta de tu situación y no de una lista de preguntas genéricas. Los huecos no son un problema, porque detectarlos pronto es justamente la idea.
#La plantilla
Copia todo lo que está en el bloque de abajo a un documento y reemplaza cada indicación entre corchetes con tu respuesta.
BRIEF DE PROYECTO EN UNA PÁGINA Tu nombre y tu empresa:Fecha: 1. El problema (dos frases)[¿Qué está roto, lento o falta hoy? ¿Cuánto te cuesta?] 2. Quién lo usa y qué hace hoy[Enumera cada tipo de usuario. De cada uno: ¿qué hace ahora y con qué herramientas?] 3. Imprescindibles[¿Qué tiene que funcionar el primer día, o el proyecto no vale la pena? Apunta a entre 3 y 7.] 4. Deseables[Útiles, pero puedes vivir sin ellos en el lanzamiento.] 5. Fuera del alcance[Lo que este proyecto no hará. Sé directo.] 6. Sistemas y datos que toca[Herramientas, hojas de cálculo, cuentas y bases de datos, y quién mantiene cada una. Señala lo que sea sensible.] 7. Cómo se ve el éxito (en palabras sencillas)[Tres meses después del lanzamiento, ¿qué es distinto? ¿Cómo lo notarías?] 8. Fecha límite[Una fecha y qué la determina. Escribe “flexible” si lo es.] 9. Rango de presupuesto[Un rango basta. Nos dice qué opciones son realistas.] 10. Quién decide[¿Quién aprueba el alcance y el precio? ¿A quién más hay que consultar?]#Cómo completarlo
- Describe el problema, no la herramienta. “Las cotizaciones tardan dos días en salir” sirve más que “necesitamos una app”.
- Nombra usuarios reales. “La recepción” y “nuestros dos estimadores” valen más que “el personal”. Usuarios distintos suelen necesitar pantallas distintas.
- Mantén cortos los imprescindibles. Si todo es imprescindible, nada lo es. Pasa el resto a deseables.
- Sé generoso con lo que queda fuera del alcance. Nombrar pronto lo que no vas a hacer evita el malentendido más común más adelante.
- Escribe el éxito como algo que puedas observar. “Nadie vuelve a escribir pedidos en el sistema de contabilidad” se puede comprobar. “Mayor eficiencia” no.
- Enumera los sistemas que ya usas. Incluye los aburridos: la hoja de cálculo compartida, la bandeja de correo, la herramienta de contabilidad. El software nuevo casi siempre tiene que leer de ellos o escribir en ellos.
- Da un rango de presupuesto. No te compromete a nada. Un rango permite que un ingeniero sugiera opciones que encajen en lugar de adivinar.
#Qué pasa después
Envía el brief antes de la llamada. El ingeniero que se une a la llamada lo lee antes, así que los 30 minutos se dedican a tus preguntas y a los huecos, no a lo básico.
Si una sección te traba, déjala en blanco y dilo. Preferimos conversar sobre un hueco honesto que leer una suposición dicha con seguridad.
A partir de ahí, el descubrimiento convierte el brief en un alcance por escrito con precio fijo. Si quieres ayuda con la redacción, lee cómo escribir un brief que un desarrollador pueda cotizar.
¿Listo? Agenda una llamada de 30 minutos y envíalo por correo a hello@altamar.dev.
