Cómo elegir una empresa de desarrollo de software

Elegir una empresa de desarrollo de software es una decisión de alto impacto que muchas organizaciones toman con menos estructura que la que usan para comprar equipamiento o contratar a una persona para un puesto gerencial. El resultado es predecible: proyectos que empiezan con entusiasmo y terminan en frustración, relaciones que se desgastan antes del primer entregable, y productos que no resuelven el problema que debían resolver.

El problema no es que falten opciones —en Chile y en la región hay agencias, consultoras, estudios y equipos freelance para todos los perfiles y presupuestos—. El problema es que los criterios que se suelen usar para elegir —precio, referencias genéricas, buena impresión en la reunión comercial— no predicen bien el resultado del proyecto.

Este artículo propone un conjunto de criterios estructurados para evaluar y seleccionar una empresa de desarrollo de software. No son criterios técnicos —no necesitás saber programar para aplicarlos—, sino dimensiones observables del proceso de trabajo que sí correlacionan con resultados.

Criterio 1: Cómo definen el alcance antes de empezar

La forma en que un proveedor aborda la definición del alcance antes de escribir código es quizás el predictor más fuerte de cómo va a ser la relación durante el proyecto.

Un proveedor serio no empieza a desarrollar después de una reunión de una hora. Tiene un proceso documentado —o al menos explicitado— para traducir lo que el cliente necesita en un plan de trabajo. Ese proceso puede tomar distintas formas: sesiones de relevamiento, documentación de historias de usuario, wireframes de baja fidelidad, un documento de especificación funcional. Lo que importa no es el formato exacto sino tres cosas:

1. Que exista un proceso. Si la respuesta es "lo vamos viendo sobre la marcha", sin ningún método para que ese "sobre la marcha" tenga dirección, el proyecto va a ir a la deriva.
2. Que el proveedor pueda mostrarte un ejemplo real de un proyecto anterior. No el documento completo —puede tener información confidencial del cliente—, pero sí la estructura, el nivel de detalle, cómo conectan los requerimientos del negocio con las decisiones técnicas.
3. Que el proceso incluya validación. No solo documentar lo que el cliente pide, sino cuestionarlo cuando detecta ambigüedades, contradicciones o funcionalidades que encarecen el proyecto sin agregar valor proporcional. Un proveedor que solo asiente y documenta no está agregando criterio: está tomando pedidos.

Criterio 2: Cómo se comunican durante el proyecto

La comunicación durante un proyecto de software no puede ser reactiva —"cuando haya algo para mostrar te avisamos"— porque cuando hay algo para mostrar, si está mal encaminado, ya es tarde para corregir sin costo.

Evaluá estos aspectos en la conversación comercial:

• Cadencia de avances. ¿Proponen reuniones con una frecuencia definida —semanal, quincenal— o dicen que "van a ir mostrando a medida que avancen"? Lo segundo suele traducirse en semanas de silencio seguidas de una demo que no se parece a lo que el cliente esperaba.
• Formato de los avances. ¿Muestran lo que construyeron funcionando —una demo— o mandan un informe de horas? El informe de horas dice cuánto se trabajó; la demo dice qué se logró. Ambos importan, pero solo el segundo permite evaluar si el proyecto va por buen camino.
• Quién es la contraparte. ¿Hay una persona identificada como responsable del proyecto —un Project Manager, un líder técnico— o te derivan a quien esté disponible? Un proyecto sin responsable asignado es un proyecto donde las decisiones importantes no tienen dueño.
• Capacidad de respuesta. ¿Cuánto tardan en responder un mensaje durante el proceso comercial? Si en la etapa donde están tratando de ganar el proyecto ya tardan tres días, durante el desarrollo —cuando la urgencia de vender ya pasó— la comunicación va a ser peor, no mejor.

Criterio 3: Referencias que puedas verificar

Todo proveedor tiene referencias. La diferencia está en qué tipo de referencias ofrece y cuán dispuesto está a que las verifiques.

Una referencia genérica —"trabajamos con empresas del sector retail" sin nombres— no sirve. Una referencia con nombre de empresa pero sin contacto directo —"podés ver nuestro portfolio en la web"— sirve a medias. Una referencia donde el proveedor te facilita el contacto de un cliente anterior para que hables directamente es oro.

Cuando hables con una referencia, no preguntes "¿están conformes?" porque la respuesta va a ser sí —si el proveedor te pasó el contacto, es porque sabe que el cliente está conforme—. Preguntá cosas más específicas:

• "¿El proyecto se entregó en el plazo y el presupuesto que acordaron al inicio? Si hubo desviaciones, ¿cómo las manejaron?"
• "¿Cómo fue la comunicación durante el proyecto? ¿Tenían una persona asignada o hablaban con quien estuviera disponible?"
• "¿Qué pasó después de la entrega? ¿Los errores se corrigieron rápido? ¿Las cosas que no estaban claras en el alcance las resolvieron bien o fue una discusión?"
• "Si tuvieras que empezar otro proyecto mañana, ¿volverías a trabajar con ellos?"

