Business Analysis y Gestión de Requisitos. It’s the Goal not the Role

En todas las formaciones de Business Analysis surge la misma duda: ¿hasta qué nivel de detalle tenemos que definir los requisitos? Invertimos muchas horas buscando los mejores requisitos pero, ¿cuándo lo hemos conseguido? ¿cuándo podemos parar?

It’s the goal, not the role

Yo siempre respondo de la misma manera, los requisitos no son un fin en sí mismo, sino un medio para conseguir el objetivo. Es decir, un analista no es el que recoge, define y documenta los requisitos, o al menos no solo es eso. It’s the goal, not the role. El analista va a tener que definir requisitos pero no se le va a valorar (solo) por ello. Entonces, ¿en base a qué se valorará su trabajo?. Intento en este post responder a estas preguntas.

Al iniciar un curso siempre hago la misma pregunta: ¿qué quiere decir análisis? Aún me sorprende cuantas personas con el título de analista no saben responderla. Según la Real Academia de la Lengua se define análisis (entre otras acepciones) como:

1. m. Distinción y separación de las partes de algo para conocer su composición.
2. m. Estudio detallado de algo

Es decir, si aplicamos esta definición al análisis de negocio, análisis implica estudio detallado del negocio, distinción y separación de las partes que forman el negocio para conocer su composición. Podemos deducir, por lo tanto, que el análisis de negocio consiste principalmente en conocer… atención!… el negocio. (ver un muy buen post al respecto).

Un analista de negocio, como agente del cambio (sí, el analista es un posibilitador del cambio para las organizaciones), tiene como objetivo transformar al negocio reduciendo sus limitaciones y permitiendo su crecimiento. Ese es el objetivo del trabajo de análisis.  (ver al respecto el post).

Ese es el QUÉ. Eso es lo que debe conseguir. Entonces la duda está en el CÓMO. El analista suele ser una persona que no es un experto en negocio y tampoco un experto en tecnología. Ni siquiera tiene la capacidad o posición jerárquica suficiente para tomar decisiones. Lo único a lo que puede aspirar es a influir para que se tomen las mejores decisiones. El analista puede saber mucho acerca de técnicas (diagramas de casos de uso, UML, entidad-relación, user stories…), de herramientas (Enterprise Architect, JIRA…), pero la clave de su trabajo van a ser las soft skills o habilidades personales (o underlying competencies en la Guía del BABOK). Para poder influir, el analista debe poseer especialmente habilidades de comunicación, interacción y liderazgo.

El analista debe ser un buen comunicador. El negocio debe estar confiado en que la solución satisfará la necesidad inicial. El equipo técnico debe estar confiado en que saben lo que deben hacer y pueden entregarlo. Pero el analista no es el que tiene las respuestas, sino el que hace las mejores preguntas. En este sentido, el analista debe interactuar de manera adecuada tanto con negocio como con equipo técnico para entender de manera completa la necesidad y definir la mejor solución. Será más fácil su trabajo en la medida en que sea reconocido como experto (liderazgo experto).

Finalmente y en definitiva, los requisitos no son más que la tangibilización de esos esfuerzos de interacción y comunicación.

Vuelvo a la pregunta inicial: ¿hasta qué nivel de detalle tenemos que definir los requisitos? Hasta el nivel en que podemos asegurar que el negocio confía en que la solución satisfará la necesidad inicial, y el equipo técnico confía en que saben lo que deben hacer y pueden entregarlo. No más (y tampoco menos).