Preguntas antes de contratar una empresa de software

Un contrato de desarrollo se firma una vez, pero lo que dice (y lo que no dice) te acompaña durante años. Por eso las preguntas antes de contratar una empresa de software no son un trámite: son la única parte del proceso en la que todavía tienes toda la capacidad de negociar. Después de firmar, cada respuesta que no pediste se paga.

Este artículo reúne las preguntas que conviene hacer a cualquier proveedor, sea quien sea, ordenadas por el riesgo que cubren. Para cada grupo te contamos cómo suena una buena respuesta y cómo suena una que debería preocuparte. No hace falta saber programar para distinguirlas: hace falta escuchar si la respuesta es concreta o se escapa por la tangente.

Una aclaración antes de empezar: hay otra lista de preguntas, igual de importante, que no va dirigida al proveedor sino a ti, sobre tu propio negocio. La tratamos en qué preguntar antes de pedir un presupuesto de software. Aquí hablamos de lo que tienes que preguntarle a quien te lo va a construir.

Propiedad: de quién es lo que pagas

Las preguntas. ¿En qué cuenta estará el repositorio con el código, y desde cuándo? ¿A nombre de quién irán la nube, el dominio y los servicios que use la aplicación? ¿Qué dice el contrato sobre los derechos del código?

Buena respuesta: «en tu cuenta desde el primer día, y tú nos das acceso a nosotros». Lo importante es el «desde el primer día»: no al terminar, no al pagar la última factura. Mala respuesta: «te lo pasamos todo al final del proyecto». Mientras tanto, tu negocio depende de que la relación vaya bien. Lo explicamos con detalle en de quién es el código de tu software.

Precio y cambios de alcance: quién paga cuando algo cambia

Las preguntas. Si el precio es cerrado, ¿qué pasa exactamente cuando aparezca algo que no estaba previsto? Si se equivocan estimando, ¿quién paga esas horas? ¿Puedo pausar o reducir el ritmo sin penalización?

Buena respuesta: una explicación concreta de cómo se gestiona un cambio (se estima, se aprueba por escrito y se incorpora) y quién asume los errores de estimación del proveedor. Los cambios de alcance ocurren en todos los proyectos, y un buen proveedor lo da por hecho en lugar de fingir que no pasará. Mala respuesta: «el precio es cerrado, no te preocupes». Un precio cerrado sin un mecanismo claro para los cambios solo traslada la discusión al día en que aparezca el primero, que será pronto.

Quién trabaja en tu proyecto

Las preguntas. ¿Qué perfiles van a trabajar, y con qué experiencia? ¿Quién será mi interlocutor, y estará en las reuniones de principio a fin? ¿Alguna parte se subcontrata a otra empresa?

Buena respuesta: nombres, perfiles y una persona técnica que te acompaña todo el proyecto. Mala respuesta: un gestor de cuentas que traslada tus decisiones a un equipo que no conocerás nunca. No es necesariamente mala fe, pero cada intermediario es un sitio donde se pierde información, y en software la información perdida se convierte en trabajo rehecho.

Entregas: qué vas a ver y cuándo

Las preguntas. ¿Cada cuánto veré algo funcionando? ¿Podré probarlo yo, con mis datos, o solo me lo enseñarán en una demo? ¿Qué recibo exactamente en la primera entrega?

Buena respuesta: un ritmo fijo, por ejemplo cada dos semanas, con software que puedes tocar y una primera entrega descrita con precisión. Mala respuesta: «te lo enseñamos cuando esté terminado». Lo que se puede probar no se puede maquillar; lo que solo se describe en informes de progreso, sí. Si quieres más señales de este tipo, las reunimos en cómo elegir equipo de desarrollo sin ser técnico.

Calidad y errores: qué pasa cuando algo falla

Las preguntas. ¿Quién prueba lo que se entrega antes de que llegue a mí? ¿Qué garantía dais por escrito y durante cuánto tiempo? Si el sistema falla un sábado por la noche, ¿quién se entera y qué pasa?

Buena respuesta: pruebas hechas por alguien distinto de quien programó, una garantía escrita con plazo concreto y un plan para las incidencias, aunque sea sencillo. Mala respuesta: «nuestro código no falla», o una garantía que no aparece en ningún documento. Todo software falla alguna vez; la diferencia está en cómo se gestiona, y es justo lo que contamos en la diferencia está en cómo gestionas los errores.

Salida: con qué te vas si la relación termina

Las preguntas. Si mañana quiero seguir con otro equipo, ¿qué me entregáis exactamente? ¿Qué documentación se escribe, y cuándo: durante el desarrollo o el último día? ¿Hay alguna parte del sistema que no funcione sin vosotros?

Buena respuesta: una lista concreta (código, accesos, documentación, una sesión de traspaso) y la idea de que la documentación se escribe mientras se construye. Mala respuesta: dudas, rodeos o una pieza propia del proveedor sin la que tu aplicación no arranca. En una parte del sector, que irse sea más caro que quedarse es precisamente el modelo de negocio, como contamos en desarrollo barato, mantenimiento caro.

Mantenimiento: qué es obligatorio y qué no

Las preguntas. ¿Hay una cuota de mantenimiento obligatoria? ¿Qué incluye y qué no? ¿Tiene permanencia? ¿Puede hacerlo otro equipo, o mi propio equipo, si lo prefiero?

Buena respuesta: mantenimiento opcional, con lo que incluye por escrito y sin permanencia. Mala respuesta: una cuota obligatoria que no se puede desglosar. Puede ser legítima, pero tienes que saber que la estás comprando antes de firmar, no después.

Datos: dónde viven y quién responde de ellos

Las preguntas. ¿Dónde se alojarán los datos de mis clientes? ¿Están cifrados y con copias de seguridad? ¿Firmamos un contrato de encargado del tratamiento antes de empezar?

Buena respuesta: una ubicación concreta, cifrado, copias periódicas y el contrato de encargado del tratamiento como paso previo, no como favor. Mala respuesta: «eso ya lo vemos». Si el software maneja datos personales, esta parte no es opcional, y un proveedor serio la saca él antes que tú.

Las señales de alarma

Más allá de cada respuesta, hay patrones que conviene reconocer. Que el proveedor no haga ninguna pregunta sobre tu negocio antes de dar un precio. Que el total llegue en cuatro líneas, sin desglose: es la lección de el presupuesto del cerrajero. Que te prometa un plazo total antes de entender el alcance. Que se incomode con estas preguntas o te pida que confíes. Ninguna de estas señales demuestra mala fe por sí sola, pero varias juntas dicen mucho de cómo será la relación cuando aparezcan los problemas.

Cómo las respondemos nosotros

Para no quedarnos en la teoría: el código, el repositorio y la nube van a tu nombre desde el primer día. Trabajamos con la tarifa publicada y entregas cada dos semanas que puedes probar, con la misma persona técnica en todas las reuniones. La garantía es de seis meses y está por escrito, el mantenimiento es opcional y sin permanencia, y la documentación se escribe mientras construimos, para que otro equipo pueda continuar si un día lo decides.

Así planteamos cualquier desarrollo de software a medida, y nos parece bien que nos hagas estas mismas preguntas, y que se las hagas también a los demás. Si quieres hacérnoslas en persona, cuéntanos tu proyecto y las contestamos en la primera conversación.