Business Analyst (BA) es un trabajo que puede ser bastante divertido o bastante aburrido, un paseo en una montaña rusa o algo mas bien plano, ¿de qué depende?, del cliente… obviamente, pero también del equipo y de la metodología de desarrollo que se esté usando. Les voy a platicar un poquito de mi experiencia tratando de BAlizar proyectos.
Ser analista no es fácil sobre todo si no está definido cual es tu rol, ya sea definir los user stories, recomendar mejoras de performance, seguridad, simplificar los requerimientos de un sistema, acotar el alcance de un proyecto, o todo a la vez.
Depende mucho del equipo con el que vas a trabajar, que tan de acuerdo están en colaborar y las expectativas que tengan del analista. Normalemente quieren soluciones técnicas y a la vez no quieren que te metas en lo técnico. En realidad, esto debe ser parte de un análisis de cada requirimiento, en conjunto con todo el equipo de trabajo y llegar a la mejor implentación del mismo, ya bastante trabajo se hace en componer buenos user stories como para aparte decir cómo se va a implementar, y es que en verdad no es parte del trabajo del analista al menos no en Scrum.
Claro el analista puede tener idea, pero siempre pasa que el analista no es muy objetivo en esto, y entre varios se puede lograr algo mejor. Ahora, si el analista dice cómo implementar, el equipo no va a estar contento de no poder sugerir mejores formas de hacer algo. Si has trabajado con un BA, seguro has dicho:
“Este cuate no sabe ni de lo que habla”.
Sé que lo has hecho. Te estoy viendo.
Esto puede ser complicado con personas que no están acostumbradas a tomar decisiones técnicas, pero no es imposible, poco a poco se van soltando y sugiriendo. Lo que yo hago es decir el requerimiento a alto nivel y si no hay participación empiezo a bajarlo, dando ejemplos, incluso usando otro framework para ello. Por ejemplo, diciendo:
“Esto en Rails se podría manejar con esta librería y luego ya se configura el usuario y prácticamente ya lo tienes”.
De repente los developers empiezan a defender su tecnología, framework, tool, o lenguaje y a la vez dando soluciones. Ya será tarea del Scrum Master encarrilar la junta de nuevo.
Pero es algo que como BA tienes que planear desde antes, cuando se están haciendo las user stories para el siguiente Sprint Planning, pensar en posibles soluciones para cada story. A medida de que el equipo va madurando, el trabajo va siendo mas divertido y fluido.
Como BA y developer uno quiere meterse al código, nos encanta, es nuestra pasión y nos trae buenos recuerdos. Pero no debemos perder nuestro foco que es hacer que el producto sea valioso para el cliente, el equipo de trabajo y la empresa. No hay que meter nuestras narices mas allá de eso porque podemos romper con la creatividad del equipo.
El cliente, es una historia muy diferente. Esto es lo que a veces pienso mientras trabajo con un cliente. Me imagino que estoy parada en un bosque, tomando una decisión sobre cual sendero tomar, uno se ve fácil, luminoso y corto; y el otro se ve oscuro, tenebroso, lleno de obstáculos, ni siquiera hay camino claro, y aún así, decido ir por ahí. Cada obstáculo que veo podría decir:
“¡Hasta aquí!, si sigo esto se pondrá más complicado y ni siquiera se ve el fin, no debería seguir”.
Pero sigo.
Y sigo porque no hay cliente malo ni bueno, todos necesitan una guía y esa guía es el BA, o sea, yo. Al principio es abrumador, es mucha información, pero por algo hay que empezar, y deberás escribir mucho aunque nadie vaya a leer tu documentación. Me hace sentir bien saber que lo que escribo me ayuda a clarificar mis ideas, aunque en teoría sea para todos. Y es que de verdad ayuda, y poco a poco el camino se hace mejor. Entre mas comunicación con el cliente, es mejor, no hay que dejar lugar a suposiciones o dudas, a medida de lo posible.
Ahora que hay que saber hasta donde va a acabar el proyecto, una vez que se tienen todos los user stories, hay que ver para cuando se quiere tener un MVP, y de ahí decidir cuales stories se van a hacer. Esto es con ayuda del product owner y a esta persona hay que explicarle que no se puede todo, que decida que es lo mas importante y de ahí uno escoge. Aquellas tareas que digamos te van a hacer abrir nuevos senderos, hay que acotarlas muy bien y ser muy claros hasta donde va a llegar.
Si eres BA y sientes que en tu team te ven con cara de “bueno a esta nada le parece”, no te preocupes, no es tu tarea ser su amigo. Tu tarea es responder sus dudas lo mejor que puedas en relación con los requerimientos. Puedes acceder a hacer push back de algún requerimiento y eso les hará felices. Pero no siempre se podrá y eso no les hará felices. Ni hablar.
Ahora que si la cosa es con los clientes, y ellos te ven con cara de “ahí está otra vez con sus preguntas”, no te preocupes, no es tampoco tu tarea ser su amigo. Quedar bien con el cliente, es cosa del Product Owner. Enfócate en tener los requerimientos de lo que estés haciendo y tener la información necesaria para crear tus user stories y para poder ayudar al equipo de trabajo. Así tengas que aclarar lo mismo varias veces, los clientes harán lo mismo contigo así que tú dale.
Por otro lado, debes hacerte amigo del Product Owner para que te ayude con el cliente y del Scrum Master para que te ayude con el equipo, si hay Project Manager pues también. Estas son las personas que te sacaran de apuros. Si tienes algún problema con el equipo, si no están avanzando a la velocidad que esperabas, si los están distrayendo con otros proyectos, si el cliente no te responde, pídeles ayuda inmediatamente.
Habrá proyectos que se salen del skillset del equipo trabajo con el cual trabajas, y no es que no puedan, pero si les no les dan tiempo de curva de aprendizaje será imposible, ese sería un ejemplo de cuando dejar un proyecto, o recomendar no tomarlo. También si el cliente no es buena persona, no hay clientes malos tal cual como clientes, pero hay personas que parece que solo quieren amargar la vida de los que los rodean, no es necesario tomar ese camino, déjaselo a alguien más. Escucha también a tu equipo, y a tu instinto; habrá proyectos que desde el principio tendrán banderas rojas y no beneficiaran a nadie e incluso pueden afectar la reputación de una empresa. Haz la recomendación, bien documentada y basada en hechos no en sentimientos, en cuanto lo identifiques. Ten en cuenta que no depende de ti, pero al menos se sabrá que alzaste la mano a tiempo.
Trabajo es trabajo, pero siempre hay que tratar de hacerlo divertido, si no te funciona, escribe un blog post y al menos te sentirás mas tranquila. A mi me funcionó.
