Build only the gap

Construir no demuestra por sí solo que se aporte valor

El desarrollo produce resultados visibles: una interfaz, una integración, una función que antes no existía. Esa visibilidad puede hacer que se mida el progreso por lo que se ha creado, aunque parte de ese trabajo replique capacidades disponibles.

La cuestión relevante es qué impedía resolver el problema. Si una función estándar ya cumple las condiciones necesarias, reconstruirla necesita una razón adicional. Puede haberla: restricciones de integración, necesidad de control o un coste de adopción desproporcionado. Pero debe hacerse explícita.

También conviene distinguir familiaridad de conveniencia. Un equipo puede construir una pieza porque conoce cómo hacerlo y subestimar el trabajo posterior de mantenerla. Otro puede adoptar una plataforma conocida sin comprobar si su configuración encaja con el uso concreto.

Ninguna preferencia sustituye al análisis del trabajo. La decisión debe comparar lo que requiere construir con lo que requiere adoptar: configuración, integración, revisión, formación y evolución. La entrega inicial solo representa una parte de esa comparación.

Esta perspectiva cambia la conversación sobre personalización. Que una empresa tenga una forma particular de operar no significa que necesite componentes propios en todas las capas. Puede necesitar una combinación específica de piezas comunes y una intervención pequeña en una frontera decisiva.

El valor de la ingeniería aparece al reconocer esa frontera. Una solución puede contener poco desarrollo propio y exigir mucho criterio. También puede justificar un componente sustancial si resuelve una necesidad que las alternativas no cubren de forma mantenible.

Lo existente debe comprobarse en el contexto real

Antes de definir una diferencia conviene conocer qué capacidades están realmente disponibles. Esto incluye las aplicaciones que la empresa ya utiliza, sus funciones configurables y las posibilidades de integración que todavía no ha aprovechado.

Una capacidad puede existir sin estar habilitada o sin encajar con el procedimiento actual. En esos casos, parte del trabajo consiste en configurarla o ajustar la operación, no necesariamente en construir otra aplicación.

Sin embargo, una coincidencia de nombres no demuestra que una función resuelva la necesidad. «Aprobaciones», «memoria» o «automatización» pueden describir comportamientos muy distintos. Hay que comprobar qué condiciones admiten, qué información conservan y qué ocurre fuera del recorrido más sencillo.

Esa revisión debe considerar también los límites de uso. Una función puede servir para preparar trabajo y resultar insuficiente para ejecutarlo. Puede cubrir una parte del volumen o necesitar intervención en casos que la empresa considera habituales.

El objetivo no es hacer un inventario exhaustivo del mercado. Es identificar alternativas plausibles y contrastarlas con los requisitos que podrían cambiar la decisión. La búsqueda debe terminar cuando existe evidencia suficiente para escoger, no prolongarse hasta encontrar una herramienta aparentemente perfecta.

Lo existente merece la misma exigencia que lo propio. Adoptar una capacidad sin probar su encaje puede ocultar trabajo de integración; descartarla por no coincidir exactamente con la primera idea del proyecto puede provocar una construcción innecesaria.

La diferencia debe expresarse como una condición incumplida

Una necesidad de desarrollo se vuelve más clara cuando puede formularse sin nombrar la solución. Qué resultado falta, qué condición no se cumple o qué responsabilidad queda sin resolver.

«Necesitamos una plataforma propia» anticipa una respuesta. «El trabajo pierde su estado al pasar entre estas aplicaciones» describe un problema que admite varias intervenciones. Puede requerir una integración, un cambio de configuración o una modificación de la forma de trabajar.

La diferencia también puede estar en un control. Quizá las herramientas existentes permiten ejecutar acciones, pero ninguna aplica una condición de autorización específica del proceso. Resolver esa condición puede tener más valor que crear una interfaz nueva sobre funciones que ya están cubiertas.

No toda particularidad merece preservarse. Algunas diferencias proceden de decisiones antiguas que ya no aportan valor. Construir para mantenerlas puede consolidar complejidad que la organización tendría la oportunidad de eliminar.

Por eso, el análisis debe distinguir necesidades justificadas, preferencias y hábitos. Una preferencia puede aceptarse si su coste resulta razonable, pero no debería presentarse como una obligación técnica. Esa distinción ayuda a evitar que el alcance crezca por acumulación de excepciones.

Una diferencia bien definida tiene un criterio de cierre. Permite saber cuándo el desarrollo ha resuelto la condición pendiente y cuándo una nueva petición pertenece a otro problema. Sin esa frontera, «construir lo que falta» puede convertirse en una ampliación indefinida del sistema.

La integración y la responsabilidad también son trabajo

Dos componentes pueden funcionar correctamente por separado y dejar un problema en su relación. Pueden interpretar de forma distinta un identificador, una cancelación o el momento en que una tarea se considera terminada.

Ese trabajo de integración no es un residuo menor del proyecto. Puede ser precisamente la diferencia que necesita ingeniería propia. Su utilidad procede de conservar el significado del trabajo al atravesar varias piezas, no de introducir una función llamativa.

También hay responsabilidades que permanecen en la organización aunque se utilicen servicios gestionados. El modelo de responsabilidad compartida de AWS lo muestra en su ámbito de seguridad: las tareas del cliente varían según el servicio elegido, y adoptar servicios gestionados no elimina todas sus obligaciones sobre datos y permisos.

