Un directivo anota con lápiz rojo un documento impreso sobre la mesa de su cocina, con una taza al lado

11 de septiembre de 2026 · 6 min de lectura

Por Thomas Cohen, fundador de Maestro

Entender un documento de requisitos de una aplicación sin ser del sector

El documento que describe tu futura aplicación se lee en diez minutos, con cuatro preguntas y un lápiz. Leerlo mal cuesta más que leerlo despacio: un acuerdo de fachada se paga en meses de desarrollo. Dónde mirar, en qué orden y las cinco fórmulas que deben hacerte levantar el lápiz.

Entender el documento de requisitos de una aplicación exige diez minutos y un lápiz, no formación. Un fundador cuenta en Reddit (r/vibecoding, junio de 2026) que sitúa el problema en él mismo y no en el código de la IA: no sabe escribir el diseño inicial. Leer ese documento es más fácil que escribirlo y basta para decidir.

Los cinco bloques, sea quien sea el autor

Un documento de requisitos tiene cinco bloques, tanto si viene de una agencia como de un freelance o un equipo de agentes. El problema y para quién. Los recorridos: lo que hace una persona, pantalla tras pantalla, desde el principio hasta el final de una tarea. Las reglas de tu actividad: lo permitido, lo prohibido y lo calculado. Los datos: qué se guarda, quién lo ve y durante cuánto tiempo. Y lo que queda fuera del alcance: lo que el producto no hará en esta versión. Un documento sin estos cinco bloques se lee en tres minutos porque no dice nada. Describimos en otro artículo lo que debe contener antes de firmar.

Los diez minutos, repartidos

Dos minutos sobre lo que queda fuera del alcance, primero: la sección que decide tu factura y tu calendario y que nadie abre. Tres minutos sobre los recorridos, siguiendo con el dedo el trayecto de tu cliente más frecuente hasta el final. Tres minutos sobre las reglas, buscando las tuyas, las que aplicas sin pensar: el descuento al cliente fiel, el presupuesto que caduca a los treinta días y el horario que nunca se reserva dos veces. Dos minutos sobre los datos: quién ve qué. Si tu regla más simple no aparece en ninguna parte, no existirá en el producto. Ten un cronómetro: después de diez minutos relees en lugar de leer y el cansancio te hará aprobar lo que no has entendido.

El asentimiento que mata un proyecto

Un fundador cuenta en Reddit (r/startups, julio de 2026) que el documento más bonito que había escrito mató nueve meses de trabajo: dos directores tenían ideas opuestas sobre para qué servía el producto y, en lugar de discutir ante el documento, ambos asintieron. No había acuerdo: cada uno supuso que había ganado. Una lectura rápida orientada a aprobar fabrica esa trampa. Una lectura útil sale a buscar el desacuerdo: si deben validar tres personas, haz que cada una escriba en una frase para qué sirve el producto antes de abrir el documento.

Las cuatro frases que deben detenerte

«El sistema gestiona los usuarios»: ¿cuántos roles y puede un empleado ver los expedientes de otro? «Se envía una notificación al cliente»: ¿por qué canal, en qué momento y qué ocurre si falla el envío? «Importación de los datos existentes»: ¿desde qué archivo, con qué columnas y quién resuelve los duplicados? «Se calcula el importe»: ¿según qué fórmula, con qué redondeo y con impuestos incluidos o no? Cada frase oculta una decisión. Si el documento no la toma, alguien la tomará por ti durante la construcción sin conocer tu actividad. Una quinta fórmula merece el lápiz rojo en cuanto aparece: «el sistema se adapta a las necesidades del cliente». No describe nada y volverá seis semanas después en forma de factura adicional o funcionalidad ausente.

El documento de un equipo de agentes tiene un defecto concreto

Una agencia te enviará un documento de requisitos largo, con anexos y planificación: aplica la misma tabla y pide la versión corta si los cinco bloques quedan enterrados. Un documento producido por un equipo de agentes, como el que redacta Victor en Maestro después de la definición de Margaux, tiene una ventaja y un defecto. La ventaja: corregirlo no cuesta nada, se reescribe mientras hablas, lo que hace rentable leerlo. El defecto: es plausible en todas partes, incluso donde ha adivinado una regla que no podía conocer. Lo que relees es, por tanto, el verdadero entregable del proyecto, no un trámite antes del trabajo serio.

En la práctica

Abre el documento junto a una libreta y anota tres líneas, no más: una regla de tu actividad que falta, un recorrido que se detiene antes del final y una palabra que no entiendes. Devuelve esas tres líneas antes de decir «Me parece bien»: en Maestro, esta puerta bloquea lo que sigue hasta que respondas, y existe precisamente por eso. Si todavía no tienes ningún documento que leer, el método de las preguntas incómodas produce uno en una hora.

Volver al diario

Toma la batuta.

Deja tu correo para probar Maestro en las primeras tandas.

La beta se abre por tandas. Las personas inscritas la prueban primero y Maestro sigue siendo gratis durante toda la beta.

La beta está disponible actualmente en macOS 13 o posterior. Tu respuesta nos ayuda a preparar otras versiones.

Tu correo solo se usa para avisarte de la apertura. Nada más, prometido.