Qué preguntarle a quien te va a construir el software

Contratar desarrollo a medida tiene un problema de asimetría: quien lo vende sabe mucho más que quien lo compra, y las dos partes lo saben. La consecuencia habitual es que la conversación se decide por confianza y por precio, que son los dos peores criterios disponibles.

Estas son las preguntas que nosotros querríamos que nos hicieran. Van con la respuesta que debería encender una luz roja, porque una pregunta sin criterio para juzgar la respuesta no sirve de nada.

Y sí, están escritas sabiendo que también nos las vas a hacer a nosotros.

1. ¿Quién va a escribir el código, y hablaré con esa persona?

Mala señal: que la primera llamada sea con alguien que no va a tocar el proyecto, o que te presenten "el equipo" sin nombres.

Cada capa entre tú y quien construye es una traducción, y en cada traducción se pierde el matiz que hacía que tu caso fuera distinto del de al lado. Pregunta también quién estará en el mes seis, no solo en la semana uno.

2. ¿Cómo estimáis, y qué pasa si la estimación se cae?

Mala señal: una cifra cerrada por teléfono, antes de haber entendido el problema.

Nadie puede estimar con confianza lo que no ha acotado. Lo que sí se puede pedir es que haya una fase corta y pagada de descubrimiento con un entregable —alcance, riesgos y número— y que quede claro qué pasa cuando algo se tuerce: si lo absorbe el proveedor, si lo pagas tú, o si se recorta alcance.

Desconfía por igual del que te da una cifra inmediata y del que se niega a comprometerse con ninguna.

3. ¿Cuándo veré software funcionando?

Mala señal: "al final", o informes de progreso semanales en vez de la aplicación.

Un documento de avance no se puede usar. Una aplicación desplegada sí, y usarla es la única forma de descubrir que lo que pediste no era lo que necesitabas — mientras corregirlo todavía es barato. Si la primera vez que tocas el producto es en la entrega, el riesgo entero es tuyo.

4. ¿De quién es el código y dónde vive?

Mala señal: "en nuestra plataforma", licencias de un framework propio, o un repositorio al que no tienes acceso.

Debería estar en tu repositorio y tu nube desde el primer día. La prueba del algodón: pregunta qué tendrías que hacer para llevarte el proyecto a otro proveedor el mes que viene. Si la respuesta es incómoda, ya sabes cuánto vale tu poder de negociación dentro de un año.

5. ¿Qué pasa con lo que ya tengo instalado?

Mala señal: dar por hecho que todo el mundo estará en la última versión.

Esta se olvida siempre y es donde se rompen los proyectos de verdad. Si tienes una app publicada, integraciones o una API que usan terceros, hay clientes que no puedes forzar a actualizar. Nosotros escribimos sobre ello a raíz de migrar el esquema de LoverCast sin romper las apps instaladas, y la lección fue que "cero rotura" casi nunca es cero: lo que hay es decidir de antemano qué se degrada, para quién y durante cuánto tiempo.

Pregunta eso exactamente. Si te contestan que no romperá nada, no te han entendido o no lo han pensado.

6. ¿Cómo sabremos si funciona?

Mala señal: "cuando esté terminado".

Vale para todo, pero es crítico si hay IA de por medio. Un asistente que acierta el 90% de las veces se equivoca el 10% restante con una seguridad absoluta, y toda la ingeniería está en ese 10%: detectarlo, acotarlo y decidir qué ocurre cuando pasa. Si nadie propone una métrica antes de elegir el modelo, lo que te están vendiendo es una demo.

En nuestros propios productos aplicamos la misma vara: Isobaria publica cuánto se equivoca cada modelo, con la evidencia archivada y las limitaciones escritas. Es incómodo y es la única forma de que la cifra signifique algo.

7. ¿Qué no vais a hacer?

Mala señal: que todo encaje. Si tu proyecto entra perfecto en su catálogo, o eres muy afortunado o te están diciendo que sí a todo.

Un proveedor que sabe lo que hace sabe también lo que no, y decirlo pronto es lo único que hace creíble el sí. Nuestras páginas de servicio llevan una sección de "cuándo no somos para ti" por eso mismo.

8. ¿Qué pasa después de lanzar?

Mala señal: que el presupuesto termine el día del despliegue.

Publicar es el principio. Las tiendas obligan a mantener, los sistemas operativos migran, las dependencias caducan y la primera semana real siempre trae sorpresas. Pregunta quién responde a las tres de la mañana, cómo se despliega un arreglo y si se puede deshacer. Si desplegar un cambio es un evento, se desplegará poco, y cada entrega llevará más riesgo que la anterior.

Lo que nos llevamos

Ninguna de estas preguntas es técnica. Todas se pueden hacer sin saber programar, y todas se responden en la primera llamada.

Si te da apuro hacerlas, mira ese apuro con atención: vas a firmar un proyecto de meses con alguien a quien no te atreves a preguntar cómo estima. Cualquier proveedor que merezca tu dinero preferirá que las hagas.

Las nuestras están respondidas por escrito en el método, justamente para que puedas usarlo en la primera llamada para pedirnos cuentas. Si tienes un proyecto en la cabeza, cuéntanoslo.