Guía de entrevista para Business Analysts

Enfoque — Objetivo → Interesados → Decisiones → Datos → Requisitos → Validación

Primero aclaro qué decisiones debe facilitar el cuadro de mando, quién lo utilizará, con qué frecuencia y qué problemas existen hoy. Después identifico a dirección, usuarios operativos, Finanzas, Ingeniería de Datos, Cumplimiento y responsables de los sistemas de origen. Para cada métrica documento su definición, responsable, fuente, cálculo, filtros, granularidad, frecuencia de actualización y limitaciones. También aclaro permisos, exportación, desglose, alertas e histórico. Los wireframes ayudan a validar el diseño; los criterios de aceptación y escenarios de UAT permiten comprobar la solución antes del lanzamiento.

Enfoque — El problema antes que la solución

Empiezo por el problema: ¿qué parte del proceso actual es lenta, propensa a errores, poco transparente o incumple normas? ¿Quién presenta solicitudes, quién las aprueba y qué ocurre después? A continuación documento campos, validaciones, reglas de enrutamiento, niveles de aprobación, escalado, rechazo, reenvío, notificaciones, informes, registro de auditoría y excepciones. El volumen, los SLA, los roles, el cumplimiento y las integraciones determinan los requisitos de calidad. Un «sistema automatizado» es una idea de solución; el requisito real es el resultado empresarial y las reglas de decisión.

Enfoque — Aclarar el cambio → Evaluar el impacto → Priorizar → Comunicar

Primero aclaro el motivo y la urgencia: una necesidad nueva, un requisito omitido, una norma, una preferencia, una limitación técnica o un hallazgo de pruebas. Después evalúo con Producto, Ingeniería, QA y el área de negocio el impacto en alcance, calendario, coste, dependencias, datos, integraciones, pruebas, formación y riesgo. El cambio puede incorporarse, aplazarse, intercambiarse por otro elemento o rechazarse. Registro la decisión y su justificación. El mayor riesgo es ampliar el alcance de forma encubierta, así que comunico expresamente qué se entregará y qué queda fuera.

Enfoque — Estado actual → Cuellos de botella → Causa raíz → Estado futuro → Métricas

Primero represento el proceso desde el registro hasta la activación completa: pasos, responsables, sistemas, traspasos, dependencias, aprobaciones, documentos y excepciones. Mido la duración de cada paso, no solo el total. Después segmento por tipo de cliente, producto, región, riesgo y canal. Las causas posibles incluyen entrada manual, documentación incompleta, acumulación en Cumplimiento, aprobaciones duplicadas o integraciones deficientes. Para cada cuello de botella evalúo impacto y viabilidad. El estado futuro podría incluir validación temprana de documentos, recordatorios automáticos, trabajo en paralelo, autoservicio, enrutamiento según riesgo y menos aprobaciones. Mediría la mediana y el percentil 90 del tiempo, la tasa de finalización, el retrabajo, la satisfacción y las excepciones de cumplimiento, y comenzaría con un piloto limitado.

Enfoque — Alcance → Participantes → Flujo → Excepciones → Controles

Primero defino el inicio, el final, los equipos y sistemas implicados y el objetivo empresarial. Para el estado actual documento participantes, pasos, entradas y salidas, decisiones, traspasos, esperas, problemas y excepciones. Un diagrama por carriles aclara responsabilidades y se valida con quienes ejecutan realmente el proceso. El estado futuro muestra los pasos modificados o eliminados, la automatización, los nuevos controles, los cambios de rol y la gestión de excepciones. También incluyo supuestos, preguntas abiertas, dependencias y métricas de éxito. Según el público, preparo una vista ejecutiva breve y otra operativa detallada.

Enfoque — Unir → Filtrar → Agrupar por mes y categoría → Sumar ingresos

