Analista de Negocio
Analista de negocio es el título menos estandarizado de esta lista. En una empresa significa recoger requisitos para un desarrollo; en otra, mejora de procesos en operaciones; en una tercera, modelización financiera; en una cuarta, esencialmente análisis de datos con otro nombre. Un currículum que no resuelve esa ambigüedad en las tres primeras líneas obliga a quien lee a adivinar, y quien adivina lo hace en tu contra.
Di qué clase de analista eres antes que nada
La línea de resumen hace más trabajo en este currículum que en cualquier otro de esta serie. «Analista de negocio con 6 años de experiencia» no resuelve nada. «Analista de negocio especializado en procesos regulados de siniestros —requisitos para la sustitución del sistema central y el rediseño de procesos alrededor— » te sitúa de inmediato.
Esto importa porque quien criba suele tener un hueco muy concreto. Alguien que reemplaza a un analista de requisitos en una migración de core bancario no busca a un especialista en mejora de procesos, por bueno que sea. Ser claramente el perfil equivocado es mejor resultado que ser vagamente plausible, porque la plausibilidad vaga es lo que llena una pila de candidatos a los que nadie hace avanzar.
Si de verdad abarcas dos de estos mundos, encabeza con el que describe la oferta y deja el otro más abajo como amplitud.
El trabajo de requisitos necesita un artefacto y una consecuencia
«Recogí y documenté requisitos de negocio» es la frase más común de estos currículums y resulta invisible, porque es lo que el título ya implica. Lo que distingue a un candidato es la forma del trabajo: cuántos interlocutores discrepaban, cuánto era heredado sin nadie que lo entendiera ya, y qué pasó cuando el desarrollo se encontró con el documento.
«Escribí 40 historias de usuario para la reconstrucción de la entrada de siniestros en tres equipos que hasta entonces definían “siniestro” de forma distinta, y dirigí el taller que lo cerró» es una afirmación real. Tiene una cifra, un obstáculo genuino y una resolución que quien lee puede imaginar.
Los requisitos que cambiaron también son material. Un analista que detectó que un requisito declarado era erróneo antes de empezar el desarrollo ahorró más dinero que otro que lo documentó fielmente, y esa historia es mucho más interesante que un recuento de documentos.
El trabajo de procesos necesita un antes y un después
Cuando el trabajo es mejora de procesos, el currículum necesita el estado de la cosa a ambos lados. «Mapeé el proceso de devoluciones de extremo a extremo y eliminé dos pasos de aprobación, reduciendo la gestión mediana de 9 días a 4» está completo: dice qué había, qué cambió y qué produjo.
Nombrar un método sin resultado es el fallo habitual. Six Sigma, mapeo de flujo de valor y reingeniería de procesos describen cómo trabajaste; por sí solos hacen suponer que no salió nada medible, lo que normalmente no es cierto.
Cuando la mejora se rechazó o nunca se implantó, di qué encontraste y cuál fue el obstáculo. Los analistas se topan con esto constantemente, y cómo alguien habla de una recomendación que no llegó a nada es genuinamente informativo.
Dónde suelen descartarse estos currículums
El más frecuente es leerse como un analista de datos más flojo. Los analistas de negocio que se apoyan en SQL y cuadros de mando para parecer técnicos acaban comparados con quien hace eso a jornada completa, y pierden una comparación en la que no necesitaban entrar. Aquí la soltura técnica es un detalle de apoyo, no el titular.
El segundo es una lista de herramientas en lugar de un método: Jira, Confluence, Visio, Excel. Todo el mundo en la pila las ha usado. Van en una línea abajo y en ningún otro sitio.
El tercero es el conocimiento de dominio invisible. Sobre todo en sectores regulados, saber cómo funcionan de verdad los siniestros, la liquidación o la codificación clínica suele ser lo más escaso que tiene un candidato, y se omite habitualmente porque desde dentro parece obvio. No lo es para quien lee, y con frecuencia es la razón por la que se avanza a un candidato y no a otro.
Términos que aparecen en casi todas las ofertas.
- Elicitación de requisitos
- El artefacto, el número de interlocutores y el desacuerdo que cerraste.
- Mapeo de procesos
- Los estados antes y después. Un nombre de método a secas no implica que cambiara nada.
- Gestión de interlocutores
- Qué áreas y qué hacía difícil el acuerdo. La etiqueta está en todos estos currículums.
- SQL / informes
- Evidencia de apoyo, no el titular: esa comparación la pierdes frente a analistas a jornada completa.
- Conocimiento del dominio
- Lo más escaso que tienes y lo que más se omite porque desde dentro parece obvio.
Añade un término solo cuando tu propia experiencia lo respalde. ApplySpan señala los requisitos que no puedes acreditar en lugar de escribirlos por ti.
Preguntas
¿Es lo mismo un currículum de analista de negocio que uno de analista de datos?+
No, y el solapamiento es justo lo que causa problemas. A un analista de datos se le evalúa por la pregunta, el análisis y la decisión que provocó. A un analista de negocio, por traducir entre personas que quieren cosas distintas y dejar algo que un equipo pueda construir o operar.
¿Cómo muestro impacto si no implementé el cambio?+
Atribúyete la parte que sí fue tuya y nómbrala con precisión: la recomendación, la especificación, el taller que cerró una definición. La implantación que no hiciste es contexto. Los analistas que describen ese límite con claridad se leen como más senior, no menos.
¿Incluyo certificaciones como CBAP o Six Sigma?+
Ponlas en una línea si las tienes. A veces pasan un filtro y nunca ganan una entrevista por sí solas: un proceso concreto que cambiaste, con las cifras a ambos lados, hace bastante más.