Entendiendo el BABOK® en Español – Capítulo 2.- Planeación y Monitoreo del Análisis de Negocio

Vamos a iniciar con la primera de las seis áreas de conocimiento del BABOK®. Esta es la de Planeación y Monitoreo del Análisis de Negocio, el propósito de esta área de conocimiento es identificar a todos los actores clave del proyecto, definir roles y responsabilidades, estimar el esfuerzo requerido para realizar cada una de las tareas de análisis de negocio, así como elaborar los diferentes planes del análisis de negocio como son los planes de comunicación y los planes de administración de los requerimientos entre otras cosas.

Este capítulo está comprendido por las siguientes secciones:

El propósito general de esta área de conocimiento se explica al inicio del capítulo, asimismo, se explica también el contexto general de entradas, tareas y salidas que se generan a través de los procesos de cada una de las tareas de esta área de conocimiento.

Como se puede apreciar en el diagrama anterior, esta área de conocimiento esta constituida por cinco componentes de entrada, seis tareas o actividades principales y siete resultados o entregables que generan esas actividades.
La forma en que se generan estos entregables, los elementos que hay que considerar para ello, los stakeholders que idealmente debieran estar involucrados en estas actividades así como las técnicas recomendadas para realizarlas, se verán en las siguientes secciones cuando veamos en detalle cada una de las tareas aquí descritas.

Como siempre, los invito a que dejen sus comentarios y sugerencias.

Entendiendo el BABOK® en Español – Capítulo 1.- Introducción – 1.6 Técnicas; 1.7 Competencias Fundamentales y 1.8 Otras Fuentes de Información del Análisis de Negocio

Estimados amigos esta vez les voy a compartir las secciones 1.6 Técnicas; 1.7 Competencias Básicas y 1.8 Otras Fuentes de Información del Análisis de Negocio y con esto daremos por terminado el Capítulo 1: Introducción.
A partir de la siguiente semana, empezaré a publicar las secciones correspondientes a cada una de las áreas de conocimiento del BABOK las cuales son la parte medular del Análisis de Negocio con lo que entraremos de lleno al tema.

Es importante considerar que las Técnicas y las Competencias Fundamentales son, además del conocimiento del framework de Análisis de Negocio, el conjunto de habilidades que idealmente un analista de negocio debe de poseer.

En ese sentido, estos son factores, representan la caja de herramientas (toolkit) que acompaña al analista de negocio todo el tiempo cuando realiza tareas de análisis de negocio y de las cuales debe de saber cuál de ellas es la mejor para realizar más eficientemente alguna tarea en particular.

Pues bien amigos, con esto terminamos el Capitulo 1: Introducción, como siempre quedo en espera de sus comentarios.

LOS MANDAMIENTOS DEL ANALISTA DE NEGOCIO

Escrito por Tim Ward
Artículo original.