Primero aclaro la granularidad. ¿Los ingresos se registran por pedido o por línea? Si la categoría pertenece a la línea, también debo agregar los ingresos en ese nivel; de lo contrario, la unión puede duplicar importes. La consulta une las líneas de pedido con productos mediante product_id y con el pedido para obtener fecha y estado. Filtra pedidos completados, agrupa por mes y categoría y suma los ingresos de las líneas. Si existen descuentos y reembolsos, aclaro si se pide ingreso bruto o neto. Para validar, comparo el total mensual con la fuente financiera, compruebo categorías ausentes y confirmo que se excluyen pedidos cancelados y de prueba.

Enfoque — Objetivo → Calidad del servicio → Eficiencia → Resultado del cliente → Métricas de control

Primero aclaro el objetivo: resolver antes, elevar la satisfacción, controlar costes, reducir escalados o apoyar el crecimiento. Las métricas deben equilibrar experiencia del cliente y eficiencia. Incluiría tiempo de primera respuesta y resolución, cumplimiento de SLA, volumen pendiente, reapertura y escalado, resolución en el primer contacto, CSAT, contactos por cliente, coste por incidencia y volumen por categoría. Segmentaré por prioridad, canal, tipo de cliente, producto y región. Las métricas de control evitan incentivos equivocados: optimizar solo el tiempo de gestión puede perjudicar la calidad. El cuadro debe mostrar conjuntamente velocidad, calidad, carga y causas.

Enfoque — Validar → Descomponer → Segmentar → Diagnosticar → Recomendar

Primero valido el dato: actualización, sistemas de origen, filtros, periodo, devoluciones, divisas y cambios de definición. Después descompongo los ingresos en tráfico o clientes potenciales, conversión, valor medio, precio, volumen, mezcla de productos, región, canal y clientes nuevos frente a recurrentes. La segmentación muestra si la caída procede de un canal, producto, mercado o grupo de clientes. Luego analizo posibles causas: estacionalidad, inversión en marketing, competencia, falta de inventario, cambios de precio, calidad del pipeline, errores técnicos o problemas de reporting. La recomendación debe responder al principal factor e indicar la incertidumbre y los datos siguientes. Si cae la conversión móvil, investigo el embudo y el rendimiento; si cae el tráfico, reviso canales y campañas.

Enfoque — Usuario → Objetivo → Beneficio → Condiciones verificables

Una historia explica quién necesita algo, qué necesita y por qué: «Como [usuario], quiero [función] para [beneficio]». El beneficio ayuda al equipo a tomar decisiones correctas cuando surgen compensaciones. Los criterios de aceptación definen de forma concreta y verificable cuándo está completada. Cubren el flujo principal, validación, permisos, errores, casos límite, reglas de datos y, cuando procede, requisitos de calidad. Ejemplo: una responsable de soporte quiere filtrar incidencias por prioridad y estado del SLA. Los criterios definen filtros, estado inicial, combinaciones, resultados vacíos, permisos, exportación y tiempo de respuesta. Antes del desarrollo valido la historia y los criterios con Negocio, Ingeniería, QA y Diseño.

Enfoque — Por qué empresarial, qué funcional y unidad entregable

Un Business Requirements Document describe el problema, los objetivos, el alcance, los interesados, los requisitos de alto nivel, los supuestos, las restricciones y el éxito. Explica por qué se necesita el trabajo y qué resultado empresarial busca. Un Functional Requirements Document detalla qué debe hacer el sistema: flujos, reglas, campos, permisos, integraciones, informes y excepciones. Una historia de usuario es una unidad más pequeña, entregable y verificable para equipos ágiles. La documentación adecuada depende del modelo de entrega y el riesgo. Un proceso bancario regulado suele exigir más evidencia formal que un cambio pequeño en un cuadro de mando interno.

Enfoque — Alcance → Usuarios → Escenarios → Datos → Defectos → Aprobación

