El negociador de conflictos (también llamado Analista funcional)

Según la definición más estricta, el papel del analista funcional en una empresa de Tecnología es capturar, consolidar y comunicar la información del proyecto al resto de los equipos (Desarrollo, principalmente). Dependiendo de la organización y el desarrollo de software que se está realizando, el título analista funcional puede ser llamado por otros nombres también. Otra etiqueta muy utilizada es analista de negocio, aunque viene a resultar lo mismo.

Pero si sólo nos quedamos con esto, no entendemos realmente cuál debe ser su posición y la importancia que tiene para el proyecto.

Un Analista funcional es un vínculo fundamental entre los distintos departamentos de la empresa con intereses muy variados, no siempre coincidentes a pesar de formar parte de un mismo proyecto. Recogiendo los requerimientos de negocio (o muchas veces teniendo que redactarlos) tiene que transformarlos en algo coherente para el equipo de desarrollo pueda entender y seguir.

Uno de los componentes clave de éste es aclarar la intención de la PYME. El analista funcional pasará una gran cantidad de tiempo a haciendo preguntas como “¿Qué quieres decir con eso?” o “¿Cómo esto encaja con lo que hablábamos antes?” Preguntas como éstas exponen potencial, a menudo sutiles, diferencias de significado entre Negocio y el resto del equipo de desarrollo. Más importante aún, estas preguntas exponen supuestos relativos a la lógica y procesos que no pueden ser claramente establecidas por negocio o incluso otras áreas como Marketing.

El analista funcional es responsable de identificar y resolver los requisitos que muchas veces son contradictorios y/o irrealizables. Si una parte de Negocio afirma que el mar es de color azul y sin embargo, otra más comercial afirma que es de color turquesa, será responsabilidad del analista resolver esa cuestión. Esto se puede hacer poniendo en común las diferentes perspectivas o negociar un punto intermedio que sea realista para llevar a cabo la tarea en los plazos marcados.

Esto nos lleva a negociaciones, que convierten al analista en ocasiones a un diplomático de zonas de guerra en conflicto, pues los intereses contrapuestos pueden llevar al hundimiento del proyecto.

Al final, el documento de requerimientos representarán el contrato entre la empresa que quiere una solución y el equipo de desarrollo de software que quiere crear la solución. Parece que es lo mismo, pero no lo es. Muchas veces Desarrollo tiene una idea clara de cómo realizar el proyecto que no se corresponde en absoluto con la que tiene Negocio. Y ahí, el documento de requerimientos es el compromiso de ambas partes de llegar a un entendimiento.

El bagaje del analista funcional es, ante todo, una caja de herramientas de habilidades de comunicación y relación interpersonal. Aunque es importante que posea algunas habilidades técnicas, su mayor activo es su capacidad de comunicarse con los demás, trabajar las relaciones con los otros, hablar sus diversos lenguajes y conducir el proyecto al éxito final.

Fuentes y más información:

Developer.com / MagnetismSolutions / Wikipedia

El rol del Analista funcional en equipos ágiles

Tradicionalmente el Rol del Analista Funcional o Ingeniero de Requerimientos ha sido definido en el contexto de un proyecto utilizando el modelo cascada del ciclo de desarrollo de software (SDLC), donde el Analista recolecta todos los requerimientos y reglas de negocio en el comienzo, antes de empezar a desarrollar. Sin embargo, la demanda acelerada de soluciones ha modificado la dinámica del desarrollo de sistemas a un enfoque más ágil, donde los requerimientos y las reglas de negocio se definen al mismo tiempo que se desarrolla el software, en ciclos iterativos.

De aquí que surje la pregunta “¿Existe la necesidad del rol de Analista Funcional en un equipo de desarrollo de software ágil?

Si el lector es de los que piensan que el rol del Analista Funcional no es necesario en el enfoque ágil, le pregunto si ha evaluado fehacientemente cómo se ve expandido el rol del desarrollador al incorpor las actividades necesarias para relacionarse directamente con el cliente.
Creo que independientemente del Ciclo de desarrollo de software elegido, el rol del analista funcional es necesario. En el caso del enfoque ágil, puede ser riesgoso para el proyecto que las funciones del Analista Funcional sean absorbidas por miembros del equipo de desarrollo.

Para los propósitos del artículo, tomaremos a Scrum como método ágil de desarrollo de software.

El Rol del Analista Funcional como Facilitador

Diferenciaremos el rol del Dueño del Producto (Product Owner) en Scrum, que es el de asegurar que se satisfagan las necesidades del negocio, del rol del del Analista Funcional que es traducir la visión del Dueño del Producto en el Listado de Requerimientos (Backlog) que servirán como entrada al equipo de desarrollo.
En algunos proyectos, ambos roles pueden estar representados en la misma persona.

