5 fallas en proyectos de software a la medida que nadie detectó a tiempo

¿Por qué los proyectos de software a la medida fracasan antes de empezar realmente?

Las fallas de software más costosas que hemos visto en Ingenia no ocurrieron durante la implementación. Ocurrieron en la tercera semana del segundo mes, cuando alguien finalmente admitió que nunca se había validado un supuesto fundamental del proceso de ventas. El código estaba bien. Las decisiones que lo precedieron, no.

Los vicepresidentes de Operaciones suelen heredar estas fallas, más que causarlas. Para cuando el incumplimiento del plazo llega a tu escritorio, los problemas estructurales suelen tener entre seis y doce meses de antigüedad. Este artículo trata de detectarlos antes de firmar, no cuando ya estás tratando de controlar los daños.

Patrón de falla 1: un "alcance flexible" que solo era flexible en una dirección

Un alcance flexible suena razonable en una propuesta. En la práctica, casi siempre significa que el proveedor conserva el derecho de ampliar los plazos y los costos, mientras tú conservas el derecho de hacer preguntas al respecto. La flexibilidad nunca parece funcionar en la otra dirección.

El mecanismo es predecible. Un proveedor gana el proyecto con un documento de alcance general lleno de frases como "por definir durante el diagnóstico" o "sujeto a los requisitos técnicos". Llega el diagnóstico. Los requisitos aumentan, como siempre ocurre cuando los responsables reales abordan problemas reales. El proveedor presenta una estimación revisada. El monto del contrato original ahora es un mínimo, y el vicepresidente de Operaciones tiene que explicarle a Finanzas por qué el proyecto supera el presupuesto en un 40 por ciento antes de que el desarrollo haya comenzado en forma.

La señal que debes buscar antes de firmar: pídele al proveedor que te muestre los últimos tres proyectos cuyo alcance cambió sustancialmente durante el diagnóstico. Pregunta cuál fue la diferencia entre el valor original del contrato y el monto final facturado. Si no puede responder con cifras reales, o si la conversación se vuelve incómoda, ya tienes tu respuesta. Los proveedores que administran bien el alcance tienen cómo demostrarlo.

Patrón de falla 2: estructuras de hitos que ocultaban el riesgo de entrega

Los contratos basados en hitos parecen mecanismos de rendición de cuentas. Con frecuencia son lo contrario. Un hito llamado "Fase 1 terminada" puede ocultar cantidades extraordinarias de trabajo inconcluso o inestable si los criterios se redactaron con suficiente ambigüedad.

La falla clásica consiste en vincular los hitos con entregables, en lugar de resultados. "Esquema de base de datos entregado" es un hito. "Esquema de base de datos validado contra todos los endpoints de integración y sometido a pruebas de carga con el volumen proyectado" es un resultado. La mayoría de los contratos se construyen en torno al primero. El hito se marca como cumplido, se activa el pago y la deuda técnica se acumula hasta manifestarse como una falla crítica durante las pruebas de aceptación del usuario (UAT) — o, peor aún, después del lanzamiento.

Espera. Ahí debería usar una coma, no una raya.

El hito se marca como cumplido, se activa el pago y la deuda técnica se acumula hasta manifestarse como una falla crítica durante las UAT o, peor aún, después del lanzamiento.

El CHAOS Report de The Standish Group, que lleva décadas dando seguimiento a los resultados de proyectos de software, sitúa la entrega de software empresarial a tiempo y dentro del presupuesto en alrededor del 31 por ciento. La ambigüedad de los hitos contribuye de manera constante a esa cifra. Antes de firmar, lee literalmente la definición de cada hito. Pregunta qué condición permitiría al proveedor declararlo terminado. Si la respuesta es subjetiva, reescríbela o recházala.

Patrón de falla 3: transferencias de arquitectura sin un responsable interno

Esto ocurre constantemente en entornos industriales B2B y empresariales donde los recursos de TI están al límite. Un proveedor entrega una aplicación a la medida. La arquitectura funciona, está razonablemente bien documentada y utiliza una plataforma tecnológica que el proveedor conoce bien. El problema es que nadie en el equipo interno del cliente la entiende lo suficiente para hacerse cargo de ella.

