¡Acceda al Manual de Certificación CBAP/CCBA en Español!

SimagesCA9YJ07Mi desea conocer el proceso necesario para presentar su solicitud (Application) para realizar el examen de certificación CBAP/CCBA en idioma Español, ahora ya está disponible este documento en este Blog.

¿Cuál es el propósito de este manual?

El propósito de este manual es proporcionar a los solicitantes de la Certificación Profesional de Análisis de Negocio (Certified Business Analysis Professional – CBAP®) o la Certificación de Competencias en Análisis de Negocio (Certification of Competency in Business Analysis – CCBA®) la información necesaria para entender la organización del Instituto Internacional de Análisis de Negocio (IIBA® – Internacional Institute of Business Analysis) y el proceso de Certificación.

¿Qué es la Certificación Profesional?

Existen muchas definiciones de certificación profesional, pero de manera general implica que una organización de certificación  apruebe el conocimiento, experiencia y habilidades de los individuos certificados.

La Certificación implica reconocimiento formal de progreso, después de probar competencia a través de una demostración real de un conjunto requerido de habilidades y/o conocimientos.

Una certificación profesional de Análisis de Negocio tomará una importancia cada vez mayor dentro de los proyectos de Negocio y Tecnología en función de cómo continúe expandiéndose el alcance y la profundidad de los conocimientos profesionales requeridos en este ámbito.

El proceso de certificación incluye demostrar la experiencia requerida, conocimientos y competencias del profesional de análisis de negocio de acuerdo a los requerimientos designados por el IIBA.

¿Quién es el Analista de Negocio y cuál es su función?

El practicante de análisis de negocio es el responsable de identificar las necesidades de negocio de sus clientes y stakeholders para ayudarles a determinar soluciones a problemas de negocio.

Es responsable del desarrollo y gestión de requerimientos. Específicamente, elicita, analiza, valida y documenta requerimientos de negocio, organizacionales y operacionales. Las soluciones no son predeterminadas por él, son impulsadas únicamente por los requerimientos de negocio. Las soluciones frecuentemente incluyen un componente de desarrollo de sistemas pero pueden también consistir en mejoras a los procesos y cambios organizacionales.

El Analista de Negocio es un facilitador clave dentro de la organización, actúa como puente entre el cliente, los stakeholders y el equipo de solución. El análisis de negocio es diferente del análisis financiero, gestión de proyectos, aseguramiento de la calidad, desarrollo organización, ejecución de pruebas, capacitación, y desarrollo de documentación. Sin embargo, dependiendo de la organización, un Analista de Negocio puede ejecutar alguna o todas estas funciones relacionadas.

¡Descargue el documento!

Si Ud, está interesado en obtener esta certificación y conocer el proceso para certificarse, diríjase al menú “Documentos de Business Analysis en Español”, seleccione “Cómo acceder a Documentos de Business Analysis en Español”, llene los datos que se solicitan y regístrese. En pocos minutos Ud. Recibirá un correo electrónico con una contraseña de acceso.

Una vez que reciba la contraseña indicada, acceda nuevamente a “Documentos de Business Analysis en Español” y ahora seleccione “CBAP/CCBA Handbook en Español”, teclee su contraseña y descargue el documento que le interese (CBAP o CCBA).

Si ud. Estimado colega requiere mayor información, participe en este blog con sus dudas, comentarios o requerimientos de información y con gusto las atenderé.

Principios de Análisis de Negocio que ayudan a mejorar la calidad de los requerimientos (3)

3.- Piensa la solución en función del negocio (no de la tecnología), reflexiona en cuál es la mejor forma de resolver el problema desde un punto de vista funcional, sugiere varias alternativas de solución a tus clientes o usuarios con sus pros y contras y decide en conjunto con ellos cuál es la solución que mejor satisface la necesidad de negocio.