El Analista Funcional funciona como enlace entre los interesados en el proyecto (stakeholders) y el equipo de desarrollo. Para ello, utiliza distintas técnicas y habilidades (tormentas de ideas, votación de las funcionalidades, análisis de costo-beneficio, generar participación activa, mantener el trabajo en foco, etc.) para asistir a los líderes del proyecto en el logro de los objetivos propuestos.


En proyectos de desarrollo utilizando el ciclo ágil, el Analista Funcional contribuye en dos actividades principales: asegurar el cumplimiento de la Visión y Alcance, y moderar las reuniones de Planificación y Revisión de cada Iteración.
Todo proyecto comienza con una definición de la Visión y Alcance de la solución a desarrollar para cumplir con una necesidad de negocio. En el enfoque ágil, la visión y el alcance se definen en un conjunto de reuniones, cada una representando una porción de la visión y alcance en ese momento, que es determinada por los interesados.

El desafío para el patrocinador del proyecto es el de asegurar que la visión y alcance del proyecto sean resultado de un esfuerzo colaborativo entre todos los interesados en el proyecto, de aquí la necesidad del rol del Analista Funcional como facilitador. El Analista Funcional debe utilizar técnicas que faciliten que todos los interesados en el proyecto participen, colaboren y lleguen a un consenso sobre el conjunto priorizado de funcionalidades de alto nivel que deben ser desarrolladas. Debe asegurarse de que estas funcionalidades están justificadas y que tienen correspondencia con las necesidades de negocio. Todas las funcionalidades estarán sujetas a la aprobación del patrocinador del proyecto.

Reuniones de Planificación, Sincronización y Retrospectiva
Luego de que se identificaron el conjunto de funcionalidades de alto nivel, las reuniones del equipo de desarrollo comienzan con un consenso sobre cuáles de ellas serán desarrolladas en la primera iteración. Una vez que se seleccionó un conjunto finito de funcionalidades y se les asignó una fecha de entrega (time-box), todos los días se realizan reuniones de sincronización para revisar el estado de avance y eliminar obstáculos. Finalmente, se valida el prototipo y se implementa, realizando luego la reunión de retrospectiva y volviendo al inicio con una nueva reunión de planificación de las funcionalidades a incluir en la siguiente iteración.

En estas reuniones, surge el mismo desafío, asegurarse de que el software desarrollado sea producto del esfuerzo colaborativo y consenso de los participantes. Una vez más surge la necesidad del rol del Analista Funcional como facilitador.
Estas reuniones involucran detalles técnicos y del negocio vitales a los efectos de la solución a desarrollar:

  • Requerimientos funcionales
  • Reglas de negocio asociadas
  • Interfaz de usuario
  • Métodos técnicos de implementación

En las reuniones de sincronización, el rol del Analista Funcional es diferente del que tiene en las de planificación. En las reuniones de planificación, el Analista Funcional definió y ejecutó una agenda, en las de sincronización el rol es el de asistir a los interesados en el proyecto y al equipo de desarrollo paradeterminar los requerimientos del sistema, con el propósito de construir los prototipos que conformen de manera incremental el sistema a desarrollar.

El Rol del Analista Funcional facilita lo anterior mediante la utilización de herramientas deModelado del Negocio para identificar y analizar requerimientos de usuario, requerimientos del sistema y reglas de negocio:

  • Diagramas de Actividad – procesos manuales
  • Casos de Uso – requerimientos funcionales
  • Diagramas de Entidad-Relación
  • Diagramas de Transición de estados
  • Diagramas de clases – para implementaciones orientadas a objetos

La rigurosidad con la cual elAnalista Funcional debe modelar el negocio es determinada por las necesidades del equipo de desarrollo. En lugar de realizar una documentación exhaustiva y detallada de los requerimientos como en el modelo en cascada (waterfall SDLC), el Analista genera la documentación “suficiente y necesaria” que permita que el equipo de desarrollo codifique los prototipos.

Conclusión
Mientras se van definiendo, priorizando, analizando y/o desarrollando las funcionalidades, el Analista Funcional se asegura que los interesados en el proyecto aprueben la solución final. El Rol del Analista Funcional podría ser llevado a cabo por un miembro del equipo de desarrollo, sin embargo, se debe considerar el riesgo que involucra que una persona menos entrenada y con menos experiencia en el Análisis Funcional sea la responsable de construir consenso entre los participantes. El nivel de productividad y consenso estará directamente relacionado con el uso efectivo de herramientas de Análisis Funcional.
Además, existe el riesgo de que los interesados en el proyecto y los desarrolladores se enfoquen en aspectos técnicos del prototipo en lugar de hacerlo en los requerimientos.

Es prudente evitar estos riesgos, y a los efectos de “asegurar” el éxito del equipo, la mejor práctica es que el rol del Analista Funcional se formalice en una persona que asista al equipo de desarrollo de software ágil.

Copiado salvajemente de Maypun / Autor: Alejandro Grinsztajn