Señales de que tu proveedor de software te está fallando (y qué hacer)

Casi nadie despierta un día y descubre que su proveedor de software es malo. Lo que pasa es más lento: una entrega que se corre "una semanita", una demo que funciona solo con el computador del desarrollador, una factura que sube sin que nadie pueda decir qué se hizo. Para cuando el gerente se da cuenta, hay meses invertidos y una duda incómoda: ¿lo corto, o le doy una oportunidad más? Este artículo es para ayudarte a detectar las señales temprano y a reaccionar con método, no con rabia.

Antes de culpar: qué es un problema y qué es ruido

Todo proyecto de software tiene atrasos, cambios de alcance y días malos. Eso no es una señal de alerta. La diferencia entre un proyecto con roces normales y uno que se está cayendo es si el problema se ve, se explica y se corrige. Un proveedor que dice "nos atrasamos por X, esto hacemos y esta es la nueva fecha" está trabajando. Uno que evita la conversación, cambia de tema o responde con tecnicismos para no responder, te está mostrando algo más grave.

Las siete señales que no debes ignorar

1. Las entregas no tienen evidencia. Te dicen "ya está listo" pero no hay demo en un ambiente que tú puedas abrir, ni acta, ni lista de lo entregado. Si no puedes tocarlo, no está entregado.
2. El avance se mide en horas, no en funcionalidades. Los informes dicen "240 horas trabajadas" pero no qué se puede hacer hoy en el sistema que ayer no se podía. Las horas son un costo, no un resultado.
3. No ves el código ni el ambiente. El repositorio es "interno", los accesos "los tenemos nosotros" y el servidor está a nombre del proveedor. Es la señal más cara de ignorar, porque es la que más te ata si quieres cambiarte.
4. Los plazos se mueven siempre, y siempre sin explicación. Un atraso aislado es vida normal. Tres consecutivos con la misma excusa vaga ("complejidad inesperada") indican que nadie está controlando el proyecto.
5. Rotación constante del equipo. Cada reunión aparece una cara distinta que pregunta lo mismo que ya explicaste. Tu conocimiento del negocio se pierde y el proveedor reinicia el aprendizaje a tu costa.
6. Los errores vuelven. Se corrige un problema y reaparece a las dos semanas, o arreglar una cosa rompe otra. Suele indicar que no hay pruebas ni revisión de calidad, y eso solo empeora con el tiempo.
7. Todo "pasa a la fase 2". Lo difícil o lo incómodo se posterga, y lo fácil y vistoso se entrega primero. Así llegas al final con una demo bonita y un sistema que no resuelve tu problema operativo.

Un ejemplo que se repite en el sur

Una distribuidora de insumos agrícolas de la Araucanía contrató un sistema de pedidos para sus vendedores en terreno. A los cuatro meses el proveedor mostraba pantallas y avances en porcentajes, pero los vendedores aún no podían ingresar un pedido real. Cuando la empresa pidió acceso al repositorio, la respuesta fue que "no era necesario". Sin código, sin acta de entregas y con el servidor a nombre del tercero, cambiar de proveedor significaba partir de cero. No era un caso de mala fe necesariamente: era un proyecto sin supervisión, donde nadie del lado del cliente sabía qué preguntar. Y ese es el patrón de fondo: la mayoría de los proyectos fallan por falta de control, no por falta de talento.

Qué hacer cuando ves dos o tres señales

No es momento de terminar el contrato, es momento de ordenar la información. Un camino sensato:

1. Documenta antes de confrontar. Junta el contrato, las bases o la cotización original, las actas, los correos con fechas comprometidas y las facturas. Con eso tienes hechos, no impresiones.
2. Pide una demo en vivo, en un ambiente que tú controles. No una presentación: el sistema funcionando, con tus datos de prueba, operado por alguien de tu equipo. Es la prueba más honesta que existe.
3. Exige acceso al repositorio y a la infraestructura. Debe estar a tu nombre o con tu empresa como propietaria. Si hay resistencia, pide por escrito el fundamento: la negativa en sí ya es información.
4. Pon un plan de recuperación por escrito. Qué se entregará, en qué fechas, con qué criterio de aceptación. Si el proveedor es serio, lo preparará sin drama. Si no puede, tienes tu respuesta.
5. Revisa qué dice el contrato sobre salida. Propiedad del código, entrega de documentación, plazos de aviso y multas. Esto define cuánto te costaría irte, y conviene saberlo antes de tener que decidir.

Cuándo tiene sentido cortar (y cómo hacerlo sin quedar a la deriva)

Corta cuando el proveedor no puede o no quiere mostrar evidencia, cuando incumple el plan de recuperación o cuando la confianza ya no alcanza para trabajar. Pero hazlo con orden: asegura primero el código, las bases de datos, los dominios y las cuentas; exige la documentación; y arma la transición con un segundo proveedor o un tercero que revise lo existente y diga qué es rescatable. Muchas veces se salva más de lo que parece, y una revisión técnica independiente es lo que te dice qué.

Cómo evitarlo la próxima vez

La mejor defensa se instala el día uno: contrato con hitos verificables y propiedad del código a tu favor, entregas con acta, accesos a tu nombre y alguien de tu lado que sepa leer lo que se entrega. El método completo está en cómo supervisar a una empresa de desarrollo de software externa, y si todavía estás eligiendo, en cómo elegir un proveedor de software en regiones están las preguntas que conviene hacer antes de firmar.

Cómo seguir

Si tienes un proyecto en marcha y te suenan dos o más de estas señales, una revisión técnica independiente cuesta mucho menos que seguir pagando a ciegas. Eso es parte del servicio de contraparte técnica: reviso lo entregado, el contrato y el estado real del proyecto, y te digo con claridad si hay que corregir el rumbo, renegociar o cambiar de proveedor. También puedes contarme tu caso por el formulario.