Cómo contratar software sin equivocarse: qué preguntar y qué exigir

Los proyectos de software casi nunca fracasan programando. Fracasan antes, en la conversación donde nadie preguntó lo incómodo. Y se descubre tarde: cuatro meses después, cuando el sistema hace lo que se dijo y no lo que hacía falta, y ya nadie se acuerda de quién dijo qué.

Lo que sigue es lo que nos gustaría que nos preguntaran a nosotros. Son las preguntas que filtran de verdad y el documento que cualquier proveedor serio debería entregarte antes de que le pagues el desarrollo completo.

Primero: escribí qué te duele, no qué querés

Antes de llamar a nadie, escribí una página. No una especificación técnica: una página en tu idioma, sobre lo que te está costando trabajo.

• Qué proceso duele y quién lo sufre. «El cierre de caja lo hace el encargado a mano y no cuadra» dice más que «necesito un sistema de ventas».
• Qué querés que cambie en concreto. Tres o cuatro objetivos, no treinta funciones.
• Qué sistemas ya tenés y no vas a tirar. Esto define la mitad del trabajo.
• Para cuándo y por qué esa fecha. Si es porque arranca el año fiscal, decilo; cambia el orden de entrega.
• Qué no puede pasar. «No podemos dejar de facturar ni un día» es una restricción más importante que cualquier función.

Una página honesta sobre el problema sirve más que veinte de requisitos copiados de internet. Y te deja comparar propuestas: si tres proveedores responden a lo mismo, las diferencias entre ellos se vuelven visibles.

Un consejo que ahorra mucho: no pidas la tecnología. Decir «lo quiero en tal lenguaje» cuando nadie en tu empresa va a mantener ese código es amarrarte las manos sin ganar nada. Dejá que el proveedor la proponga y te la justifique. Esa justificación, por cierto, es una de las preguntas que filtran.

Las preguntas que filtran

Hacelas todas, a todos, y pedí las respuestas por escrito. No es desconfianza: es que lo escrito se puede comparar y lo dicho en una reunión no.

• ¿De quién es el código cuando terminemos? Y con él: el esquema de la base de datos, los datos, las instrucciones para montarlo en otro servidor. Si esta respuesta no es clara y por escrito, lo demás da igual.
• ¿Quién va a trabajar en esto, con nombre? No el tamaño del equipo. Quién. Y qué parte de su tiempo. Es común que te venda el socio y lo programe alguien que nunca viste.
• ¿Qué pasa si a mitad del proyecto pido un cambio? Vas a pedirlo. Lo que importa es si hay un mecanismo escrito o si se resuelve discutiendo.
• Mostrame algo parecido, funcionando. No capturas de pantalla: una dirección, un cliente con el que pueda hablar, algo verificable.
• ¿Qué pasa si desaparecen? Pregunta fea y necesaria. La respuesta correcta es que no importa demasiado, porque el código, la documentación y los accesos están en tu poder.
• ¿Qué incluye el soporte y qué no? Que esté escrito qué es un error a corregir sin costo y qué es una mejora que se cobra. Esa frontera es el origen de casi todas las peleas posteriores.
• ¿Qué necesitás de mi lado? Un proveedor que no te pida nada no entendió el proyecto. Todo sistema necesita datos, decisiones y tiempo de tu equipo.

La última es la más reveladora de todas. Las respuestas serias incluyen trabajo tuyo: alguien que decida, alguien que pruebe, alguien que limpie los datos viejos. Si te prometen que no vas a tener que involucrarte, o no te creen capaz o no van a hacer el trabajo bien.

El documento que tiene que entregar antes de cobrar el desarrollo

Esta es la parte que más cambia el resultado de un proyecto y la que casi nadie exige. Antes de pagar el desarrollo completo, el proveedor tiene que entregarte un documento de alcance. No una cotización: un alcance.

Tiene que contener, como mínimo:

• Los procesos tal como son hoy, escritos por él después de hablar con tu gente. Si no puede describir cómo trabajás ahora, no puede construir cómo vas a trabajar.
• Las excepciones. La lista de los «sí, pero cuando…». Es la parte más valiosa y la que determina el costo real.
• Qué queda fuera, dicho explícitamente. Un alcance sin exclusiones no es un alcance.
• El orden de entrega. Qué funciona primero, qué después. Entregas parciales que se puedan usar, no un único día de estreno al final.
• Qué significa «terminado» para cada parte: la condición concreta que, cumplida, cierra ese punto sin discusión.
• Qué te toca a vos y para cuándo. Datos, decisiones, personas disponibles.

El documento de alcance es el entregable más importante del proyecto, y es el único que podés evaluar antes de haber gastado casi nada.

Pedirlo tiene dos efectos. Uno: te deja ver cómo piensa el proveedor antes de comprometerte con él. Dos: ese documento es tuyo y te sirve con cualquier otro, porque con el alcance escrito las propuestas se vuelven comparables.

Nosotros lo llamamos auditoría de procesos y es lo primero que hacemos en desarrollo de software. Si querés ver cómo esos procesos se reparten en módulos antes de la reunión, está en sistemas.

Las respuestas que son una señal de alarma

• «Depende» en todo. En el precio es razonable antes del alcance. En quién va a trabajar, en el plazo y en qué incluye el soporte, no.
• Una propuesta notablemente más barata que el resto. Rara vez es eficiencia. Casi siempre es la misma propuesta con cosas quitadas, que van a volver después como trabajo adicional.
• «Trabajamos ágil» sin explicar cómo. Preguntá cada cuánto vas a ver algo funcionando y quién te lo va a mostrar. Si no hay respuesta, la palabra no significa nada.
• Decir sí a todo. Un proveedor que no te contradice nunca no está escuchando. En una conversación de verdad, alguien debería decirte que una de tus ideas no conviene y explicarte por qué.
• Un plazo que suena increíble. Suele serlo. Preguntá qué queda fuera para que ese plazo se cumpla; siempre queda algo.

Cómo comparar al final

Cuando tengas las propuestas, no las ordenes por el total. Compará estas cosas, en este orden:

• Qué entiende cada uno del problema. Se nota en cómo describe tu operación.
• Qué incluye y qué excluye, lado a lado. Casi siempre no están cotizando lo mismo.
• Qué va a costar el segundo año, no el primero.
• Quién trabaja, con nombre, y cuánto de su tiempo.
• Qué casos parecidos pudiste verificar por tu cuenta.

Si ninguna propuesta te convence, lo más probable es que el problema esté en tu página inicial, no en los proveedores. Reescribila con lo que aprendiste preguntando y volvé a pedir. Es mucho más barato repetir esa vuelta que arrancar un proyecto con el alcance borroso.

Si parte de lo que vas a contratar es un sitio y no un sistema, los errores típicos de ese lado los juntamos en errores al contratar una página web.