"Me pidieron X, pero necesitaban Y"

Hay una escena que todo el que trabaja con datos reconoce en cuanto la oye: alguien entra pidiendo una cosa muy concreta —un ibuprofeno, un número— y resulta que lo concreto era una solución que se le había ocurrido, no el problema que tenía. La directora de marketing dice "dame las ventas del mes", pero lo que necesita saber es si van por encima o por debajo del presupuesto y, si van por debajo, dónde está el hueco. Nadie formula esa segunda pregunta en voz alta. Y si tú devuelves un número sin investigar qué hay detrás, vas a acabar haciendo tres consultas que, juntas, no responden a nada.

Bienvenido al error más caro y más frecuente del analista: entregar exactamente lo que te pidieron. Suena paradójico, pero es así. El error no es equivocarte en un cálculo, ni elegir la métrica equivocada, ni presentar mal un gráfico. El error es aceptar la pregunta tal como viene, sin investigar qué hay detrás, y devolver un número técnicamente correcto que no sirve para nada. Es el equivalente profesional de responder a la pregunta del examen sin leer el enunciado completo.

### La analogía del médico: lo que pides no siempre es lo que necesitas

Un paciente entra en la consulta y dice: "me duele la cabeza, dame un ibuprofeno". Fíjate en lo que hace un buen médico: no abre el cajón y le da el ibuprofeno. Pregunta. ¿Desde cuándo te duele? ¿Cuántas horas has dormido esta semana? ¿Estás bebiendo suficiente agua? ¿Te ha subido la tensión? El paciente no formula su problema como una pregunta diagnóstica —formula una solución que se le ha ocurrido a él, basada en su modelo mental de cómo funciona el cuerpo—. El médico sabe que detrás de "me duele la cabeza" pueden estar la deshidratación, la tensión arterial alta, la falta de sueño, la vista cansada, o una contractura cervical. El ibuprofeno resuelve exactamente una de esas cinco causas. Para las otras cuatro, el ibuprofeno es un parche que dura cuatro horas y vuelve a doler.

Con el analista de datos pasa exactamente lo mismo. La persona que te pide un dato no es un analista: es alguien de marketing, de operaciones, de producto, de finanzas, que tiene un problema en la cabeza —"creo que estamos vendiendo menos", "sospecho que la campaña no funcionó", "no sé si mi equipo cumple los plazos"— y formula ese problema como la primera consulta que se le ocurre, no como la pregunta que de verdad necesita responder. Tu trabajo no es ser el cajón que le da el ibuprofeno. Tu trabajo es ser el médico que pregunta, que investiga, y que a veces dice: "te voy a dar algo mejor que lo que has pedido".

### Por qué la pregunta que te hacen casi nunca es la pregunta correcta

No es que tus compañeros sean imprecisos por pereza. Es que formulan desde su modelo mental del mundo, que no incluye la estructura de los datos, ni las tablas disponibles, ni las métricas exactas que se pueden calcular. El director de operaciones sabe que los pedidos tardan más de lo normal, pero no sabe que en tu base de datos hay un campo de timestamp que permite calcular el tiempo exacto entre que un pedido se confirma y se entrega. La directora de producto sabe que los usuarios se dan de baja, pero no sabe que tú puedes distinguir entre quienes se dieron de baja tras un mes de inactividad y quienes se dieron de baja el día después de una subida de precio. Cada uno formula desde lo que ve, no desde lo que tú puedes medir.

Hay una segunda razón, más sutil. Muchas veces la persona ya tiene una hipótesis en la cabeza —"creo que el problema es el precio", "creo que es por la campaña de la competencia"— y formula la petición como una confirmación disfrazada de pregunta. "¿Me puedes sacar cuántos usuarios se han dado de baja desde que subimos el precio?" no es una pregunta abierta: es una afirmación con interrogantes. Si tú entregas ese número sin más, le estás confirmando su marco mental, haya o no una causa mejor. Si de cada diez bajas solo una ocurrió la semana de la subida de precio y las otras nueve llevaban meses sin entrar, la respuesta literal a su pregunta es técnicamente correcta y profundamente engañosa al mismo tiempo.

### Tres señales de que la pregunta que te hacen no es la correcta

No siempre es obvio que una petición necesita reformularse. A veces es perfectamente legítima y hay que responderla rápido. Pero hay tres señales que, cuando aparecen, casi siempre indican que lo que te piden no es lo que necesitan. Aprende a reconocerlas como un detector de humo: no siempre hay fuego, pero cuando suena, merece la pena asomarse.

### Señal 1 — Es demasiado vaga