Una de las situaciones más comunes que enfrentan aquellos analistas que surgen del ambiente de TI es que generalmente están más orientados a darle a la solución de negocio un enfoque tecnológico. Hay una clara tendencia en defender el aspecto tecnológico y “olvidar” la razón de negocio que hay detrás de alguna otra solución que no sea la que hemos concebido sobre una base “tecnológica”. De aquí podemos nombrar casos en que la oportunidad o problema de negocio se queda paralizada mientras se resuelve el aspecto tecnológico que va desde no aceptar una solución porque no está de acuerdo a la arquitectura tecnológica adoptada por la organización, hasta aquellas que no son fáciles de implementar desde la perspectiva de lo que tenemos ya desarrollado e implantado.

De aquí se derivan diversas adaptaciones para poder dar una solución que generalmente no satisface la necesidad del negocio. La pregunta es ¿Por qué tenemos que supeditar las decisiones de negocio a las de tecnología? Si lo que manda es el negocio, y el negocio lleva un ritmo que debe de resolver día a día los retos de oportunidades y problemas de negocio, porque no buscar soluciones en términos del negocio?

Lo anterior tampoco es fácil de resolver, ya que por otro lado, para hacer que el negocio sea sustentable en términos de la tecnología, ésta debe de ser pensada y planeada en el largo plazo, de tal forma que soporte el crecimiento del negocio. Si dejamos que las cambiantes necesidades del negocio obliguen a tener diversas soluciones tecnológicas implementadas, también se puede poner en riesgo la sustentabilidad del negocio al largo plazo.

Me parece que el enfoque siempre debe de ser orientado a las necesidades del negocio, y lo que se recomienda una buena práctica, es plantear varias alternativas de solución soportadas por diferentes opciones tecnológicas, poniendo énfasis en las ventajas y desventajas de cada una y un apropiado análisis de los riesgos de adoptar cada una de ellas de tal forma que se tengan suficientes elementos para tomar una decisión en conjunto con los usuarios, stakeholders y ejecutivos de la organización.

La ventaja es que se tendría mayor conciencia de los impactos al adoptar alguna de las alternativas y se podría establecer una estrategia de respuesta de cómo la organización hará frente al impacto en caso de que este se presente.

Conclusión:
Una solución puede estar correctamente implementada desde el punto de vista tecnológico, sin embargo es necesario asegurarnos que satisface funcionalmente la necesidad de negocio.

En la medida que encontremos un adecuado balance entre la funcionalidad del negocio y de la tecnología tendremos soluciones que aporten mayor valor al negocio. De ahí la importancia del conocimiento del Analista de Negocio en ambas funciones: negocio y tecnología.

Por último, es muy importante tomar en cuenta que en muchas ocasiones no encontraremos ese balance, entonces habrá que documentar correctamente las ventajas y desventajas con sus impactos (riesgos) para que todo mundo esté consciente de ellos y se puedan tomar las medidas necesarias en caso de que se requiera.

Como siempre les invito a enviarme sus comentarios y sugerencias para poder seguir haciendo de estos artículos algo que aporte valor a nuestra actividad como analistas de negocio.

Principios de Análisis de Negocio que ayudan a mejorar la calidad de los requerimientos (2)

2.- Confirma los supuestos, no tomes como mandatorio lo que el cliente o usuario solicita. No asumas que sabe lo que quiere, siempre pregunta ¿porque? las veces que sea necesario.

Cuantas veces nos hemos enfrentado a solicitudes de nuestros usuarios o stakeholders respecto a resolver un problema o necesidad de negocios, en la cual identificamos que:

• puede haber una mejor solución
• que lo que están solicitando parece excesivo y simplemente no se justifica
• que parece tener un alcance mas corto de lo que realmente se requiere.

El principal valor que aporta el Analista de Negocio al ciclo de vida de requerimientos es el de identificar la necesidad real de la organización frente a las diferentes iniciativas que propone el negocio y determinar la mejor solución.

El análisis de negocio no cuestiona en realidad si el que cliente, usuario o stakeholder sabe lo que quiere, él es el experto en su área de dominio por lo que es el más indicado para proponer una solución, sin embargo el analista de negocio en términos de lo que sugiere el BABOK debe desarrollar una visión lo más amplia posible del negocio con el fin de poder aportar y recomendar la mejor solución a la iniciativa de negocio que se plantea por parte del usuario.

