Intent Contracts frente a PRD

Qué es un PRD

Un documento de requisitos del producto es una especificación exhaustiva que describe lo que debe hacer un producto o una funcionalidad. Normalmente incluye:

Una especificación funcional que enumera cada funcionalidad, historia de usuario y criterio de aceptación. Una especificación técnica que describe cómo debe funcionar el sistema, a menudo con mucho detalle. Perfiles de usuario y casos de uso que ponen los requisitos en contexto. Criterios de éxito, aunque a menudo son vagos o faltan por completo. Dependencias y restricciones, a veces enterradas en un anexo.

Los PRD están pensados para que los lean gerentes de producto, ingenieros, diseñadores y partes interesadas. Aspiran a ser la fuente única de verdad. Los mejores PRD están bien organizados y son claros. Pero, en la práctica, la mayoría de los PRD se convierten en documentos que se escriben una vez y rara vez se vuelven a leer completos. A menudo ya están desactualizados cuando empieza el desarrollo. Llegan a ocupar 20, 30 y hasta 50 páginas. Y tratan el alcance como algo que solo se suma: una vez que se incluye una funcionalidad, quitarla se siente como un fracaso, aunque no tenga importancia para los resultados.

Qué es un Intent Contract

Un Intent Contract es una declaración breve y aprobada del resultado, el alcance, las métricas de éxito, las restricciones, los límites de la autoridad humana y los criterios de aceptación. No es un acuerdo legal; las condiciones comerciales se establecen en el contrato del proyecto. Define lo que usted busca lograr y cómo medirá el éxito antes de escribir código. Es mucho más corto que un PRD (normalmente de 2 a 4 páginas) y responde estas preguntas centrales:

¿Cuál es el objetivo de negocio? ¿Qué resultado medible define el éxito? ¿Qué queda explícitamente dentro del alcance y qué queda explícitamente fuera? ¿En qué condiciones reduciríamos el alcance o nos detendríamos? ¿Qué pasa después del lanzamiento: qué medimos?

Un Intent Contract incluye criterios de aceptación y restricciones técnicas, pero empieza por la intención. Obliga a los equipos de producto a explicar la justificación de negocio, no solo la lista de funcionalidades. Declara el riesgo desde el principio. Define quién decide cuando cambia el alcance. Y crea responsabilidad en torno a resultados medibles, no solo a la entrega.

InTech usa Intent Contracts porque reflejan la velocidad con la que hoy se desarrollan los productos. Cuando un equipo de ingeniería capacitado puede construir e iterar con rapidez, un PRD de 40 páginas a menudo se vuelve un lastre. Se pasan semanas afinando una especificación que cambiará en cuanto los usuarios reales vean el producto. Un Intent Contract le da las restricciones y la claridad sobre el resultado que necesita, sin atarlo a una lista de funcionalidades que quizá ya no tenga sentido en la cuarta semana.

Las diferencias de fondo

Las diferencias entre un PRD y un Intent Contract se reducen a una cuestión de filosofía.

Un PRD se centra en las funcionalidades. Responde: ¿qué hace el producto? Un Intent Contract se centra en los resultados. Responde: ¿qué logra el usuario o el negocio? Cuando empieza por las funcionalidades, corre el riesgo de construir cosas que no importan. Cuando empieza por los resultados, el alcance se convierte en una palanca que puede ajustar para alcanzar su objetivo.

Un PRD suele ser estático. Se escribe, se revisa, se aprueba y se entrega. Un Intent Contract es dinámico. Se revisa a medida que se aprende. La alineación ocurre al escribirlo juntos (equipo de producto, ingeniería y partes interesadas). El documento en sí es la prueba de esa alineación.

Un PRD supone que el alcance es fijo y que se entregará todo. Un Intent Contract supone que el alcance puede ajustarse. Define explícitamente qué queda fuera del alcance y qué condiciones podrían llevar a reducirlo. Esto no es un fracaso; es ejecución disciplinada. Lo que se dice es: estamos resolviendo este problema de esta manera y, si aprendemos algo que cambia el enfoque, lo decidimos juntos, no dejamos que el alcance crezca sin control.

Un PRD normalmente no define criterios de detención. Un Intent Contract sí. Se acuerdan de antemano las condiciones en las que se pausaría o detendría el trabajo. Podría ser que, si la métrica principal no se mueve para la sexta semana, detengamos el trabajo en funcionalidades y hagamos un diagnóstico. O que, si una dependencia técnica cuesta tres veces más de lo previsto, revisemos el alcance. Estas conversaciones ocurren en un Intent Contract antes de convertirse en reuniones de emergencia en un proyecto basado en un PRD.

Un PRD mide el éxito por la entrega. ¿Construimos lo que dijimos? Un Intent Contract mide el éxito por los resultados. ¿Cambió el comportamiento del usuario? ¿Se movió la métrica de negocio? Esto traslada la responsabilidad de la actividad a los resultados.

Cuándo funcionan bien los PRD

Los PRD no están mal. Hay situaciones en las que son la herramienta adecuada.

Si construye dentro de una gran empresa regulada, con documentación y registros de auditoría obligatorios, un PRD a menudo es innegociable. Los bancos, las empresas de salud y los contratistas del gobierno necesitan un rastro documental detallado de las especificaciones. Los PRD se lo dan.

Si construye una integración compleja o un sistema con muchas dependencias y equipos, un PRD detallado ayuda a coordinar entre silos. Cuando trece equipos necesitan alinearse en un contrato de API, se necesita ese nivel de especificación.

