Cómo gestionar a tu proveedor de software sin perder el control del proyecto

Gestionar a un proveedor de software es una habilidad que la mayoría de empresas medianas aprenden tarde y mal. Pagas a alguien para que construya algo crítico para tu negocio y, a los tres meses, descubres que el código no es tuyo, los plazos se han movido sin que nadie te avise y el presupuesto inicial es ya un recuerdo lejano. La culpa no siempre es del proveedor: muchas veces el problema es que la empresa cliente delegó la responsabilidad y el control al mismo tiempo, cuando en realidad debía delegar solo la primera. En Everglow llevamos años viendo proyectos que se han salvado —y otros que se han hundido— por la diferencia entre un cliente que sabe gestionar a su proveedor y uno que no.

Este post no va de desconfiar. Va de profesionalizar la relación para que tanto tú como tu proveedor podáis hacer bien vuestro trabajo. Cuando el cliente entiende qué pedir, cómo medir y dónde poner los límites, el proveedor entrega más rápido, con más calidad y con menos fricción.

Por qué pierdes el control de un proyecto de software

La pérdida de control casi nunca es un evento súbito. Es la acumulación de pequeñas decisiones que, sumadas, dejan al cliente fuera del proyecto. Estos son los patrones que más vemos:

• Contratos vagos: “desarrollo de aplicación móvil” sin alcance funcional, sin hitos, sin definición de “terminado”.
• Comunicación 100 % asíncrona y sin actas: emails sueltos, mensajes en Slack y reuniones sin notas que nadie firma.
• Métricas inexistentes: nadie sabe cuántas tareas se han cerrado esta semana ni qué porcentaje del backlog se ha entregado.
• Repositorio en manos del proveedor: el código vive en su GitHub, su servidor o su entorno cloud, sin acceso real del cliente.
• Documentación que llega “al final”: que en software suele ser un eufemismo de “nunca”.
• Stakeholder único en el cliente: una sola persona habla con el proveedor, y cuando se va de vacaciones el proyecto se para.

Perder el control no es que el proveedor sea malo. Es que tú, como cliente, no has construido los mecanismos para mantenerte en el asiento del conductor.

La buena noticia es que recuperar el control —o mejor, no perderlo nunca— es una cuestión de proceso. No necesitas un máster en gestión, necesitas decidir qué vas a exigir desde el día uno.

El contrato es la primera línea de defensa

Antes de hablar de Jira, demos o sprints, todo empieza en el contrato. Si el contrato no protege al cliente en lo básico, ningún workflow posterior te va a salvar.

Un buen contrato con un proveedor de software incluye, como mínimo:

1. Alcance funcional detallado, idealmente como anexo con historias de usuario, no como un párrafo genérico.
2. Hitos de pago vinculados a entregables verificables, no al paso del tiempo. Pagar por mes te garantiza facturas; pagar por hito te garantiza progreso.
3. Cesión total de la propiedad intelectual del código y los activos digitales producidos.
4. Acceso del cliente al repositorio desde el día uno, con permisos de lectura y, si procede, de escritura.
5. Cláusulas de salida claras: qué pasa si quieres cambiar de proveedor a mitad de proyecto. Si la respuesta no está en el contrato, asume que será un problema caro.
6. Acuerdo de nivel de servicio (SLA) para mantenimiento posterior, con tiempos de respuesta y resolución por severidad.
7. Cláusula de auditoría técnica que te permita revisar el código con un tercero independiente cuando quieras.

Si tu proveedor se resiste a alguno de estos puntos, pregúntate por qué. Una productora que confía en su trabajo no tiene problema en firmar un contrato exigente. Las que sí tienen problema suelen ser las que más probabilidad tienen de generártelos a ti más adelante.

Discovery: la fase que más control te da y que casi nadie usa bien

Antes de escribir una sola línea de código, deberías exigir una fase de discovery técnico-funcional. Es la inversión con mejor retorno en todo el proyecto. Una semana —o dos, según el tamaño— pagada por el cliente, con un objetivo concreto: dejar el alcance, la arquitectura y el plan de hitos bien definidos por escrito.

Lo que un buen discovery debería producir:

