Qué preguntas hacer antes de contratar a un proveedor tecnológico

Contratar a un proveedor tecnológico es una decisión que va a afectar al negocio durante meses o años. El producto que construyan —o no—, la relación que se establezca —o no— y la capacidad del negocio de evolucionar sin depender del proveedor dependen en buena medida de la información que se obtenga antes de firmar.

El problema es que muchas de las preguntas que se hacen en una reunión comercial no producen información útil para decidir. "¿Tienen experiencia en proyectos como este?" va a recibir un sí aunque la experiencia haya sido marginal. "¿Cumplen los plazos?" va a recibir un sí aunque el cumplimiento haya sido con cambios de alcance que inflaron el presupuesto. Las preguntas genéricas obtienen respuestas genéricas, y con respuestas genéricas no se toman buenas decisiones.

Este artículo propone un conjunto de preguntas concretas, agrupadas en cinco áreas, diseñadas para obtener información que efectivamente permita comparar proveedores y anticipar cómo va a ser la relación durante el proyecto.

Preguntas sobre el proceso de trabajo

El proceso de trabajo es lo que determina si el proyecto va a avanzar de manera predecible o a los tumbos. No hace falta que el proveedor siga una metodología específica —Scrum, Kanban, lo que sea—, pero sí que tenga un proceso definido y que pueda explicarlo.

¿Cómo definen el alcance antes de empezar a programar?

Un proveedor que no tiene un proceso documentado para traducir necesidades de negocio en requerimientos técnicos va a empezar a programar sobre supuestos. Preguntá cómo documentan lo que el cliente necesita, cómo validan que entendieron bien y cómo manejan las ambigüedades. Si la respuesta es "lo charlamos y vamos viendo", no hay proceso. Si describen sesiones de relevamiento, documentos de especificación, validación con el cliente antes de empezar, hay un método.

¿Cómo organizan el trabajo en el día a día?

No necesitás saber qué herramienta usan para gestionar tareas, pero sí entender cómo saben qué está haciendo cada persona del equipo, cómo se asignan las prioridades y cómo se detecta que algo se está desviando del plan. Un equipo que trabaja sin visibilidad interna —cada desarrollador hace lo que cree que hay que hacer— es un equipo donde los desvíos se detectan tarde.

¿Cómo gestionan los cambios de alcance durante el proyecto?

Esta es quizás la pregunta más importante de la categoría. Todo proyecto tiene cambios: funcionalidades que el cliente no había considerado, complejidades que aparecen durante el desarrollo, prioridades que cambian. Un proveedor serio tiene un proceso definido para gestionar estos cambios —quién los evalúa, cómo se cotizan, cómo afectan los plazos—. Uno que dice "no va a haber cambios" o "lo resolvemos sobre la marcha" está evitando una conversación incómoda que va a ser mucho más incómoda cuando el cambio efectivamente aparezca.

Preguntas sobre comunicación

La comunicación durante un proyecto de desarrollo no es un nice-to-have: es el mecanismo por el cual el cliente sabe si lo que se está construyendo es lo que necesita. Sin comunicación estructurada, el cliente se entera de los problemas cuando ya no hay margen para corregirlos.

¿Con qué frecuencia y en qué formato muestran avances?

La respuesta ideal incluye una cadencia —semanal, quincenal— y un formato —demo funcionando, no solo informe de horas—. Mostrar lo que se construyó en funcionamiento permite al cliente verificar que el proyecto va por buen camino. Un informe de horas solo dice cuánto se trabajó, no qué se logró.

¿Quién es mi contraparte durante el proyecto?

Preguntá si hay una persona asignada como responsable —Project Manager, líder técnico, account manager— o si la comunicación va a ser con quien esté disponible. Un proyecto sin responsable asignado es un proyecto donde las decisiones importantes no tienen dueño y donde los problemas se pasan de mano en mano sin que nadie los resuelva.

Si tengo una urgencia un viernes a las seis de la tarde, ¿a quién llamo y en cuánto tiempo me responde?

No es una pregunta sobre disponibilidad 24/7 —que probablemente no esté incluida en el servicio estándar—, sino sobre el mecanismo de escalamiento. Un proveedor serio puede describir cómo se manejan las urgencias, qué canales se usan, qué tiempos de respuesta se comprometen y bajo qué condiciones.

Preguntas sobre el equipo

El equipo que va a construir el proyecto es más importante que la empresa que firma el contrato. Las empresas no escriben código: lo escriben personas concretas con experiencia, criterio y contexto específicos.

¿Quiénes van a trabajar en mi proyecto? ¿Puedo conocerlos antes de empezar?