I. Elimina la ambigüedad. Si puedes llegar a más de un entendimiento o conclusión, lo más probable es que así lo interprete también el desarrollador e ingeniero de pruebas.
II. Cuando utilices terminología, no asumas que todos tienen el mismo entendimiento. Obtén confirmación inmediata para evitar malos entendidos. Un glosario de términos y alias relacionados es muy útil.
III. Promueve la comunicación clara y directa y el uso de un lenguaje común cuando describes situaciones de negocio, reglas, normas, procesos, datos, etc. Si es necesario documentar algo en argot de negocios o TI entonces parafrasea su verdadero significado en lenguaje llano.
IV. Cuando utilices términos de negocios o TI para describir algo, siempre confirma su definición (ejemplo: cuando decimos “transferir” significa…)
V. No pidas permiso, pide absolución
VI. Entiende las diferencias culturales dentro o entre las entidades organizacionales de negocio y TI. Ayudará a seguir otros mandamientos.
VII. Los requisitos describen lo que algo es, así como lo que no es.
VIII. Cuando elicites requisitos, realiza preguntas de aclaración para confirmar que los requisitos están siendo claramente registrados
IX. Cuando elicites requisitos, es importante identificar la audiencia afectada (ejemplo: líneas de negocio, productos, tipos de planes, etc.)
X. Cuando documentes requisitos, decisiones o resolución de asuntos, es igualmente importante documentar el “porqué” tanto como el “quién”, “qué”, “cuándo”, “dónde”, y “cómo”. Si no lo haces, lo más probable es que nadie recordará después porque se fueron por cierto camino.
XI. Cuando definas requisitos, recuerda que tienen que ser comprobables. Si no lo puedes probar adecuadamente, entonces el requisito no está definido de forma adecuada.
XII. No hay supuestos, solo un entendimiento actual de los hechos. El uso de los supuestos solo promueve el crecimiento de características anatómicas indeseables.
XIII. Cuando escribas (o hables), ponte en los zapatos de los lectores (o escuchas). ¿Pueden realmente entender lo que estoy tratando de comunicar basado únicamente en las palabras que escrito o hablado? ¿Existe alguna expectativa de que la audiencia tenga algún conocimiento implícito en comprender el tema?
XIV. Trata a tus desarrolladores y equipo de trabajo de soporte técnico como deseas ser tratado: como un aliado confiable y buen amigo
XV. Entiende que las personas que requieren de tus servicios como analista de negocio no siempre saben lo que quieren y/o están en posibilidad de articular efectivamente sus necesidades. Es por esto que Dios invento a los analistas de negocio.
XVI. Como experto confiable en el tema, las personas usualmente creerán lo que dices como un hecho, especialmente si eres bueno comunicando claramente. Estando en esa posición de confianza, existe un riesgo inherente que algunas veces te equivoques en tu entendimiento (y no estés consiente). Sin embargo, eres lo suficientemente persuasivo para convencer a todos de esa verdad. Necesitas confiar en otros para estar en posibilidad de detectar la transmisión de falsas verdades antes de que sea demasiado tarde.

No olvides dejar tus comentarios.

Hábitos de un efectivo Analista de Negocio

De acuerdo con Karl Wiegers, Principal Consultant en Process Impact,( www.ProcessImpact.com), los Administradores de Software muchas veces asumen que un talentoso programador es también competente entrevistando clientes y escribiendo requisitos sin ninguna formación previa, recursos o entrenamiento, lo cual resulta un supuesto mal fundamentado y que requiere de tener su propio conjunto de habilidades.
Sostiene que el rol del Analista de Negocio es crítico para un proyecto de software y muchas organizaciones esperan que los desarrolladores o los directores de proyectos (PM’s) gestionen esta función vital. El analista de negocio proporciona capacidades especializadas que pueden hacer la diferencia entre un proyecto exitoso y aquel que avanza con dificultad y mucho esfuerzo.

En este artículo de dos partes, Karl describe varias características y prácticas para analistas de negocio exitosos.

CERRAR LA BRECHA DE LA COMUNICACIÓN

El analista de negocio es un interlocutor que cierra la brecha entre las vagas nociones del cliente y unas especificaciones claras. El analista de negocio debe de entender las necesidades reales del usuario y entonces definir el conjunto de requisitos funcionales y objetivos de calidad que permita a los desarrolladores construir y a los ingenieros de pruebas verificar el sistema. Para ser un efectivo analista de negocio, se debe de ser competente en todas las formas de comunicación, incluyendo el saber escuchar, hablar y escribir. En la medida que el analista de negocio interactúa con los patrocinadores ejecutivos del proyecto, mercadotecnia, y usuarios, entiende los objetivos para el sistema propuesto y las preocupaciones de los usuarios con relación al negocio y la aplicación. Utilizar un vocabulario adecuado al dominio de la aplicación en lugar de forzar a los clientes a entender la jerga de la computación es elemental.

Tómese el tiempo para aprender acerca de sus clientes y usuarios y entienda como prefieren ellos establecer esa comunicación. Vigile los supuestos que se esconden debajo de la expresión de necesidades de los usuarios y sus propios pensamientos. Evite imponer filtros personales de lo que escucha de los usuarios. Mantenga uno de los axiomas de Karl para desarrollo de software: El cliente no siempre tiene la razón, pero siempre tiene un punto importante. Ud. Tiene que entender y respetar estos puntos de tal forma que puedan ser apropiadamente considerados en el producto.