Cuando termina la relación con el proveedor, o cuando su ingeniero clave deja la cuenta, el cliente queda, en la práctica, atado a él. Los cambios menores exigen volver a contratar al proveedor. Clasificar errores implica explicarle el sistema a alguien que no lo construyó. Las decisiones de infraestructura se posponen porque nadie dentro de la empresa tiene el contexto para evaluarlas con confianza. A veces esto se denomina "dependencia indirecta del proveedor", y es más común que la dependencia directa (plataformas propietarias, API cerradas).

La solución no es complicada, pero exige disciplina. Antes de iniciar el proyecto, identifica a la persona interna que será responsable de la arquitectura de este sistema. Esa persona debe participar en las revisiones de diseño, los registros de decisiones de arquitectura (ADR) y las conversaciones sobre infraestructura, no solo en las demostraciones de cada sprint. Si no cuentas con esa persona, incluye el costo de contratarla o formarla en el costo total del proyecto. Nuestro trabajo de desarrollo de software en Ingenia incluye hitos explícitos de transferencia de conocimiento precisamente por esta razón. Requiere tiempo al principio. Ahorra mucho más al final.

Patrón de falla 4: integraciones prometidas antes de completar el diagnóstico

El software a la medida en entornos empresariales casi nunca funciona de forma aislada. Se integra con un ERP, un CRM, un almacén de datos, un sistema de manufactura heredado o alguna combinación de los cuatro. La complejidad de las integraciones es donde las estimaciones de los proyectos se desmoronan y donde las promesas de los proveedores suelen ser más optimistas y menos defendibles.

El patrón es el siguiente: durante el proceso de ventas, el proveedor confirma que puede integrarse con tu ERP. Lo que realmente ha confirmado es que antes se ha integrado con el producto de ese proveedor de ERP, probablemente en otra versión, sobre la infraestructura de otro cliente y con un modelo de datos distinto. El trabajo real de integración, incluidos los endpoints específicos de la API, los protocolos de autenticación, el mapeo de datos entre esquemas, los límites de solicitudes y la lógica de manejo de errores, no se ha dimensionado porque aún no se ha realizado el diagnóstico.

Una encuesta de MuleSoft de 2023 encontró que las organizaciones administran un promedio de 976 aplicaciones y que la complejidad de las integraciones es la principal razón por la que se estancan los proyectos digitales. Esa cifra tiende a ser mayor en los entornos de energía y manufactura de Texas y de toda la costa del Golfo, donde la tecnología operativa heredada convive con infraestructura moderna en la nube en configuraciones que, por decirlo amablemente, acumulan capas históricas.

El punto de la lista de verificación es específico: ninguna integración debe aparecer como "incluida" en un contrato que se firme antes de una sesión de diagnóstico técnico con acceso a la documentación real de tus sistemas. Si un proveedor está dispuesto a cotizar una integración con un ERP antes de conocer su configuración, o tiene mucha experiencia con tu configuración exacta (pídele que lo demuestre) o está cotizando con optimismo y planea negociar después. Nuestros proyectos de soluciones de IA tratan el diagnóstico de integración como un entregable independiente antes de finalizar cualquier estimación de desarrollo. Es gestión de riesgos, no burocracia.

Patrón de falla 5: contratos de precio fijo que castigaban el cambio

Los contratos de precio fijo atraen a los vicepresidentes de Operaciones por razones obvias. La certidumbre presupuestaria tiene un valor real. El problema es que, en el contexto del software a la medida, estos contratos suelen convertir los cambios legítimos del negocio en negociaciones contractuales conflictivas.

Los requisitos del software cambian. A veces por una mala planeación, pero sobre todo porque las empresas operan en entornos reales donde las prioridades cambian, las exigencias regulatorias evolucionan y los usuarios interactúan con las primeras versiones de formas que revelan nuevos requisitos. Un contrato de precio fijo sin un proceso de órdenes de cambio claro y ágil crea incentivos negativos para ambas partes. El proveedor se resiste a aclarar el alcance porque absorbe el costo. El cliente evita plantear inquietudes legítimas porque teme iniciar una conversación sobre una orden de cambio. Ambas partes terminan tomando decisiones poco convenientes para proteger sus respectivas posiciones.