Si está en un mercado maduro y tiene claro lo que quieren los usuarios, un PRD funciona bien. Ya validó la necesidad. Conoce a su usuario. Está optimizando la ejecución. Un PRD no estorba y le deja construir.

Si sus partes interesadas y sus ingenieros están repartidos en distintas zonas horarias y no pueden colaborar de forma iterativa, un documento escrito y completo es más eficiente que un refinamiento constante en tiempo real.

En estos contextos, los PRD son una elección sensata. Generan responsabilidad y documentación. Escalan con la complejidad. Funcionan bien.

Cuándo funcionan mejor los Intent Contracts

Un Intent Contract es la mejor opción cuando la velocidad de ejecución y la claridad sobre el resultado importan más que una especificación detallada.

Si construye algo nuevo y el comportamiento de los usuarios es incierto, necesita enfocarse en el resultado, no tener certeza sobre las funcionalidades. Un Intent Contract le permite moverse en esa incertidumbre. Sabe qué está resolviendo; mantiene la flexibilidad sobre cómo hacerlo.

Si trabaja con un socio especializado en ingeniería de producto (no con contratación de personal por demanda, sino con un equipo que asume la responsabilidad por los resultados), el Intent Contract es la forma de alinearse. Usted dice: este es el problema de negocio, esta es la métrica que importa y estas son las restricciones. Ellos encuentran el mejor camino. Cada semana se corrige el rumbo. Una especificación de 40 páginas los frenaría.

Si opera con un presupuesto ajustado, no puede darse el lujo de construir rápido lo equivocado. Un Intent Contract obliga a tener la conversación difícil sobre el alcance y sus ventajas y desventajas antes del código. Ahorra dinero porque evita que las funcionalidades crezcan sin control y que el esfuerzo se desalinee.

Si su equipo avanza rápido y aprende sobre la marcha, los PRD se vuelven documentos obsoletos. Un Intent Contract es un documento vivo. Sigue siendo relevante porque se vuelve a revisar una y otra vez, en lugar de archivarse.

Si quiere responsabilidad sobre los resultados y no solo sobre la entrega, un Intent Contract cambia la conversación. La pregunta no es: ¿lo lanzamos? Es: ¿funcionó? Ese es otro tipo de contrato.

Cómo funcionan los Intent Contracts en InTech

En InTech, tratamos el Intent Contract como la base de cada proyecto. Así encaja en nuestro proceso.

Antes de cualquier estimación de construcción, redactamos el Intent Contract junto con usted. Normalmente toma días, no semanas, y surge de la evaluación cuando la hay. No es un documento que le entregamos para que lo llene. Nosotros facilitamos el proceso. Hacemos preguntas difíciles sobre el objetivo de negocio, el contexto del usuario y cómo se ve realmente el éxito para su negocio, no solo para el producto.

El Intent Contract incluye un plan de automatización explícito que describe qué fases del trabajo usarán IA (para multiplicar la capacidad y ganar velocidad)↗ (se abre en una pestaña nueva) y dónde se requiere supervisión humana (para las decisiones que exigen criterio y los controles de calidad). Usamos la IA para redactar, investigar y hacer la implementación inicial. Mantenemos a las personas en el circuito para las decisiones de arquitectura, la síntesis de la retroalimentación de los usuarios y las decisiones de avanzar o detenerse.

Definimos un plan de telemetría que indica exactamente qué se mide después del lanzamiento. Esto le obliga a pensar en los resultados antes de salir a producción. Demasiados equipos lanzan y luego se preguntan por qué no pueden responder: ¿esto funcionó?

Declaramos el riesgo desde el principio. ¿Es de baja o de alta complejidad? ¿Qué dependencias existen? ¿Qué podría salir mal? Clasificamos el riesgo para que no haya sorpresas a mitad del proyecto.

Y definimos criterios de detención. Podemos decir: si nuestra métrica principal no se mueve para la cuarta semana, pausamos el trabajo en funcionalidades y hacemos un diagnóstico. Eso no es un fracaso. Es disciplina. Evita el escenario en el que se sigue construyendo porque ya hay un compromiso, aunque se esté resolviendo el problema equivocado.

El Intent Contract se mantiene como un documento colaborativo durante todo el proyecto. A medida que aprendemos, lo actualizamos. Cuando cambia el alcance, lo revisamos. Lo repasamos en las reuniones semanales de seguimiento. Así nos mantenemos alineados.

Conclusiones clave

Tanto los PRD como los Intent Contracts tienen valor. La elección depende de su contexto y de lo que busca optimizar.

Si busca una especificación completa y el cumplimiento regulatorio, un PRD es la herramienta adecuada. Si busca claridad sobre el resultado y velocidad de ejecución, un Intent Contract es más preciso.

Un Intent Contract obliga a tener la conversación que de todos modos debería tener. ¿Qué problema está resolviendo? ¿Por qué importa? ¿Cómo sabrá que funcionó? ¿Qué está realmente dentro del alcance? Estas preguntas importan más que cualquier lista de funcionalidades.

En un desarrollo de producto que avanza rápido, la claridad siempre le gana a la especificación exhaustiva. Un equipo con resultados claros y un alcance flexible avanzará más rápido que un equipo con una especificación perfecta y funcionalidades rígidas.

Un Intent Contract no reemplaza el buen pensamiento de producto. Pero es un mejor marco para ese pensamiento que un PRD tradicional. Lo mantiene enfocado en lo que importa.