"Dame las ventas." "Sácame los datos de usuarios." "¿Cómo van las campañas?" Cada una de estas frases admite diez respuestas distintas, todas técnicamente válidas. ¿Las ventas de qué periodo? ¿En unidades o en dinero? ¿De toda la empresa o de un canal? ¿Los datos de usuarios activos, registrados, o los que pagaron algo? ¿Cómo van las campañas respecto a qué: al objetivo, al mes pasado, a la competencia? La vaguedad no es pereza del otro: es la señal de que todavía no ha pensado exactamente qué necesita. Y tu primer instinto —asumir lo más razonable y ponerte a calcular— es exactamente lo que produce entregas que vuelven rebotadas.

### Señal 2 — Pide un número sin decisión detrás

"¿Cuántos usuarios tenemos?" El número es 47.382. Vale. ¿Y ahora qué? Si ese número no va a cambiar nada —no hay un umbral que lo convierta en alarma, no hay una comparación que le dé significado, no hay una acción que dependa de que sea alto o bajo—, entonces la pregunta que de verdad tienen en la cabeza es otra. Quizá es "¿estamos creciendo o estamos perdiendo usuarios?". Quizá es "¿tenemos suficientes usuarios para lanzar la funcionalidad nueva?". Quizá es "¿cuántos usuarios activos de verdad hay detrás de esa cifra de registrados?". El número suelto, sin contexto de decisión, es un dato huérfano: nació sin padre que lo recoja.

### Señal 3 — La respuesta al pie de la letra no cambiaría nada

Esta es la más reveladora de las tres. Imagina que respondes literalmente. "¿Cuántos se dieron de baja este mes?" — "347". Y la persona dice: "vale... ¿y eso es mucho?". Si la respuesta literal genera inmediatamente una segunda pregunta que es la que de verdad importa, entonces la pregunta original no era la correcta. Lo que necesitaban era "¿estamos perdiendo usuarios más rápido de lo normal?", que ya incluye la comparación y el contexto que convierten un número en una señal. El test mental es sencillo: imagina que das la respuesta perfecta a lo que te han pedido, al pie de la letra. ¿Cambiaría algo? ¿Alguien haría algo distinto mañana? Si la respuesta es no, la pregunta no era la buena.

### La técnica de las "dos preguntas antes"

Si hay una sola cosa que te lleves de esta lección, que sea esta técnica. Es tan simple que parece que no puede funcionar, y funciona tan bien que la mayoría de analistas senior la hacen sin darse cuenta de que tienen un nombre para ella. Antes de abrir SQL, antes de abrir una hoja de cálculo, antes de tocar una sola tabla, haz estas dos preguntas a la persona que te ha hecho la petición:

1. 01."¿Para qué necesitas este dato?" — No es una pregunta retórica ni un cuestionamiento. Es genuina curiosidad por el contexto. La respuesta te dice qué problema están intentando resolver, que casi nunca es "quiero ver un número por verlo".
2. 02."¿Qué decisión vas a tomar con la respuesta?" — Esta es la que cierra el círculo. Si la respuesta es "si el número está por debajo de X, voy a hacer Y; si está por encima, no hago nada", ya sabes exactamente qué necesitan: no el número en bruto, sino si están por encima o por debajo de X, y quizá por cuánto y desde cuándo.

Estas dos preguntas hacen algo muy concreto: redirigen desde la solución que se le ha ocurrido al otro (el ibuprofeno, el número de ventas) hacia el problema real que tiene (el dolor de cabeza persistente, la sospecha de que algo va mal en el negocio). Y lo hacen sin que la otra persona sienta que la estás cuestionando o que estás siendo difícil. No estás diciendo "tu pregunta está mal". Estás diciendo "quiero darte algo que de verdad te sirva, ayúdame a entender para qué lo vas a usar".

### Cinco casos reales: pidieron X, necesitaban Y

La teoría está clara. Ahora veamos cómo se manifiesta en situaciones que vas a vivir, o que ya has vivido sin darte cuenta. Cada caso sigue el mismo patrón: lo que pidieron, lo que habrías entregado si te lo tomas al pie de la letra, lo que de verdad necesitaban, y cómo lo descubriste (o lo habrías descubierto) con las dos preguntas.

