Qué quiere decir «terminado»
Un proyecto puede estar entregado, facturado y cerrado, y el problema seguir intacto. Pasa todo el tiempo.
Hay una escena que se repite: el proveedor entrega, presenta, factura y cierra el proyecto. Todos los tickets están en verde. Y tres meses después el negocio sigue resolviendo el mismo problema con las mismas planillas de siempre.
Nadie mintió. El proyecto estaba «terminado» según la definición que se había acordado. El problema es que esa definición no incluía al negocio.
Las tres definiciones que no alcanzan
«Funciona en el ambiente de prueba». Es la más común y la más engañosa. El ambiente de prueba tiene datos limpios, volúmenes chicos y ningún caso raro. La realidad del cliente tiene quince años de datos cargados por gente distinta, con criterios distintos, y una excepción para el cliente más importante que nadie documentó nunca.
«Pasa la demo». Una demo es un camino feliz ensayado. Demuestra que el software puede funcionar, no que funciona.
«Están todos los requerimientos». Esta es la más peligrosa, porque parece rigurosa. Una lista de requerimientos es una hipótesis sobre cómo resolver el problema, escrita antes de empezar, cuando menos se sabía. Cumplirla al pie de la letra y no resolver el problema es perfectamente posible — y es lo que pasa cuando alguien releva requerimientos en vez de diagnosticar.
La definición que sí sirve
Terminado es cuando el problema que originó el proyecto dejó de existir, en la operación real, con la gente real que la opera.
Eso implica tres cosas incómodas para el proveedor, y por eso casi nadie lo firma:
- La condición se escribe antes, al final del descubrimiento, y sale del problema de negocio — no de la solución que se imaginó después.
- Se verifica en producción, con datos y usuarios reales.
- Si no se cumple, el proyecto no está terminado. Aunque el software esté escrito. Aunque las horas estén consumidas.
Cómo se escribe una condición así
No es una declaración de intenciones, es algo que se puede verificar. La diferencia:
- Malo: «El sistema mejorará la gestión de pedidos.» No se puede verificar nada de eso.
- Mejor: «Los pedidos se cargan una sola vez, en un solo lugar, y el equipo de depósito los ve sin pedírselos a nadie.»
La segunda se puede ir a mirar. Alguien entra al depósito un martes cualquiera y comprueba si es cierto o no. No hace falta que tenga un número: hace falta que sea observable.
Cuando la condición tiene número, mejor —«el cierre mensual deja de tardar tres días»— pero exigir números donde no los hay lleva a inventarlos, y una métrica inventada es peor que ninguna.
La parte que casi nadie hace
Si «terminado» se verifica en producción, entonces el proveedor tiene que seguir ahí cuando el sistema entra en producción. Y ese es justo el momento en que buena parte de los proveedores ya se fue: el contrato decía entrega, y la entrega ya ocurrió.
Por eso la definición de terminado y el modelo de contratación son el mismo tema. Si te pagan por entregar, entregás. Si te pagan por resolver, te quedás hasta que esté resuelto.
Antes de firmar
Preguntá una sola cosa: ¿cómo vamos a saber que esto está terminado, y quién lo verifica?
Si la respuesta habla de entregables y no del negocio, ya sabés cómo termina.