Cómo supervisar a una empresa de desarrollo de software externa

La mayoría de los proyectos de software subcontratados no fracasan por mala fe del proveedor: fracasan porque nadie del lado del cliente supervisó con método. El proveedor reporta "avance del 70%", el gerente asiente, paga la cuota… y los problemas aparecen todos juntos al final, cuando ya no hay presupuesto ni tiempo para corregirlos. Esta guía resume qué puedes hacer tú, como cliente, para que eso no te pase.

La supervisión empieza antes de firmar

El 80% de tu capacidad de supervisar se define en el contrato. Una vez firmado un contrato vago, supervisas desde la debilidad. Antes de firmar, asegúrate de que existan:

• Alcance por escrito y entendible. Qué hace el sistema, qué no hace, y qué pasa con lo que "se asumió". Si el alcance solo existe en correos y reuniones, no existe.
• Hitos con entregables verificables. No "avance del 50%", sino "el módulo X funcionando en un ambiente de prueba con datos reales". Los pagos se asocian a hitos, no a fechas.
• Criterios de aceptación. Cómo se decide, objetivamente, que un entregable está aprobado. Sin esto, "terminado" significa lo que el proveedor quiera.
• Propiedad del código y los datos. El código fuente, las cuentas cloud y las bases de datos deben quedar a tu nombre o con acceso garantizado. Es tu seguro si la relación termina mal.
• Condiciones de salida. Qué recibe cada parte si el contrato se corta a mitad de camino.

Si estás en etapa de cotización, complementa con la guía de cuánto cuesta desarrollar software a medida en Chile: muchas cláusulas débiles nacen de comparar propuestas solo por precio.

Durante el proyecto: cadencia y evidencia

Supervisar no es perseguir; es instalar una rutina donde la evidencia fluye sola. Tres prácticas bastan para cambiar por completo el equilibrio:

1. Demos sobre software real, no presentaciones

Reunión corta cada dos o cuatro semanas donde el proveedor muestra el sistema funcionando, idealmente en un ambiente al que tú también tengas acceso. Una diapositiva que dice "módulo terminado" no es evidencia; poder hacer clic, sí. Si durante un mes nadie puede mostrarte nada que funcione, eso es información.

2. Acceso permanente a los avances

Pide acceso de lectura al repositorio de código y al ambiente de pruebas desde el día uno. No necesitas leer código: necesitas que el proveedor sepa que el trabajo es visible. Un proveedor serio no tiene problema con esto; la resistencia a darte acceso es, en sí misma, una señal.

3. Acta breve de cada hito

Qué se entregó, qué se revisó, qué quedó pendiente y qué se aprobó. Dos párrafos bastan. Cuando hay desacuerdos seis meses después, esa trazabilidad vale oro.

Qué revisar en cada entrega (sin ser técnico)

• ¿Funciona con datos reales? Todo funciona con tres registros de prueba. Pide ver el sistema con volúmenes y casos verdaderos de tu operación.
• ¿Lo puede usar un usuario final? Siéntate con la persona que lo usará a diario, no con el jefe de proyecto, y mírala usarlo.
• ¿Qué pasa cuando algo sale mal? Pide que te muestren un error: datos mal ingresados, conexión caída. La diferencia entre software serio y frágil está en los caminos infelices.
• ¿Existen pruebas y respaldos? Pregunta cómo se prueba el sistema antes de cada entrega y cómo se respalda la información. No necesitas entender la respuesta completa; necesitas que exista una respuesta concreta.
• ¿La documentación permitiría que otro continúe? El estándar es simple: si este proveedor desaparece mañana, ¿otro equipo podría tomar el sistema?

Señales de alerta

• El avance solo existe en reuniones. Semanas de "vamos bien" sin nada usable que mostrar.
• Jerga como escudo. Las preguntas simples reciben respuestas incomprensibles. Quien entiende algo de verdad, puede explicarlo simple.
• Todo cambio "no estaba considerado". Cobros adicionales constantes suelen indicar que el alcance inicial se cotizó a la rápida.
• Rotación silenciosa del equipo. Las personas que partieron el proyecto ya no están y nadie te lo informó.
• Resistencia a darte accesos. Al repositorio, a los ambientes, a las cuentas cloud. Tu proyecto, tus llaves.

Ninguna de estas señales prueba mala fe por sí sola. Pero dos o tres juntas justifican parar, pedir una revisión del estado real y renegociar la forma de trabajo antes del siguiente pago.

Cinco preguntas para tu próxima reunión de avance

Si quieres partir hoy mismo, llega a la próxima reunión con estas preguntas. Ninguna requiere conocimiento técnico y todas producen información útil:

1. "¿Me pueden mostrar esto funcionando, en vez de contármelo?"
2. "Si el proyecto terminara hoy, ¿qué me llevo y en qué estado?"
3. "¿Qué es lo que más riesgo tiene de atrasarse de aquí al próximo hito, y qué están haciendo al respecto?"
4. "¿Quiénes están trabajando en mi proyecto esta semana?" (compara con lo que decía la propuesta)
5. "¿Cómo accedo yo al ambiente de pruebas y al repositorio?"

No importa tanto cada respuesta como el patrón: un proveedor sano responde con hechos y accesos; uno en problemas responde con explicaciones y postergaciones.

Cuando no tienes a nadie técnico del lado tuyo

Todo lo anterior puedes hacerlo sin saber programar. Pero hay un límite honesto: evaluar la calidad interna del código, la arquitectura o la seguridad requiere criterio técnico que se construye con años de oficio. Si el proyecto es grande o crítico para tu operación, una contraparte técnica independiente hace esa revisión por ti y te recomienda, en cada hito, qué aprobar, corregir o rechazar. Si todavía no te queda claro el rol, parte por qué es una contraparte técnica y cuándo la necesitas.