1. 01.Pidieron: "dame el número de descargas de la app este mes". Habrías entregado: 23.400 descargas. Necesitaban: saber si la campaña de adquisición de la semana pasada funcionó o hay que pararla. La pregunta real: "¿cuántas descargas vinieron de la campaña, cuántas habrían venido sin ella, y el coste por descarga está dentro de lo que pactamos?". La diferencia: un número frente a una recomendación de continuar o parar.
2. 02.Pidieron: "¿cuántos tickets de soporte abrimos el mes pasado?". Habrías entregado: 1.247 tickets. Necesitaban: saber si la última actualización del producto generó más incidencias de lo normal. La pregunta real: "¿hay un pico de tickets en los días posteriores al despliegue, y si lo hay, qué categoría de incidencia concentra el exceso?". La diferencia: un contador frente a un diagnóstico con causa localizable.
3. 03.Pidieron: "dame el churn del trimestre" (churn: la proporción de clientes que se dan de baja en un periodo). Habrías entregado: 4,2%. Necesitaban: saber si los clientes que subieron de plan son más fieles que los que se quedaron en el plan básico, porque están pensando en forzar una migración de plan. La pregunta real: "¿el churn es distinto por plan, y si lo es, cuántos clientes retendríamos migrándolos?". La diferencia: un porcentaje global frente a un caso de negocio con proyección de impacto.
4. 04.Pidieron: "sácame una lista de los clientes que no han comprado en 90 días". Habrías entregado: un CSV con 8.400 filas. Necesitaban: decidir a cuáles merece la pena llamar con una oferta de reactivación, porque el equipo comercial solo puede hacer 200 llamadas a la semana. La pregunta real: "de los inactivos, ¿cuáles tienen mayor probabilidad de volver y mayor valor histórico, para priorizar las 200 llamadas?". La diferencia: una lista plana frente a una lista priorizada con criterio.
5. 05.Pidieron: "¿cuánto gastamos en cloud el mes pasado?". Habrías entregado: 14.300 euros. Necesitaban: saber si un servicio concreto se ha disparado de coste porque un proceso mal configurado está consumiendo más de lo previsto. La pregunta real: "¿qué servicio o proceso explica el aumento respecto al mes anterior, y es un pico puntual o una tendencia?". La diferencia: una factura frente a una alarma con responsable.

Fíjate en el patrón que comparten los cinco casos. En todos, lo que pidieron es un dato plano: un número, una lista, un porcentaje. En todos, lo que necesitaban incluye una comparación (contra un objetivo, contra un periodo, contra un subgrupo), un contexto de decisión (parar una campaña, priorizar llamadas, investigar un servicio) y, a menudo, una recomendación. El salto de X a Y no es un salto de complejidad técnica: es un salto de utilidad. La consulta SQL puede ser prácticamente la misma; la diferencia está en qué preguntas hiciste antes de escribirla.

### El equilibrio: no seas el analista que cuestiona todo y nunca entrega

Hay un peligro real en esta lección, y sería deshonesto no nombrarlo. Si interiorizas demasiado la idea de que "la pregunta siempre es otra", puedes convertirte en el analista que cuestiona cada petición, que siempre necesita una reunión de contexto antes de mover un dedo, que filosofa sobre el propósito de cada número mientras el otro lleva media hora esperando un dato que está a una consulta de distancia. Ese analista existe, y es igual de inútil que el que entrega sin preguntar.

La realidad del trabajo es que muchas peticiones son exactamente lo que parecen. "¿Cuántos pedidos se procesaron ayer?" a veces es una pregunta operativa legítima de alguien que necesita el número para rellenar un informe que tiene que enviar en diez minutos. "¿Cuánto facturamos en julio?" a veces es una cifra que el director financiero necesita para una diapositiva del consejo de administración, y no hay ningún misterio detrás. Cuando la petición es clara, la persona sabe para qué la quiere, y la respuesta literal sí cambia algo (o cumple un requisito concreto), entrégala sin rodeos. La velocidad también es valor.

La regla práctica es esta: usa las tres señales como filtro. Si no aparece ninguna —la petición es concreta, tiene un "para qué" evidente, y la respuesta literal sí cambiaría algo—, entrega. Si aparece una o más, invierte treinta segundos en las dos preguntas. No son excluyentes: a veces haces las dos preguntas, descubres que la petición original era la correcta, y entregas exactamente eso con la tranquilidad de saber que no te has dejado nada. Esos treinta segundos nunca se pierden.

### Cómo se veía este problema antes de que existieran los analistas

Esta habilidad no es nueva. Lo nuevo es el contexto donde se aplica. En los años 80, cuando las empresas empezaron a informatizar sus datos de ventas, el "analista" era muchas veces un contable que, además de cuadrar los libros, sacaba cifras cuando alguien las pedía. El director general decía "necesito los números de este trimestre" y el contable le preparaba un informe. Literal: se lo preparaba. Con una máquina de escribir, después con una hoja de cálculo, y lo dejaba en su mesa. El contable no preguntaba "¿para qué?". No le correspondía. Era un servicio de extracción, no de interpretación.

