Claridad antes del código

Por qué la claridad es más difícil de lo que parece

La mayoría de los equipos cree saber qué está construyendo. Lo que a menudo no sabe es qué problema está resolviendo.

Hay una brecha entre "necesitamos una funcionalidad que haga X" y "necesitamos llevar el comportamiento de nuestros usuarios en la dirección Y, medido por Z, porque eso resuelve el problema A". En esa brecha vive el retrabajo.

Las partes interesadas pueden describir funcionalidades sin parar. Definir un resultado medible es más difícil. Exige decidir qué importa y aceptar qué no. La mayoría de las organizaciones evita esa decisión todo lo que puede. En su lugar, escribe largas listas de funcionalidades. Las listas de funcionalidades se sienten concretas. Se sienten como un avance. Pero no son alineación.

Luego está la velocidad. Los equipos con una intención poco clara pueden empezar a construir de inmediato. Eso se siente más rápido que dedicar tiempo a la claridad. Durante unas semanas, sí es más rápido. Luego empieza el ciclo de retrabajo. Los diseños no coinciden con la intención. Las especificaciones cambian a mitad del desarrollo. Lo que parecía tiempo ahorrado en la primera semana se convierte en tiempo perdido en la cuarta. La falacia del costo hundido mantiene el proyecto en la dirección original, aunque todos ya saben que es equivocada.

En un modelo de entrega tradicional, este retrabajo toma semanas. En un entorno acelerado por IA↗ (se abre en una pestaña nueva), la construcción desalineada ocurre en días. El ciclo de retrabajo es más corto y más caro, porque la velocidad hizo que la dirección equivocada pareciera legítima. Se construyó rápido. Debe estar bien.

No lo está.

El Intent Contract: cómo la claridad queda por escrito

La claridad necesita un mecanismo. En InTech, ese mecanismo es el 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. Tampoco es una especificación ni una lista de requisitos. Es una declaración compartida de qué significa el éxito antes de empezar a construir, escrita en un lenguaje sencillo que tanto las partes interesadas del negocio como los ingenieros pueden leer y aprobar.

Redactar uno bueno implica responder cinco preguntas:

¿Cuál es el objetivo de negocio? No la funcionalidad. El resultado que persigue el negocio. "Necesitamos reducir el volumen de soporte por restablecimiento de contraseñas", "Necesitamos que los usuarios pasen más tiempo en la sección de analítica" o "Necesitamos migrar a los equipos de los sistemas heredados a la nueva plataforma".

¿Cuál es la métrica de resultado principal? El único resultado medible que demuestra el éxito. "Los tickets de soporte por restablecimiento de contraseñas disminuyen 40 por ciento", "El tiempo en la sección de analítica aumenta a un promedio de 8 minutos por sesión" o "El 80 por ciento de los equipos activos completó la migración en un plazo de 90 días". Tiene que ser observable y real.

¿Qué está explícitamente dentro del alcance y qué queda fuera? Suena obvio. Rara vez lo es. Los límites del alcance evitan las conversaciones de "ya que estamos" que inflan los proyectos. No son restricciones que limitan el pensamiento. Son acuerdos que protegen el plazo. Si la lista de lo que queda fuera del alcance no está escrita, terminará dentro del alcance durante el desarrollo.

¿Cuál es el contexto del usuario y qué cambio de comportamiento se espera? ¿Cómo cambia el mundo cuando esto esté terminado? ¿Quién lo usa, en qué contexto y qué hace distinto después? Esto conecta la funcionalidad con el resultado.

¿Cuáles son los criterios de aceptación y los criterios de cancelación? Los criterios de aceptación definen cuándo algo está terminado. Los criterios de cancelación definen cuándo detenerse. Es la parte más difícil de escribir, porque exige que la organización admita que algunos caminos podrían no funcionar. Un criterio de cancelación podría ser "si descubrimos que la métrica de fondo no puede moverse más de 15 por ciento, revisamos el enfoque". Suena pesimista. En realidad es optimista. Evita los proyectos zombi que siguen consumiendo recursos en busca de una hipótesis fallida.

El Intent Contract no es un predictor perfecto. No puede serlo. El futuro es incierto. Pero establece una línea base de entendimiento compartido. Cuando surgen desacuerdos durante el desarrollo (y siempre surgen), hay una fuente de verdad escrita a la cual remitirse.

Cómo funciona en la práctica: el Express Pod

En InTech, este principio está incorporado en el Express Pod. Un Express Pod lleva una mejora medible a producción en cuestión de semanas, con el plazo acordado en el Intent Contract antes de empezar a construir.

