Cómo definir la intención de negocio

Por qué se pierde la intención

La brecha entre la intención y la ejecución existe por la forma en que la mayoría de las organizaciones aborda el desarrollo de software.

Las partes interesadas rara vez presentan problemas. Presentan soluciones. Un fundador llega diciendo "necesitamos una aplicación móvil" antes de que alguien pregunte si una aplicación móvil es la herramienta adecuada. Un líder de operaciones pide "un mejor CRM" sin definir qué significa "mejor" en términos medibles. Un gerente de producto pide una funcionalidad antes de explicar qué resultado de negocio debería cambiar esa funcionalidad.

Los equipos responden estimando la solicitud: "Sí, podemos construir un tablero con cinco gráficos en tres semanas". Es una respuesta razonable a una mala solicitud, pero también es una garantía de decepción. El tablero se lanza, los gráficos son correctos, la calidad del código es alta y nada cambia para el negocio. El proyecto es un éxito técnico y no significa nada en lo comercial.

Definir la intención es el correctivo. Es la conversación que ocurre antes de que ingeniería estime cualquier cosa. No pregunta "¿podemos construir esto?", sino "¿deberíamos construir esto y cómo sabremos que funcionó?".

Intención vs. requisitos vs. funcionalidades

Estas tres cosas no son lo mismo, y confundirlas es lo que hace que la mayoría de los proyectos se desvíe.

Los requisitos son especificaciones de tareas. "El tablero debe mostrar datos en tiempo real". "El sistema debe soportar 10,000 usuarios simultáneos". Los requisitos son importantes para la ejecución, pero no son intención. Usted puede cumplir todos los requisitos y aun así fracasar si nadie sabía qué problema resolvía cada requisito.

Las funcionalidades son lo que se construye. Un tablero. Una función de búsqueda. Un sistema de notificaciones. Las funcionalidades son tangibles y se pueden contar, y eso las hace parecer concretas. Pero una funcionalidad que no cambia el comportamiento no es un éxito, aunque funcione perfectamente.

La intención de negocio es el resultado medible que se busca lograr. "Hoy los gerentes de campo pasan dos horas al día haciendo llamadas manuales de seguimiento a los sitios de trabajo. Necesitamos reducir esas llamadas un 50% en los 60 días posteriores al lanzamiento". Eso es intención. Incluye un usuario (los gerentes de campo), un problema (las llamadas manuales), un resultado medible (una reducción del 50%) y un plazo (60 días). Es lo bastante específica para orientar la construcción, pero no prescribe cómo construir.

La intención debe escribirse antes de decidir las funcionalidades. De hecho, una intención clara suele revelar que la funcionalidad propuesta originalmente era la solución equivocada. Una empresa puede querer "reducir las llamadas manuales", y la solución quizá no sea un tablero en absoluto. Puede ser una integración por SMS que envíe actualizaciones de estado automáticamente, un sistema de notificaciones push en una aplicación móvil o una mejor higiene de datos en el sistema de origen. La intención es estable. La solución es flexible.

Esta distinción importa porque el costo de ingeniería crece con el número de funcionalidades. El resultado logrado, no. Lo que se busca es resolver el problema con la solución más pequeña y rápida posible. Eso solo ocurre si todos saben qué intentan resolver realmente.

Cómo define InTech la intención en la práctica

En InTech Ideas, definir la intención no es opcional. Normalmente toma días, no semanas, y surge de la evaluación cuando la hay. Siempre ocurre antes de escribir una sola línea de código.

El artefacto que la recoge 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.

Del lado de la intención de negocio, redactar uno implica trabajar estos puntos:

• Objetivo de negocio - El resultado que buscamos lograr, en términos de negocio
• Métrica de resultado principal - Cómo mediremos el éxito y cuál es la meta
• Contexto del usuario - A quién afecta, cómo es su experiencia actual y qué fricción estamos atendiendo
• Cambio de comportamiento esperado - Qué será diferente para esas personas después del lanzamiento
• Límites del alcance - Qué está dentro del alcance y qué queda explícitamente fuera
• Restricciones - Presupuesto, plazos y límites técnicos u organizacionales
• Criterios de aceptación - Las condiciones medibles que definen cuándo está terminado
• Criterios de cancelación - Las métricas que nos indicarían que debemos detenernos y cambiar de rumbo