Lo que cambió entre los años 80 y hoy no es solo la tecnología. Es que la cantidad de datos disponibles se multiplicó por un factor que nadie calculó de antemano. Cuando una empresa tenía cien transacciones al día, el director podía leerlas todas. Cuando tiene cien mil, necesita a alguien que le diga qué mirar. Y "qué mirar" no es una pregunta técnica: es una pregunta de negocio disfrazada. El analista de datos nació exactamente en ese hueco: la persona que traduce entre el volumen inmanejable de datos y la decisión concreta que alguien tiene que tomar. Y esa traducción empieza antes de la consulta, no después.

### De X a Y: el proceso completo en un ejemplo

Vamos a recorrer un caso de principio a fin, como si estuvieras sentado delante de la petición un martes por la mañana. El responsable de producto te escribe: "¿Me puedes sacar cuántos usuarios usaron la funcionalidad de exportar a PDF el mes pasado?". Parece concreta. Tiene una métrica implícita (usuarios), un ámbito (la funcionalidad de exportar), y un periodo (el mes pasado). Pero apliquemos las tres señales.

• ▹¿Es demasiado vaga? No mucho, pero "usaron" es ambiguo: ¿la abrieron, la completaron con éxito, o la intentaron aunque fallara?
• ▹¿Tiene decisión detrás? No lo dice. Un número de usuarios sin contexto de decisión: señal 2 activa.
• ▹¿La respuesta literal cambiaría algo? Si dices "4.200 usuarios", ¿alguien hace algo distinto mañana? No está claro.

Dos de tres señales activas. Aplicas las dos preguntas: "¿Para qué necesitas este dato?" — "Estamos decidiendo si meter recursos en mejorar esa funcionalidad o matarla". "¿Qué harías con la respuesta?" — "Si la usa poca gente, la quitamos y nos ahorramos el mantenimiento; si la usa mucha, invertimos en mejorarla". Ahora sabes que la pregunta real no es "cuántos usuarios la usaron", sino "¿esta funcionalidad justifica la inversión de mantenerla y mejorarla?". Y esa pregunta necesita mucho más que un número: necesita saber si los usuarios que la usan son los que pagan (clientes de plan alto), si la usan como parte de su flujo crítico o como curiosidad puntual, si el uso está creciendo o decreciendo, y cuánto cuesta mantenerla. La entrega pasa de un número en un mensaje a una recomendación de una página con datos que sostienen la decisión.

### La entrega "X + contexto": cuando no puedes hacer Y

A veces no tienes acceso a la persona que hizo la petición. A veces es urgente y no hay tiempo para las dos preguntas. A veces ya conoces el contexto porque llevas meses trabajando con ese equipo y sabes perfectamente que "las ventas del mes" significa "comparadas con el objetivo". Pero hay un escenario intermedio que merece nombre propio: cuando no puedes hacer Y completo, pero puedes entregar X con el contexto mínimo que lo convierte en algo útil.

A esto se le llama "X + contexto". Te piden las ventas del mes: entregas las ventas del mes, pero añades una línea que dice "esto supone un 94% del objetivo trimestral prorrateado" o "esto es un 7% menos que el mismo mes del año pasado". No has reformulado la pregunta, no has hecho un análisis profundo, pero has convertido un número huérfano en un número con referencia. Has pasado de un dato que no dice nada a un dato que dice "estamos cerca" o "hay un problema". Es la versión de emergencia de esta lección: cuando no puedes hacer Y, haz X de manera que quien lo reciba pueda decidir si necesita Y.

### Resumen: el checklist antes de aceptar una petición

1. 01.Lee la petición y pásale el filtro de las tres señales: ¿es vaga? ¿tiene decisión detrás? ¿la respuesta literal cambiaría algo?
2. 02.Si alguna señal se activa, haz las dos preguntas: "¿para qué necesitas este dato?" y "¿qué decisión vas a tomar con la respuesta?".
3. 03.Reformula la pregunta real: la que incluye comparación, contexto y acción.
4. 04.Si no puedes hacer las dos preguntas (urgencia, falta de acceso), entrega X + contexto: el número que te pidieron, con la referencia mínima que lo haga útil.
5. 05.Si la petición pasa el filtro limpia (concreta, con decisión clara, la respuesta literal sí sirve), entrégala sin rodeos. La velocidad también es valor.