La primera etapa de un Express Pod, Alinear, está dedicada por completo a la claridad. Nada de iteraciones de diseño. Nada de prototipos. Nada de código. El Product Delivery Lead, el equipo de ingeniería y las partes interesadas del negocio trabajan juntos en el Intent Contract. Se hacen preguntas. Se ponen a prueba los supuestos. El alcance se reduce y se cierra. Se define la métrica.

Nada pasa a construcción hasta que se aprueba el Intent Contract.

Este enfoque se siente lento al inicio. La mayoría de las organizaciones preferiría empezar a construir de inmediato. Pero la estructura fija una fecha límite para la claridad. No existe la opción de ser vago. La vaguedad se hace visible por escrito, y la vaguedad visible se resuelve antes de que empiece el desarrollo.

El resultado: una vez que empieza la construcción, el equipo ya resolvió la mayoría de las conversaciones que normalmente estarían dispersas a lo largo de un proyecto de seis meses. El trabajo de ingeniería se vuelve traducción e implementación, no descubrimiento y retrabajo.

Esto no se debe a que el equipo sea perfecto o clarividente. Se debe a que el contrato de claridad obliga a pensar a fondo desde temprano. El costo de equivocarse se paga al inicio, en tiempo de conversación, y no después, en retrabajo de código.

Qué pasa sin claridad: cómo fallan los proyectos

Cuando la claridad se omite o se apresura, los proyectos de software fallan siguiendo patrones predecibles.

Crecimiento descontrolado del alcance y listas interminables de funcionalidades. Sin límites explícitos del alcance, cada parte interesada agrega prioridades. El "producto mínimo viable" se convierte en un producto medianamente viable y luego en un producto máximamente viable. El plazo sigue igual. El equipo se agota.

Ciclos de retrabajo. El trabajo de diseño se rechaza porque no coincide con expectativas que nadie expresó. El trabajo de desarrollo se cuestiona porque el objetivo de negocio en realidad nunca se puso por escrito. Los diseños se revisan. El código se refactoriza. El equipo siente que avanza, pero la distancia al lanzamiento no deja de aumentar.

Construir lo equivocado con total confianza. La peor forma de fallar es avanzar rápido hacia el destino equivocado. El equipo entrega a tiempo. A las partes interesadas les encantan las funcionalidades. Seis meses después, nadie lo usa. O no mueve la métrica de negocio que supuestamente importaba. El problema nunca fue que el equipo no pudiera construir. El problema fue que el equipo construyó algo que, para empezar, nadie necesitaba.

La IA acelera el trabajo en la dirección equivocada. En un entorno de desarrollo asistido por IA↗ (se abre en una pestaña nueva), el trabajo en la dirección equivocada se desvía más rápido. Un ingeniero puede usar IA para crear el prototipo de una funcionalidad en un día. Eso se siente como una validación. No lo es. Un prototipo construido en la dirección equivocada sigue estando equivocado. Pero el efecto del costo hundido se vuelve más fuerte. Lo construyeron rápido. Debe estar bien. Hay que lanzarlo.

Por qué esto importa en la era de la IA

El software siempre ha sido caro de cambiar una vez construido. Pero los cambios eran lo bastante lentos como para crear pausas naturales para reflexionar.

En la era de la IA, no hay pausas naturales. Los equipos pueden pasar de la idea a la producción en días. Eso es bueno para construir más rápido lo correcto. Es catastrófico para construir lo equivocado.

El antídoto es poner el trabajo de claridad en el mismo calendario que el trabajo de construcción. Si va a avanzar rápido, primero tiene que tener clara la dirección. La velocidad sin claridad no se siente riesgosa. Se siente productiva. Esa es la parte peligrosa.

Claridad antes del código no significa avanzar más lento. Significa avanzar bien. El equipo que dedica unos días a la alineación y luego construye lo correcto lanza antes que el equipo que empieza construyendo lo equivocado y pasa semanas corrigiéndolo.

Principios clave

La verdad compartida es un requisito previo para la velocidad. No se puede paralelizar el trabajo de ingeniería si las personas no están de acuerdo en qué están construyendo. El equipo entrará en conflicto. El retrabajo se acumulará.

La claridad se escribe, no se dice. Las conversaciones se olvidan. Los Intent Contracts escritos permanecen. Son la referencia cuando los recuerdos no coinciden.

Los límites del alcance son protección, no limitación. Decir lo que no está incluido evita que el proyecto se expanda. El equipo puede concentrarse sin negociar prioridades a cada momento.

Las métricas de resultado son innegociables. Si no puede definir cómo sabrá si esto funcionó, en realidad no ha definido qué está construyendo. Las listas de funcionalidades no son resultados.

La organización tiene que decidir qué importa. La claridad exige concesiones. Si el negocio no elige qué es lo más importante, el equipo no puede construir en esa dirección.