Primero defino el alcance de la UAT: flujos, roles, sistemas, integraciones, informes y reglas de negocio. La UAT confirma que la solución está lista desde el punto de vista empresarial; no repite todas las pruebas de QA. Deben participar gestores de siniestros, supervisores, Cumplimiento, Operaciones e Informes. Los escenarios proceden de casos reales: estándar, documentos ausentes, importe elevado, rechazo, escalado, duplicado y excepción. Los datos de prueba cubren límites, permisos, cambios de estado, notificaciones, trazabilidad, informes y sistemas posteriores. Durante la prueba registro defectos con gravedad, responsable, estado e impacto empresarial, y separo fallos de software, carencias de formación y nuevas peticiones. La aprobación confirma que los escenarios críticos han pasado, los riesgos residuales se aceptan y la operación está preparada.

Enfoque — Comprensión compartida → Restricciones → Opciones → Documentación

Primero aclaro el problema empresarial y el resultado deseado. Con Ingeniería analizo restricciones técnicas, dependencias, integraciones, modelo de datos, rendimiento y seguridad. Descompongo los requisitos complejos en reglas de negocio, flujo de usuario, necesidades de datos, comportamiento de API, permisos, errores e informes. Los diagramas, ejemplos y datos de muestra reducen la ambigüedad. Ingeniería aporta opciones y compensaciones, como un MVP más pequeño o una entrega por fases. Mi función no es diseñar la solución técnica en solitario, sino asegurar que cumple el objetivo empresarial y que las compensaciones son visibles. Documento acuerdos, preguntas abiertas, supuestos y criterios de aceptación.

Enfoque — Medir → Segmentar → Diagnosticar → Mejorar

Primero defino el uso de acuerdo con el objetivo: inicio de sesión, apertura de la función, finalización del flujo, uso recurrente o resultado empresarial. Después segmento por rol, equipo, región, grupo de formación y tiempo desde el lanzamiento. Las causas pueden ser falta de conocimiento, valor poco claro, mala usabilidad, permisos incorrectos, procesos antiguos que siguen activos o una solución inadecuada. El embudo de uso, las incidencias, las entrevistas y la observación del proceso ayudan a diagnosticarlo. Las medidas pueden incluir formación, comunicación, mejoras de UX o del flujo, retirada de herramientas antiguas, corrección de permisos o revisión de requisitos. Mido el éxito mediante el resultado previsto, como tiempo ahorrado, menos errores o mejor cumplimiento de SLA, no solo por clics.

Enfoque — Valor empresarial → Urgencia → Riesgo → Esfuerzo → Dependencias

Primero aclaro los objetivos empresariales del periodo, como ingresos, cumplimiento, experiencia del cliente, coste o riesgo. Después evalúo cada requisito según valor, urgencia, riesgo regulatorio y operativo, impacto en usuarios, esfuerzo, dependencias y confianza en los supuestos. Una puntuación sencilla aporta transparencia, pero no sustituye al criterio: los requisitos normativos o de continuidad pueden ser obligatorios. Los agrupo en imprescindibles, alto valor, resultados rápidos, prerrequisitos y posteriores, y comunico qué se elige o aplaza y por qué. También busco solapamientos y causas raíz. Veinte peticiones pueden proceder de cinco problemas fundamentales; resolver la causa suele ser mejor que crear muchas funciones aisladas.

Enfoque — Coste actual → Riesgo de error → Coste de automatización → Beneficio → Recomendación

Evalúo beneficios cuantitativos y cualitativos. El coste actual incluye tiempo de trabajo, errores, retrasos, riesgo de auditoría y trabajo de mayor valor que no se realiza. En procesos financieros o normativos, reducir riesgo puede importar más que ahorrar tiempo. Lo comparo con desarrollo o proveedor, mantenimiento, gestión de excepciones, controles, pruebas, formación e integración. También considero el crecimiento: 40 horas actuales pueden aumentar rápidamente con el volumen. Recomiendo automatizar cuando el proceso es estable, reglado, frecuente, propenso a errores y tiene fuentes claras. Si las reglas cambian a menudo o requieren mucho criterio humano, empezaría por estandarizar y automatizar parcialmente.

Enfoque — Definir productividad → Línea base → Uso → Resultado → Métricas de control