• Backlog priorizado con historias de usuario y criterios de aceptación.
• Diagrama de arquitectura técnica de alto nivel.
• Stack tecnológico justificado, con alternativas descartadas y por qué.
• Plan de hitos con fechas estimadas y dependencias.
• Estimación de coste con rango (no un número mágico).
• Riesgos identificados con plan de mitigación.

Esto te da algo que no te da ningún otro entregable: una línea base medible contra la que vas a poder comparar todo el avance posterior. Sin esa línea base, cualquier desviación es discutible. Con ella, tienes datos para tomar decisiones.

Hitos, no horas: cómo estructurar el plan de pago

Pagar por horas es la peor decisión que puede tomar un cliente sin equipo técnico para supervisar. Premia la lentitud, oscurece el progreso y convierte cada extra en una negociación incómoda.

Pagar por hitos cierra esos huecos. Un hito es un entregable verificable, con un criterio de aceptación que dice “esto se da por bueno cuando X funciona en este entorno y pasa estas pruebas”. Si el proveedor tarda más, su problema. Si tú cambias el alcance, tu problema (y se renegocia, no se discute).

Una estructura típica que funciona bien:

• Pago inicial al cierre del discovery (10–20 % del total).
• Pagos por hito repartidos entre el 60 % y el 80 % del proyecto, contra entregables aceptados.
• Pago final a la entrega completa con tests y documentación cerrados.
• Retención del 5–10 % liberada tras un periodo de garantía (30–90 días).

Esta forma de pagar alinea incentivos y obliga a las dos partes a definir qué es “estar terminado”. Esa única conversación, repetida hito a hito, evita el 80 % de los conflictos típicos.

Métricas mínimas que tienes que mirar cada semana

No necesitas convertirte en project manager para gestionar bien a tu proveedor. Necesitas mirar pocas cosas, pero mirarlas siempre. Si tu proveedor no te las ofrece, pídelas. Si se resiste, sospecha.

Las métricas operativas que más te van a decir, sin marearte con jerga ágil:

• Velocity por sprint o tareas cerradas por semana, comparadas con la previsión.
• Burndown del hito actual: cuánto queda contra cuánto debería quedar.
• Bugs abiertos por severidad y tiempo medio de resolución.
• Cobertura de tests automáticos del código nuevo.
• Deuda técnica acumulada, idealmente con un número trazable (TODOs, code smells, módulos sin refactorizar).
• Despliegues a entornos (dev, staging, prod) y frecuencia.

Con esos seis indicadores y una reunión semanal de 30 minutos te basta para saber si el proyecto va bien o va mal. No hace falta más. Hace falta hacerlo siempre.

Repositorio, despliegue y secretos: nunca cedas la infraestructura

Una de las palancas de poder más obvias y peor gestionadas es la infraestructura. Si el repositorio de código vive en la cuenta de GitHub del proveedor, si el dominio está a su nombre, si las credenciales de AWS son suyas, no estás contratando un servicio: estás alquilando tu propio producto.

Reglas de higiene que tienes que aplicar sin excepción desde el primer día:

• El repositorio vive en una organización tuya. El proveedor tiene acceso, no propiedad.
• El dominio y los certificados están a nombre de tu empresa.
• Las cuentas cloud (AWS, GCP, Azure) son tuyas, con un usuario o rol delegado al proveedor.
• Los secretos y credenciales están en un gestor que tú controlas (1Password, Vault, KMS).
• Los servicios de terceros (Stripe, Sendgrid, analytics) se contratan a tu nombre.
• Los datos de producción nunca salen de tu entorno sin un acuerdo firmado.

Esto no es desconfianza. Es higiene. El día que decidas cambiar de proveedor —y ese día llegará tarde o temprano— querrás que la transición sea cuestión de revocar accesos, no de pelear por tus propios activos.

Cómo estructurar la comunicación con el proveedor

La calidad de la comunicación importa más que la cantidad. Un proyecto con 40 mensajes diarios sueltos y ninguna acta puede ir peor que uno con una sola reunión semanal documentada.

La estructura mínima que funciona:

