Todavía Otro Cuerpo de Conocimiento Más (BABOK 2.0)

El Business Analysis Body of Knowledge (BABOK) es una colección de conocimiento dentro de la profesión del Análisis de Negocio y refleja unas mejores prácticas generalmente aceptadas. Como con otras profesiones, el cuerpo de conocimiento es definido y mejorado por profesionales Analistas de Negocios quienes lo aplican en su trabajo diario. El BABOK  describe las áreas de conocimiento del Análisis de Negocio, sus actividades asociadas y las tareas y habilidades necesarias para ser efectivo en su ejecución.

Como todo cuerpo de conocimiento (PMBOK, SWEBOK, entre otros), el BABOK tiene varias áreas de Conocimiento. Cada una de estas áreas se enfoca en una parte del análisis del negocio. Estas áreas son:

·         Planeación y Monitoreo del Análisis de Negocio

·         Obtención de Requisitos

·         Gestión y Comunicación de Requisitos

·         Análisis Empresarial

·         Análisis de Requisitos

·         Evaluación y Validación de la Solución

·         Competencias Subyacentes 

·         Dinámica de Análisis de Negocios 

Me parece importante anotar que esto no es más que eso, una propuesta de prácticas que funcionan en ciertos contextos, en muchos realmente, pero no es una solución definitiva a todos los posibles escenarios que nos encontramos en la “vida real” del análisis y modelado de negocios en los proyectos actuales.

Cuando se trata de estándares siempre recomiendo darles el beneficio de la duda. Lo primero que debemos hacer es estudiarlo profusamente y entenderlo, apoyándonos en expertos que lo hayan puesto en prácticas en diversas situaciones. A partir de allí, podemos iniciar un proceso de adopción y adaptación. A esto último yo lo llamo “tropicalización”.

Lo adaptamos a nuestras necesidades, a nuestra forma de hacer las cosas, a nuestro presupuesto y economía, a nuestra experiencia (que siempre nos va a faltar), a nuestra idiosincrasia, a nuestra forma de ver el mundo y de interpretarlo, a la agenda tan apretada que tenemos en los proyectos. Esto es importante, porque este tipo de estándares son definidos por organizaciones o grupos de organizaciones que tienen otra filosofía, existen en otras economías (generalmente mejores que las nuestras), la gente que los práctica allá piensa diferente, los proyectos tienen otros presupuestos y otras agendas, los equipos de trabajo son más grandes, tienen más recursos y más experiencia, tienen más expertos, etc.

¿A quiénes les interesa este estándar?

Principalmente a los Analistas del Negocio, pero también a los Ingenieros de Requisitos o Analistas de Requisitos.

“El Analista de Negocios es el responsable de identificar las necesidades de negocios de sus clientes y usuarios interesándose en ayudarlos a determinar las soluciones a sus problemas”.

·         El Analista de Negocios es responsable del:

o    Desarrollo y Administración de Requisitos de sistemas

o    Validación de requisitos para re-ingeniería de Procesos

o    Análisis y recomendación de soluciones de mejora continua

o    Validación y documentación de problemas y oportunidades de negocio

o    Análisis de requisitos Organizacionales u Operacionales

·         Las Soluciones NO son predeterminadas por el Analista- de Negocios- y son manejadas solamente a través del requerimiento de negocios.

·         Las Soluciones frecuentemente incluyen componentes de desarrollo de sistemas- pero pueden también consistir en mejoramiento de procesos o cambios organizacionales.

·         El Analista de Negocios es el facilitador clave dentro de una organización, el cual actúa como puente entre el cliente, el usuario interesado y el equipo de solución.

·         El Análisis de Negocios es distinto al análisis financiero, a la administración de proyectos, al aseguramiento de calidad, al desarrollo organizacional, a la ejecución de pruebas, a la capacitación y al desarrollo de documentación.

Sin embargo dependiendo de la organización, un Analista de Negocios puede ejecutar alguna o todas estas funciones relacionadas.

Estándares Relacionados

Relacionado estrechamente con el BABOK encontramos el SWEBOK (Software Engineering Book of Knowledge), sobre todo en el capítulo 2 que tiene que ver con Ingeniería de Requisitos. Este estándar es soportado por la IEEE.

Analista del Negocio versus Analista Funcional, Parte 2

Veamos ahora el asunto con el Analista Funcional. Este es también conocido como Analista del Sistema, Analista del Software o también Ingeniero de Requisitos.

En términos simples, este personaje es quien identifica (captura), documenta, organiza y administra los requisitos del sistema de software. Más exactamente, es quien desarrolla la Visión del Sistema, atiende las solicitudes de todos los involucrados, define el contexto del sistema, encuentra actores y casos de uso del sistema y estructura el modelo de casos de uso; también es quien desarrolla las especificaciones suplementarias (requisitos no funcionales y otros) y administra las dependencias entre los requisitos.

Este Analista Funcional es quien tiene la tarea de definir el producto que luego usarán los usuarios para resolver sus necesidades de negocio, como se la expresaron al Analista del Negocio. ¿Ah, ya vieron la relación?

