Contratar desarrollo de software se parece bastante a contratar una reforma. Pides tres presupuestos, te llegan tres números que se diferencian en un factor de cuatro, y no tienes forma evidente de saber cuál corresponde a un trabajo bien hecho. La diferencia es que en una reforma, al menos, ves la obra.
Escribimos esto desde Sevilla y trabajamos con empresas de aquí y del resto de España. Lo que sigue es lo que nosotros miraríamos si estuviéramos al otro lado de la mesa.
Por qué la proximidad todavía importa (y por qué no siempre)
El desarrollo se puede hacer en remoto, evidentemente. Nosotros trabajamos así con clientes de fuera. Pero hay tres situaciones en las que tener al equipo cerca cambia el resultado:
Cuando hay que entender un proceso físico. Si vas a digitalizar un almacén, un taller o una consulta, la diferencia entre que alguien lo vea con sus ojos y que lo lea en un documento es enorme. Media hora en el sitio ahorra semanas de malentendidos.
Cuando el proyecto es largo. Poder sentarse en la misma mesa cada pocas semanas mantiene el proyecto pegado a la realidad del negocio.
Cuando la empresa no tiene perfil técnico interno. Si nadie de tu equipo puede traducir entre negocio y tecnología, la cercanía compensa esa falta.
Si tu proyecto es acotado y tienes claro lo que quieres, el proveedor puede estar donde sea. No pagues por proximidad si no la vas a usar.
Lo que de verdad diferencia a unos de otros
Que te digan que no
Es la señal más fiable y la más contraintuitiva. Un proveedor que acepta todo lo que le pides sin objetar nada no te está escuchando: te está vendiendo. Nosotros hemos terminado fases de descubrimiento recomendando comprar una herramienta que ya existe en lugar de desarrollar. Se pierde el proyecto y se gana un cliente que vuelve.
Desconfía de la reunión en la que todo lo que propones es “sin problema, eso lo hacemos”.
Que pregunten antes de presupuestar
Si te dan precio sin haber entendido el alcance, ese precio es ficticio. O se lo comen ellos, o te llega en forma de “esto no estaba incluido” en el mes cuatro.
Que el código sea tuyo
Pregúntalo explícitamente y que conste por escrito: el código, el repositorio y los accesos a la infraestructura son tuyos. Si el proveedor se lo queda, no has comprado software: has alquilado una dependencia.
Que sepas quién escribe el código
Es legítimo subcontratar. Lo que no es legítimo es que no te lo digan. Pregunta quién va a estar en el proyecto y si vas a poder hablar con esas personas.
Cómo comparar tres presupuestos que no se parecen en nada
El error habitual es comparar la cifra final. La cifra final no dice nada si el alcance de cada uno es distinto, que es lo normal.
Haz esto en su lugar:
- Escribe tú una lista de funcionalidades en lenguaje llano, antes de pedir nada. Diez o quince líneas bastan.
- Pide a los tres que presupuesten esa lista, no su interpretación de tu idea.
- Exige desglose por fases: descubrimiento, diseño, desarrollo, pruebas, publicación.
- Pregunta qué pasa fuera del alcance: precio por hora o por punto de función para lo que surja.
- Pregunta por el mantenimiento del año siguiente, antes de firmar el primero.
Cuando lo tengas, verás que la diferencia de precio casi siempre se explica por lo que cada uno ha entendido, no por lo caros que son.
Señales de alarma
- Precio cerrado en la primera llamada. Ya lo hemos dicho, pero es la más frecuente.
- No hay fase de diseño. Si se pasa de la idea al código, alguien va a diseñar sobre la marcha, y ese alguien será un programador improvisando pantallas.
- “Te lo hago con una plantilla”. Puede estar bien para una web sencilla. No lo está para software de negocio.
- No hablan de mantenimiento. Significa que no piensan estar ahí.
- Enseñan proyectos pero no dicen qué hicieron en ellos. Muchos portfolios incluyen trabajo donde el proveedor puso una parte pequeña.
- Presión por firmar rápido. El software no caduca en 48 horas.
Sobre los portfolios que no puedes ver
Aquí una cosa incómoda y honesta: buena parte del trabajo de desarrollo a medida está bajo acuerdo de confidencialidad. Un proveedor serio a menudo no puede enseñarte el software interno que ha construido para otra empresa.
Eso no es excusa para no enseñar nada. Lo que sí puede hacer es explicarte el problema y la solución sin nombrar al cliente, enseñarte producto propio, o ponerte en contacto con alguien que dé referencias. En nuestro caso, lo que podemos abrir de par en par es Bipsy, nuestro producto propio: se ve cómo lo pensamos, cómo lo diseñamos y en qué punto está.
Preguntas para la primera reunión
Llévalas escritas. Las respuestas te van a decir más que cualquier presentación:
- ¿Qué necesitáis saber de mi negocio antes de dar un precio?
- ¿Quién va a escribir el código y podré hablar con esa persona?
- ¿De quién es el código y dónde va a estar alojado?
- ¿Qué pasa si a mitad de proyecto cambio de idea sobre algo?
- ¿Qué incluye el mantenimiento y qué cuesta al año?
- ¿Qué proyecto habéis rechazado últimamente y por qué?
La sexta es la que más información da. Quien no ha rechazado nunca nada, acepta cualquier cosa.
Si estás en ese punto y quieres una conversación sin compromiso, cuéntanos qué tienes entre manos. Y si quieres ver antes cómo enfocamos cada tipo de proyecto, están detallados en nuestros servicios.
