Qué preguntar al pedir referencias de un proveedor tecnológico

Pedir referencias es uno de los pasos más recomendados al evaluar un proveedor tecnológico y, al mismo tiempo, uno de los peor ejecutados. La conversación típica dura diez minutos, incluye la pregunta "¿recomendarías a este proveedor?" y termina con un "sí, todo bien" que no aporta información útil para decidir.

El problema no es pedir referencias: es que las preguntas que se hacen suelen ser tan genéricas que cualquier proveedor con un cliente satisfecho —y todo proveedor tiene al menos uno— puede pasar ese filtro sin revelar nada sobre cómo trabaja en condiciones reales.

Este artículo propone un conjunto de preguntas concretas para hacerle al cliente de referencia. No propone historias inventadas ni testimonios ficticios: es una guía práctica para aprovechar la conversación con quien ya pasó por la experiencia de trabajar con el proveedor que estás evaluando.

Por qué la pregunta obvia no sirve

"¿Recomendarías a este proveedor?" es una pregunta inútil por tres razones:

• El cliente de referencia fue elegido por el proveedor. Es alguien que, como mínimo, no tuvo una mala experiencia. Si la tuvo, el proveedor no te va a pasar su contacto. Partís de una muestra sesgada.
• La respuesta es binaria y no informa. Un "sí" no te dice en qué condiciones trabaja bien el proveedor, qué tipo de proyectos se le dan mejor, ni qué cosas podrían haber salido mejor.
• La gente evita criticar abiertamente a un proveedor con el que quizás sigue trabajando. Incluso si hubo problemas, es incómodo decirlo en una conversación con un desconocido que fue coordinada por ese mismo proveedor.

Para obtener información útil, hay que hacer preguntas que no se respondan con un sí o un no, que no pongan al cliente en la posición incómoda de criticar directamente y que revelen cómo fue la experiencia real, no la versión editada.

Preguntas sobre el proceso de trabajo

El día a día de un proyecto de software dice más sobre un proveedor que el resultado final. Las siguientes preguntas apuntan a entender cómo fue trabajar con ese equipo durante meses, no solo qué entregaron al final.

"¿Cómo fue la comunicación durante el proyecto?"

Esta pregunta es mejor que "¿son buenos comunicándose?" porque invita a describir en lugar de calificar. Lo que interesa saber:

• ¿Tenían reuniones regulares o la comunicación era reactiva —solo cuando alguien preguntaba algo—?
• ¿Quién era el punto de contacto del lado del proveedor? ¿Cambió durante el proyecto?
• ¿Cuándo surgía un problema o un retraso, el proveedor lo comunicaba apenas lo detectaba o esperaba a que el cliente preguntara?
• ¿El cliente sentía que entendía en qué estaba trabajando el equipo en cada momento, o había períodos de silencio?

Un proveedor que comunica mal genera desgaste aunque el producto final sea bueno. Un proveedor que comunica bien reduce la fricción incluso cuando las cosas no salen según lo previsto.

"¿Respetaron los plazos que acordaron al inicio?"

Casi ningún proyecto de software cumple exactamente los plazos originales. La pregunta no busca confirmar que todo se entregó a tiempo —eso sería ingenuo—, sino entender cómo se gestionaron las desviaciones.

Lo que conviene escuchar en la respuesta:

• Si hubo cambios en los plazos, ¿fueron comunicados con anticipación o el cliente se enteró cuando ya se había vencido la fecha?
• ¿Los ajustes de calendario respondieron a cambios en el alcance pedidos por el cliente, a subestimaciones del proveedor o a imprevistos técnicos? La primera es normal; las otras dos merecen más atención.
• ¿El proveedor propuso alternativas —reducir alcance, priorizar funcionalidades, entregar por fases— cuando vio que un plazo no se iba a cumplir?

"¿El equipo que empezó el proyecto fue el mismo que lo terminó?"

La rotación de personas en un proyecto de software es un riesgo real. Si el cliente de referencia trabajó con tres personas distintas en el mismo rol a lo largo del proyecto, eso afectó la continuidad, la calidad y probablemente los plazos.

Esta pregunta también revela si el proveedor asigna a sus mejores personas a la venta y después rota a perfiles más junior para la ejecución —una práctica más frecuente de lo que los proveedores admiten—.

Preguntas sobre los problemas

Todo proyecto tiene problemas. Lo que distingue a un buen proveedor no es la ausencia de problemas, sino cómo los maneja. Pero preguntar "¿tuvieron problemas?" suele generar respuestas defensivas. Es mejor preguntar por situaciones concretas.

"¿Hubo algo que no salió como esperaban y que, mirando hacia atrás, podrían haber previsto?"

Esta formulación es menos amenazante que "¿qué salió mal?". Reconoce que los proyectos tienen imprevistos y le da al cliente permiso para mencionar algo sin sentir que está hablando mal del proveedor.

Lo que interesa no es tanto el problema en sí —que probablemente no se repita en tu proyecto— sino cómo reaccionó el proveedor: ¿lo resolvió rápido?, ¿asumió la responsabilidad o buscó a quién culpar?, ¿cambió algo en su forma de trabajar para que no volviera a ocurrir?

"¿Hubo algún momento en que pensaron en cambiar de proveedor?"

Es una pregunta directa pero efectiva. Si la respuesta es un "no" inmediato y creíble, es una señal positiva. Si la respuesta es un "no" después de una pausa, o un "bueno, hubo un momento tenso cuando...", ahí hay información valiosa.