Siendo consecuentes con la definición que hice de Analista del Negocio, es recomendable que un analista funcional sea, entre todo lo demás, un experto en la identificación y entendimiento de problemas y oportunidades. Esto incluye la habilidad de articular las necesidades que están asociadas con el problema clave a ser resuelto u oportunidad a ser abordada. A esto yo lo llamo, conocer el problema detrás del problema.

Por supuesto, un buen analista del sistema es un buen facilitador y también debe tener excelentes habilidades de comunicación (todo tipo de comunicación). El conocimiento del dominio del negocio y de la tecnología son habilidades adicionales útiles para estas personalidades. Sin embargo, estas últimas son de menos importancia si el individuo tiene la habilidad de absorber y entender información nueva rápidamente. Y ya que es un papel central en los equipos de proyectos, un analista funcional debe ser capaz de colaborar efectivamente con otros miembros del equipo.

¿Y todo esto qué nos dice? Que siempre es posible que un Analista Funcional o Ingeniero de Requisitos juegue a ser Analista del Negocio; y al contrario, un Analista del Negocio puede ser un analista funcional, aunque esto último no siempre es posible, ya que un Analista del Negocio puede ser “interpretado” por alguien que no tenga preparación académica ni experiencia en tecnología de software y relacionados. Al menos, eso me lo ha enseñado la experiencia. Con el tiempo, ambos roles se pueden intercambiar uno con otro, yo lo he hecho durante la última década sin problemas.

También ocurre que en proyectos de medianos a grandes y dependiendo del presupuesto del proyecto y de la organización, es posible tener los dos roles por separado; pero la mayoría de las veces estos dos roles son jugados por una sola persona. Si son dos personas distintas, deben trabajar en estrecha relación, apoyándose mutuamente y comunicándose todo el tiempo. Este es el factor de clave éxito: la comunicación. No en vano, la recomendación de que ambos figurantes tengan esta como una de sus destrezas esenciales.

----------------------------------------------------------------------------------------------

La primera parte de este artículo lo encuentran en este mismo blog en:

http://gazafatonarioit.blogspot.com/2012/04/analista-del-negocio-versus-analista.html

Analista del Negocio versus Analista Funcional, Parte 1

Hagamos esto en dos partes. En esta hablaré del Analista del Negocio. Empecemos con las definiciones del mismo BABOK.

Un Analista del Negocio  es cualquier persona que ejecute actividades de análisis del negocio, sin importar cual sea su cargo o rol en la organización. Los Analistas del Negocio incluyen no solo personas con ese cargo, sino también analistas de sistemas de negocios, analistas de sistemas, ingenieros de requisitos, analistas de procesos, gerentes de producto, propietarios de producto, analistas corporativos, arquitectos del negocio, consultores de administración o cualquier otra persona que ejecute las tareas descritas en la guía del BABOK, incluyendo aquellas que ejecutan disciplinas relacionadas como gerencia de proyectos, desarrollo de software, aseguramiento de la calidad y diseño de interacción.

¡A decir verdad, todo eso me parece un chiste! Veamos algo más práctico y basado en hechos reales.

Como lo conocemos en este lado del continente, hablo de América Latina principalmente, un analista del negocio es quien lidera y coordina todo el proceso de identificación, documentación, organización y administración de requisitos del negocio delimitando la organización que está siendo modelada. Esto es, un conocedor de los procesos del negocio, alguien capaz de ejecutar tareas como:

1.    Evaluar la organización objetivo, es decir, hacia dónde va la compañía;

2.    Establecer y ajustar objetivos;

3.    Mantener las reglas del negocio;

4.    Identificar las metas del negocio;

5.    Encontrar a los actores y casos de uso del negocio (las actividades del negocio y quien las realiza).

Es recomendable que un analista del negocio sea un buen facilitador y tenga excelentes habilidades de comunicación; además, tener conocimiento del dominio del negocio es esencial para actuar en este papel. UN analista del negocio debe estar preparado además para:

1.    Entender los requisitos de los usuarios, sus estrategias y sus metas;

2.    Realizar un análisis costo beneficio para cualquier cambio que se sugiera en la organización; y

3.    Discutir y apoyar a quienes mercadean y venden el producto final del proyecto.

Adicionalmente, un buen analista del negocio:

1.    Hace análisis arquitectónico del negocio;

2.    Construye pruebas de concepto arquitectónicas para el negocio;

3.    Hace análisis de los casos de uso del negocio;

4.    Prioriza los casos de uso del negocio;

5.    Analiza la operación del negocio; y

6.    Diseña la operación del negocio

Más adelante volveremos sobre este tema para ver quien puede actuar bien en este papel de Analista del Negocio.

Sobre el Papel del Analista Funcional y la Reunión de Presentación de Casos de Uso

Sobre el Analista Funcional

Uno de los errores más comunes que se comenten a la hora de hacer análisis funcional es pensar solo en el presente, en resolver la situación actual, cuando se debería pensar en el futuro, hacía donde quiere ir la organización, cuál es su misión, cuál es su visión y con qué cuenta para llegar hasta allá.