El cliente, el Product Delivery Lead y el equipo de ingeniería revisan y aprueban el Intent Contract antes de que empiece cualquier desarrollo. Es el único control de aprobación que convierte la intención en trabajo autorizado.

Un Product Delivery Lead (PDL) es responsable del resultado: gestiona la intención, los hitos y el ritmo de entrega durante todo el proyecto. La intención va primero: un PDL pregunta "¿por qué estamos construyendo esto?" antes de preguntar "¿qué estamos construyendo?". Si la intención se desvía durante el proyecto, el PDL la restablece. Si se propone un cambio de alcance, el PDL evalúa si sirve a la intención original o la compromete.

Por eso la claridad de la intención importa tanto en el desarrollo de la era de la IA. Hoy, el costo de una intención mal planteada es mayor. En un proyecto tradicional de tres meses con un equipo distribuido, una intención mal planteada se detecta en la semana seis, cuando la funcionalidad se lanza y no mueve los indicadores. Todo el equipo todavía puede corregir el rumbo. En un entorno acelerado por la IA↗ (se abre en una pestaña nueva), se puede construir lo mismo en dos semanas. Se puede construir tan rápido que nadie nota que la intención era equivocada hasta que ya se va por la tercera versión en la dirección equivocada.

La claridad antes del código no es una carga burocrática. Es la póliza de seguro que impide que la velocidad se convierta en desperdicio.

Pensar desde la intención vs. pensar desde las funcionalidades

La diferencia se hace evidente en la práctica. Tres ejemplos ilustrativos (casos compuestos, no resultados de clientes):

Empresa de suministros médicos: la solicitud original era "construir un portal para clientes". Eso es una solicitud de funcionalidad. Lo que en realidad ocurría era que entraban llamadas al servicio al cliente para preguntar por el estado de los pedidos, y eso consumía el equivalente a dos empleados de tiempo completo cada semana. La intención real era reducir esas llamadas un 60% en 90 días. Saberlo significó que la solución no era un portal completo. Era una página ligera de estado de pedidos que se podía construir y desplegar en dos semanas, más una integración de correo electrónico que enviaba de forma proactiva actualizaciones de envío. El enfoque guiado por la intención ahorró seis semanas de desarrollo y resolvió el problema 10 veces más rápido.

Firma de servicios profesionales: la solicitud era "construir un tablero de reportes". Lo que en realidad necesitaban era visibilidad sobre qué clientes estaban en riesgo de irse, con base en las métricas de utilización y la velocidad de los proyectos. El enfoque guiado por las funcionalidades habría sido un tablero genérico con todas las métricas que pidieron. El enfoque guiado por la intención fue un tablero más pequeño, con métricas de alto valor informativo y un sistema de alertas para cuando la utilización cayera por debajo de los umbrales históricos. Conocer la intención significó construir la mitad de las funcionalidades y entregar el doble de valor.

Agencia de reclutamiento: la solicitud era "necesitamos un mejor CRM". El problema que buscaban resolver era el paso manual de copiar los datos de los candidatos entre tres sistemas distintos (seguimiento de candidatos, nómina y control de horas). La solución no era un CRM nuevo. Era una integración por API que movía los datos de los candidatos una sola vez y los sincronizaba en los tres sistemas. Se construyó en tres semanas en lugar de seis meses. La intención era clara; la lista de funcionalidades era irrelevante.

En cada caso, el equipo que hizo las preguntas correctas desde el principio construyó menos, lanzó antes y creó más valor. El equipo que saltó directo a las funcionalidades construyó más, lanzó después y generó confusión.

Ideas clave

La intención no es la visión, la misión ni la estrategia. Es el contrato operativo de un solo bloque de trabajo. Es la respuesta a "¿cómo se ve el trabajo terminado y cómo lo demostramos?".

La intención no es burocracia. Es lo contrario. Definir la intención evita las reuniones, el retrabajo y las solicitudes de funcionalidades que nacen de la ambigüedad. Toma días al inicio y ahorra mucho más que eso en la ejecución.

La intención no es algo que ocurre una sola vez. Los proyectos que mantienen clara la intención de principio a fin tienen menos crecimiento descontrolado del alcance, lanzamientos más rápidos y mejores resultados. El trabajo del PDL es mantener esa claridad intacta.

La intención es lo que distingue la ingeniería de producto de la entrega de servicios. Un equipo de servicios construye lo que usted pide. Un equipo de ingeniería de producto aclara qué necesita pedir y luego construye eso.