Qué pedirle a un proveedor antes de firmar un desarrollo de software

Lo que tiene que estar por escrito

El alcance, con criterios de aceptación. «Módulo de pedidos» no basta. Tiene que decir qué debe poder hacer alguien con él para que la fase se dé por buena. Sin ese criterio, «terminado» es una opinión y la discusión llega en el peor momento.

Las fases, y qué entra en la primera. Un proyecto por fases se puede parar sin perderlo todo. Uno que solo se entrega al final te deja sin capacidad de reaccionar durante meses.

La propiedad. El código, los datos, los repositorios y los accesos son tuyos, y por escrito. Si el proveedor conserva la propiedad y te licencia el uso, has alquilado un software cuyo desarrollo además pagaste tú.

Las dependencias de terceros. Qué servicios de pago hacen falta para que aquello funcione, quién los contrata y a nombre de quién. La sorpresa clásica llega el día que el dominio, el hosting o la cuenta del proveedor de correo están a nombre de la agencia.

Qué pasa después de la entrega. Cuánto dura la garantía sobre errores, qué se considera error frente a mejora y qué modelo de mantenimiento hay. Un software sin plan para el día siguiente empieza a degradarse desde la primera semana; lo desarrollamos en qué incluye el mantenimiento de un software.

La salida. Qué ocurre si decides parar en la fase dos, qué se te entrega, en qué estado y con qué documentación. Si no está escrito, se negocia justo cuando la relación ya se ha roto.

Lo que debe quedar en tus manos al cerrar cada fase

El contrato dice que el software es tuyo. Esta lista comprueba si lo es en la práctica. Al terminar cada fase deberías poder contestar que sí a todas estas preguntas.

• ¿Puedes tener el repositorio del código con solo pedirlo?
• ¿Sabes dónde está alojada la aplicación y a nombre de quién están las cuentas críticas (dominio, hosting, servicios de pago)?
• ¿Hay documentación suficiente para que otro desarrollador se incorpore?
• ¿Está escrito cómo se despliega una versión nueva?
• ¿Sabes cómo se restaura una copia de seguridad?
• ¿Conoces los servicios externos de los que depende?
• ¿Sabes dónde se consultan los errores y quién recibe los avisos?

Si alguna respuesta depende de que el proveedor quiera, dependes de él, diga lo que diga el contrato.

Las cinco preguntas

1. ¿Qué NO incluye este presupuesto? Es la pregunta más rentable de toda la conversación. Un proveedor que ha analizado el proyecto tiene una lista preparada; uno que ha estimado por encima se queda en blanco.
2. ¿De qué supuestos depende el precio? Todo presupuesto de software descansa sobre suposiciones (que el ERP tiene API, que los datos están limpios, que alguien decidirá a tiempo). Pide que las escriba. Cuando una se cae, ya sabéis los dos por qué cambia el número.
3. ¿Quién va a programar esto? Ojo, que no es lo mismo que quién lo vende o quién lo dirige. Si la respuesta es vaga, o si el equipo cambia entre la propuesta y el arranque, el criterio que compraste no es el que vas a recibir.
4. ¿Qué pasa si aparece una integración que no estaba prevista? Aquí se va el dinero en casi todos los proyectos. Más que la respuesta, interesa el procedimiento: cómo se valora y quién lo aprueba.
5. ¿Cómo se sale de esto? Preguntarlo antes de empezar dice mucho de la relación. Quien lo tiene claro y lo cuenta sin incomodarse suele ser también quien menos problemas te va a dar.

Cómo comparar dos presupuestos que no se parecen en nada

Es lo normal. Pides tres presupuestos y vuelven tres proyectos distintos con precios que no se pueden restar. Antes de mirar el importe, iguala tres cosas.

• El alcance. Si uno incluye la migración de los datos históricos y otro no, estás comparando cosas distintas. Pon las dos propuestas en una tabla por funcionalidad y verás aparecer los huecos.
• El horizonte. Suma tres años de desarrollo, mantenimiento y licencias de terceros, más lo que cuesta el cambio si hay que rehacerlo. El más barato de comprar rara vez es el más barato de tener.
• Lo que queda tuyo. Dos propuestas al mismo precio no valen lo mismo si una te deja el código y la documentación y la otra te deja atado.

La forma más eficaz de igualarlas es no dejar que cada proveedor defina su propio alcance y llevar el tuyo escrito de antemano. De eso va un Discovery.

Señales de alarma

• Presupuesto cerrado sin haber preguntado casi nada. O ha hecho este proyecto exacto veinte veces, o el precio lleva un colchón que pagas tú.
• Sin plazos por fases, solo una fecha final. No hay forma de saber si vais tarde hasta que ya es tarde.
• Nadie ha pedido hablar con quien ejecuta el proceso. Va a construir el proceso que le contaron en la reunión.
• La documentación aparece como extra. Documentar forma parte de entregar.
• Prisa por firmar. Un descuento con fecha de caducidad es una técnica de venta y no tiene nada que ver con el proyecto.

Lo que sí es razonable que el proveedor te pida a ti

La responsabilidad no es toda de un lado. Un proyecto se tuerce igual de rápido cuando el cliente no aporta un interlocutor con capacidad de decidir, no da acceso a los sistemas a tiempo o cambia de criterio cada dos semanas. Si te piden por escrito quién decide y en cuánto tiempo, es buena señal. Significa que han visto proyectos encallar por eso.

Nuestra versión

Nosotros no firmamos desarrollos con un alcance de dos párrafos. Cuando el proyecto no está definido, empezamos por un Discovery. El documento que sale es del cliente, y con él puede pedir presupuestos a quien quiera, nosotros incluidos. Y en lo que construimos, el código y los datos son de la empresa, sin licencias por usuario ni cuotas que conviertan la propiedad en alquiler.