Guía para identificar el momento en que mantener la relación con un proveedor de desarrollo cuesta más que cambiarlo: señales de alerta, criterios de decisión, y cómo hacer la transición sin poner en riesgo la operación.
Cambiar de proveedor tecnológico no es una decisión que se tome a la ligera. Implica costos de transición, riesgo operativo, y la incertidumbre de si el nuevo equipo va a ser mejor que el anterior. Por eso muchas empresas postergan el cambio incluso cuando ya tienen claro que la relación no funciona: el costo de cambiar es visible e inmediato, mientras que el costo de no cambiar es difuso y se acumula de a poco.
Pero mantener un proveedor inadecuado también tiene costos. Proyectos que no avanzan, oportunidades de negocio que se pierden por falta de capacidad técnica, productos que llegan tarde al mercado o con una calidad que aleja clientes. La pregunta no es si cambiar tiene costo —lo tiene—, sino si el costo de no cambiar es mayor. Este artículo ofrece criterios para tomar esa decisión con los ojos abiertos.
No toda insatisfacción con un proveedor justifica un cambio. Pero hay un conjunto de señales que, cuando aparecen de manera sostenida, indican que la relación está generando más daño que valor:
Los plazos se incumplen sistemáticamente. Un retraso puntual puede tener mil explicaciones legítimas. Pero cuando cada hito se posterga, y las nuevas fechas también se incumplen, el problema no es de estimación: es de capacidad de ejecución o de compromiso con el proyecto.
La calidad del trabajo es inferior a lo esperado. Bugs que se repiten, funcionalidades que fallan en producción, código que cada vez es más difícil de mantener. La calidad no debería ser negociable, y cuando se deteriora de manera persistente, es una señal de que el equipo no está a la altura —o de que ya no le interesa estarlo—.
La comunicación se ha deteriorado. El proveedor responde tarde, no informa proactivamente sobre bloqueos, y las conversaciones se vuelven defensivas en lugar de colaborativas. Cuando la comunicación se rompe, los problemas técnicos se amplifican porque nadie los detecta a tiempo.
El equipo asignado rota constantemente. En todo equipo hay rotación. Pero si cada dos meses cambian las personas que trabajan en el proyecto, el conocimiento se pierde y cada nuevo integrante arranca de cero. El cliente termina pagando por la curva de aprendizaje una y otra vez.
El proveedor no aporta valor más allá de programar. Un buen proveedor tecnológico no solo escribe código: propone mejoras, alerta sobre riesgos, sugiere alternativas. Si el proveedor se limita a ejecutar lo que se le pide sin agregar criterio, la empresa está pagando por manos, no por cabeza.
Todo proyecto tiene semanas malas, desacuerdos y momentos de frustración. La diferencia entre un problema puntual y uno estructural es la persistencia. Una señal de alerta que aparece una vez puede ser un accidente. La misma señal repitiéndose durante dos o tres meses seguidos probablemente sea un patrón.
El costo de mantener un proveedor inadecuado no siempre es obvio porque se manifiesta como costo de oportunidad: lo que la empresa deja de ganar, no lo que pierde directamente. Algunos de esos costos:
Antes de tomar la decisión, conviene hacerse algunas preguntas:
¿El problema es el proveedor o es el proyecto? A veces lo que falla no es el equipo de desarrollo sino la definición del proyecto: alcance poco claro, requerimientos cambiantes, expectativas irreales. Cambiar de proveedor sin corregir esos problemas es cambiar de ejecutor para repetir los mismos resultados.
¿Se intentó corregir la relación? Antes de romper, vale la pena tener una conversación franca donde se expliciten los problemas, se acuerden expectativas concretas de mejora y se defina un plazo para evaluar resultados. Si el proveedor no muestra mejoras después de esa conversación, la decisión es más clara.
¿Cuál es el costo y el riesgo de la transición? Cambiar de proveedor implica que el nuevo equipo va a necesitar tiempo para entender el sistema actual —y eso cuesta dinero—. También implica riesgo operativo durante la transición. Conviene tener un plan de transición antes de comunicar la decisión.
¿Están dadas las condiciones para una transición ordenada? La empresa debe tener acceso al código fuente, a las cuentas de infraestructura y a la documentación del sistema. Si el proveedor actual es el único que tiene las llaves, la transición va a ser más difícil —y ese es un error que conviene no repetir con el próximo proveedor—.
Una forma de evaluar la situación es preguntarse: si hoy estuviéramos empezando el proyecto desde cero, ¿volveríamos a elegir a este proveedor? Si la respuesta honesta es no, entonces la pregunta relevante no es si conviene cambiar, sino cuándo y cómo hacerlo de la manera menos disruptiva posible.
Una vez tomada la decisión, la transición debería manejarse con cuidado para minimizar el impacto en la operación:
No quemar el puente antes de cruzarlo. Comunicar la decisión al proveedor actual antes de tener al nuevo equipo listo para empezar puede dejar el sistema sin mantenimiento durante la transición. Lo recomendable es seleccionar al nuevo proveedor, acordar fechas de inicio, y recién entonces comunicar la salida.
Pedir un traspaso ordenado. El proveedor saliente debería entregar documentación actualizada, transferir el acceso a todas las cuentas y servicios, y hacer sesiones de traspaso con el nuevo equipo. Si el contrato original no contemplaba esto, puede requerir una negociación —y posiblemente un pago adicional—. Vale la pena: un traspaso desordenado le cuesta al nuevo equipo semanas o meses de ingeniería inversa sobre el código existente.
Planificar un período de solapamiento. Idealmente, el equipo saliente y el entrante coexisten durante algunas semanas. El nuevo equipo aprende del que se va, entiende las decisiones técnicas que se tomaron, y empieza a operar con algo de supervisión. Esto reduce el riesgo de que cosas importantes se pierdan en la transición.
El artículo sobre cómo retomar un proyecto desarrollado por otro equipo detalla lo que el nuevo proveedor necesita para arrancar con buen pie, y el artículo sobre cómo evitar depender completamente de un proveedor tecnológico explica cómo evitar que la próxima relación termine en la misma situación.
Cambiar de proveedor tecnológico no es un fracaso. Es, en muchos casos, una decisión de negocio responsable: reconocer que lo que funcionó en una etapa ya no funciona en la siguiente, y actuar en consecuencia antes de que el costo de la inacción sea mayor que el costo del cambio.
¿Quieres evaluar cómo aplicar esto a tu proyecto?
Cuéntanos tu caso →