Por otro lado también recomienda entender las expectativas implícitas del usuario con relación a las características del sistema, tales como rendimiento, usabilidad, eficiencia, y confiabilidad. Como analista de negocio, debe de entender la intención detrás de cada una de esas expectativas de tal forma que se pueda traducir de algo muy vago y subjetivo a algo concreto y específico. Una técnica es preguntar al usuario que constituye un rendimiento, usabilidad o confiabilidad inaceptables.

Otro aspecto importante es la escritura de los requisitos que expresen claramente un entendimiento compartido la cual es responsabilidad del analista de negocio. El escribir documentos de especificación de requisitos que los usuarios puedan entender y verificar, mientras que comunique de una manera precisa y sin ambigüedades requisitos funcionales y no funcionales a los desarrolladores es una tarea difícil y complicada.

Los usuarios con frecuencia proponen sólo fragmentos de funcionalidad y comunican solo parte de lo que tienen en mente. Karl propone que es preferible enfocarse en las tareas que el usuario necesita lograr con el sistema: casos de uso o historias de usuario (desarrollo ágil). Este enfoque ayuda a entender porque la funcionalidad o características descritas por el cliente son importantes. El entendimiento de sus objetivos, lleva a los requisitos funcionales necesarios, los cuales llevan al diseño detallado de la interface.

Debido a que los casos de uso describen la vista del usuario respecto del sistema, los usuarios deben de entenderlos. Sin embargo los casos de uso solos raramente comunican suficiente información a los desarrolladores. Una tarea importante del analista de negocio es inferir de cada caso de uso los requisitos funcionales específicos que, cuando se implementen, permitan al usuario realizar las tareas descritas en el caso de uso. Esto significa que debe de estar en posibilidad de comunicar efectivamente en ambas direcciones: con los usuarios (la vista de tareas) y con los desarrolladores (la vista técnica). Para estar seguro de lo que ha Ud. entendido, haga que los usuarios, desarrolladores e ingenieros de pruebas revisen sus documentos.

EJECUTE DE FORMA SEGURA, NO CORRA RIESGOS

Inicie su investigación de los requisitos del nuevo sistema a través de la última visión de lo que el producto o aplicación será o tendrá que hacer. Hable con el patrocinador, gerente de mercadotecnia o de producto anticipadamente para definir los objetivos de negocio del proyecto. Esta información le ayudará a contestar esta pregunta crítica cada vez que alguien sugiere una nueva característica del producto: “Esta esta característica incluida en el alcance?”.

Los equipos rara vez implementan la última solución en un solo paso. En su lugar, definen el alcance de una primera versión o iteración como un subconjunto de un producto final. Describa una ruta de evolución a partir de la primera versión hasta alcanzar la última visión a través de una serie de versiones o iteraciones, También documente cualquier limitante conocida o funcionalidad que no intente construir pero que algún usuario espere encontrar en la aplicación. La gestión de las expectativas es una estrategia importante.

REALICE PREGUNTAS RELEVANTES

Cuando trabaje como analista de negocio, necesita facilitar activamente la discusión con los usuarios para obtener información que de otra forma podría no ser especificada. Realice preguntas para identificar posibles formas alternativas que el usuario podría querer para realizar alguna tarea y descubrir tareas relacionadas que los usuarios no mencionaron inicialmente.

Los usuarios normalmente se enfocan en el comportamiento normal esperado del sistema, Sin embargo, los desarrolladores, escriben mucho código para el manejo de excepciones, de tal forma que tiene que buscar posibles condiciones de error que puedan surgir y decidir como debe de responder el sistema. Si no describe Ud. las excepciones durante la elicitación de los requisitos, pasa una de dos cosas: o los desarrolladores harán su mejor elección para manejarlos o el sistema simplemente fallará cuando el usuario se encuentre con esa condición de error. Seguro que un error del sistema no es parte del plan.

Un analista de negocio creativo debe sugerir ideas y alternativas durante la elicitación. Cuando los usuarios no pueden expresar lo que necesitan, obsérvelos trabajando y sugiera alternativas para automatizar parte del trabajo. Los analistas de negocio frecuentemente piensan “fuera de la caja” que limita la creatividad de las personas que están demasiado cerca del problema que se desea resolver. Sea cuidadoso para evitar exceder las expectativas del usuario adicionando funcionalidad extra que solo se vea agradable o de alguna forma sólo es deseable.