Preguntas sobre el producto entregado

El producto final es lo más visible, pero no siempre lo más informativo. Estas preguntas ayudan a ir más allá de "quedó lindo".

"Desde que terminó el desarrollo, ¿tuvieron que hacer ajustes o correcciones? ¿Quién los hizo?"

Todo software requiere mantenimiento. La pregunta busca saber si el proveedor acompañó después del lanzamiento o si desapareció apenas cobró la última factura. También revela si el producto requirió muchos ajustes post-entrega —lo que puede indicar problemas de calidad o de definición de requisitos— o si los cambios fueron menores y esperables.

"¿El costo final fue el que acordaron al inicio? Si cambió, ¿por qué?"

El presupuesto inicial y el final rara vez coinciden exactamente. La pregunta no busca un número —que probablemente el cliente no quiera compartir— sino entender si los cambios de costo fueron razonables y transparentes:

• ¿Los aumentos respondieron a nuevas funcionalidades pedidas por el cliente? Eso es esperable.
• ¿Respondieron a cosas que el proveedor no supo estimar bien? Eso es una señal de alerta.
• ¿El cliente se enteró de los aumentos a tiempo para decidir si los aceptaba, o aparecieron en la factura final?

"¿Hay algo que hoy harían distinto si volvieran a empezar el proyecto?"

Esta pregunta cierra la conversación con una mirada retrospectiva que suele revelar lo que las preguntas anteriores no capturaron. Puede referirse al proveedor, al proceso, al alcance o a decisiones del propio cliente. Cualquiera de esas respuestas te da información sobre cómo evitar los mismos tropiezos.

Preguntas sobre la relación actual

El proyecto no termina cuando se entrega el software. Lo que pasa después también importa.

"¿Siguen trabajando con el proveedor? ¿En qué?"

Si el cliente siguió contratando al proveedor para nuevas fases, mantenimiento u otros proyectos, es una señal de que la relación funcionó. Si no, conviene preguntar por qué —sin asumir que sea por algo negativo; a veces el proyecto simplemente terminó y no hubo necesidad de continuar—.

"Si tuvieras que definir en una frase para qué tipo de proyectos es bueno este proveedor, ¿cuál sería?"

Esta pregunta obliga al cliente a sintetizar su experiencia. Las respuestas útiles son específicas: "para proyectos donde el alcance está muy claro desde el inicio", "para cuando necesitás velocidad más que documentación", "para integraciones con sistemas legacy". Las respuestas genéricas —"para todo", "son muy buenos en general"— no aportan.

Cómo estructurar la conversación

Una llamada de referencias no debería durar más de veinte o treinta minutos. No es una auditoría: es una conversación para capturar la experiencia de alguien que ya pasó por lo que estás por hacer. Algunas recomendaciones prácticas:

• No mandes las preguntas por anticipado. Si el cliente las recibe antes, va a preparar respuestas y la conversación pierde espontaneidad. Sí podés adelantar los temas generales: proceso, plazos, equipo, producto final.
• No empieces con "¿todo bien?". Esa pregunta condiciona toda la conversación hacia lo positivo. Empezá con una pregunta abierta: "Contame cómo fue el proyecto desde tu perspectiva."
• Hablá con quien estuvo en el día a día, no solo con el que firmó el contrato. El director o founder que autorizó la contratación puede tener una visión general positiva, pero quien trabajó codo a codo con el proveedor sabe exactamente cómo fue la comunicación, si entregaban a tiempo y cómo reaccionaban ante los problemas.
• Dejá espacio para el silencio. Después de una pregunta, esperá. A veces la información más útil aparece cuando el cliente siente que tiene que llenar ese silencio con algo más que una respuesta ensayada.

Qué hacer con lo que escuchaste

Una sola referencia no alcanza para decidir. Lo ideal es hablar con al menos dos clientes, idealmente de proyectos de escala y complejidad comparables al tuyo. Si el proveedor solo te pasa una referencia o ninguna, eso ya es una señal.

Después de la conversación, escribí las respuestas —no de memoria, sino apenas cortás—. Las impresiones se desvanecen rápido y lo que recordás una semana después puede no coincidir con lo que realmente se dijo.

Compará lo que escuchaste con lo que leíste en los casos de éxito del proveedor. Si el caso de éxito prometía plazos récord y las referencias mencionan retrasos gestionados con transparencia, hay una brecha entre el marketing y la realidad. Si el caso de éxito y las referencias coinciden en los puntos importantes, tenés información más sólida para decidir.

Relación con otras decisiones

Verificar referencias es un paso que ocurre al final del proceso de evaluación, cuando ya tenés claro qué necesitás y ya filtraste proveedores por otros criterios. Si todavía no definiste el alcance del proyecto, el artículo sobre qué validar antes de desarrollar una aplicación cubre ese paso previo.

Si lo que estás por encargar reemplaza sistemas actuales que ya no dan abasto —como cuando las planillas se convierten en un riesgo operativo—, las referencias de proveedores que hicieron migraciones similares son particularmente valiosas: podés preguntar cómo manejaron la transición, qué datos se perdieron en el camino y cuánto tardó el equipo en adaptarse.

Pedir referencias no garantiza una buena decisión, pero reduce la probabilidad de sorpresas. La mayoría de los problemas que aparecen durante un proyecto de software ya ocurrieron antes, en otros proyectos, con otros clientes. Hablar con quienes ya pasaron por eso es la forma más barata de aprender sin pagar el costo de la experiencia propia.