Un buen brief de proyecto explica quién necesita ayuda, qué necesita hacer y cómo se ve un buen resultado. Con unos pocos párrafos claros, un boceto y un ejemplo concreto ya tenemos por dónde empezar.
Con ese contexto te hago preguntas y definimos juntos el trabajo antes de proponer un alcance y un calendario. Esta guía muestra qué incluir, tomando como ejemplo un producto de reservas inventado. Las mismas preguntas sirven para una app nueva, un bot o una funcionalidad dentro de un producto que ya existe.
Empieza por el problema y por las personas
Cuéntame quién va a usar el producto, qué intenta hacer y cómo lo hace hoy. En nuestro ejemplo de reservas: “Los clientes escriben a nuestro equipo para pedir una hora. El equipo revisa un calendario compartido, envía un enlace de pago y confirma cada reserva a mano.” Eso explica qué trabajo tiene que facilitar el software.
Incluye el resultado que quieres ver. Puede ser tener menos pasos manuales, un flujo de reservas que funcione o una forma de que los clientes sigan su pedido. Si hoy mides algo, compártelo. Si no, describe cómo sería un buen resultado.
Recorre una tarea importante de principio a fin
Elige una tarea que importe y descríbela de principio a fin. Por ejemplo: un cliente elige un servicio, selecciona una hora disponible, paga y recibe una confirmación. Después, una persona del equipo puede ver o cancelar la reserva.
Menciona también las excepciones. ¿Qué pasa si el pago falla, si el cliente cambia de idea o si dos personas eligen la misma hora? No tienes que resolver cada caso por tu cuenta. Plantear la pregunta nos ayuda a descubrir el trabajo antes de comprometernos con un calendario.
Decide qué necesita la primera versión
Separa lo imprescindible para una primera versión útil de lo que puede llegar después. Un producto de reservas puede necesitar un solo proveedor de pagos al lanzar, mientras que las suscripciones y las recompensas por recomendación pueden esperar. Tus prioridades me ayudan a proponer una versión que sea útil por sí sola.
El nombre de una funcionalidad puede esconder varias decisiones. Para “cuentas de cliente”, dime quién puede registrarse, qué puede ver, si el equipo tiene permisos distintos y qué pasa cuando alguien pierde el acceso. Puedes dejar estos puntos como preguntas abiertas para resolverlas juntos.
Escribe cómo vas a comprobar que una funcionalidad está terminada. “Enviar correos de reserva” deja espacio a expectativas distintas. Una comprobación más clara sería: “Tras un pago correcto, el cliente recibe un correo con el número de reserva, la fecha y las instrucciones para cancelar.”
Estas comprobaciones suelen llamarse criterios de aceptación. Laguía de GOV.UK sobre historias de usuario explica la misma idea: describe la necesidad del usuario y luego enumera los resultados que confirman que se ha cubierto.
Comparte lo que ya existe
Tu web o app actual, y si ya la está usando gente.
Diseños, recursos de marca, contenidos y ejemplos de interfaces que te gusten. Explica qué te gusta de cada uno.
Servicios que deben conectarse al producto, como pagos, correo, un CRM o un bot de Telegram.
Datos existentes que haya que migrar, y quién es el titular de las cuentas correspondientes.
Restricciones como idiomas necesarios, dispositivos, requisitos de accesibilidad o una tecnología ya elegida.
Si vas a mejorar un producto que ya existe, dilo desde el principio. Una funcionalidad puede implicar cambios en los datos, permisos y flujos actuales. Revisar el sistema existente forma parte de entender el alcance.
Explica el plazo y quién decide
Si hay una fecha de lanzamiento, cuéntame por qué es importante y qué tiene que estar listo para entonces. Una fecha ligada a un evento lleva a decisiones distintas que una fecha deseada. Un rango de presupuesto, si lo tienes, también nos ayuda a hablar de prioridades antes de preparar una propuesta.
Indica quién puede confirmar las prioridades y aprobar el trabajo. Cuéntame también las dependencias: contenidos pendientes, accesos de un desarrollador anterior u otro equipo responsable de una integración. Pueden afectar a la planificación tanto como el código.
Cómo es un buen brief inicial
Ofrecemos servicios con cita previa. Hoy los clientes reservan por mensaje y el equipo revisa la disponibilidad a mano.
En la primera versión, los clientes deberían elegir un servicio y una hora disponible, pagar con nuestro proveedor actual y recibir una confirmación de la reserva. El equipo necesita ver las reservas y gestionar las cancelaciones.
Ya tenemos web, identidad de marca y una cuenta de pagos. Los paquetes de suscripción y las recompensas por recomendación pueden llegar más adelante.
Necesitamos ayuda para decidir cómo deben funcionar las cancelaciones y los pagos fallidos. Tenemos una fecha de lanzamiento preferida, pero queremos acordar qué es realista cuando esas preguntas estén resueltas.
Aun así, este ejemplo deja cosas por definir: reglas de disponibilidad, reembolsos, permisos del equipo y qué información lleva cada confirmación. Es normal. Un brief inicial da suficiente contexto para identificar esas decisiones.
Un brief que puedes copiar
Queremos crear o mejorar: …
Las personas que lo usan son: …
El problema del proceso actual es: …
La tarea más importante que debe completar un usuario es: …
Para la primera versión necesitamos: …
Estas funcionalidades pueden esperar: …
Lo que ya existe, incluidos diseños e integraciones: …
Nuestro plazo, restricciones y rango de presupuesto, si los conocemos: …
Lo daremos por bueno cuando: …
La persona que toma las decisiones es: …
Deja una línea en blanco si todavía no sabes la respuesta. Que las preguntas abiertas queden a la vista. Una vez acordado el alcance, cada nueva petición debería venir acompañada de una conversación sobre su efecto en el trabajo y el calendario antes de añadirse.
Puedesenviar tu brief aquí. Trabajo por escrito, así que no tienes que preparar presentaciones ni llamadas. Te responderé con preguntas y próximos pasos antes de acordar el trabajo.