Cómo realizar un buen análisis de requisitos y qué cualidades ha de tener un Business Analyst

Cómo realizar un buen análisis de requisitos y qué cualidades ha de tener un Business Analyst para implementar un proyecto tecnológico como la transformación digital de una empresa o el desarrollo de una app.

Según la guía BABOK del International Institute of Business Analysis, el Análisis de Negocio (Business Analysis) es “el conjunto de tareas y técnicas utilizadas para trabajar como enlace entre los stakeholders con el fin de entender la estructura, políticas, y operaciones de una organización, y para recomendar soluciones que permitan a la organización alcanzar sus metas”.

Dicho de otro modo, el Business Analysis es la traducción de las necesidades de una organización en los requerimientos técnicos de una solución, especialmente en el campo de las soluciones tecnológicas, como la transformación digital o el desarrollo de apps.

Por lo tanto, el Analista de Negocio (Business Analyst) es un perfil profesional capaz de entender el modelo de negocio, el plan estratégico y de operaciones de la organización y traducirlo en requerimientos técnicos y funcionales concretos. Ser capaz de entender cómo funciona el negocio, sus procesos y los diferentes roles de los profesionales, identificar áreas u oportunidades de mejora y definir las soluciones necesarias teniendo especialmente en cuenta la viabilidad técnica y económica de la propuesta.

 [pic 1]

El analista de negocio puede ser una persona que desempeñe esta función en exclusiva o puede ser cualquier otro profesional de un área concreta que desempeñe esta función de cara a un momento dado o un proyecto en concreto. Por lo tanto, no importa tanto el puesto o rol que el profesional desempeñe en la organización, sino que lleve a cabo el objetivo del análisis de negocio. En muchas ocasiones estos perfiles son analista+s de sistemas, consultores IT, ingenieros, analistas de procesos, project managers, etc.

La importancia del Business Analysis (BA) reside en la incertidumbre implícita en cualquier proyecto de desarrollo tecnológico, siendo el BA un conjunto de métodos dirigidos a minimizar esta incertidumbre y por lo tanto los riesgos, es decir, se encarga de “aterrizar” al máximo el proyecto antes del inicio de su implantación.

Cualidades del Business Analysis

El Analista de Negocio debe poseer un importante pensamiento analítico orientado a la resolución de problemas, un conocimiento transversal de la compañía, especialmente de las interrelaciones y dependencias entre departamentos, una fuerte habilidad de comunicación y negociación, puesto que en muchas ocasiones le tocará intermediar entre departamentos para facilitarles el encuentro en puntos comunes y, por supuesto, debe tener un amplio conocimiento de las tecnologías disponibles y sus principales características e implicaciones.

Es muy común en organizaciones “tipo” encontrar cómo se generan tensiones entre departamentos al tratar de impulsar un proyecto tecnológico; un caso típico son las tensiones entre departamentos de marketing, innovación y sistemas. Marketing e Innovación ven cómo se solapan en algunas responsabilidades cuando la digitalización se dirige a la comunicación o al desarrollo de producto; Sistemas limita el alcance de los requerimientos al estar orientado a la estabilidad, funcionamiento y seguridad de los sistemas (suele tener una alta aversión al riesgo frente a la visión de innovación por ejemplo). El Business Analyst debe dimensionar, priorizar y ponderar las preocupaciones y objetivos de los diferentes departamentos y encontrar los puntos de encuentro, ofreciendo soluciones equilibradas.[pic 2]

La inversión en Análisis de Negocio impactará muy positivamente en el presupuesto final de implementación dado que minimizará incertidumbre, errores y desviaciones. En muchas ocasiones se realizan descripciones, análisis de requisitos o requerimientos de propuesta muy pobres, donde abundan generalidades, imprecisiones o falta de detalle dando por entendido muchos aspectos que deberían haberse concretado. Este tipo de arranques de proyecto acaban generando multitud de iteraciones, ya que la definición se va realizando a lo largo del proyecto, requiriendo una y otra vez rehacer partes del proceso hasta ajustar la realidad a unas expectativas que no se habían plasmado ni consensuado en un documento.

En tecnología las prisas suelen curiosamente ralentizarlo todo. Es crucial una planificación pormenorizada y una buena documentación para facilitar una comprensión del alcance de un proyecto por parte de todos los participantes y stakeholders.

Un mal análisis de requisitos conduce a procesos de innovación caóticos

Imaginemos mediante un caso bastante común un requerimiento para una plataforma de gestión online, en el que a la primera pantalla que se va a encontrar el usuario la denominamos “Login”. En el análisis de requisitos no se profundiza ni detalla mucho más dando por hecho que un Login no deja de ser una pantalla con un campo “usuario” y otra para la “contraseña”.

Arrancamos la implementación y alguien del departamento de Recursos Humanos apunta que es complejo generar de nuevo claves y contraseñas cuando ya se disponen de claves para otras herramientas y pregunta si no se pueden utilizar las mismas credenciales. Perfectamente lógico, pero se acaba de abrir la puerta a una integración con una tercera herramienta o sistema que habrá que analizar para comprobar si dispone de API, etc.[pic 3]

Por otro, lado alguien pregunta qué sucede si un usuario pierde la clave de acceso. En este caso se plantean diferentes soluciones para recuperar la contraseña (de nuevo más tiempo y más integración), alguien más indica que sería bueno saber en esa pantalla a qué se está accediendo y facilitar en el primer acceso un tutorial u on-boarding que facilite paso a paso la comprensión para el usuario (de nuevo, más ideas, más desarrollo, más recursos necesarios)…

Al final, una funcionalidad muy estándar y aparentemente sencilla puede acabar requiriendo cinco veces más de los recursos presupuestados, solo por haber dado por sentado que era una funcionalidad sencilla y no haber profundizado un poco más. Si este ejemplo lo aplicamos al resto de funcionalidades, algunas de ellas con una complejidad mucho mayor, las desviaciones acaban siendo la tónica general del proyecto y la implementación se convierte en un proceso totalmente caótico del que nadie sabe cómo se va a salir ni cuándo. De ahí que muchos proyectos de tecnología queden estancados, se dilaten o incluso nunca lleguen a ver la luz. Y todo eso suele originarse con un análisis de requerimientos pobre o flojo.

...