La mayoría de los sobrecostes de un proyecto empiezan antes de la primera línea de código: el equipo construye lo que entendió, no lo que el negocio necesitaba. Un brief claro es la forma más barata de evitarlo, y no requiere conocimientos técnicos.
Empieza por el objetivo
Describe en términos de negocio por qué existe el proyecto: más solicitudes desde la web, menos trabajo manual en la oficina, lanzar un nuevo servicio, sustituir un sistema anticuado. Añade cómo sabrás que ha funcionado, por ejemplo por el número de solicitudes al mes o el tiempo dedicado a un proceso. Un objetivo ayuda al equipo a tomar cientos de pequeñas decisiones en la dirección correcta.
Describe a los usuarios
¿Quién usará el producto: clientes, empleados, socios, administradores? ¿Qué necesitan hacer y en qué situaciones: desde el móvil sobre la marcha, en el escritorio todo el día, una vez al año? Incluso un párrafo breve sobre cada grupo es más útil que una lista de funciones.
Enumera los escenarios clave
Escribe las acciones principales como historias sencillas: «Un cliente elige un servicio, una hora, paga y recibe una confirmación». De cinco a diez historias así cubren el núcleo de la mayoría de los proyectos. Son fáciles de discutir, estimar y comprobar al final.
Sé honesto con las restricciones
Rango de presupuesto, plazo, sistemas existentes que hay que conectar, requisitos legales, idiomas, quién gestionará el contenido tras el lanzamiento. Las restricciones no son un punto débil del brief: son lo que permite al equipo proponer una solución realista en lugar de una ideal.
Fija prioridades
Marca qué debe estar sí o sí en la primera versión y qué puede esperar. Un lanzamiento en el que los escenarios esenciales funcionan bien casi siempre es mejor que un lanzamiento tardío con todo a medio hacer.
Qué puedes dejar fuera
No hace falta elegir tecnologías, dibujar cada pantalla ni describir la base de datos: eso es trabajo del equipo. Ejemplos de webs o productos que te gustan -y qué te gusta exactamente de ellos- suelen valer más que bocetos detallados.
En resumen
Un brief útil responde a cinco preguntas: por qué, para quién, qué deben poder hacer los usuarios, con qué límites y qué va primero. Dos o tres páginas suelen bastar para ahorrar semanas de rehacer trabajo.