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.


Comentarios

Hábitos de un efectivo Analista de Negocio — 2 comentarios

  1. excelente articulo. es un hecho que a los desarrolladores nos ensenan a programar, pero no nos capacitan para entender a los usuarios.

  2. Hola Pedro. En efecto una de las cosas que es necesario cambiar, es el enfoque sumamente técnico que tenemos la gente de tecnología. Necesariamente se requiere tener un perfil que entienda más allá del entorno tecnológico y que pueda hablar el “lenguaje” del negocio y poder interpretarlo adecuadamente y orientarlo a las áreas que ejecutan la solución. Una de las principales cosas que aporta el Análisis de Negocio en este sentido, es precisamente en tener la formación y visión necesaria para entender primeramente al negocio y después plantear la solución. Gracias por tu comentario y quedo a tus órdenes.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *