Preguntas que debes hacer antes de contratar un proveedor tecnológico

La decisión de con qué proveedor tecnológico trabajar es una de las que más impacto tiene en el resultado de un proyecto de software. Y sin embargo, muchas empresas la toman con menos información de la que usarían para comprar equipamiento o contratar a una persona para un puesto clave.

El problema no suele ser falta de opciones —hay agencias, estudios, freelancers y consultoras para todos los perfiles—, sino falta de un método para compararlas. Las propuestas comerciales tienden a parecerse: todas prometen calidad, cumplimiento de plazos y un equipo comprometido. Las diferencias reales aparecen cuando se indaga en cómo trabajan, no en qué prometen.

Este artículo propone nueve preguntas para hacer antes de firmar, agrupadas en tres áreas: proceso, comunicación y entregables. No son preguntas técnicas —no necesitás saber de programación para hacerlas—, pero las respuestas revelan más sobre la seriedad del proveedor que cualquier brochure.

Sobre el proceso de trabajo

1. ¿Cómo definen el alcance antes de empezar a desarrollar?

Un proveedor serio no empieza a escribir código después de una reunión de una hora. Tiene un proceso —formal o no— para traducir lo que el cliente necesita en un plan de trabajo. Ese proceso puede incluir sesiones de relevamiento, documentación de historias de usuario, prototipos de baja fidelidad o un documento de especificación funcional.

Lo que importa no es el formato, sino que exista. Si la respuesta es "lo vamos viendo sobre la marcha" sin aclarar qué método usan para que ese "sobre la marcha" no se convierta en un proyecto sin dirección, hay un riesgo concreto de que el alcance se desdibuje y los plazos también.

Pedí que te muestren un ejemplo real de cómo documentaron el alcance de un proyecto anterior. No hace falta que te den acceso al documento completo; con que te expliquen la estructura y el nivel de detalle alcanza para evaluar si trabajan con la rigurosidad que tu proyecto necesita.

2. ¿Cómo manejan los cambios de alcance durante el proyecto?

Todo proyecto tiene cambios. Lo que diferencia a un buen proveedor de uno que genera fricción constante es cómo gestiona esos cambios. ¿Hay un proceso definido? ¿Se documentan? ¿Se estima el impacto en tiempo y costo antes de implementarlos?

Si el proveedor no puede describir su proceso de control de cambios, lo que va a pasar es que cada solicitud se negocie caso por caso, por los canales equivocados —un mensaje directo al desarrollador en vez de una conversación con el responsable del proyecto—, y con criterios inconsistentes sobre qué es un cambio menor y qué es un adicional.

3. ¿Quién va a trabajar en el proyecto y cuánta dedicación va a tener?

En muchas agencias y consultoras, el equipo que se presenta en la propuesta comercial no es el mismo que termina trabajando en el día a día. Las figuras senior participan en la venta y la definición inicial; después el proyecto queda en manos de perfiles más junior con supervisión esporádica.

Preguntá nombres, roles y dedicación semanal estimada. No para auditar currículums, sino para entender si el proveedor está dimensionando tu proyecto como prioritario o como uno más en una cartera que se gestiona con el equipo que va quedando disponible.

Si la respuesta es genérica —"un equipo de tres personas con experiencia en este tipo de proyectos"—, pedí que te presenten a quien sería el responsable técnico del día a día. Una conversación de quince minutos con esa persona te da más información que cualquier propuesta escrita.

Sobre la comunicación

4. ¿Con qué frecuencia y en qué formato vamos a recibir avances?

La comunicación durante un proyecto de software no puede ser reactiva —"cuando haya algo para mostrar te avisamos"— porque el cliente necesita saber si el proyecto va por buen camino antes de que sea tarde para corregir.

Un esquema saludable incluye:

• Una reunión de avance con frecuencia definida (semanal, quincenal).
• Una demostración de lo construido, no un informe de horas consumidas.
• Un canal de comunicación para el día a día (Slack, Teams, mail) con tiempos de respuesta esperados.
• Un mecanismo para escalar problemas cuando algo no se está resolviendo por la vía habitual.

Si el proveedor no propone una cadencia concreta, proponela vos. Si se resiste a comprometer una frecuencia, preguntate cómo vas a saber si el proyecto está avanzando o no durante las semanas en que no hay contacto.

5. ¿Cómo manejan los desacuerdos sobre lo acordado?

Tarde o temprano va a haber una diferencia de interpretación: algo que el cliente creía incluido y el proveedor considera adicional, una funcionalidad que no funciona como el cliente esperaba, un plazo que no se cumple.

