Qué preguntas hacerle a un proveedor de desarrollo antes de contratar

Contratar un proveedor de desarrollo de software es una de las decisiones más difíciles de evaluar para alguien que no es técnico.

No porque los proveedores sean opacos, aunque algunos lo son. Sino porque las preguntas incorrectas producen respuestas que suenan bien pero no revelan nada útil.

"¿Tienen experiencia en este tipo de proyectos?" Todos dicen que sí.

"¿Pueden cumplir con el plazo?" Todos dicen que sí.

"¿El precio incluye todo?" Todos dicen que sí, hasta que no.

Las preguntas que realmente revelan la calidad de un proveedor de desarrollo son las que no tienen una respuesta obvia y que requieren especificidad para ser respondidas bien.

Estas son las que deberías hacer antes de contratar a cualquiera.

Sobre el proceso de trabajo

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

Esta es probablemente la pregunta más importante de toda la evaluación.

En casi todos los proyectos de desarrollo aparecen cambios: requisitos que no estaban claros al inicio, funcionalidades que el cliente descubrió que necesitaba o ajustes que surgieron al ver el producto en acción.

Cómo maneja un proveedor esos cambios revela su madurez de proceso. ¿Tienen un procedimiento formal para documentar y aprobar cambios de alcance? ¿Cómo impactan en el costo y el plazo? ¿Quién los autoriza?

Un proveedor que no tiene una respuesta clara a esta pregunta va a generar conflictos cuando aparezca el primer cambio, y ese momento siempre llega.

¿Qué metodología usan y cómo me involucra a mí como cliente?

No se trata de que el cliente entienda la diferencia entre Scrum y Kanban. Se trata de entender con qué frecuencia va a ver avances, cuándo puede dar retroalimentación y en qué momentos del proceso su aprobación es necesaria para continuar.

Un proveedor que trabaja en silos durante semanas y entrega al final tiene un riesgo de desalineación mucho mayor que uno que tiene puntos de revisión frecuentes con el cliente.

¿Qué pasa si el proyecto se retrasa?

Los retrasos en desarrollo son más comunes que los cumplimientos exactos de plazo. La pregunta no es si pueden ocurrir, sino cómo los maneja el proveedor cuando ocurren.

¿Hay penalidades contractuales? ¿Cómo se comunican los retrasos al cliente? ¿Quién absorbe el costo del tiempo adicional? Un proveedor que tiene respuestas claras a esto demuestra que ha navegado esas situaciones antes y que tiene un protocolo para manejarlas.

Sobre el equipo

¿Quién va a trabajar específicamente en mi proyecto?

Esta pregunta distingue a los proveedores que tienen un equipo estable de los que subcontratan o reasignan recursos según la disponibilidad del momento.

No es necesario conocer a cada desarrollador, pero sí saber quién lidera el proyecto técnicamente, quién es el punto de contacto principal y si el equipo que presenta en la venta es el mismo que va a ejecutar.

Cambiar de equipo a mitad de un proyecto tiene un costo real en tiempo de adaptación y en continuidad del conocimiento acumulado sobre el proyecto.

¿Qué pasa si alguien clave del equipo sale durante el proyecto?

La rotación de personal en desarrollo de software es alta. Un proveedor serio tiene un protocolo para manejar esas situaciones sin que el proyecto se detenga o se deteriore.

Si la respuesta es evasiva o si el proveedor no ha pensado en este escenario, es una señal de alerta.

Sobre la entrega y lo que viene después

¿A quién le pertenece el código al final del proyecto?

Esta pregunta debería estar en el contrato, pero vale la pena hacerla explícita antes de llegar a esa instancia.

Algunos proveedores mantienen la propiedad del código o de partes de él, lo que puede generar dependencias problemáticas si la relación termina. El cliente debería salir del proyecto con la propiedad completa del código y la documentación necesaria para que otro equipo pueda continuarlo.

¿Cómo queda documentado el proyecto?

Un proyecto de desarrollo sin documentación es un proyecto que solo puede ser mantenido por quien lo construyó. Si ese proveedor deja de estar disponible, el costo de que alguien más entienda el código puede ser significativo.

La documentación técnica, los comentarios en el código y los manuales de usuario o administración no son opcionales. Son parte de la entrega.

¿Qué soporte ofrecen después de la entrega y a qué costo?

Todo software tiene bugs que solo aparecen en producción. La pregunta es quién los resuelve, en qué plazo y a qué costo.

Un período de garantía post-entrega donde el proveedor corrige errores sin costo adicional es lo mínimo razonable. Cuánto dura ese período y qué cubre exactamente debe quedar claro antes de firmar.

Sobre referencias y evidencia

¿Pueden mostrarme proyectos similares que hayan completado?

No portfolios genéricos. Proyectos con características similares al tuyo en complejidad, tecnología o industria, donde puedan describir el problema que resolvieron, cómo lo abordaron y cuál fue el resultado.

Si no tienen ejemplos relevantes, eso es información valiosa.

¿Puedo hablar con algún cliente anterior?

Esta es la pregunta que más incomoda a los proveedores que tienen algo que ocultar. Un proveedor con clientes satisfechos no debería tener ningún problema en facilitar una referencia directa.

Una referencia que puedas contactar y preguntarle cómo fue la experiencia real, no solo si el producto funcionó, vale más que cualquier testimonio publicado en el sitio web del proveedor.

Sobre el contrato

¿Qué está explícitamente excluido del alcance?

Tan importante como saber qué incluye el proyecto es saber qué no incluye. Las exclusiones son donde aparecen los costos inesperados después.

Hosting, licencias de software, integraciones con sistemas externos, capacitación del equipo, migración de datos. Si alguno de estos elementos es necesario para que el proyecto funcione, debe estar claro si está incluido o si va a tener un costo adicional.

Conclusión

Contratar desarrollo de software no requiere ser técnico. Requiere hacer las preguntas correctas y prestar atención a la calidad de las respuestas.

Un proveedor serio tiene respuestas específicas, documentadas y coherentes para todas estas preguntas. Uno que evade, generaliza o no ha pensado en estos escenarios está revelando algo importante sobre cómo va a manejar el proyecto cuando las cosas se compliquen.

Las preguntas que haces antes de contratar determinan los problemas que evitas después de firmar.