CAS 2016 – Comunicación vs Información
Puede que la información fluya, pero ¿la comunicación entre el área tecnológica y de negocio es realmente efectiva? En la VI Conferencia Agile Spain (CAS), que se celebró en Vitoria en diciembre, ofrecí una charla en la que describí el rol del business analyst tradicional como comunicador y sus funciones y cómo evoluciona este rol a través de la comunicación en los proyectos agile. Finalmente, expliqué qué papel desempeñará el business analyst de ahora en adelante: ¿Es realmente necesario? ¿Lo seguirá siendo en el futuro?
La comunicación en proyectos tradicionales.
En CAS tuve la ocasión de hablar de la comunicación dentro de los equipos. Lo hice desde el punto de vista del business analyst (BA) tradicional, que es el rol que he desarrollado durante gran parte de mi carrera profesional. En un proyecto tradicional (aka, waterfall) los BAs tienen tres funciones muy importantes:
Una de ellas es la de documentar. Probablemente sea ésta la que se entiende como rol principal de un business analyst: escribir los requerimientos. Y tiene sentido que el BA desempeñe ese rol como experto en el dominio de negocio relevante en el proyecto. Su conocimiento tanto del negocio como del ciclo de vida del desarrollo de software le brinda la capacidad de analizar las peticiones provenientes del negocio y canalizarlas en un documento que sea fácil de entender para el resto de miembros del equipo.
Lo que muchas veces se obvia es que para tener un documento detallado de todos los requerimientos de un proyecto hay que hablar con mucha gente. Con usuarios, con stakeholders, con subject matter experts (SMEs), con arquitectos, con diseñadores… y es el conjunto de conversaciones lo que hace que el business analyst no deje el proyecto una vez firmado el Business Requirement Document (BRD), porque es muy difícil reflejar las conversaciones en un documento. Una vez alguien me dijo que un BRD es tan bueno o tan malo como el business analyst que lo ha escrito, y aunque podríamos debatir mucho sobre el tema, lo que refleja esa frase es exactamente la dificultad de escribir un buen BRD. De ahí que el rol del business analyst vaya más allá. Otra de las funciones de un BA, aparte de documentar, es verificar. Verificar que lo que se ha desarrollado cumple los objetivos mínimos. De ahí que, antes de subir código a un entorno de test de integración, se realicen “smoke tests”. La experiencia me ha demostrado que la persona más indicada para hacer esos tests acostumbra a ser el BA, no por ser el que mejor conoce el BRD sino por haber estado en esas conversaciones previas. Y por esa misma razón es el BA el mejor indicado para verificar si los defectos identificados durante la fase de pruebas son efectivamente defectos de código.
Y durante todo este proceso el BA desarrolla lo que en mi opinión es su rol más importante: el de comunicador. El BA es seguramente la persona del equipo que tiene comunicación con más stakeholders dentro del proyecto. El BA es el nexo entre usuarios, shareholders, arquitectos, desarrolladores, testers, project managers, diseñadores… o por lo menos, un buen BA debería serlo.
La comunicación en proyectos Agile
En Agile, ese rol de nexo que tradicionalmente hacía un BA se intenta eliminar. Eso no significa que la figura de BA deje de ser necesaria, pero de la misma manera que se trasladan responsabilidades de gestión y coordinación al equipo, también se trasladan responsabilidades de comunicación.
Con ese fin se idearon las User Stories por ejemplo. Una de las famosas 3 C’s de las User Stories se refiere a Conversación. Las User Stories son realmente recordatorios de que hay que discutir un tema.
Aun así, muchas veces caemos en la tentación de usar las user stories como mini-BRDs, o tener las conversaciones en equipo pero sin asegurarnos de que todo el equipo entiende el significado de la conversación.
Y aquí es donde entra en juego una práctica que, a mi parecer, cubre las tres funciones tradicionales del business analyst: documentar, verificar y comunicar. Esta práctica es hoy ampliamente conocida como Behaviour Driven Development (BDD) y también ampliamente confundida con una práctica de testing. En un mundo dominado por la tecnología y los tecnólogos es muy fácil caer en la tentación de focalizarnos sólo en las herramientas. Por eso prefiero usar el término “Specification by Example”(1), para evitar confusiones y focalizarnos en lo que realmente es importante. BDD no es sobre testing, es sobre comunicación, sobre entendimiento colectivo. Y sobre entender por encima de todo por qué hacemos lo que hacemos.
El futuro del Business Analyst
Quizás las funciones del BA queden cubiertas con una práctica de equipo. Pero que quede claro que esto no significa que no se necesiten las habilidades de un buen business analyst en un proyecto agile. Igual no lo llamaremos BA pero el rol sigue siendo necesario. Porque la parte más difícil de implementar BDD no está en usar la herramienta sino en asegurar el entendimiento colectivo. Y de momento, la persona más indicada para ayudar a conseguirlo es el business analyst tradicional.
Mis impresiones
Es el segundo año que GFT tiene presencia en este evento, pero esta vez no sólo asistimos como espectadores sino que participamos activamente como patrocinadores y como ponentes. Y podemos decir que ha sido todo un éxito: nos aceptaron tres propuestas de las cuatro que presentamos. A continuación podéis conocer otra de las tres conferencias que impartimos en CAS 2016:
(1) Para más información sobre Specification by Example podéis descargaros el libro “Bridging the Communication Gap” de Gojko Adzic.
¿Os ha parecido interesante? Podéis encontrar mi presentación en slideshare.