La lección para el alcance del proyecto es acotada: hay que identificar lo que sigue correspondiendo a quien utiliza la solución. No se puede inferir de la palabra «gestionado» que el resultado completo tenga un responsable externo.

La propia evaluación puede formar parte de esa responsabilidad retenida. Una herramienta ofrece una capacidad, pero alguien debe comprobar si su combinación con el resto del sistema sigue resolviendo el trabajo. Construir esa comprobación puede ser necesario aunque ninguna funcionalidad visible sea original.

Por tanto, construir solo la diferencia no significa entregar solo un conector y dejar sin resolver la operación. Significa cubrir la parte necesaria que las demás piezas no cubren, incluidos los controles y la evidencia que permiten hacerse cargo del conjunto.

Comprar y construir generan compromisos diferentes

La comparación debe examinar qué esfuerzo se asume con cada opción. Construir introduce mantenimiento del código y de sus dependencias. Adoptar incorpora configuración, integración y decisiones sobre cómo convivir con la evolución de otra solución.

Ninguna de esas alternativas queda libre de trabajo posterior. Lo que cambia es su distribución y la capacidad necesaria para atenderlo. Una opción puede ser más adecuada porque el equipo sabe mantenerla, aunque su coste inicial no sea el menor.

También debe considerarse cuánto del desarrollo es específico y cuánto se ha añadido por conveniencia. Una integración puede empezar resolviendo una necesidad concreta y terminar incorporando administración, permisos y pantallas que una pieza existente ya ofrece.

La fragmentación excesiva plantea el problema contrario. Elegir muchas herramientas pequeñas para evitar desarrollo puede aumentar el número de relaciones que hay que mantener. La solución con menos código propio no es necesariamente la de menor complejidad operativa.

Por eso, la unidad de comparación debe ser el servicio completo. Interesa qué necesita la empresa para usarlo, comprobarlo y corregirlo durante su vida útil. Las estimaciones deberían distinguir costes conocidos y supuestos, sin presentar como ahorro demostrado lo que todavía depende del uso.

La decisión puede combinar caminos. Adoptar una capacidad estándar, configurar otra y construir una integración específica no es una solución intermedia por falta de ambición. Puede ser la forma más precisa de asignar esfuerzo a lo que realmente necesita atención.

Construir una diferencia no obliga a sustituirlo todo

Una necesidad nueva puede incorporarse sin reconstruir toda la base existente. Cuando las fronteras lo permiten, una intervención acotada facilita comprobar el valor y aprender antes de ampliar el cambio.

La coexistencia, sin embargo, requiere saber qué parte del trabajo corresponde a cada sistema. No basta con mantener dos aplicaciones disponibles. Hay que evitar que ambas actúen sobre la misma responsabilidad sin un criterio claro.

El patrón Strangler Fig documentado por Microsoft describe una sustitución gradual de funciones mientras el sistema anterior sigue atendiendo las que aún no se han migrado. Es un patrón de modernización, no una obligación para cualquier proyecto de IA. Ilustra que el alcance del cambio puede delimitarse por funciones en lugar de asumir una sustitución completa desde el principio.

En una intervención más pequeña, la decisión puede ser conservar una aplicación y cubrir una carencia concreta alrededor de ella. Lo importante es conocer qué relación seguirá existiendo y qué trabajo adicional introduce esa convivencia.

También conviene definir cuándo una pieza provisional debe retirarse. Una integración temporal puede convertirse en infraestructura permanente si nadie conserva el criterio que justificaba su existencia. Su mantenimiento empieza entonces a consumir recursos sin que se haya tomado expresamente esa decisión.

La ampliación debería responder a evidencia sobre nuevas necesidades. Si la primera intervención cumple su función, eso no demuestra que convenga absorber las demás. Cada crecimiento del alcance necesita explicar qué problema adicional resuelve y qué responsabilidad añade.

La diferencia cambia con el tiempo

Lo que hoy necesita construcción propia puede estar disponible más adelante como una capacidad adecuada. También puede ocurrir lo contrario: una solución adoptada deja de cubrir las condiciones del trabajo y exige una adaptación.

Mantener el criterio requiere revisar por qué existe cada componente propio. Si su razón ha desaparecido, conservarlo solo porque costó construirlo puede perpetuar trabajo innecesario. Retirarlo tampoco es gratuito: hay que valorar la transición y el comportamiento que debe preservarse.

La pregunta no es si otra herramienta ofrece una función parecida. Es si permite resolver la misma necesidad con condiciones aceptables y un esfuerzo total más conveniente. Esa revisión evita tanto la sustitución constante por novedad como la permanencia por inercia.

Conviene que cada desarrollo conserve una justificación comprensible: qué condición cubre, qué alternativas se descartaron y qué cambio haría razonable reconsiderarlo. No necesita una documentación extensa, pero sí una relación visible con el trabajo que sostiene.

Build only the gap es, por tanto, una disciplina de alcance durante toda la vida del sistema. Permite construir cuando hace falta, aprovechar lo que ya existe y retirar lo que deja de aportar. La medida de éxito es el trabajo resuelto con responsabilidades claras, no la cantidad de software que queda bajo autoría propia.