Es por eso que, para entender con mayor precisión estas iniciativas es necesario enfocarse al problema que se desea resolver y no directamente a la propuesta que se hace por parte del usuario. Para esto, es importante preguntar ¿Por qué? Las veces que sea necesario con la finalidad de llegar a la causa real de la necesidad.

El riesgo es que si nosotros como analistas de negocio asumimos que el cliente, usuario o stakeholder esta planteando o solicitando la solución aparentemente correcta y ésta no lo es, entonces no aportamos nada de valor al proceso y perdemos la oportunidad de identificar si algo está mal planteado de origen y por lo tanto el proyecto nace con bases erróneas que provocan que al final el producto generado por el proyecto no entregue el valor esperado por el negocio.

Debido a eso, es muy importante que todos los supuestos en los que se basa una solicitud se confirmen en la medida de lo posible. Muchas veces la información que fluye a través de nuestros usuarios no es del todo precisa y una regla de oro que hay que tener siempre en cuenta es que todo supuesto que no es confirmado se convierte en un riesgo para el proyecto. Reflexionen sobre esto y encontraran que seguramente tienen varias experiencias que confirman este precepto.

Recuerden que nuestro objetivo no es encontrar culpables cuando las cosas salen mal, sino que el proyecto en su conjunto sea exitoso y entregue el valor que el negocio está esperando.

Conclusión:
El cliente o usuario puede estar en lo correcto pero no pongamos en riesgo el proyecto y asegurémonos de que así es. Aportemos valor al ciclo de vida de los requerimientos y hagamos nuestra tarea confirmando la información que hemos recibido para evitar potenciales problemas subsecuentes al proyecto.

Estimados amigos, como siempre espero contar con sus comentarios y encantado de conocer su opinión con el fin de enriquecer estos conceptos que aquí planteo. Quedo a sus órdenes

Principios de Análisis de Negocio que ayudan a mejorar la calidad de los requerimientos

1.- Entiende la necesidad, el problema a resolver. Averigua, cuestiona, trata de encontrar la razón que origina cada requerimiento.

Uno de los problemas más frecuentes en la recolección de los requerimientos es que los analistas encargados de su recolección y documentación se han convertido en “tomadores de pedidos”.

Si queremos ayudar a nuestros clientes/usuarios a encontrar la mejor solución a sus problemas de negocio, es necesario que el analista por un lado conozca más acerca del negocio, esto es ¿que hace la empresa, área o departamento en que estoy llevando a cabo el análisis?, ¿cuales son sus funciones principales, que productos/entregables genera?, ¿quienes se benefician de esos productos/entregables?, etc. Por otro lado, es necesario entender cual es el problema, necesidad u oportunidad que se pretende atender/resolver.
Con estos dos elementos bien identificados, el analista estará en posibilidad de ofrecerle a sus clientes/usuarios un punto de vista que pueda aportar valor al proceso de análisis y que conlleve a encontrar la mejor solución al problema en cuestión.

Generalmente los clientes/usuarios llevan ya una concepción propia de cómo resolver un problema y su primera reacción a ello es solicitar que se haga como ya lo han concebido. Aquí el cuestionamiento clave es, no enfocarse a como lo quiere resolver el cliente/usuario, sino enfocarse en el problema que se quiere resolver para que el analista esté en mejor posición de ayudar a resolverlo. Por supuesto que para entonces, el analista deberá haberse ganado un aceptable nivel de confianza y credibilidad para con sus clientes/usuarios de tal forma que esto se pueda dar. De aquí que el analista debe de trabajar mucho en entender el negocio en general y del área o departamento en particular para que sea acreedor a ganar la confianza de clientes/usuarios.

Entender el negocio significa mucho mas allá de los que imaginamos. Entender el negocio es además de lo que ya comentamos, conocer de sus procesos, políticas, procedimientos y sistemas. El objetivo es poder tener una visión global que vaya más allá del área de análisis que se está trabajando con el objetivo de ver a la organización como un todo y visualizar los impactos que la atención del problema/necesidad en cuestión pudiera ocasionar a lo largo de toda la organización.