Un proveedor maduro tiene un mecanismo para resolver estas situaciones sin que escalen a conflicto: un responsable de cuenta o de proyecto con autoridad para tomar decisiones, un proceso de revisión conjunta de lo documentado, una instancia de escalamiento si no hay acuerdo. Preguntá específicamente: "Si en tres meses vos y yo no estamos de acuerdo sobre si algo está dentro del alcance o no, ¿cómo lo resolvemos?"

La respuesta revela si el proveedor ya atravesó esta situación antes y aprendió a gestionarla, o si confía en que con "buena predisposición de ambas partes" todo se arregla —lo cual funciona hasta que deja de funcionar.

6. ¿Quién es mi contraparte durante el proyecto?

En proyectos chicos, puede ser una sola persona. En proyectos más grandes, conviene saber si hay un responsable de proyecto dedicado, un líder técnico y un canal comercial. Lo importante es que sepas a quién recurrir según el tipo de problema: una cosa es una duda funcional, otra es una discusión sobre presupuesto, otra es un incidente técnico urgente.

Si la respuesta es "hablá conmigo y yo derivo", preguntá cuántos proyectos más está gestionando esa persona al mismo tiempo. Un Project Manager con ocho proyectos simultáneos no va a estar disponible cuando tu proyecto necesite una decisión rápida.

Sobre los entregables y la continuidad

7. ¿Qué incluye exactamente la entrega?

"El sistema funcionando" no es un entregable suficientemente específico. Una entrega profesional debería incluir como mínimo:

• El código fuente, en un repositorio al que tengas acceso desde el primer día.
• Documentación básica: cómo instalar o desplegar el sistema, cómo usarlo, cómo está estructurado.
• Credenciales y accesos a todos los servicios externos que se hayan contratado para el proyecto (servidores, bases de datos, dominios, APIs de terceros).
• Un registro de decisiones técnicas relevantes y sus fundamentos.

Si estos elementos no están en la propuesta, pedí que los incluyan. No son un costo adicional: son la garantía de que al terminar el proyecto, el cliente no depende del proveedor para operar lo que pagó.

8. ¿Cómo es el proceso de corrección de errores post-entrega?

Ningún software sale sin errores. Lo que importa es cómo se manejan. Preguntá:

• ¿Hay un período de garantía durante el cual los errores se corrigen sin costo adicional?
• ¿Cómo se define qué es un error y qué es un cambio? ¿Quién lo decide?
• ¿Cuál es el tiempo de respuesta para un error que impide usar el sistema?

Si el proveedor no tiene un procedimiento definido —con tiempos, canales y criterios claros—, cada error post-entrega va a ser una negociación nueva, y eso desgasta la relación y retrasa la operación real del negocio.

9. ¿Qué pasa si el proyecto se interrumpe antes de terminar?

No es una pregunta que a nadie le guste hacer, pero es necesaria. Los proyectos se interrumpen por razones que no siempre puede controlar el proveedor: el cliente se queda sin presupuesto, cambian las prioridades del negocio, surge una oportunidad que requiere redirigir recursos.

Un proveedor serio tiene una respuesta preparada: cómo se entrega lo construido hasta el momento, en qué condiciones, y con qué documentación. Si la respuesta es evasiva o parece que nunca lo habían considerado, estás frente a alguien que no tiene experiencia manejando proyectos reales, donde los imprevistos existen.

Cómo usar estas preguntas

No hace falta hacer las nueve en una misma reunión —sonaría a interrogatorio y no es el objetivo. Dos o tres por encuentro alcanzan, siempre que registres las respuestas y las compares entre proveedores con los mismos criterios.

El objetivo no es encontrar al proveedor perfecto —no existe—, sino identificar cuáles son las brechas de cada uno y decidir con cuáles podés convivir. Un proveedor que es débil en documentación pero muy fuerte en comunicación y disponibilidad puede ser una mejor opción que uno que cumple todos los casilleros formales pero tarda tres días en responder un mensaje.

Relacionado: si además de evaluar proveedores de desarrollo estás considerando automatización, revisá cómo elegir un proveedor de automatización, donde encontrarás criterios específicos para ese tipo de proyectos. Y antes de llegar a la instancia de contratación, conviene tener claro qué validar antes de desarrollar una aplicación para llegar a la conversación con el proveedor con el alcance bien definido.

Explorá más herramientas de evaluación en la categoría de proveedores tecnológicos.