¿Cómo recopilas requisitos de stakeholders que no saben exactamente qué quieren?

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.

¿Cómo gestionas requisitos contradictorios de diferentes stakeholders?

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.

¿Cómo documentas y gestionas los requisitos en un proyecto?

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.

Cuéntame sobre un momento en que identificaste un problema que los stakeholders no habían notado.

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.

Describe un proyecto donde los requisitos cambiaron significativamente durante la ejecución.

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.

¿Cómo has construido relaciones con equipos técnicos que veían la participación del BA como una carga?

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.

¿Cómo utilizas el modelado de procesos en tu trabajo?

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.

¿Cómo redactas los criterios de aceptación y por qué importa?

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.

¿Cómo abordas el análisis de datos como parte del rol de BA?

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.

Analista de negocio

Las entrevistas para Analista de negocio evalúan tu capacidad para conectar los problemas de negocio con las soluciones técnicas. Los entrevistadores quieren ver que puedes recopilar y documentar requisitos con precisión, traducir procesos complejos en especificaciones claras y comunicarte igual de bien con stakeholders y desarrolladores. Esta guía cubre las preguntas más frecuentes y las respuestas que distinguen a los analistas que generan cambio real de los que producen documentos que acaban ignorados.

Para consejos generales de preparación, consulta nuestra guía sobre las preguntas de entrevista más frecuentes.

Preguntas de entrevista habituales para Analista de negocio

Preguntas conductuales para puestos de Analista de negocio

Preguntas técnicas para candidatos a Analista de negocio

Lo que buscan los reclutadores en las entrevistas para Analista de negocio

Los mejores Analistas de negocio son intelectualmente curiosos y cómodos con la ambigüedad. Indaga cómo gestionan stakeholders que no pueden articular lo que necesitan: la respuesta revela si el candidato es un facilitador o un documentador. Pregunta específicamente sobre cambios de alcance y conflictos de requisitos. Observa si distinguen entre requisitos y diseño: los buenos analistas definen el "qué" y dejan el "cómo" al equipo técnico.

Preguntas que puedes hacer al entrevistador

→¿Cómo interactúa el rol de BA con la gestión de producto aquí: dónde termina uno y dónde empieza el otro?
→¿Qué metodologías utiliza el equipo y cuánta flexibilidad hay para adaptarlas al proyecto?
→¿Cómo se toman las decisiones de priorización de requisitos y quién tiene la última palabra sobre el alcance?
→¿Cómo es un proyecto típico desde el brief inicial hasta el go-live?
→¿Cuáles son las principales carencias o retos en el proceso de requisitos actual?

Practica estas preguntas antes de tu entrevista

El simulador de entrevista prepara una sesión de práctica basada en una oferta de empleo concreta y tu perfil, para que repases las preguntas con más probabilidad de aparecer.

Empezar a practicar

Gratis durante la beta. Sin compromiso.

Puestos relacionados