Conclusión:
Un buen analista de negocio siempre debe de tener la mente abierta a entender las causas que originan un requerimiento y siempre debe de tener un conocimiento profundo del entorno de negocio en que está trabajando. En la medida que el analista aporte valor al proceso, será reconocido y digno de confianza.

El objetivo es transformar el rol del actual analista y convertirlo de:
1) De ser un tomador de pedidos a ser un consultor
2) De ser una persona pasiva a ser una persona proactiva
3) De ser un receptor de instrucciones a ser un generador de soluciones
4) Y por último, convertirlo de ser un analista empírico a ser un analista profesional con la adopción de un marco de trabajo, mejores prácticas y técnicas que le ayuden a realizar su trabajo más profesional y eficientemente.

Y uds. estimados amigos, que opinan? Como siempre les agradezco sus comentarios y quedo a sus órdenes.

10 formas de afinar sus habilidades de comunicación como analista de negocio

De acuerdo con Morgan Masters, Business Analyst y parte del staff de ModernAnalyst.com, las 10 formas principales de afinar sus habilidades de comunicación, divididos en tres categorías son:

Principios Generales de Comunicación

1.- Comunicar a la gente donde está.- El uso del correo o de la intranet para comunicar no garantiza que la gente leerá la información. Dependiendo de la personalidad de cada uno, requerirán que ésta sea comunicada por escrito o personalmente. No se puede confiar en utilizar solo un canal de comunicación. Al igual que las campañas de marketing que utilizan docenas o cientos de puntos al mismo tiempo, la comunicación en Business Analysis sigue el mismo principio. Comunicar el mismo claro mensaje a todos, en cualquier lugar, al mismo tiempo.

2.- Haga el mensaje fácil de comprender.- Simplifique. Comunique lo que necesita en las menos palabras posibles. Si su audiencia es diversa, comunique sin utilizar términos técnicos.

3.- Establezca objetivos concretos, no sólo visiones subjetivas.- Cuantifique sus expectativas. No utilice frases como “Esto necesita estar lo más pronto posible”, sino “La fecha límite para entregar esto es el 1 de junio”. No “Me pueden enviar sus comentarios cuanto antes?”, sino “Se que están ocupados pero si queremos cumplir con las fechas del proyecto, necesito que me contesten hoy mismo”.

4.- Adecúe el mensaje a la audiencia.- El BABOK establece que una fuerte señal de habilidades de redacción es “la habilidad de ajustar el estilo de escritura a las necesidades de la audiencia”. Utilice un lenguaje coloquial y enfóquese en lo que su audiencia necesita escuchar. A los desarrolladores de software no se les necesita vender la genialidad de un nuevo producto, pero al cliente que puede dar retroalimentación, si. Expréseles algo como “Necesitamos de su experiencia para darle forma a un nuevo producto que requerirá de al menos 10 horas de su tiempo cada mes”.

5.- Sea proactivo.- No deje que otros interpreten los detalles o el estatus por usted. Si es información controversial o importante, expóngala claramente por escrito y envíela fechada. No deje que los colegas, stakeholders o desarrolladores lo escuchen de alguien más. Si no está en los requerimientos, no debe de estar en la cabeza de nadie. Recuerde que hay mucha especulación alrededor de los requerimientos y la dura realidad es que muchos stakeholders nunca leen los requerimientos a detalle. Realice un esfuerzo para activamente llegar a ellos dónde están.

6.- Utilice los recursos a su disposición.- Si no encuentra la mejor manera de comunicar algo a su auditorio, apóyese en su departamento de marketing. Una llamada a un experto en comunicación puede ayudarle a adecuar su mensaje y ahorrarse decenas de horas explicando las cosas mas tarde.

Comunicaciones Escritas

