Las entrevistas de business analyst testean cómo levantas requisitos, manejas stakeholders en desacuerdo, y conviertes la ambigüedad en algo que un equipo pueda construir. Aquí están las preguntas más comunes con respuestas modelo. Junior: teoría básica, definiciones y casos prácticos simples.
Un requisito funcional dice qué hace el sistema — el usuario puede resetear una contraseña. Uno no funcional dice qué tan bien — en menos de dos segundos, para diez mil usuarios concurrentes, accesible a un lector de pantalla. Los requisitos no funcionales son los que se dejan afuera y luego causan una reescritura, porque restringen la arquitectura en vez del comportamiento.
Que puedas decir inequívocamente si se cumple. "La página debería cargar rápido" no es testeable; "la página renderiza en menos de dos segundos en una conexión 3G" sí lo es. La prueba es si dos personas leyéndolo construirían la misma verificación — si no lo harían, el requisito es un deseo.
Una user story nombra quién quiere algo y por qué, en una oración, y existe para empezar una conversación en vez de reemplazarla. Los criterios de aceptación son las condiciones que la hacen terminada, escritas para que un desarrollador y un tester acuerden de antemano. Una story sin criterios es de donde vienen los desacuerdos de alcance.
Un requisito de negocio es el resultado que la organización quiere — reducir llamadas de soporte sobre facturación. Un requisito de solución es lo que el sistema debe hacer para llegar ahí. Confundirlos es cómo un proyecto entrega exactamente lo que se pidió y no mueve el número que a alguien le importaba.
Entrevistas para profundidad con una persona, workshops cuando varios stakeholders deben acordar en la sala, observación para cómo se hace realmente el trabajo en vez de cómo se describe, y análisis de documentos para reglas ya escritas. La observación es la subutilizada, porque lo que la gente dice que hace y lo que hace difieren más de lo que se dan cuenta.
Un use case describe una interacción en pasos, incluyendo flujos alternativos y de excepción — es completo. Una user story es un placeholder para una conversación y deliberadamente no lo es. Los use cases convienen para flujos regulados o complejos donde importan las excepciones; las stories convienen para trabajo iterativo donde el detalle emerge.
En una entrevista real hablas bajo presión. Cam hace estas mismas preguntas, evalúa cada respuesta y muestra exactamente qué mejorar.
Practicar entrevista de Junior Business Analyst →