Analista de Negocio, de Sistemas, o de Procesos ?

El rol de Análisis cumple varias funciones: de negocio, sistemas, requisitos, procesos, etc. En definitiva, y conforme al IIBA todas estas funciones están involucradas dentro de la definición de un Análisis del Negocio. Siendo asi, la definición es muy abarcativa y puede crear cierta confusión en la práctica y la academia, que impacta en los diseños de roles, evaluación de habilidades, reclutamiento y desarrollo profesional. Existen además distintas certificaciones y cuerpos de conocimientos (BoKs) lo cual trae más vaguedad al tema. En este artículo trataremos de explicar las distintas definciones de Analistas según la visión del IIBA, PMI y ABPMP. Lea más aqui

Anuncios

El Analista de Negocio y su rol en el Proyecto

En el anuncio de la nueva certificación PMI-PBA, el PMI citó una estadística respecto de que se prevé que los trabajos de análisis de negocios aumenten un 19 % para 2022. En esa misma dirección el MBA y PMP Ori Schibi explica en sus charlas y eventos del PMI cómo incorporar el cada vez más valioso papel del analista de negocios (BA) en el proceso de gestión de las expectativas de los interesados, y las oportunidades de colaboración PM-BA para maximizar los beneficios relacionados con la comunicación, la comprensión de las necesidades de las partes interesadas, la gestión de riesgos, control de cambios y la gestión de calidad. Este artículo explica los conceptos de este autor y cómo se expande el rol del BA, aumentando su colaboración en el proyecto para lograr resultados más eficaces y con mayor eficiencia. Leer más aquí

Intersecting Project Management and Business Analysis

Los gerentes de proyecto experimentados saben que además de controlar costos y ajustarse al cronograma del proyecto, la gestión del alcance es una de las tareas más difíciles en la gestión de proyectos. El punto de vista de lo que define el éxito del proyecto ha ido más allá de la simple gestión de la triple restricción. Uno de los aspectos más importantes hoy en día es la gestión orientada a la satisfacción de las partes interesadas. Manejar las expectativas y dar forma a las percepciones a través de una comunicación efectiva es importante, pero la recopilación de requisitos eficaces en el inicio del proyecto es el paso clave que asegurará que el proyecto ofrezca lo que realmente se espera. En este sentido, el analista de negocios (BA) debe convertirse en un aliado clave y asesor del director del proyecto. La mayoría de los gerentes de proyecto no están entrenados en la disciplina de análisis de negocios, de modo que aprovechando eficientemente las habilidades que un analista de negocios puede ofrecer, se puede mejorar en gran medida la posibilidad de éxito del proyecto. Leer el artículo

Gestión de Requisitos: Nueva certificación del PMI

Como sabemos la organización PMI® permite mejorar y madurar el éxito de las organizaciones en la profesión de gestión de proyectos a través de sus normas reconocidas a nivel mundial, certificaciones, recursos, herramientas, investigación académica, publicaciones, cursos de desarrollo profesional y otras oportunidades. En un reciente anuncio, la institución hizo realidad algo que venía promulgando sobre nuevas ofertas en materia de “Gestión de Requisitos”. Esto terminó en el ofrecimiento actual de una nueva certificación en “Análisis de Negocio” el PMI Profesional Certification en Análisis de Negocios (PMI- PBA). Además anunció otros planes tales como el desarrollo de una “Guía Práctica de Análisis de Negocio” para este año, así como un “Practice Standard sobre Análisis de Requerimientos” para el próximo año. La primera pregunta que me vino a la mente fue el título de un post en Internet: ¿Necesitamos (otra) certificación de análisis de negocios?. Leer más aquí

Definiendo Requerimientos: Tradicional vs. Caso de Uso vs. Historias de Usuario

He trabajado la mayor parte de mi vida con proyectos de IT utilizando metodología tradicional y últimamente tuve varias experiencias con la gestión ágil. En muchos casos, el uso de las historias de usuario parece ser un punto de fricción dado que no todos entienden su uso y sobre todo para aquellos analistas que provienen de métodos tradicionales terminan armando historias tan largas y detalladas que se asemejan a los requerimientos tradicionales. La pregunta común es “¿Cuáles son las diferencias entre los requisitos tradicionales, casos de uso, y las historias de los usuarios?” En este artículo trato de responder a esta inquietud. Verlo aquí