Definición del problema y alcance
Del deseo al problema
«Queremos usar IA» no es un problema. Hay que bajarlo a una necesidad concreta: qué dolor, qué decisión o qué proceso se quiere mejorar, y por qué importa.
Preguntas que aclaran
- ¿Quién sufre el problema y cuánto?
- ¿Qué decisión cambiaría con una mejor respuesta?
- ¿Cómo se mide hoy y cómo se mediría el avance?
Objetivos medibles
Cada objetivo debe ligarse a una métrica y un umbral. «Mejorar la predicción» se vuelve «subir el recall de fraude del 70 % al 85 % sin pasar de 1 % de falsos positivos».
Métricas de negocio frente a técnica
- Una métrica de modelo no siempre traduce valor real.
- Conectar exactitud con coste, ingreso o riesgo.
- Validar que optimizamos lo que de verdad importa.
Acotar el alcance
Definir qué entra y, sobre todo, qué queda fuera. El alcance acotado hace el proyecto terminable; sin recortes, todo proyecto se desborda.
Requisitos y restricciones
- Datos disponibles y su calidad real.
- Limitaciones de tiempo, cómputo y presupuesto.
- Restricciones legales, éticas y de privacidad.

Estudio de viabilidad
Antes de comprometerse, conviene un análisis rápido: ¿existen los datos? ¿hay señal plausible? ¿el esfuerzo justifica el beneficio esperado?
Riesgos tempranos
- Datos inaccesibles o de peor calidad de la supuesta.
- Problema que resulta no ser de datos.
- Criterio de éxito ambiguo que nadie firmó.
El documento de alcance
Un texto breve y firmado que fija problema, objetivos medibles, entregables, límites y riesgos. Es el contrato que evita discusiones después.
Partes interesadas
- Identificar quién decide y quién sufre el resultado.
- Alinear expectativas desde el principio.
- Un patrocinador que respalde el criterio de éxito.
Revisión y validación
Contrastar la definición con expertos del dominio. El error más caro es resolver perfectamente el problema equivocado.
Errores frecuentes
- Empezar por la técnica antes de entender el problema.
- Dejar el alcance abierto y sin límites escritos.
- Atar el éxito a una métrica vaga que nadie firmó.
Ejemplo resuelto: de un deseo a un problema acotado
Un banco dice «queremos usar IA». Así se traduce a un proyecto definible:
- Identificar el dolor concreto: impagos que se detectan tarde.
- Definir la decisión que apoya: a qué cliente revisar primero.
- Atar una métrica con umbral: subir el recall del 70 al 85 por ciento.
- Acotar el alcance: solo crédito al consumo, no hipotecas.
- Verificar viabilidad: existen los datos y hay señal plausible.
¿Para qué sirve en la realidad?
La mayoría de proyectos de datos fracasan por un mal arranque: definir bien el problema y firmarlo evita meses trabajando en algo inabarcable o que nadie necesitaba.
Un buen objetivo de proyecto de datos debe ser:
Acotar el alcance de un proyecto aumenta la probabilidad de terminarlo con éxito.
Alcance
Toca una tarjeta para ver la respuesta.
Ordena la puesta a punto de un proyecto:
Arrastra cada ficha a su categoría (o tócala y luego toca la categoría). También puedes usar el teclado.
Acta de proyectoDocumento que autoriza y delimita un proyecto.
Une cada pregunta con lo que aclara:
Del deseo al acta
- Definir un proyecto
- Problema
- quién lo sufre
- quién lo sufre
- qué decisión apoya
- Problema
- métrica con umbral
- datos disponibles
- qué entra
Deriva del alcanceEl crecimiento descontrolado de límites que desborda un proyecto.
Un banco pide «predecir impagos con IA». Formula el problema en una frase, una métrica con umbral y un riesgo de viabilidad que comprobarías primero.
Tu texto se guarda sólo en este dispositivo.
Comentarios
Inicia sesión para comentar.
Todavía no hay comentarios. Sé la primera persona en opinar.