Les agradezco su atención y espero que este artículo haya sido de su interés. Nuevamente, les invito a colaborar con este blog a través de sus comentarios y buscar temas de tu interés que ayuden a contribuir al crecimiento de la práctica.

Tomado del artículo original en http://www.batimes.com/blog/karl-wiegers.html. Espere el segundo artículo que comentará sobre otros hábitos que ayudan al analista de negocio hábil a contribuir a construir estupendos sistemas.

Entendiendo el BABOK® en Español – Capítulo 1.- Introducción – 1.5 Tareas

En esta ocasión les voy a compartir la sección 1.5 Tareas, la cual describe la forma en que el BABOK estructura cada una de las tareas contenidas en cada una de las áreas de conocimiento.

Lo anterior es importante tomarlo en cuenta al momento de leer el BABOK para lograr una mejor comprensión del mismo. Esta estructura se repite a lo largo del libro para cada una de las áreas de conocimiento.

Como siempre los invito a enviarme sus comentarios y observaciones.

Entendiendo el BABOK® en Español – Capítulo 1.- Introducción – 1.4 Áreas de Conocimiento

Ahora vamos a ver la sección 1.4 que explica de modo general cada una de las áreas de conocimiento que componen la práctica de Análisis de Negocio en el BABOK®:

Lo anterior es sólo una breve descripción de cada una de las áreas de conocimiento y su interrelación con el resto de áreas de conocimiento. Algo importante que hay que considerar, es que el BABOK® no prescribe un orden para la ejecución de cada una de las áreas de conocimiento y manifiesta en todo momento que las actividades en cada una de ellas se pueden realizar en distintos momentos a lo largo del ciclo de vida de la solución.

Espero que esta nueva sección del BABOK® le sea de utilidad y como siempre los invito a enviarme sus comentarios y observaciones.

Entendiendo el BABOK® en Español – Capítulo 1.- Introducción – 1.3.3 Requerimientos

En esta ocasión vamos a ver la sección 1.3.3 Requerimientos dentro de 1.3 Conceptos Clave, la cual explica el concepto y clasificación manejado por el BABOK para este término.

Como podrán ver, este concepto de requerimientos está piramidado partiendo de un enfoque de negocio hasta llegar a un enfoque de solución en donde cada uno de ellos tiene un objetivo bien definido. Lo anterior se puede representar mejor con el siguiente modelo:

Bien amigos, con esto damos por terminada esta sección, recuerden que todos sus comentarios son bienvenidos.

Entendiendo el BABOK® en Español – Capítulo 1.- Introducción – Conceptos Clave

Continuando con el estudio de las secciones del BABOK, esta vez veremos la sección de Conceptos Clave, estos conceptos se manejan a lo largo del BABOK y es importante homologar su significado en estos términos con el fin de tener el mismo entendimiento respecto a ellos.
En esta ocasión veremos el concepto de Dominios y el de Soluciones y la siguiente semana explicaremos lo correspondiente a los Requerimientos y los diferentes tipos de Requerimientos (o Requisitos como se conocen en algunos otros lugares de habla hispana).

La definición de Dominio en el BABOK dice lo siguiente:

En este sentido, un Dominio es el área donde vamos a trabajar y realizar el análisis de negocio. Puede ser un área, departamento o toda la organización, define las fronteras de esta área y establece las interrelaciones con stakeholders que están dentro y fuera de esas fronteras.

Con relación al concepto de Soluciones, el BABOK establece:

Los cambios se derivan generalmente de una necesidad de negocio o problema de negocio, estos para que causen efecto en la organización necesitan ser aplicados al estado actual de la organización lo cual generará un nuevo estado de la organización que responde a las necesidades del negocio.

Con relación al alcance del dominio éste normalmente comprende al alcance de la solución y éste a su vez está compuesto de los diferentes componentes de solución que afectarán al estado actual de la organización con el fin de habilitarlo con la nueva necesidad de negocio.