La comunicación escrita puede ser engañosa. Como dice el BABOK “La comunicación escrita es capaz de registrar una gran cantidad de información, pero frecuentemente es un reto asegurar que el texto redactado se entiende correctamente”. Algunos tips específicos para la comunicación escrita son:

 7.- Realice una lectura completa con el fin de eliminar oraciones complejas y evitar lenguaje excesivamente técnico.- Las personas que son sumamente técnicas tienden a expresar sus ideas de forma más compleja de lo que tiene que ser. “Deseleccione la tecla apropiada indicando si desea cancelar sus actualizaciones o continúe y salve”, en lugar de “Dé Cancelar o Continuar”. Puede necesitar refrasear algunas ideas para que estas sean mas comprensibles a una mayor audiencia.

8.- Si se requiere, repase su vocabulario y habilidades gramaticales.- La mayoría de los analistas de negocio son también por defecto redactores de tiempo parcial, gracias a los requerimientos. El BABOK enfatiza, “La comunicación escrita efectiva requiere que el analista de negocio tenga un amplio vocabulario, fuerte comprensión de la gramática y estilo y un entendimiento de cuales modismos y términos serán fácilmente comprendidos por la audiencia”. Una buena guía básica es The Elements of Style por Strunk and White.

Comunicaciones Habladas

9.- Siempre utilice las comunicaciones habladas como un complemento de lo que ya este escrito.- Nunca confíe en sólo hablar. Esto es como las funcionalidades extra (gold-plating), los supuestos y los rumores empiezan. Asegúrese de lo que desea comunicar está escrito claramente y publicado para que su audiencia lo acceda fácilmente.

10.- Mantenga un tono positivo y amigable.- Si está cansado o frustrado, trate de no demostrarlo. Eso hará que la gente se incline menos a ayudarlo o escucharlo. El BABOK menciona que uno puede desarrollar y entregar “presentaciones poderosas posicionando su contenido y objetivos apropiadamente (por ejemplo: tono positivo en lugar de negativo)”. La negatividad frecuentemente hace a las personas estar a la defensiva y no genera ningún beneficio. Para cada audiencia, permanezca positivo, ya sea presentando un problema o una solución.

Practique la escucha activa

La escucha activa es simplemente repetir lo que entendió de su interlocutor y pronunciar lo que interpretó de ello. Esto da oportunidad a su interlocutor de aclarar y eliminar supuestos. Frecuentemente los analistas no están incluso consientes de que están haciendo suposiciones e incluyéndolas dentro de los requerimientos, por lo que esta práctica es especialmente útil durante la fase de identificación. Por ejemplo, un CSR (customer service representative) puede decir “No nos gusta la función del reporte actual. Toma demasiado tiempo y los clientes siempre se frustran con él.” Un analista que practica la escucha activa podría decir algo como “Entonces su mayor preocupación es hacer llegar la información a los clientes el mismo día ya sea en un reporte o no” Esto podría llevar al CSR afirmar el supuesto del analista o corregirlo.

Espero que esta información les sea de utilidad para el desempeño de sus funciones como analistas de negocio y como siempre los invito a dejar sus comentarios.

Tomado de: ModernAnalyst.com http://www.modernanalyst.com/Resources/Articles/tabid/115/articleType/ArticleView/articleId/1994/10-Ways-to-Hone-Your-Communication-Skills-as-a-Business-Analyst.aspx

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

Una de las actividades más importantes del área de conocimiento Planeación y Monitoreo del Análisis de Negocio, es la 2.1 Planear el Enfoque del Análisis de Negocio. En esta actividad se especifica cómo seleccionar el mejor enfoque para ejecutar el análisis de negocio y cuales son aquellos stakeholders que deben de estar involucrados en esta actividad.

En esta ocasión les comparto las secciones 2.1.1 Propósito; 2.1.2 Descripción y 2.1.3 Entradas a esta tarea.

Estas tres secciones describen cual es el objetivo de esta tarea y las principales entradas que se esperan en el proceso de esta actividad.

Les recuerdo que cada área de conocimiento se compone de 7 secciones: 1.- Propósito; 2.- Descripción; 3.- Entradas; 4.- Elementos; 5.- Técnicas; 6.- Stakeholders y 7.- Salidas, en las próximas entregas continuaremos viendo las secciones restantes.

Espero que esta información les sea de utilidad y como siempre, los invito a que dejen sus comentarios y sugerencias.

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.