Elegir un proveedor informático: 10 preguntas que hacerle

Agencia de desarrollo, empresa de desarrollo de software, profesional independiente, consultora: sobre el papel, las ofertas se parecen. Todas prometen calidad, y los presupuestos son difíciles de comparar. Sin embargo, elegir un proveedor informático significa confiarle su código, sus datos y una parte de su actividad, a menudo durante varios años.

¿La forma más fiable de decidir entre los candidatos? Hacerles a todos las mismas preguntas y comparar las respuestas. Aquí tiene diez, con lo que revelan y las respuestas que cabe esperar.

Antes de elegir un proveedor informático, prepare el terreno

Tres precauciones hacen que la comparación sea más justa:

• Describa su necesidad en unas pocas páginas: el problema que hay que resolver, los usuarios, las herramientas existentes, el plazo. El documento no tiene que ser perfecto: nuestro método para redactar un documento de requisitos de software le ayuda a quedarse con lo esencial.
• Envíe el mismo documento a todos los proveedores, para comparar respuestas a una misma pregunta.
• Prefiera una conversación a un formulario. Un buen socio se interesa por su actividad antes de hablar de tecnología, y le dice con franqueza cuando no es la opción adecuada.

El marco: propiedad, método y demostraciones

1. ¿A quién pertenecerán el código fuente y los datos?

Es la primera pregunta que hay que hacer, porque todo lo demás depende de ella. Sin derechos sobre el código, puede que no logre hacerlo evolucionar sin su proveedor, ni confiarlo a otro. En Francia, por ejemplo, pagar el desarrollo no basta para ser su propietario: la cesión de los derechos de autor debe preverse expresamente en el contrato.

La respuesta que cabe esperar: el código fuente, los datos y la documentación le pertenecen, y el contrato lo dice por escrito. La única excepción legítima: los componentes de terceros y las herramientas genéricas del proveedor siguen sujetos a su propia licencia, que debe permitirle seguir utilizándolos. Pregunte también cuándo se entregará el código: según el proyecto, puede ser de forma continua, en un repositorio al que usted tenga acceso (en GitHub o GitLab, por ejemplo), o en hitos acordados de antemano, cuando el trabajo no se divide en partes entregables. Lo importante es que esos hitos figuren en el contrato.

2. ¿Cómo van a trabajar con nosotros?

Ágil, Scrum o modelo en V: la etiqueta importa menos que el funcionamiento real.

La respuesta que cabe esperar: iteraciones cortas, un interlocutor dedicado, prioridades fijadas con usted y una regla clara para gestionar las nuevas peticiones que surjan por el camino. Desconfíe de un proveedor que desaparece durante meses y vuelve con el software terminado: cada mes sin ver nada es un mes de posibles malentendidos.

3. ¿Cuándo veremos algo que funcione?

Una demostración vale más que cualquier cantidad de informes de avance.

La respuesta que cabe esperar: maquetas navegables antes del desarrollo y, después, una demostración al final de cada iteración, en un entorno de pruebas en el que sus equipos experimentan por sí mismos, con sus propios casos. Una primera versión debería poder usarse pronto, sin esperar al final del proyecto: en el CRM/ERP de un bufete de abogados de Sídney, un proyecto que nuestro fundador dirigió como director de TI en DIGIIT Solutions, el bufete pudo usar una primera versión en menos de seis meses.

La calidad: pruebas, seguridad y documentación

4. ¿Cómo prueban lo que entregan?

Sin pruebas automatizadas, un software se vuelve frágil enseguida: cada corrección corre el riesgo de romper otra parte.

La respuesta que cabe esperar: pruebas automatizadas escritas al mismo tiempo que el código y ejecutadas con cada cambio, una fase de aceptación en la que usted verifica y aprueba antes de cada paso a producción, y una garantía que cubre los defectos detectados tras la entrega, durante un periodo definido. Unas comprobaciones puramente manuales, o delegadas en sus equipos, no bastan: las pruebas de aceptación sirven para aprobar el trabajo, no para encontrar los errores en lugar del proveedor.

5. ¿Cómo protegerán nuestra aplicación y nuestros datos?

La seguridad no se añade al final: se prevé desde el diseño.

La respuesta que cabe esperar: accesos según el rol, contraseñas y claves almacenadas de forma segura, copias de seguridad cuya restauración se prueba, actualizaciones periódicas y datos reales que no se copian en los equipos de los desarrolladores. Si el proveedor trata datos personales por cuenta de usted y su empresa está sujeta al RGPD europeo, el reglamento exige además un contrato que regule lo que el proveedor puede hacer con esos datos.

6. ¿Qué documentación nos entregarán?

La documentación es lo que permitirá que otra persona retome su software mañana.

La respuesta que cabe esperar: una documentación técnica (arquitectura, instalación, despliegue), una guía de usuario y un registro de las decisiones importantes. Se redacta a medida que avanza el proyecto, no la última semana, y se le entrega junto con el código.

