Una sala de reuniones vacía después del encuentro, con un documento encuadernado abierto entre dos tazas frías y una silla apartada

· 5 min de lectura

Por qué fracasan los proyectos de software pese a tener un documento de requisitos: el desacuerdo silencioso

El documento estaba completo, revisado y aprobado por todos. Nueve meses después, el producto salía y nadie lo quería. Lo que cuentan estas historias sobre la diferencia entre un acuerdo obtenido y un acuerdo real, y sobre lo que debe provocar un punto de validación.

En Reddit (r/startups, julio de 2026), un fundador cuenta nueve meses de trabajo con un equipo completo para un producto que nació muerto, aunque todo el mundo había aprobado su documento de requisitos. Los proyectos de software fracasan pese a tener un documento de requisitos cuando la validación ha servido sobre todo para evitar una conversación.

Lo que había ocultado la validación

El autor reconstruye la escena después. Dos directores tenían dos ideas incompatibles sobre la finalidad del producto. En lugar de aclararlas en la sala, ambos asintieron ante el documento y se marcharon convencidos de haber conseguido lo que querían. La aprobación general registraba una ausencia de objeciones, lo cual no dice nada sobre lo que cada uno había entendido. Los nueve meses siguientes sirvieron para construir un producto que respondía a dos encargos distintos y, por tanto, a ninguno de los dos. El documento había registrado un silencio, y ese silencio duró hasta la publicación, cuando los dos directores descubrieron a la vez que habían perdido.

Un documento impecable agrava el riesgo

Un documento cuidado se lee como un trabajo terminado, y objetar ante un trabajo terminado parece un ataque contra quien lo hizo. Cuanto más largo es, menos se lee; cuanto más pulido está, más confianza inspira sin que nadie lo lea. La paradoja se verifica tanto en documentos comerciales como en documentos de proyecto, y explica por qué un presupuesto aceptado no fija el costo. Un borrador manuscrito y tachado provoca más discrepancias que una versión encuadernada, porque permite al lector intervenir. Conviene que un documento de proyecto circule en ese estado, incompleto y abierto a correcciones, mientras no se hayan tomado las decisiones costosas.

Tres señales de un acuerdo que no lo es

La primera: la validación llega en menos de un minuto, sin que nadie haya abierto ninguna página dos veces. La segunda: nadie ha hecho preguntas, aunque un documento de veinte páginas siempre contiene al menos una frase ambigua y una decisión costosa. La tercera, la más fiable: pregunta a tres personas, por separado, qué permitirá hacer el producto dentro de seis meses que no puedan hacer hoy, y compara las respuestas. Cuando las tres frases no coinciden, el documento no ha establecido ningún acuerdo, por muchas firmas que haya al pie de la página.

Una puerta que se abre y permanece abierta

En Maestro, cada documento que producen los agentes espera un «Me parece bien» antes de que empiece lo siguiente: el brief, el documento de requisitos, la división en etapas y luego cada etapa construida. Esa puerta tiene dos propiedades que aquí importan. Llega pronto y con frecuencia, así que un malentendido cuesta una relectura del brief en lugar de nueve meses de construcción. Y permite modificar el documento después: puedes volver a abrir el documento de requisitos, corregir una frase o regresar a una versión anterior de tu producto. La validación marca un momento de la conversación, no cierra el asunto, y hemos explicado en otro artículo por qué esta puerta es nuestra principal medida de seguridad.

Lo que una puerta no puede hacer por ti

Un punto de validación se convierte en un sello cuando lo cruzas sin leer. El mecanismo protege a quien lo utiliza para plantear sus preguntas; no protege a nadie de un clic automático, y la historia de las grandes decisiones automatizadas mal revisadas demuestra lo que cuesta aprobar por comodidad, incluso cuando una multa de 825 millones de euros sanciona una decisión que nadie volvió a examinar. Nuestra parte del trabajo consiste en hacer que el documento sea breve, esté escrito en tu idioma y se divida lo bastante pronto como para que una objeción no cueste casi nada. Tu parte consiste en formular la objeción.

Hacer que el desacuerdo hable

Antes de tu próxima validación, haz el ejercicio de las tres frases. Pide a cada persona relevante que escriba sola, sin consultar a las demás, qué permitirá hacer el producto, para quién y qué no hará. Bastan veinte minutos, y las tres líneas de «qué no hará» revelan la mayoría de los desacuerdos, porque ahí es donde cada uno ha colocado mentalmente la funcionalidad que le importa. Pon las respuestas una al lado de otra, resuelve las diferencias delante de los interesados, anota la decisión en el propio documento en lugar de en un acta que nadie volverá a abrir, y luego valida. Lo que queda después de este ejercicio merece llamarse acuerdo.

Leer la guía completa: crear una aplicación sin programar

Volver al diario

Toma la batuta.

Deja tu correo para probar Maestro en las primeras tandas.

La beta está abierta por invitación en macOS 13 y versiones posteriores. Deja tu email para una próxima tanda de acceso. Windows está en preparación.

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.