De nada sirve resolver el problema presente si al día siguiente se nos van a presentar otros. En este caso, la anticipación es la clave y más que ello, la visión que tengan los analistas funcionales de hacia donde se va a mover el mercado, el conocimiento de las tendencias, los movimientos de la competencia, las expectativas de los clientes, las corrientes tecnológicas, los rumbos de la economía, entre otros aspectos significativos.

Es allí donde precisamente los indicadores de gestión juegan un papel de apoyo a la hora de tomar las mejores decisiones, aquellas que permitan ir en la dirección correcta. Esa es la trascendencia del Analista Funcional, muchas veces poco vislumbrada en nuestro ámbito, pero real y necesaria. No se trata solo de un asunto de modelamiento de requisitos, se trata de modelar toda una organización y de su perspectiva de supervivencia en el tiempo y en el medio ambiente que la rodea.

Sobre la Reunión de Presentación de Requisitos

Es altamente recomendable que los participantes de la reunión también sirvan como “revisores pares”. Es decir, todos debemos contribuir a que el producto resulte de la mejor calidad posible y esta es una muy buena oportunidad para hacer una gran intervención.

Cada participante bien podría “correr” una lista de chequeo similar, para que la revisión sea lo menos subjetiva posible y para que haya cierta homogeneidad. Esta revisión debería buscar errores de forma, apuntar en principio a aquellos atributos que mencioné en la presentación inicial de este debate, como la claridad, la atomicidad y la precisión de los requisitos y casos de uso, entre otros atributos. 

Pero también, si es posible, buscar errores de contenido, del “negocio”, aspectos que bien pudieron omitirse por parte del Analista Funcional, quizás por considerarlos sobrentendidos o quizás porque nadie se percató de ello con anterioridad. Por ejemplo, revisar si faltaron aspectos contables o regulaciones legales por especificar, o si no se consideraron a ciertos interesados (léase “stakeholders”) externos, como agencias auditoras o supervisoras del gobierno. 

Para todo esto sirve esta primera presentación al resto del equipo y por ello es que la lectura por parte de todos es ineludible.

Sobre “interpretación” vs. “realización” de casos de uso

Algo que ocurre muchas veces es que todos los miembros en un equipo de proyecto de software esperan que en la documentación de requisitos, en general, y de casos de uso, en particular, esté incluido no solo la especificación de requisitos (funcionales y no funcionales), la definición del problema y sus detalles, sino también la solución de ese problema en términos de software.

Es decir, esperamos que la especificación de un caso de uso, por ejemplo, contenga los elementos básicos de un caso de uso, como el Actor, la secuencia básica y las alternativas (si existen), las pre y pos-condiciones y los requisitos especiales, entre otras. Pero también esperamos que tenga la así llamada “realización del caso de uso”. 

Esta no es más que el análisis y diseño del caso de uso, o sea, la manera como se va a implementar ese caso de uso en términos de diseño. Normalmente para esto usamos diagramas de UML, los que sean necesarios, empezando por diagramas de interacción (ya sean de Secuencia o de Comunicación), y también diagramas de Estado o de Actividad, entre otros.

El asunto es que la especificación del caso de uso debe ser lo suficientemente clara (no ambigua) y completa para que cualquier “interpretación” que se haga de la misma arroje los mismos resultados. Y esto debe ser así no solo para el equipo de diseño y de programación, sino para el equipo de pruebas. Es decir, la documentación debe ser tal que el diseñador y el verificador se hagan el mismo modelo o esquema mental del diseño y de las pruebas (casos de prueba) respectivamente.

Algunas técnicas para mejorar la especificación de requisitos (y de casos de uso) incluyen la revisión par, que debe comprender revisión de forma y de contenido. Esta revisión debe validar que cada requisito (y cada caso de uso) cumpla con algunas características bien conocidas:

• Claro
• Atómico
• No ambiguo
• Verificable
• Necesario
• Priorizado

Entre tanto, la especificación de requisitos (incluyendo todos los casos de uso) debe ser:

• Correcta
• Independiente de diseño
• Completa
• Consistente
• Rastreable
• Modificable / Extensible

Para finalizar, los Analistas Funcionales deben presentar esta especificación al equipo de diseño, construcción y pruebas. Este es un paso muy importante que muchas veces se omite o se cumple con simplemente enviar un mensaje electrónico que incluye los documentos relacionados. El objetivo de la presentación no debe ser únicamente exhibir la especificación, sino lograr que todos los involucrados en el equipo salgan con las mismas ideas, con el mismo mapa mental del que hablaba antes.

*+*+*+ /*+*+*+ /*+*+*+ /*+*+*+ /*+*+*+ /*+*+*+ /*+*+*+ /*+*+*+ /
PD. Los invito a leer mi artículo sobre Realización de Casos de Uso. Lo encuentran en el enlace adjunto: http://gazafatonarioit.blogspot.com/2007/10/lecturas-fundamentales-10-lectura_3046.html