El Documento de Requerimientos Es una Foto Borrosa
La forma estándar de construir software para una empresa es esta: una junta de descubrimiento, un documento de requerimientos, una propuesta, meses de construcción, y al final — la entrega. Las personas que van a usar el sistema lo ven por primera vez cuando ya está terminado.
Toda esa cadena depende de un documento que empezó a envejecer en el momento en que se escribió. Los requerimientos capturados en una sala de juntas son recuerdos de segunda mano de cómo ocurre el trabajo en realidad. Quien los escribió estaba traduciendo. Quien los leyó estaba interpretando. Para cuando el sistema se entrega, describe una empresa que ya no existe — si es que alguna vez existió.
Dejamos de trabajar así. No porque el descubrimiento sea inútil, sino porque un documento es el contenedor equivocado para él.
El Intake Vive Dentro del Producto
Este es el movimiento que cambió cómo construimos: el intake no es un formulario que llenas antes del proyecto. Es la primera funcionalidad del proyecto.
A días de arrancar un encargo, desplegamos un portal vivo — URL real, accesos reales, niveles de acceso reales. Y su primer módulo es el onboarding mismo: un conjunto estructurado de preguntas que cada equipo responde dentro del sistema que va a usar.
Esto logra tres cosas que un documento de requerimientos no puede:
El cliente es usuario desde el día uno. Antes de que exista cualquier funcionalidad "de verdad", la gente ya entra, responde, y ve sus respuestas persistir. La adopción no es una fase después de la entrega — empieza antes de la construcción.
Las respuestas llegan con autor y fecha. Sabemos quién dijo qué, desde qué rol, y cuándo. Cuando dos áreas describen el mismo proceso de forma distinta — y siempre pasa — podemos ver el desacuerdo en lugar de promediarlo hasta desaparecerlo.
El intake nunca cierra. Cada etapa nueva abre preguntas nuevas. El sistema sigue preguntando mientras crece, porque la empresa sigue cambiando mientras crece.
Cada Respuesta Es una Decisión de Ingeniería
Las preguntas no son encuestas de satisfacción. Cada una existe porque su respuesta decide algo de la arquitectura.
"¿Quién da la aprobación final?" no es curiosidad — se convierte en una regla de permisos. Si solo la dirección aprueba, el sistema lo hace cumplir, y un intento de aprobación desde cualquier otro lugar se rechaza y queda registrado.
"¿Dónde vive tu información hoy?" decide integraciones e importaciones. Si la respuesta honesta es hojas de cálculo, correo y chats — y casi siempre lo es — eso nos dice exactamente qué tan fácil tiene que ser el sistema para ganarles.
"¿Qué necesitas del otro equipo?" se convierte en un módulo. La primera petición entre áreas capturada en un intake suele ser el plano de cómo va a fluir el trabajo por la plataforma.
"¿Qué campos tiene tu formato actual?" se convierte en el esquema de datos. De eso hablamos abajo.
Esto es lo que queremos decir con construir de la mano del cliente: no que hacemos más juntas, sino que sus respuestas específicas — con nombre, fecha y procedencia — son los insumos de decisiones de ingeniería. El cliente co-diseña el sistema describiendo su realidad con precisión, y nosotros tomamos la responsabilidad de convertir esa realidad en estructura.
Sus Formatos Son el Esquema — Más la Memoria que Nunca Tuvieron
No llegamos con una ontología. Las empresas ya tienen formatos — la hoja donde rastrean proyectos, el formulario donde nace una propuesta, la lista que debe pasar un pedido. Esos formatos codifican años de conocimiento operativo, y la gente que los usa ya confía en ellos.
Así que la estructura de captura del sistema es la estructura de ellos. Los campos que su equipo diseñó se vuelven los campos en pantalla, con sus nombres, en su orden.
Lo que agregamos es lo que sus documentos nunca tuvieron: las columnas de resultado. ¿En qué estado está esto? ¿Quién decidió? ¿Cuándo? ¿Por qué? Una hoja de cálculo puede guardar cien decisiones sin conservar una sola razón. Los sistemas que construimos hacen la razón obligatoria — un rechazo sin su "porqué" registrado no se acepta, porque un "no" que no se explica no le enseña nada al siguiente intento.
Esa es la tesis silenciosa de todo lo que construimos: el registro no es el valor. El juicio alrededor del registro — quién, cuándo, por qué, con base en qué — es el valor. La memoria institucional no es una funcionalidad. Es el producto.
El Sistema Crece por Evidencia, No por Calendario
Construimos por etapas, y las etapas se abren por prueba de uso — no porque un cronograma lo diga. Una etapa que no se usa no se gana una sucesora. Eso protege al cliente de pagar por software de repisa, y nos protege a nosotros de construir sobre arena.
Y nada se entrega declarado; se entrega probado. Antes de que un módulo llegue a usuarios, se ejercita de punta a punta — incluyendo sus negativas. Verificamos lo que el sistema correctamente niega con el mismo cuidado que lo que permite, porque un sistema de permisos que nunca se probó contra el usuario equivocado es un diagrama, no un sistema.
En un mundo de promesas, vendemos pruebas. Esa frase es nuestro manifiesto, y esta metodología es cómo se ve en la práctica.
Creado con Inteligencia Humana
Construimos con IA, a velocidad de máquina. Lo decimos sin rodeos. Lo que hace que el resultado sea nuestro — y lo que hace que funcione — es dónde se sienta el humano en el proceso.
El humano decide el alcance, elige el criterio y verifica antes de que algo se entregue. La máquina ejecuta lo repetible. Nadie firma lo que no revisó.
Por eso cada plataforma que entregamos lleva la misma firma: Creado con inteligencia humana. No es una negación de las herramientas. Es un reclamo sobre quién decide y quién garantiza.
El método descrito aquí es cómo ese reclamo se vuelve verdad, un sistema a la vez.