Esto no significa que los contratos de precio fijo sean categóricamente incorrectos. Significa que el mecanismo de gestión de cambios dentro del contrato importa tanto como el precio base. Antes de firmar, plantea un supuesto: "Supongamos que en el tercer mes descubrimos que un flujo de trabajo central debe cambiar a partir de las pruebas con usuarios. Explícame exactamente qué pasa según este contrato". Esa respuesta te dice más sobre la relación de trabajo que el plan del proyecto.

Los contratos por tiempo y materiales tienen sus propios riesgos, principalmente que transfieren todo el riesgo de costos al cliente y pueden desviarse sin una supervisión sólida. La estructura que suele funcionar mejor para los proyectos empresariales es híbrida: alcance fijo para las fases bien comprendidas, T&M con un tope para el diagnóstico y la integración, y umbrales explícitos para órdenes de cambio que no requieran escalar a la dirección los ajustes menores. Conviene analizar esto junto con tu estrategia general de crecimiento empresarial y operaciones, porque la estructura contractual de un proyecto de software debe reflejar la madurez operativa del negocio, no solo las preferencias del equipo jurídico del proveedor.

¿Cómo es realmente una relación de trabajo bien planteada?

Un proveedor con el que vale la pena firmar puede explicar sus patrones de falla. Sabe dónde se debilita su proceso, qué condiciones crean riesgos y qué hace al respecto. Los proveedores que solo presentan historias de éxito durante la evaluación no han hecho el trabajo interno necesario para entender su propia confiabilidad.

Solicitudes específicas antes de firmar con cualquier socio de desarrollo de software a la medida:

Un análisis retrospectivo completo de un proyecto que excedió el presupuesto o el plazo, con el análisis del propio proveedor sobre lo que salió mal
Referencias de clientes cuyos requisitos cambiaron sustancialmente a mitad del proyecto y detalles sobre cómo lo manejó el proveedor
Documentación que muestre cómo su equipo gestiona la transferencia de conocimiento sobre la arquitectura
Una explicación clara y por escrito de cómo se define el alcance y se cotizan las integraciones antes de terminar el diagnóstico

Si esas solicitudes generan una actitud defensiva en lugar de documentación, eso también es información.

La lista de verificación que realmente necesitan los vicepresidentes de Operaciones

Redacción del alcance: Encuentra cada aparición de "por definir", "sujeto al diagnóstico" o "flexible" en el contrato. Cada una es un posible punto de incremento de costos. Exige definiciones específicas antes de firmar.
Criterios de los hitos: Lee literalmente cada hito. Pregunta cuál es la condición mínima aceptable para que el proveedor lo declare terminado. Si es subjetiva, hazla objetiva.
Responsable interno de arquitectura: Designa a la persona de tu equipo que estará a cargo del sistema antes de firmar el contrato. Si esa persona no existe, presupuéstala.
Definición del alcance de las integraciones: No se debe cotizar ninguna integración antes de una sesión de diagnóstico técnico que tenga a la mano la documentación real de tus sistemas.
Mecanismo de gestión de cambios: Recorre un escenario de cambio antes de firmar. Entiende el proceso exacto, el costo y la ruta de escalamiento antes de necesitarlos.
Historial de fallas del proveedor: Pide un análisis retrospectivo de un proyecto que no salió bien. Presta más atención a cómo lo cuenta que a lo que dice.

Ninguno de estos puntos supone una revisión extraordinaria. La mayoría no se realiza porque el proceso de ventas genera presión de tiempo y una inercia social que hace parecer que las preguntas rigurosas entorpecen el avance. No es así. Son parte del trabajo.

La orden de cambio de $40,000 que aparece en el cuarto mes de un proyecto de seis meses casi siempre se remonta a una pregunta que nadie hizo en el primer mes.

Ingenia es una agencia de marketing digital y desarrollo de IA con sede en Houston, Texas, que atiende a clientes industriales B2B, del sector energético y empresariales. Si estás evaluando un proyecto de software a la medida y quieres una segunda opinión sobre su estructura técnica y contractual antes de firmar, ponte en contacto con nuestro equipo.