Pedir software a un equipo técnico sin un briefing claro es como pedirle una casa al arquitecto sin saber cuántas habitaciones quieres. Algo va a salir. Probablemente no lo que necesitabas. Y el arreglo cuesta más caro que haberlo hecho bien la primera vez.

Antes de que exista la primera línea de código, alguien tiene que hacer una serie de preguntas aburridas. Preguntas que parecen pérdida de tiempo al principio y que pagan oro en los meses siguientes. Vamos a recorrer las principales.

El briefing: el único momento en que equivocarse sale barato

Tres preguntas funcionan como brújula: quién va a usar el producto, qué problema resuelve y cómo vamos a medir si salió bien. Suena simple, pero la mayoría de los proyectos arranca sin respuesta firme a por lo menos una de ellas. Cuando el software llega a producción y nadie lo usa, normalmente es porque la pregunta 1 se contestó con 'todo el mundo'. Cuando se vuelve centro de costo permanente, la pregunta 3 nunca se hizo. Documenta las respuestas en una página, dos como máximo. No es el momento de un PowerPoint de cincuenta slides. Visión, problema central, premisas, restricciones conocidas. Ese documento se va a consultar por meses, así que tiene que ser lo suficientemente corto para que alguien lo abra antes de una reunión.

Entender al usuario antes de imaginar la pantalla

Usa una narrativa simple: escribe un día en la vida del usuario al que quieres atender. Descubre dónde se traba, qué herramientas usa hoy y qué sería 'ahora se volvió fácil' para él. Esa descripción vale más que cualquier wireframe dibujado antes de entender el contexto. Un wireframe sin contexto es solo una pantalla bonita, y una pantalla bonita no resuelve problemas.

Equipo mínimo viable

Al principio, tres roles suelen alcanzar: alguien de producto que decide prioridades, alguien de diseño que da forma a la experiencia, alguien de ingeniería que entrega. QA, datos, infraestructura entran a medida que el alcance crece. Inflar el equipo para parecer serio es la forma más cara de no decidir nada. La pregunta paralela: ¿tercerizar o armar equipo interno? No hay respuesta correcta. Solo trade-offs. Un tercero entrega rápido y se va. El equipo interno demora más en producir pero construye conocimiento que queda.

Arquitectura sin jerga

La arquitectura es el esqueleto: web o mobile, base de datos, integraciones con sistemas que ya existen, autenticación. No necesitas entender cada decisión técnica, necesitas insistir en que estén documentadas. Un archivo corto llamado Architecture Decision Record (ADR) con el porqué de cada elección vale oro por años. Sin eso, en un año alguien va a querer cambiar la base de datos y nadie va a recordar por qué eligieron la actual.

Antes de programar: checklist honesto

Siempre hay tendencia a querer empezar a construir rápido porque 'ya tenemos lo suficiente'. Antes de soltar al equipo a programar, valida: ¿el usuario fue mapeado de verdad o sigue siendo 'cualquiera'? ¿El prototipo se probó con gente real? ¿Las métricas de éxito están acordadas entre negocio e ingeniería? ¿Los riesgos conocidos tienen plan? Si la respuesta a alguna de esas es 'más o menos', el primer sprint ya empieza con deuda.

“El dinero más caro de un proyecto es el que gastas rehaciendo cosas porque saltaste pasos al principio.”

Con estos pasos no evitas todos los problemas, evitas los caros. Las sorpresas van a aparecer, siempre aparecen. La diferencia es que aparecen en cosas que vale la pena aprender, no en decisiones que podrías haber tomado antes de gastar tres meses construyendo.