El equipo, la vida después del proyecto y las referencias

7. ¿Quién trabajará realmente en nuestro proyecto?

La persona que presenta la propuesta no siempre es la que la llevará a cabo.

La respuesta que cabe esperar: los nombres y las funciones de las personas que intervendrán, el interlocutor que seguirá su proyecto en el día a día y una transparencia total sobre una posible subcontratación. Pregunte también qué ocurre si alguien deja el equipo: la documentación y el código compartido deberían permitir un relevo sin sobresaltos.

8. ¿Qué ocurre después de la puesta en marcha?

Un software vive durante años: hay que mantenerlo en funcionamiento, protegerlo y hacerlo evolucionar.

La respuesta que cabe esperar: una oferta de mantenimiento que precise lo que cubre (correcciones, actualizaciones de seguridad, pequeñas mejoras), unos plazos de respuesta por escrito según la gravedad del problema y un costo previsible, por ejemplo una suscripción mensual.

9. ¿Y si queremos cambiar de proveedor?

A nadie le gusta hablar de ruptura en el momento de firmar. Sin embargo, es el mejor momento para hacerlo: todo el mundo está lleno de buena voluntad.

La respuesta que cabe esperar: una cláusula de salida que prevea la entrega del código, de los datos en un formato utilizable, de la documentación y de todos los accesos, con un periodo de transición. Un consejo sencillo: desde el principio, abra las cuentas esenciales (alojamiento, nombre de dominio, tiendas de aplicaciones) a nombre de su empresa. Un proveedor seguro de su trabajo no tiene ningún motivo para atarle por contrato.

10. ¿Pueden mostrarnos proyectos comparables?

Las referencias son la mejor prueba, siempre que se sepan leer.

La respuesta que cabe esperar: proyectos similares al suyo, explicados de forma concreta (la necesidad, la solución, el papel exacto del proveedor y el resultado). Si es posible, hable con un antiguo cliente. Y, para cada resultado expresado en cifras, pregunte cómo se midió.

Antes de firmar: lo que debe precisar el contrato

Las buenas respuestas en una reunión también deben quedar por escrito. Compruebe que la propuesta o el contrato precisan claramente:

• el alcance y la lista de entregables;
• el calendario, con sus hitos y sus demostraciones;
• el modelo de facturación (precio cerrado, por jornada o por suscripción) y la forma de gestionar las nuevas peticiones;
• la cesión de los derechos sobre el código y la propiedad de sus datos;
• la aceptación: quién aprueba y con qué criterios;
• la garantía tras la entrega;
• el mantenimiento: lo que incluye y sus plazos de respuesta;
• la seguridad y, si confía datos personales, las cláusulas que exige el RGPD;
• la salida: lo que se le entrega si se va y en qué plazo;
• las personas que trabajarán en el proyecto y la posible subcontratación.

Para las cláusulas jurídicas, el consejo de un abogado sigue siendo muy valioso.

Preguntas frecuentes

Profesional independiente, agencia o empresa de desarrollo de software: ¿cuál elegir?

Todo depende del proyecto. Un profesional independiente encaja en un encargo bien definido, siempre que se prevea la continuidad en caso de ausencia. Una agencia de desarrollo suele especializarse en sitios y aplicaciones web. Una empresa de desarrollo de software o una consultora suele abarcar un perímetro más amplio: diseño, integraciones, seguridad, mantenimiento. En todos los casos, la pregunta 7 sigue siendo decisiva: ¿quién trabajará realmente en su proyecto?

¿Hay que elegir el presupuesto más barato?

No necesariamente. Dos presupuestos no siempre cubren el mismo trabajo: las pruebas, la documentación, la migración de datos o el mantenimiento pueden estar incluidos en uno y faltar en el otro. Compare en igualdad de condiciones, incluido el mantenimiento de los años siguientes. Para entender lo que realmente determina el precio, lea nuestro artículo sobre el costo de un software a medida.

¿Se puede trabajar con un proveedor a distancia?

Sí, si la comunicación está bien organizada: videollamadas periódicas, demostraciones, horarios de trabajo que coincidan en parte y un idioma de trabajo común. Pregunte también quién responde en caso de urgencia, y a qué hora. La distancia importa menos que la claridad.

En resumen

Un buen proveedor informático no se reconoce por sus promesas, sino por la precisión de sus respuestas. Haga estas diez preguntas a cada candidato y pida que las respuestas figuren en el contrato.

Pregúntenos también a nosotros: nuestras preguntas frecuentes ya responden a varias de ellas (propiedad del código, desarrollo de los proyectos, soporte tras la puesta en marcha, recuperación del control), y con gusto repasamos las demás en una llamada. ¿Tiene un proyecto de software a medida, de aplicación web o de herramienta empresarial? Reserve una llamada exploratoria gratuita de 30 minutos: escuchamos sus necesidades y, si no somos las personas adecuadas para el trabajo, se lo decimos.