Cómo elegir una software factory: 12 preguntas que separan las serias del resto

Elegir proveedor de software tiene un problema estructural: la asimetría de información es total. Vos no podés evaluar la calidad técnica de lo que te ofrecen, y ellos lo saben. Los portfolios se ven todos bien, las tecnologías que nombran son las mismas, y los presupuestos son incomparables entre sí porque cada uno entendió algo distinto.

La salida no es aprender a programar. Es hacer preguntas cuyas respuestas revelan cómo trabaja el proveedor, sin necesidad de que entiendas la tecnología. Estas son doce, en el orden en que conviene hacerlas, con lo que tenés que escuchar en cada caso.

Sobre el proyecto y el alcance

1. ¿Cómo llegan a un número? ¿Qué hacen antes de cotizar?

Lo que buscás: un proceso de relevamiento previo, aunque sea corto. Alguna forma de descubrimiento antes del precio.

Señal de alarma: un presupuesto formal después de una llamada de treinta minutos. No es agilidad, es adivinanza. Ese número o tiene un colchón enorme o va a crecer en el mes dos.

2. ¿Qué queda explícitamente afuera del alcance?

Lo que buscás: que tengan una respuesta preparada. Los equipos que trabajaron en serio a precio cerrado saben que el documento de exclusiones es tan importante como el de inclusiones.

Señal de alarma: "todo lo que necesites está incluido". Es imposible y garantiza una discusión en el mes tres.

3. ¿Cómo se manejan los cambios de alcance?

Lo que buscás: un mecanismo concreto. Cómo se pide, cómo se cotiza, quién aprueba, qué pasa con los cambios chicos.

Señal de alarma: que la pregunta los incomode, o "eso lo vamos viendo". Los cambios van a aparecer sí o sí. La diferencia entre un proyecto sano y uno conflictivo es si el mecanismo existía antes del primer cambio.

Sobre el equipo

4. ¿Quiénes van a trabajar en mi proyecto? Nombre y rol.

Lo que buscás: nombres concretos y disponibilidad real. Idealmente, conocer al que va a estar todos los días.

Señal de alarma: "un equipo de seniors" sin nombres. La práctica de vender con los perfiles fuertes y ejecutar con los que están libres es común y es difícil de detectar después.

5. ¿Cuántos proyectos tiene en paralelo esa persona?

Lo que buscás: una respuesta honesta y un número razonable. Que alguien esté en dos proyectos no es malo; que esté en cinco significa que no está en ninguno.

Señal de alarma: que no lo sepan.

6. ¿Quién va a ser mi contacto y con qué frecuencia hablamos?

Lo que buscás: una persona identificada y una cadencia fija. Una reunión semanal corta es mejor que "escribinos cuando necesites".

Señal de alarma: que el único contacto sea comercial y no tenga acceso técnico al proyecto. Vas a pasar meses jugando al teléfono descompuesto.

Sobre cómo trabajan

7. ¿Cada cuánto voy a ver algo funcionando?

Es la pregunta más importante de la lista.

Lo que buscás: entregas verificables cada una o dos semanas. No presentaciones ni informes de avance: el sistema andando, en un ambiente donde vos puedas entrar y probarlo.

Señal de alarma: "te mostramos cuando esté listo". Cuatro meses sin ver nada es cuatro meses sin poder detectar que se está construyendo algo distinto a lo que pediste. Los proyectos que fracasan casi nunca fracasan de golpe: fracasan de a poco, sin que nadie mire.

8. ¿Cómo pruebo yo que lo que entregaron está bien?

Lo que buscás: criterios de aceptación escritos por funcionalidad. Algo tan simple como "cuando el usuario hace X, el sistema tiene que hacer Y".

Señal de alarma: que la aceptación quede en la impresión general. Sin criterios, discutir si algo está terminado se vuelve una cuestión de opinión.

9. ¿Qué pasa si aparece un error después de entregado?