• Reunión semanal de 30 minutos con orden del día, acta y decisiones por escrito.
• Demo quincenal o mensual sobre entorno real, no diapositivas. Si no se puede mostrar funcionando, no está hecho.
• Canal de comunicación rápido (Slack, Teams) para temas no urgentes, con la regla clara de que las decisiones siempre se documentan en otro sitio.
• Steering committee mensual con dirección del cliente para decisiones estratégicas, presupuesto y reorientaciones.

Documenta todo lo que sea decisión. No documentes ruido. La diferencia entre un proyecto sano y uno tóxico está casi siempre en si las decisiones quedan trazadas o no.

Señales tempranas de que estás perdiendo el control

Detectarlo a tiempo es la diferencia entre rectificar y reescribir. Si ves dos o más de estas señales en el mismo mes, es momento de actuar:

• El proveedor empieza a faltar a reuniones o las acorta sistemáticamente.
• Las demos se sustituyen por capturas, vídeos o “mejor te lo enseño la próxima”.
• Los tickets cerrados no se corresponden con lo que ves funcionando.
• Aparecen retrasos que se justifican con causas vagas (“dependencias externas”, “complejidad inesperada”) sin plan de recuperación.
• El equipo del proveedor cambia sin avisar y sin handover.
• El presupuesto se revisa al alza sin un cambio de alcance claro.
• Tu acceso al repositorio se vuelve confuso o se “rompe” temporalmente.

Cuando aparecen, lo peor que puedes hacer es esperar a la siguiente reunión. Lo correcto es pedir una auditoría técnica externa, pausar pagos del próximo hito hasta tener visibilidad y, si es necesario, traer a un Product Manager externalizado o a un CTO fraccionado para tomar el control operativo.

Cuándo conviene auditar al proveedor con un tercero

Una auditoría técnica externa cuesta una fracción de lo que te puede costar un proyecto descarrilado y, bien hecha, te dice tres cosas: si el código que pagas tiene la calidad que crees, si la arquitectura es razonable y si vas a poder mantenerlo el día que cambies de proveedor.

Tiene sentido auditar:

• Antes de aceptar un hito grande (más del 30 % del presupuesto).
• Antes de renovar un contrato anual de mantenimiento.
• Cuando notas señales tempranas de pérdida de control.
• Antes de un cambio de proveedor, para preparar el handover.
• Antes de una ronda de inversión, donde los inversores van a auditar igualmente.

En España, una auditoría técnica seria de un proyecto mediano cuesta entre 4.000 y 15.000 euros, según alcance. El retorno típico, cuando hay problemas reales, es entre 5x y 20x esa inversión. Si el proveedor se opone a una auditoría externa, eso ya es información valiosa sobre tu situación.

El rol del cliente: gestionar no es microgestionar

El error opuesto a perder el control es asfixiar al proveedor con microgestión. Pedir reportes diarios, revisar cada commit, opinar sobre el nombre de las variables. Eso no es gestión, es ruido, y termina por matar la productividad de cualquier equipo serio.

Gestionar bien a un proveedor de software se parece más a pilotar que a programar:

• Decides el destino (objetivo de negocio).
• Validas la ruta (arquitectura y plan de hitos).
• Lees los instrumentos (métricas semanales).
• Intervienes cuando algo se desvía (decisiones, no comentarios).
• Confías en el piloto profesional para todo lo demás.

Si has elegido bien al proveedor, esto funciona. Si no has elegido bien, ningún nivel de gestión lo va a compensar. Por eso la decisión de a quién contratas pesa diez veces más que cualquier proceso posterior. Si quieres entrar en cómo elegir bien, tenemos una checklist completa en el post sobre cómo contratar un estudio de ingeniería de software.

Recomendación

Si solo te llevas tres cosas de este post, que sean estas: firma un contrato exigente, paga por hitos verificables y mira las métricas operativas todas las semanas. Con eso solo, estás por delante del 80 % de las empresas que externalizan desarrollo en España.

En Everglow trabajamos así por defecto, no porque nos lo pidan los clientes. Es la única forma que conocemos de mantener relaciones largas, sanas y rentables para ambas partes. Si tienes un proyecto activo y empiezas a notar señales tempranas de pérdida de control, o si vas a arrancar uno nuevo y quieres montarlo bien desde el inicio, hablamos en el contacto. Sin compromiso, te ayudamos a poner el marco de gestión que tu proyecto necesita.