Qué exigir en la entrega
Cómo revisar el sistema que te entregaron: diez comprobaciones en una hora
En una hora, sin saber programar, puedes comprobar diez cosas: que las pruebas existen y corren, que el manual técnico está escrito, que el respaldo se restaura de verdad, que los permisos viven en la base de datos, que el código y las cuentas están a tu nombre, y que lo que no se entregó está dicho por escrito. Si alguna falla, todavía estás a tiempo.
Publicado el · 9 minutos · César Barreto
El momento de revisar es antes del último pago, no seis meses después. Y no hace falta un perito: nueve de estas diez comprobaciones las puede hacer el dueño con el proveedor sentado al lado, pidiéndole que enseñe algo en pantalla. La décima es una llamada.
Una regla que ahorra discusiones: todo lo que se pide aquí se comprueba en vivo, no con un informe en PDF. Un informe se escribe; una suite de pruebas se ejecuta delante de ti en un minuto.
Las diez comprobaciones
- 01
Pide ver las pruebas automatizadas corriendo
En pantalla, con el conteo al final. No un reporte: la ejecución. Si existen, toma menos de un minuto; si no existen, la respuesta será que las pruebas se hicieron a mano.
- 02
Pide que rompan una regla a propósito
Que cambien delante de ti el cálculo de un descuento o de un total, y vuelvan a correr. Si nada falla, las pruebas no cubrían eso. Es la diferencia entre tener pruebas y tener pruebas que sirven.
- 03
Pregunta qué pasa si una prueba falla al publicar
La respuesta correcta es que la publicación se detiene. Si es que se revisa después, las pruebas son decorativas y no van a impedir que un cambio rompa el cobro.
- 04
Abre el manual técnico y busca el modelo de datos
No hace falta entenderlo: hace falta que exista. Un sistema sin documento técnico solo lo puede continuar quien lo escribió, y eso es un costo que se paga después.
- 05
Pide una restauración del respaldo, hoy
Que tomen el respaldo de anoche y lo levanten en una base vacía delante de ti. Un respaldo que nunca se ha restaurado no es un respaldo: es un archivo con esperanza.
- 06
Comprueba dónde vive el respaldo
Una de las copias tiene que estar en una cuenta tuya, a la que tú tengas acceso sin pedir permiso. Si todas están en la cuenta del proveedor, tu continuidad depende de que él siga existiendo.
- 07
Entra con el usuario de menor permiso e intenta ver de más
Con la cuenta de un vendedor o un almacenista, busca el saldo de un cliente que no le toca o el margen de un producto. Si el sistema solo esconde botones, el dato sigue estando ahí para quien sepa pedirlo.
- 08
Pregunta dónde se cumplen esos permisos
La respuesta que quieres oír es que en la base de datos. Si están solo en la pantalla, cualquier herramienta que hable directo con los datos se los salta. Es la diferencia entre esconder un botón y cerrar una puerta.
- 09
Pide la lista de lo que NO se entregó
Todo proyecto deja algo fuera. Lo que separa a un proveedor serio es que esté escrito, con nombre, y no que se descubra el día que alguien lo necesita. Si te dicen que se entregó el cien por ciento, pide el documento que lo compara punto por punto contra lo pactado.
- 10
Comprueba de quién son las cuentas
Repositorio de código, servidor, base de datos, dominio y correo. Entra a cada uno con tu propia contraseña. Es la comprobación más aburrida y la única que decide qué pasa el día que cambies de proveedor.
¿Qué se ve cuando todo esto existe?
Un ejemplo con números, para que la lista no quede en abstracto. En la entrega del ERP de Distribuidora del Golfo, la puerta de calidad de la última fase midió 1,148 pruebas automatizadas, repartidas en cuatro capas: unitarias, de integración, de base de datos y de navegador. Entre ellas hay una que verifica que inventario, caja, crédito y utilidad cuadren entre sí, y otra que apaga la aplicación, corta la red y la vuelve a abrir.
La entrega documental fueron seis PDF: manual de uso, manual técnico, requerimientos cumplidos, respaldo y restauración, arquitectura para un comercio electrónico futuro y diseño de interfaz. El de requerimientos cumplidos es el que responde a la novena comprobación: compara los 19 módulos pactados punto por punto contra la pantalla donde cada uno se cumple, y dice cuáles quedaron parciales y por qué.
¿Y si algo de esto falla?
Depende de cuál. Hay tres niveles, y confundirlos lleva a pelear por lo que no importa.
| Si falla… | Qué tan grave es | Qué pedir |
|---|---|---|
| No hay pruebas automatizadas | Serio, pero se arregla | Que se escriban primero sobre lo que mueve dinero: cobro, inventario, permisos. Se puede hacer sobre un sistema ya hecho |
| No hay manual técnico | Serio, y es lo más barato de arreglar | Modelo de datos, cómo se levanta el sistema desde cero y qué decisiones se tomaron. Un documento, no una presentación |
| El respaldo no se ha restaurado nunca | Grave | Una restauración de verdad, hoy, delante de ti. Hasta que no ocurra, no sabes si tienes respaldo |
| Los permisos solo están en la pantalla | Grave si manejas dinero o datos de clientes | Que se muevan a la base de datos y que haya una prueba que lo verifique |
| Las cuentas están a nombre del proveedor | El más grave de todos | Transferencia de repositorio, servidor, base de datos y dominio antes del último pago |
¿Cuándo conviene pedir una segunda opinión?
Cuando el proveedor se niega a enseñar algo en pantalla, cuando cada pregunta se responde con vocabulario técnico que no aclara nada, o cuando la lista de lo que falta cambia cada vez que se pregunta. Ninguna de las tres prueba mala fe por sí sola, pero las tres juntas sí explican por qué tantos sistemas terminan a medias.
Una revisión externa de un sistema entregado se hace en unas horas y cuesta mucho menos que continuar sobre algo que no se sostiene. Y si el sistema está bien hecho, lo dice también: eso vale para dormir tranquilo y para negociar la siguiente fase con el mismo proveedor.
Cuándo esta lista no aplica
- En un sitio informativo o una landing sin operación detrás. Ahí basta con comprobar que carga rápido, que el formulario entrega y que puedes editar los textos.
- En un prototipo hecho para decidir si vale la pena construir algo. Se prueba la idea, no el código, y exigir esta lista encarece algo que se va a tirar.
- En una automatización pequeña que una persona revisa a diario y cuyo error se ve el mismo día. Aquí la comprobación 5 y la 10 siguen valiendo; el resto puede esperar.
- Cuando el sistema lo hizo alguien de tu propio equipo y se va a quedar. Cambian los riesgos: sigue importando el respaldo y la documentación, no tanto la propiedad de las cuentas.
Quién escribe
César Barreto, fundador de riel. Ingeniería industrial y desarrollo: mira la operación antes que el código.
Construyó el ERP de Distribuidora del Golfo, 19 módulos entregados en 6 fases con 1,148 pruebas automatizadas.
Conocer a riel →Preguntas frecuentes
¿Necesito un técnico para hacer estas comprobaciones?
Para nueve de las diez, no: se piden en lenguaje de negocio y se comprueban mirando la pantalla. La única que agradece una segunda opinión técnica es la de permisos, y aun así el resultado se ve sin saber programar: entra con el usuario más limitado e intenta ver lo que no le toca.
¿Cuándo debo hacer esta revisión?
Antes del último pago de la fase, que es cuando todavía tienes cómo pedir que se corrija. Si el sistema ya está entregado y pagado, sirve igual para saber dónde estás parado antes de contratar la siguiente etapa con quien sea.
¿Es normal que un proyecto deje cosas fuera?
Es lo normal y no es un defecto. El defecto es que no esté escrito. Un documento que compare lo pactado contra lo entregado, módulo por módulo, y diga cuáles quedaron parciales, vale más que una promesa de que todo se cumplió.
¿Puedo pedir el código aunque no sepa qué hacer con él?
Sí, y conviene. No es para leerlo: es para que otro equipo pueda continuarlo. El código, la base de datos, el dominio y los respaldos a tu nombre son lo que hace que cambiar de proveedor sea una decisión y no una catástrofe.