Acotar no es reducir por miedo. Es definir qué tiene que pasar para que el sistema se pueda probar, operar y mejorar.
La ficha de una página
Un proyecto de IA bien acotado se puede resumir en una página. Si necesitas veinte diapositivas para explicar qué hace, el alcance no está claro. La ficha tiene seis partes: el trabajo, el resultado, el responsable, las herramientas, el límite y el criterio de cierre.
La ficha es para el equipo, no para el cliente. Sirve para decidir qué se construye, qué se deja fuera y cómo se sabrá si ha funcionado.
El trabajo
Describe el proceso que se repite, con sus pasos y sus excepciones. No escribas «gestionar incidencias». Escribe «recibir una incidencia, identificar el pedido, comprobar el estado, responder al cliente y abrir una devolución cuando corresponde».
Incluye el volumen y la frecuencia. Un proceso que ocurre tres veces al mes no justifica un sistema complejo. Uno que ocurre doscientas veces al día sí. El volumen también ayuda a calcular el coste por caso.
El resultado
El resultado es lo que cambia fuera del sistema cuando hace su trabajo. Una cita en el calendario, un pedido actualizado, una devolución abierta, una respuesta enviada. Tiene que ser observable y, si es posible, verificable por otra herramienta.
«Responder bien» no es un resultado. «Responder con el estado del pedido y la fecha de entrega, o derivar si no se encuentra el pedido» sí lo es.
El responsable
Cada proyecto necesita una persona que responda del resultado. Es la persona que conoce el trabajo y puede decir si el sistema ha hecho lo que tenía que hacer, no la que programa ni la que patrocina.
El responsable también decide cuándo se activa una persona, qué excepciones se aceptan y qué se hace cuando el sistema no sabe. Sin esa decisión, el equipo técnico acaba inventando la política del negocio.
Las herramientas y el límite
Enumera las herramientas y bases de datos que puede leer y escribir. No hace falta una integración perfecta para empezar, pero sí saber qué datos están disponibles y con qué permisos. Si una herramienta no tiene API, el alcance tiene que reflejarlo.
El límite es igual de importante. Qué no puede decir, qué no puede prometer, qué no puede modificar y cuándo tiene que parar. Un límite claro no hace al sistema más débil. Lo hace operable.
El criterio de cierre
El criterio de cierre responde a una pregunta: ¿cómo sabremos que este trabajo está terminado? En una reserva, puede ser una cita creada y confirmada. En una incidencia, un ticket resuelto o derivado con el contexto completo. En formación, una conversación evaluada con una rúbrica.
Si el criterio no se puede comprobar con un caso real, es una expectativa. Y las expectativas no se pueden poner en producción.
Lo que dejas fuera
Un buen alcance también dice qué no entra. Otros idiomas, otros canales, otros tipos de caso, otras herramientas. Dejarlo escrito evita que el proyecto crezca sin control y permite volver más tarde con una base que ya funciona.
El alcance es una foto del primer sistema que se va a probar, no una promesa de que nunca cambiará. Si cambia, que sea por una razón y con una evaluación nueva.
La ficha, en la práctica
Una ficha real puede ocupar media página. Empieza por el trabajo: «recibir consultas de disponibilidad, comprobar el calendario y concertar una visita». Sigue con el resultado: «cita creada y confirmada; si no hay hueco, derivación con motivo». Después, el responsable: «la persona que hoy gestiona la agenda». Las herramientas: «calendario, CRM y teléfono». El límite: «no promete precios ni fechas fuera del calendario». Y el cierre: «la cita existe y la persona la ha recibido».
Si alguno de esos campos está vacío, no sigas. Un proyecto sin responsable no tiene quién decida. Un proyecto sin límite no tiene quién responda cuando el sistema se equivoque. Un proyecto sin criterio de cierre no se puede evaluar. La ficha no es burocracia: es la diferencia entre construir y adivinar.
Sigue leyendo