Autor: Raúl Fernández Cuenca (https://www.linkedin.com/in/raulfernandezcuenca/)

Area de Conocimiento de Análisis:

Con este nuevo artículo de la saga sobre PMI-PBA tools, cruzamos el ecuador de este repaso a través de las herramientas más utilizadas en las diferentes áreas de conocimiento en las que el Project Management Institute agrupa las actividades de Análisis de Negocio.

Llegados a este punto, nos adentramos en el área de conocimiento que lleva el mismo nombre que la propia disciplina: Análisis (Analysis), lo cual la convierte en la de mayor contenido de todas las que nos encontramos en el camino de preparación como Analistas de Negocio. 

Análisis (Analysis)

Una vez identificadas las necesidades de los interesados, comprendidas las oportunidades y/o problemas a abordar y recopilados los requerimientos, comenzamos a examinar, descomponer y clasificar toda la información recopilada, con el fin de entenderla, comprenderla y refinarla, hasta alcanzar el conocimiento que consideremos suficiente de la misma.

Igualmente, los procesos que forman parte del análisis, suelen llevarse a cabo de forma iterativa y en paralelo junto a las tareas de elicitación vistas en mi anterior publicación. Esto significa que, a medida que vamos recopilando información mediante la ejecución de las tareas de elicitación, vamos revisando si todo encaja, a través del análisis de toda esta información. Si al analizar la información recopilada falta conocimiento, continuamos elicitando hasta alcanzar su comprensión completa.

Debemos alcanzar tanto nivel de detalle sobre el producto final, como aquel que nos permita garantizar que lo que quieren los interesados está completamente alineado con las metas y objetivos del negocio. Es decir, aportará un valor tangible o intangible al negocio.

Gracias a esta labor de refinamiento de requerimientos, minimizaremos el impacto de la ocurrencia de posibles riesgos del producto final, y con ello, pondremos el foco y priorizaremos, todo aquello que aporte ese mayor valor al negocio.

El análisis, se centra en refinar y comprender la información relacionada con los requisitos, que consideramos suficiente

Las tipologías de información que debemos analizar para alcanzar este refinamiento, son:

• Objetivos de negocio medibles y cuándo debemos medirlos
• Alineamiento Estratégico de la solución con los objetivos del negocio
• Propietario de los beneficios, que deberá monitorizar, registrar e informar de estos beneficios
• Plan de medición que determine si cumplimos con los objetivos
• Riesgos que pueden afectar a cumplir con estos objetivos
• Supuestos y restricciones a tener en cuenta al analizar el cumplimiento de objetivos

A continuación, se identifican los procesos que nos vamos a encontrar dentro del área de conocimiento de Análisis:

• Determinar el Enfoque del Análisis
• Crear y Analizar Modelos
• Definir y Elaborar Requisitos
• Definir los Criterios de Aceptación
• Verificar Requisitos
• Validar Requisitos
• Priorizar Requisitos y otra Información del Producto
• Identificar y Analizar Riesgos del Producto
• Evaluar Opciones de Diseño del Producto

Y todos estos procesos, vienen agrupados de la siguiente manera:

Grupo de procesos de Planificación (Planning Process Group)

• Determinar el enfoque del Análisis (Determine Analysis Approach): Pensamos sobre cómo realizaremos las tareas de análisis, que es lo que analizaremos, qué modelos serán más beneficiosos; y cómo se verificarán, validarán y priorizarán los requisitos junto a otra información del producto, permitiéndonos alcanzar con ello, un entendimiento compartido sobre como será llevado a cabo el trabajo de análisis, hasta completar el desarrollo de la solución.

Grupo de procesos de Ejecución (Executing Process Group)

• Crear y Analizar Modelos (Create and Analyze Models): Creamos y analizamos todas aquellas representaciones visuales de información del producto, en forma de diagramas, tablas o textos estructurados, que son las que nos permitirán organizar y transmitir la información, de manera efectiva y concisa. Estas representaciones, facilitan su análisis e identificación de gaps existentes, entre la información representada y la que realmente es necesaria. Estos modelos podemos categorizarlos, de la siguiente manera: 

            - Modelos de alcance: Permiten delimitar la solución

            - Modelos de proceso: Permiten entender el funcionamiento y como se usará la solución

            - Modelos de reglas: Identificar reglas que la solución debe hacer cumplir

            - Modelos de datos: Definir datos utilizados y su ciclo de vida

            - Modelos de interfaz: Identificar la interacción de la solución con sistemas y usuarios

• Definir y Elaborar Requisitos (Define and Elaborate Requirements): Refinamos y documentamos los requisitos y otra información del producto hasta el nivel de detalle, formato y formalidad requerido en función de las diferentes audiencias a las que debamos dirigirnos. Hasta conseguir completar el paquete de requisitos, la definición y elaboración de requisitos implica también definir:

            - Supuestos y restricciones que pueden afectar al desarrollo de la solución.

            - Dependencias.

            - Problemas con requisitos que deban solucionarse antes de completarlos.

            - Riesgos que puedan tener efectos positivos o negativos sobre el producto.

• Definir Criterios de Aceptación (Define Acceptance Criteria): Obtenemos acuerdos que permitan verificar, que uno o más aspectos de la solución se han desarrollado con éxito. Como resultado, la definición de criterios de aceptación nos ayuda a refinar requisitos, hasta el punto de alcanzar el entendimiento compartido de las partes interesadas, sobre lo que se entregará al final.

• Verificar Requisitos (Verify Requirements): Comprobamos que los requisitos y otra información del producto que hayamos tomado, tienen suficiente calidad, son precisos y cumplen con los estándares aplicables. Si un requisito o información no es verificada, debemos revisarla y reescribirla hasta alcanzar la calidad suficiente como para continuar.

La información recopilada de un producto, tiene la calidad suficiente, cuando sea correcta, completa y consistente.

• Validar Requisitos (Validate Requirements): Con la validación de requerimientos, lo que hacemos realmente, es confirmar que estos requerimientos cubren el valor esperado y cumplen con los objetivos y metas del negocio. Esto permite reducir el riesgo de alejarnos de lo que realmente quieren los interesados y acabar entregando una solución incorrecta

• Priorizar Requisitos y Otra Información del Producto (Prioritize Requirements and Other Product Information): Los requisitos que ya han sido validados, debemos  priorizarlos de forma que nos centremos en aquello en lo que se debe trabajar antes o después, para que los objetivos de negocio se logren en el orden que mejor se ajuste a las necesidades. Con la priorización, ponemos por tanto el foco, en aquello que aporta más valor. 

• Identificar y Analizar Riesgos del Producto (Identify and Analyze Product Risks): Debemos descubrir y examinar toda aquellas incertidumbres que pueden afectar de forma positiva o negativo, al éxito de la definición o desarrollo de nuestra solución. Esta identificación y análisis de riesgos del producto (NO del proyecto), va a permitir por tanto, poder descubrir y abordar de forma proactiva, todas aquellas fortalezas y debilidades que detectemos sobre el producto.

• Evaluar Opciones de Diseño del Producto (Assess Product Design Options): Identificamos, analizamos y comparamos las diferentes opciones de diseño presentadas para abordar la solución, en base a las metas y objetivos establecidos por el negocio, los costes de implementación, la viabilidad y los riesgos asociados al desarrollo de cada una de ellas. Los resultados de esta evaluación pueden ser utilizados para proponer recomendaciones de rediseño sobre las opciones presentadas, y proporcionan información relevante sobre los pros, contras, riesgos y costes de desarrollar cada una de las opciones propuestas. Esta labor la llevamos a cabo junto al Project Manager, como parte de sus actividades de Definición del Alcance del Proyecto.

  Después de comparar las diferentes opciones de diseño, y determinar cual es la que mejor logra los objetivos generales, aquellas que no son consideradas viables, son eliminadas de la lista para no tenerlas en consideración. Esta labor es llevada a cabo, siempre antes de que comencemos con el desarrollo de cualquier  solución  o componente de la misma.

Herramientas empleadas por los procesos de análisis

Como en posts anteriores, a continuación resumo las herramientas utilizadas para producir los entregables para cada proceso, y que es obligado conocer, si lo que queréis es prepararos el examen de certificación PMI-PBA: 

7.1 – Determinar el enfoque del Análisis (Determine Analysis Approach)

• Document Analysis
• Brainstorming
• Retrospectives and Lessons Learned

7.2 – Crear y Analizar Modelos (Create and Analyze Models)

Scope Models:

1. Context diagram
2. Ecosystem map
3. Event list
4. Feature model
5. Goal and business objectives model
6. Organizational chart
7. Use case diagram

Process Models:

1. Process flows
2. Use Case
3. User Stories

Rules Models: 

1. Business Rules Catalog
2. Decision tree and decision table

Data Models:

1. Data dictionary
2. Data flow diagram
3. Entity relationship diagram
4. State table and state diagram

Interface Models: 

1. Prototypes, wireframes, and display-action-response models
2. Report table
3. System interface table
4. User interface flow

7.3 – Definir y Elaborar Requisitos (Define and Elaborate Requirements)

• Business rules catalog
• Definition of ready
• Glossary
• Product backlog
• Requirements management tool
• Story elaboration
• Story slicing
• Use case
• User story

7.4 – Definir Criterios de Aceptación (Define Acceptance Criteria)

• Behavior-Driven Development (BDD)
• Definition of Done (DoD)
• Story elaboration

7.5 – Verificar Requisitos (Verify Requirements)

• INVEST
• Peers Review

7.6 – Validar Requisitos (Validate Requirements)

• Delphi
• Goal model and business objectives model
• Traceability matrix
• Walkthroughs

7.7 – Priorizar Requisitos y Otra Información del Producto (Prioritize Requirements and
Other Product Information)

• Backlog management
• Goal model and business objectives model
• Iteration planning
• Kanban board
• Prioritization schemes
• Buy a Feature
1. Delphi
2. Minimum Viable Product (MVP)
3. MoScoW
4. Multivoting
5. Purpose Aligment Model
6. TimeBoxing
7. Weighted Ranking
8. Weighted Shortest Job First (WSJF)
• Story mapping
• Traceability matrix

7.8 – Identificar y Analizar Riesgos del Producto (Identify and Analyze Product Risks)

• Context diagram
• Ecosystem map
• Elicitation techniques
• Estimation techniques
• Organizational chart
• Process flows
• Product backlog
• Risk burndown chart
• Risk register
• Root cause and opportunity analysis
• SWOT analysis

7.9 – Evaluar Opciones de Diseño del Producto (Assess Product Design Options)

• Affinity diagram
• Brainstorming
• Competitive analysis
• Focus groups
• Product backlog
• Real options
• Vendor assessment

Bibliografía
The PMI Guide to BUSINESS ANALYSIS (2017)
Project Management Institute, Inc.
ISBN: 978-1-62825-198-2

Autor: Raúl Fernández Cuenca (https://www.linkedin.com/in/raulfernandezcuenca/)

Hace ya unos cuantos meses, publiqué el segundo de los capítulos de mi saga sobre PMI-PBA tools, donde hacía un breve repaso de las herramientas utilizadas en la segunda de las áreas de especialización en las que el Project Management Institute agrupa las tareas de Análisis de Negocio.

Si en aquella ocasión me centraba en el área de conocimiento de Compromiso de los grupos de interés (Stakeholder Engagement), hoy realizaré una revisión rápida sobre conceptos básicos de procesos y de herramientas empleadas como parte de las actividades relacionadas con el área de conocimiento de la Elicitación (Elicitation).

Elicitación (Elicitation):

Aunque son muchas las personas que cuando utilizo la palabra Elicitación, me rectifican indicando que me he confundido y que debería poner “Licitación”, he de deciros que el término Elicitación existe y viene del verbo inglés “To Elicit”, que corresponde a los verbos españoles provocar, suscitar u obtener.

Por ello, decimos en Análisis de Negocio que la Elicitación es aquella actividad de obtener información de las partes interesadas y otras fuentes, sobre un producto final que queremos construir, hasta alcanzar un entendimiento compartido de esta.

Es por todos sabido que los stakeholders tienen deseos, necesidades e ideas, que con bastante asiduidad no saben expresar con la suficiente claridad, haciendo necesario que dispongamos del conocimiento y la experiencia suficientes como para saber identificar enfoques y técnicas apropiadas en cada momento, que permitan extraer correctamente toda esta información.

Será, por lo tanto, una tarea de interacción de ida y vuelta entre el analista y los stakeholders, de intercambio de información sobre el producto final que se quiere llegar a obtener. Esta tarea iterativa sólo se da por finalizada, cuando todos los criterios de aceptación del producto quedan claros. Por esta razón, para llegar a “refinar” este conocimiento por completo, las actividades de elicitación y análisis se realizan, a menudo, al mismo tiempo.

Elicitar es ayudar a extraer el conocimiento que tienen los interesados en su cabeza.