Si se dan cuenta, una de las diferencias importantes del enfoque del análisis de negocio, es su alcance respecto de las soluciones, ya que su visión abarca cualquier capacidad que requiera una organización para satisfacer una necesidad de negocio, las cuales pueden ser desde aplicaciones de software, servicios web, procesos de negocios, reglas de negocios hasta cambios en la estructura organizacional o procesos de outsourcing.

Pues bien amigos con esto damos por terminado el comentario de esta semana y como siempre, quedo en espera de sus comentarios.

Nuevos retos para el Analista de Negocio

De acuerdo a Gartner, cuatro fuerzas están dando forma al futuro de IT teniendo a la “Consumerization” –tecnología orientada al consumidor- de fondo.

1.- La Nube. La cual ofrece nuevas opciones y estilos de entrega industrializados en una cadena de valor en donde TI es sólo una parte de la entrega
2.- Computación Social. Permite la colaboración entre los usuarios y esta generando cambios los patrones de conducta de los usuarios en las comunidades personales, laborales y profesionales en las cuales se desempeñan
3.- Mobilidad. Ofrece nuevos accesos hacia a aplicaciones y datos y al mismo tiempo proporciona a los usuarios una amplia variedad de dispositivos a elegir
4.- “Big Data”. Inició para alterar por siempre la relación de la tecnología con el consumo de información. En la medida que los datos llegan desde múltiples fuentes y en formas tanto estructuradas como no estructuradas estos deben de ser analizados utilizando nuevas metodologías

Los resultados son ya por todos conocidos:

El reto para los analistas de negocio es primero comprender en que consiste cada una de estas fuerzas, cómo afectará a nuestra organización, cuales nuevas soluciones en torno a estas tendencias puedo ofrecer a mis stakeholders, que implicaciones hacia adentro de la organización puede ocasionar (procesos, sistemas, estructura organizacional, etc.)
Ud. estimado lector ¿que opina?, ¿ha considerado estas nuevas tendencias?, ¿cree que tengan algún impacto en su organización?, ¿afectará a la interacción del negocio con su entorno?
Como siempre lo invito a que envíe sus comentarios.

Entendiendo el BABOK® en Español – Capítulo 1.- Introducción – ¿Qué es el Análisis de Negocio?

Estimados amigos, continuando con las secciones del BABOK ya traducidas, esta semana les comparto la sección ¿Qué es el Análisis de Negocios? En este capítulo se define el Análisis de Negocios: Que es, Qué implica, Para que se utiliza, Cuáles son las funciones del Analista de Negocio y Cuál es la definición del Analista de Negocio.

Textualmente podemos leer lo siguiente:

Interpretando esta definición de Análisis de Negocio hay que comprender que el análisis de negocio requiere entender ampliamente a la organización. Esto es, requiere entender cual es la razón de ser del negocio (metas y objetivos), cuales son las diferentes áreas de que está compuesta la organización, los principales procesos que se ejecutan, las reglas de negocio que rigen esos procesos, los sistemas (aplicativos, de seguridad, etc.) que apoyan esos procesos, con el fin de tener la visión más amplia posible que permita recomendar la mejor solución viable a una iniciativa de negocio.

Por años, esta función ha sido realizada por diferentes personas dentro de la organización los cuales tenían diferentes roles, algunas veces eran analistas de sistemas que demostraban habilidades para entender del negocio y a veces eran analistas de producto o personal operativo que tenia habilidades para entender de procesos y sistemas. Al final, siempre ha habido algún rol que ha servido de puente entre el negocio y las áreas de ejecución (sistemas, procesos y procedimientos, operaciones, producción). La diferencia ahora con la aparición del Análisis de Negocio como una profesión, es que el rol está definido, y lo más importante es que ahora con esta práctica también está definida una forma estándar de trabajo apoyada con una serie de técnicas y tareas que permiten realizar esta función de una manera más eficiente y que en el futuro, en la medida que esta práctica se extienda, los diferentes analistas de negocio de diferentes organizaciones y de diferentes países podrán tener un marco de referencia estándar que norme su función.

Como siempre, quedo en espera de su participación y sus importantes comentarios. Saludos.