Lo que buscás: un período de garantía explícito —treinta, sesenta o noventa días son valores habituales— con una distinción clara entre error y funcionalidad nueva. Y un tiempo de respuesta comprometido.

Señal de alarma: que no exista garantía, o que todo error se cotice como trabajo adicional.

Sobre lo que queda cuando termina

10. ¿El código es mío? ¿Dónde vive?

Lo que buscás: repositorio a nombre de tu empresa desde el día uno, con vos como propietario y ellos como colaboradores. No al revés.

Señal de alarma: cualquier versión de "te lo entregamos al final". El código tiene que estar en tu poder mientras se escribe, no cuando termina la relación.

11. ¿A nombre de quién están la infraestructura y las cuentas?

Esta pregunta se olvida y es la que más ata. Servidor, base de datos, dominio, cuentas de Google Play y Apple, servicios de terceros, pasarelas de pago.

Lo que buscás: todo a nombre de tu empresa, con vos como administrador, y ellos con accesos que vos podés revocar.

Señal de alarma: que esté todo a nombre del proveedor "por comodidad". Es cómodo hasta el día que querés irte.

12. ¿Qué documentación me dejan?

Lo que buscás: como mínimo, cómo levantar el sistema desde cero, qué servicios externos usa y con qué credenciales, y un manual de uso para tu equipo. No hace falta un tratado; hace falta que otro equipo pueda tomar el proyecto.

Señal de alarma: "el código se documenta solo".

Dos verificaciones que valen más que las doce preguntas

Pedí hablar con un cliente cuyo proyecto haya terminado hace más de un año

No con el cliente estrella y reciente. Con uno viejo. Y preguntale tres cosas concretas:

• ¿El presupuesto final coincidió con el inicial? Si no, ¿por qué?
• ¿Cuánto se demoró respecto a lo prometido?
• ¿Qué pasó cuando necesitaste un cambio después de terminado?

Las respuestas a esas tres preguntas dicen más que cualquier portfolio.

Pedí ver un documento de alcance real de otro proyecto

Con los datos del cliente tachados. No importa el proyecto: importa el nivel de detalle. Vas a ver de inmediato si sus documentos definen cosas verificables o si son listas de deseos.

Un proveedor que trabaja en serio te lo muestra sin problema. Uno que no tiene documentos de ese tipo va a dar vueltas.

Cómo comparar presupuestos que no son comparables

Si pediste tres presupuestos y llegaron tres cosas distintas, es porque cada uno entendió un proyecto distinto. La solución no es pedir aclaraciones: es darles a todos el mismo documento.

Escribí vos —o pagá una etapa corta de relevamiento— un documento con: qué tiene que poder hacer el sistema el primer día de producción, quiénes lo usan, con qué se integra, y qué queda explícitamente para una segunda etapa. Mandáselo a los tres.

Los presupuestos que vuelvan van a ser comparables. Y el proceso tiene un beneficio adicional: cómo reaccionan a ese documento es información valiosa. El que lo lee y vuelve con preguntas incómodas y observaciones sobre cosas que no pensaste probablemente sea con el que quieras trabajar. El que lo lee y sólo pone un número, no.

Lo que no hay que mirar tanto

Para cerrar, tres cosas a las que se les da más peso del que tienen:

• La lista de tecnologías. Casi todos usan lo mismo. Lo que diferencia no es la herramienta sino cómo la usan.
• El tamaño de la empresa. Un equipo de cinco personas enfocado puede rendir mejor que uno de cincuenta que te asigna al que está libre. Lo que importa es quién trabaja en lo tuyo.
• El portfolio visual. Que las pantallas se vean lindas no dice nada sobre si el sistema funcionó, si se entregó a tiempo o si el cliente lo sigue usando.

Lo que sí importa: cada cuánto vas a ver algo funcionando, qué pasa cuando algo cambia, y de quién es el código cuando esto termine.