Muchos proveedores asignan al equipo después de firmar el contrato. Pedir conocer al equipo antes —aunque sea en una videollamada de quince minutos— permite evaluar si las personas que van a construir el producto entienden el problema y tienen la experiencia que el proyecto requiere.

¿Qué pasa si una persona clave del equipo se va durante el proyecto?

La rotación existe en todas las empresas. Lo que importa no es si va a pasar, sino cómo lo maneja el proveedor: ¿tienen documentación interna que permita a una persona nueva ponerse al día rápido? ¿Hay períodos de solapamiento entre quien se va y quien entra? ¿Cuánto impacta en los plazos? Si la respuesta es "nuestro equipo es estable, eso no pasa", el proveedor está evitando la pregunta.

¿El equipo trabaja en otros proyectos en paralelo o está dedicado al mío?

No hay una respuesta correcta universal. Un equipo parcialmente dedicado puede funcionar bien si la carga está bien dimensionada. El problema es cuando el proveedor no es transparente al respecto y el cliente descubre sobre la marcha que el equipo no avanza al ritmo esperado porque está repartido entre tres proyectos.

Preguntas sobre entregables y propiedad

Lo que el cliente recibe al final del proyecto —y durante el desarrollo— determina su capacidad de operar y evolucionar el producto sin depender del proveedor.

¿El código fuente va a estar en un repositorio al que yo tenga acceso desde el día uno?

Si el código vive en la máquina de un desarrollador o en un repositorio al que el cliente no tiene acceso, al terminar el proyecto —o si la relación se interrumpe— el cliente se queda sin capacidad de acción sobre su propio producto. El acceso al repositorio desde el inicio no solo es una cuestión de propiedad: es una señal de transparencia.

¿Qué documentación entregan al finalizar?

Preguntá específicamente: documentación de arquitectura, manual de instalación y despliegue, credenciales de todos los servicios externos, documentación de APIs si las hay. Si el proveedor dice que "el código es la documentación", lo que está diciendo es que no documenta.

¿Quién es el dueño del código fuente?

La respuesta debería ser inequívoca: el cliente. Si el proveedor propone un modelo de licenciamiento, copropiedad o cualquier esquema que no sea propiedad plena del cliente, es una decisión de negocio que conviene entender y discutir antes de firmar.

Preguntas sobre mantenimiento y soporte post-entrega

El proyecto no termina cuando se entrega el código. Lo que pasa después —corrección de errores, actualizaciones, soporte— es tan importante como el desarrollo y suele estar peor definido en el contrato.

¿Qué cubre la garantía post-entrega? ¿Por cuánto tiempo?

Preguntá: ¿solo corrección de errores o también consultas de uso? ¿Treinta, sesenta, noventa días? ¿Qué pasa si un error aparece después de ese período: se corrige sin costo si es atribuible al desarrollo original o se cobra aparte?

¿Cómo se gestionan las actualizaciones de seguridad de las dependencias?

Las bibliotecas y frameworks sobre los que se construye el software se actualizan constantemente, muchas veces por vulnerabilidades de seguridad. ¿Quién se ocupa de mantener eso al día? ¿Está incluido en el servicio o es un costo adicional? ¿Con qué frecuencia se revisan?

¿Qué necesito para que otro equipo pueda tomar el proyecto si en el futuro decido cambiar de proveedor?

Un proveedor que se resiste a responder esto o que pone trabas —"nuestro código es muy complejo, otro equipo no va a poder"— está protegiendo su negocio, no el del cliente. La respuesta correcta describe qué documentación, accesos y conocimiento se transfieren para que la transición sea posible.

Cómo usar este checklist sin que sea un interrogatorio

No hace falta hacer las quince preguntas en una sola reunión. Tres o cuatro por encuentro, distribuidas en dos o tres conversaciones, permiten cubrir todas las áreas sin que la reunión se vuelva tensa. Lo importante es registrar las respuestas y compararlas entre proveedores con los mismos criterios.

Llevar una planilla con los proveedores en las columnas y las áreas —proceso, comunicación, equipo, entregables, mantenimiento— en las filas ayuda a que la decisión se base en datos y no en la simpatía que generó la reunión comercial.

Para complementar este checklist con criterios más amplios de evaluación, el artículo sobre cómo elegir una empresa de desarrollo de software cubre seis dimensiones que van más allá de las preguntas puntuales. Y si ya estás en instancia de analizar propuestas, revisar el artículo sobre señales de alerta en una propuesta comercial ayuda a identificar patrones que anticipan problemas.

Más contenido sobre selección de equipos en la categoría de proveedores tecnológicos.