Ir al contenido principal

Antes de ser ágil

Hace unos cinco años y medio, empecé a trabajar en una nueva empresa internacional, donde la sede principal está situada en otro país, la empresa tenía negocio en dicho país y en otro más, y además abrieron la sede en España donde yo me uní.

En ese momento yo tenía catorce años de experiencia en empresas de IT, principalmente como desarrollador de software en distintos lenguajes y tecnologías, en escritorio y web, pero también había realizado labores de analísta y coordinador de equipos de trabajo.

Cuando digo que que trabajé en rol de analísta, no me refiero al gran demandado y polivalente "analísta-programador", que sí, que también tuve ese título en otra empresa, sino a meramente "analísta". ¿Qué hacía como analísta? Básicamente me llegaban solicitudes de requisitos de compañeros consultores, los cuales trataban directamente con el cliente final. Algunos de estos consultores tenían el clásico corte de comercial, otros, en cambio, sí tenían background en tecnologías de la información. Estos compañeros se dedicaban a tomar un pliego de ideas, requerimientos, propuestas, soluciones, deseos, lo que veían en la competencia, etc... y lo transcribían de una manera más o menos ordenada. Mi labor era comprender dicho pliego de requisitos, ver como se ajustaban en la aplicación (nuestra) que ya tenía el cliente, estudiar si realmente las soluciones propuestas por el cliente solucionaría realmente el problema o necesidad que tenía, o si había forma más simple (ahorrando en tiempo y mejorando productividad) de hacerlo. Esto lo traducía a otro documento de análisis funcional, listo para ser leído y entendido por algún equipo de desarrollo, y adicionalmente, dependiendo de la madurez y experiencia del equipo destino de desarrollo, acompañaba un análisis técnico y/o indicaciones/ayudas al desarollo.

También he desempeñado el cargo de coordinador de equipos de desarrollo, donde mi función, era decidir el orden en que se debían ejecutar las tareas (balanceando coste y beneficio), y proponer quién haría cada parte. 

Las relaciones humanas como analista eran bien pocas, quizás hablar con el consultor si algo no me quedaba claro, y quizás los desarrolladores preguntarme algo, pero en general poca conversación.

En cambio, como coordinador si había más iteración humana, sobre todo en la fase de planificación del proyecto, en el arranque.

Esta era mi forma de trabajar, la que conocía, con la que empecé en el mundo laboral, con la que me sentía muy cómodo, se me daba bien, entendía, y sacaba todo el jugo posible.


Al empezar a trabajar en esta empresa, todo cambió ...


Comentarios

Entradas populares de este blog

Primer contacto con el agilismo

Al entrar a trabajar en una empresa donde imperaba ser ágil, las metodologías con mismo nombre, y el framework de Scrum, me chocó todo un poco al principio, y pasados los primeros días el choque fue mayor aun. Es cierto que la oficina llevaba poco tiempo en funcionamiento en nuestra ciudad, eramos muy pocos, y toda la oficina estaba inmersa en conocer los productos, el código, y empezar a ser mínimamente productivos, es decir, en aquel entonces no había grupos de trabajo a pleno rendimiento, ni eran sabios en la parte funcional donde se implementaba. Dadas estas circunstancias, y a la metodología ágil de Scrum, la forma de trabajo fue muy distinta a lo que yo estaba acostumbrado, no era mi zona de confort. Por un lado teníamos unas sesiones mañaneras llamadas "stand up" o "dailies", donde había que decir que se había hecho el día anterior, que se iba hacer en el día presente y si habías tenido algún bloqueo o impedimento. Teóricamente estas sesiones no debían pasar

Mi primer toma de contacto con un refinamiento de Scrum

 Como he comentado en un artículo anterior, he trabajado durante muchos años en empresas que no usaban la metodología ágil. Los requerimientos venian dados por un analista (en el mejor de los casos, otras veces venía directamente de consultores con poco o ningún bagaje en tecnologías de la información); y normalmente eran unos documentos extensos, muy detallados, con gráficos, ... incluso notas o indicaciones técnicas. A mi personalmente me gustaban esos documentos, todo quedaba muy detallado, claro y conciso, pero esto mismo produce su gran debilidad, que hablaré más detenidamente de ello en otro artículo. Estando acostumbrado a trabajar con dichos documentos, me sorprendió bastante, primero con desconfianza y con el paso del tiempo con agrado, mis primeras sesiones de refinaminamiento, o también conocidas como refinements . El equipo de desarrollo al completo más el product owner (PO), nos reuníamos una o un par de veces semanalmente para hablar de los requerimientos. A diferencia de