Primero defino productividad según el objetivo: más actividades cualificadas, ciclo de ventas más corto, mayor conversión, más pipeline, mejores previsiones o más ingresos por persona. Necesito una línea base previa y, si es posible, un grupo de comparación o un lanzamiento escalonado. Mido tanto el uso correcto como los resultados. Observaría tiempo administrativo, seguimientos, tiempo de respuesta, avance de etapas, conversión, duración de ventas, calidad de datos, precisión del pronóstico e ingresos por persona. La satisfacción, la experiencia del cliente y los incentivos no deseados actúan como controles. Segmentar por equipo, región, experiencia y mercado revela diferencias. A partir de ahí decido si ampliar, formar, simplificar o revisar requisitos.

Enfoque — Aclarar objetivos → Mostrar compensaciones → Utilizar evidencia → Decidir

Primero aclaro los objetivos subyacentes. Los conflictos suelen surgir de incentivos distintos, como flexibilidad para Ventas frente a control para Cumplimiento. Después hago visibles el impacto, las personas afectadas y los riesgos, y analizo si la configuración, los permisos, una entrega por fases o cambios de proceso pueden satisfacer ambas necesidades. Los datos sobre ingresos, riesgo, volumen, errores, coste o impacto en clientes ayudan a decidir. Si la decisión exige más autoridad, escalo con opciones y una recomendación, no con un conflicto sin resolver. Documento la decisión, su justificación y las necesidades aplazadas.

Enfoque — Impacto empresarial, opciones y compensaciones

Traduzco la limitación a consecuencias empresariales: más coste, mayor plazo, menor fiabilidad, riesgo de seguridad, solución manual o lanzamiento posterior. La jerga técnica rara vez ayuda. Después comparo opciones concretas. Por ejemplo: la opción A entrega todo en ocho semanas; la B entrega el núcleo en tres semanas con gestión manual de excepciones; y la C utiliza una herramienta existente con límites de reporting. Cada opción debe mostrar claramente sus compensaciones. Diagramas sencillos, ejemplos o datos de prueba facilitan la comprensión. El objetivo no es convertir a los interesados en técnicos, sino permitirles tomar una decisión informada.

Enfoque — Problema → Análisis → Solución → Implantación → Impacto

Elijo un ejemplo con un antes y un después claros: un plazo largo, una tasa de errores elevada, demasiado trabajo manual, poca transparencia, reclamaciones o riesgo normativo. Explico después mi análisis, como el modelado del proceso, entrevistas con usuarios, medición de cuellos de botella, revisión de datos o análisis de causa raíz. A continuación describo la solución y mi aportación a los requisitos, la alineación de interesados, el cambio de proceso o sistema, la UAT, la formación y el lanzamiento. Cierro con resultados medibles, como horas ahorradas, menos errores, mejor cumplimiento de SLA, menor coste o mayor satisfacción, y un aprendizaje breve.

Enfoque — Ambigüedad → Supuestos → Validación → Decisión

El ejemplo debe mostrar por qué esperar a tener toda la información habría puesto en riesgo el avance, qué datos faltaban y cuáles estaban disponibles. Explico cómo avancé de forma responsable: documenté supuestos, cubrí primero las lagunas de mayor valor, consulté a interesados, planteé escenarios, utilicé datos indirectos o dividí la entrega en fases. Lo importante es mostrar un criterio equilibrado: ni temerario ni paralizado. Hago visible la incertidumbre, tomo una decisión razonada y cierro con el resultado y los ajustes realizados al disponer de información nueva.

Enfoque — Contexto → Detalle → Riesgo → Acción → Resultado

Utilizo un ejemplo en el que la atención al detalle evitó retrabajo, riesgo normativo, errores de datos, perjuicio para clientes o un problema de lanzamiento. Explico el contexto, por qué importaba y cómo lo detecté de forma sistemática: revisión de requisitos, pruebas de límites, conciliación de datos, análisis de excepciones o validación con usuarios. Después describo la acción: añadir criterios, detener la aprobación, alinear a los interesados, corregir un informe o introducir un control. El resultado debe ser concreto. La historia no trata de perfeccionismo, sino de proteger un resultado empresarial.