Si el proveedor se resiste a darte contactos directos —"por políticas de confidencialidad", "los clientes no quieren que los contacten"—, puede ser cierto o puede ser una señal de que las referencias no son tan sólidas como parecen. En cualquier caso, es información útil para la decisión.

Para una guía más detallada sobre cómo verificar referencias, revisá el artículo sobre qué preguntar para verificar referencias de un proveedor.

Criterio 4: Cómo documentan lo que hacen

La documentación es el síntoma más visible de la madurez de un equipo de desarrollo. No porque la documentación en sí misma sea el objetivo —el objetivo es que el software funcione—, sino porque un equipo que documenta bien es un equipo que sabe que el proyecto no termina cuando se entrega el código.

Preguntá:

• ¿Entregan el código fuente en un repositorio al que el cliente tiene acceso desde el primer día? Si el código vive en la máquina de un desarrollador o en un repositorio privado del proveedor al que vos no tenés acceso, al terminar el proyecto dependés completamente de ellos para cualquier modificación.
• ¿Documentan la arquitectura y las decisiones técnicas relevantes? No hace falta un tratado de cien páginas. Pero si dentro de seis meses otro equipo necesita modificar algo, debería poder entender por qué se tomaron ciertas decisiones sin tener que hacer arqueología del código.
• ¿Entregan credenciales y accesos a todos los servicios externos? Servidores, bases de datos, dominios, APIs de terceros. Si estos accesos quedan en manos del proveedor, tu independencia operativa es cero.
• ¿Documentan cómo instalar, desplegar y operar el sistema? Si el sistema deja de funcionar un domingo a las diez de la noche y el proveedor no está disponible, ¿alguien de tu equipo —o un tercero— puede levantarlo con la documentación disponible?

Criterio 5: Cómo manejan los problemas

Ningún proyecto de software sale exactamente como se planeó. Lo que distingue a un buen proveedor no es que no tenga problemas, sino cómo los gestiona.

En la conversación comercial, preguntá:

• "Si en tres meses descubrimos que algo que yo creía incluido ustedes lo consideran adicional, ¿cómo lo resolvemos?" Un proveedor con experiencia en este tipo de situaciones tiene una respuesta articulada: cómo documentaron el alcance inicial, cómo definen qué es un cambio, quién toma la decisión. Un proveedor sin experiencia dice "no va a pasar" o "lo resolvemos hablando".
• "Si un desarrollador clave del proyecto se va, ¿cómo afecta los plazos y qué mecanismos tienen para mitigarlo?" Si la respuesta es "nuestro equipo es estable, eso no pasa", están evitando la pregunta. Si describen un proceso —documentación interna, rotación planificada, períodos de solapamiento—, están mostrando madurez operativa.
• "Si el proyecto se interrumpe antes de terminar por razones ajenas a ustedes, ¿cómo me entregan lo construido hasta ese momento?" No es una pregunta cómoda, pero un proveedor serio tiene una respuesta preparada.

Criterio 6: El precio en contexto

El precio importa, pero no como número aislado. El precio tiene sentido solo en relación con el alcance, la calidad del equipo, la comunicación y la documentación que el proveedor ofrece.

Un proveedor que es más barato pero no documenta, no da referencias verificables y no tiene un proceso claro de definición de alcance probablemente termine costando más en el total: el sobrecosto no aparece en la cotización inicial, sino en los cambios de alcance no previstos, las funcionalidades que hay que rehacer y el tiempo interno que tu equipo dedica a perseguir avances y resolver malentendidos.

Un proveedor que es más caro pero invierte tiempo en entender el problema, documenta lo que construye, te da acceso al código desde el día uno y tiene referencias verificables de clientes que volvieron a trabajar con ellos probablemente termine costando menos en el total, aunque el número de la cotización sea más alto.

Cómo usar estos criterios sin que sea un interrogatorio

No hace falta aplicar los seis criterios en una sola reunión. Dos o tres por encuentro alcanzan, siempre que registres las respuestas y las compares entre proveedores con los mismos criterios. Llevar una planilla simple con los proveedores en las columnas y los criterios en las filas ayuda a que la decisión se base en datos y no en la impresión que dejó la última reunión.

El objetivo no es encontrar al proveedor perfecto —que no existe—, sino identificar qué brechas tiene cada uno y decidir con cuáles podés convivir. Un proveedor que es excelente en comunicación pero débil en documentación puede ser suficiente para un proyecto chico y bien acotado. Esa misma debilidad puede ser crítica en un proyecto grande con múltiples integraciones y un ciclo de vida largo.

Si querés un checklist más detallado de preguntas para hacer durante la evaluación, el artículo sobre preguntas que debes hacer antes de contratar un proveedor tecnológico cubre nueve preguntas clave agrupadas en proceso, comunicación y entregables. Y para complementar, el artículo sobre señales de alerta en una propuesta comercial te ayuda a identificar patrones que anticipan problemas antes de firmar.

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