Preguntas de entrevista Analista de negocio

Empiezo siempre entendiendo el problema que intentan resolver, no la solución que creen querer. Si un stakeholder dice "necesito un nuevo informe", mi primera pregunta es "¿qué decisión te ayudará a tomar ese informe?" Utilizo una combinación de técnicas: entrevistas estructuradas para decisores, recorridos de proceso para equipos operativos y facilitación de talleres cuando los requisitos abarcan varios equipos. Documento lo que escucho como user stories y lo devuelvo para validación, porque los stakeholders suelen descubrir lagunas o conflictos cuando ven sus requisitos escritos. También saco a la luz la distinción "imprescindible" versus "deseable" pronto, porque el scope creep casi siempre surge de confundir ambos.

Los requisitos contradictorios casi siempre son señal de prioridades en conflicto, no de un problema de documentación. Mi primer paso es hacer el conflicto explícito: presento ambos requisitos lado a lado y muestro a cada stakeholder por qué están en tensión. Esto suele sacar a la luz suposiciones que ninguna parte había articulado. Luego facilito una decisión sobre cuál tiene prioridad, basada en impacto de negocio y alineación estratégica, y documento esa decisión con su razonamiento. Si el conflicto no puede resolverse a nivel de stakeholders, escalo al decisor apropiado con un resumen claro del compromiso y una recomendación.

Uso un enfoque por capas. En el nivel más alto capturo el caso de negocio y los objetivos. Por debajo documento requisitos funcionales como user stories con criterios de aceptación, y los requisitos no funcionales por separado. Mantengo una matriz de trazabilidad de requisitos para mostrar qué funcionalidades del sistema se corresponden con qué requisitos de negocio, esencial para evaluar el impacto de cambios cuando el alcance varía. Versiono toda la documentación y comunico los cambios formalmente. También hago una revisión de requisitos con el equipo de desarrollo antes del sign-off para detectar ambigüedades o problemas técnicos.

La IA ha resultado útil en varios puntos de mi flujo de trabajo como BA. Para la documentación de requisitos, la uso para convertir notas brutas de stakeholders en user stories estructuradas y criterios de aceptación: el formato sale bien, aunque siempre valido la lógica contra lo que el negocio realmente dijo. Para el mapeo de procesos, he usado la IA para identificar lagunas o redundancias describiendo un proceso en texto plano y pidiendo un análisis, lo que saca a la luz cosas que quizás no habría detectado. Para el trabajo de datos ad hoc, la uso para ayudar a redactar y depurar consultas SQL o scripts Python. Para presentar hallazgos a stakeholders no técnicos, uso la IA para simplificar y estructurar información compleja en un lenguaje que quede claro en las reuniones. Donde soy más cautelosa es en todo lo que requiere un conocimiento profundo de nuestros sistemas y procesos específicos: el modelo no tiene ese contexto.

Durante un taller de requisitos para un nuevo portal de clientes, mapeé el proceso actual de principio a fin y noté que dos equipos mantenían por separado los mismos datos de clientes en sistemas distintos, sin proceso de sincronización entre ellos. Ninguno lo había señalado porque cada uno asumía que el otro era el sistema de referencia. Reuní a ambos equipos con el mapa de proceso y documenté la inconsistencia de datos como un problema central a resolver. La solución final incluyó un paso de consolidación de datos que ningún equipo había incluido en el alcance inicial. Sin él el portal habría mostrado información contradictoria a los clientes.

A mitad de una implementación de CRM de seis meses, la empresa adquirió una compañía más pequeña cuyos procesos eran materialmente distintos a los requisitos originales. Realicé un análisis de impacto rápido: identifiqué qué requisitos no cambiaban, cuáles necesitaban modificación y cuáles nuevos había que añadir. Lo presenté al sponsor como una solicitud de cambio estructurada con estimación de tiempo y coste adicional. Eligió ampliar el plazo seis semanas y ajustar el alcance. Después re-facilité los talleres de requisitos incorporando a los stakeholders de la empresa adquirida. El proyecto entregó según el plan revisado.

Lo encontré con un equipo de desarrollo que había sufrido con documentos de requisitos demasiado prescriptivos que limitaban sus decisiones técnicas sin aportar valor. Cambié mi enfoque: en lugar de entregar especificaciones extensas, empecé a organizar sesiones cortas conjuntas para explorar los requisitos juntos, dejando claro que el diseño de la solución era suyo. Me centré en el "qué" y el "por qué" y me mantuve fuera del "cómo". También pasé a user stories más cortas con criterios de aceptación claros, que el equipo encontraba mucho más útiles para la planificación de sprint. En dos meses los desarrolladores me incluían proactivamente en sus conversaciones de diseño.

Uso modelos de proceso en diferentes niveles de abstracción según la audiencia y el propósito. Para stakeholders sénior uso diagramas de carril de alto nivel para mostrar quién hace qué y dónde se producen los traspasos. Para equipos operativos entro más en detalle con flujos que capturan puntos de decisión, excepciones e interacciones de sistema. Uso notación BPMN cuando la organización tiene un estándar, o diagramas de flujo más simples cuando la audiencia no es técnica. El valor clave de un modelo de proceso es hacer explícito el conocimiento tácito: casi siempre encuentro pasos que las personas realizan pero no mencionaron.

Redacto los criterios de aceptación en formato Dado / Cuando / Entonces o como lista de condiciones verificables. El principio clave es que cada criterio debe ser verificable de forma independiente: alguien que no participó en la redacción debe poder mirar el sistema y decir definitivamente si pasa o no. "El sistema debe ser rápido" no es un criterio de aceptación. "La página carga en menos de 2 segundos en una conexión 4G para el 95% de las solicitudes" sí lo es. También me aseguro de que los criterios cubran casos límite y rutas de error, no solo el camino feliz. Los criterios ambiguos son la principal causa de disputas entre negocio y desarrollo al final de un sprint.

El análisis de datos aparece en mi trabajo de varias formas. En la fase de descubrimiento analizo datos existentes para entender el estado actual: volúmenes, calidad de datos y patrones que cuestionan las suposiciones de los stakeholders. Durante la definición de requisitos documento los requisitos de datos: qué datos necesita cada función, de dónde vienen y qué transformaciones se requieren. Uso datos para validar suposiciones: si un stakeholder dice "la mayoría de los clientes hacen X", intento verificarlo antes de construir un requisito sobre esa base. Uso SQL para consultas estructuradas y Excel para análisis ad hoc.