Escribí este artículo para el blog de la empresa donde trabajo, aunque lo publiqué en inglés quiero compartir con ustedes la versión en español.
Aunque hay distintas variantes de cómo conformar los equipos de trabajo en la industria del software, lo más común en las empresas es tener un equipo de desarrollo encargado de crear el software y un equipo de QA (aseguramiento de la calidad) encargado de probar dicho software.
Comencé en el mundo del software hace 10 años aproximadamente, para ese momento trabajé investigando productos e identificando y desarrollando requerimientos para implementar en el software.
Dadas mis responsabilidades debía estar en comunicación constante tanto con el equipo de Desarrollo como con el equipo de QA. Desde un primer momento podía ver que existía una fuerte rivalidad entre ellos, algo así como si fueran fanáticos de diferentes equipos de béisbol (Yankees vs Boston) o fútbol (Real Madrid vs Barcelona) en la final del torneo.
Como eran equipos rivales las acciones de uno perjudicaban al otro, es decir, si el equipo de QA conseguía issues en el software, eso implicaba que el equipo de desarrollo hacía mal su trabajo (punto para QA), por otro lado cualquier razón era buena para poner un issue “Rechazado” o “No se puede reproducir”, un error de redacción, faltó un paso, etc. (punto para desarrollo). Así mismo, presencié y participé en reuniones interminables donde se luchaba a capa espada con argumentos de toda índole para tener la razón sobre la implementación de un requerimiento o un issue que se detectó. Si se conseguía un issue en producción era muy fácil culpar al equipo “contrario”, uno decía “QA no hizo bien las pruebas”, el otro decía “Desarrollo lo hizo mal” o “entregaron tarde”. Era muy sencillo descalificar el trabajo del otro para depositar en otros la responsabilidad.
Con el tiempo se empezó a evidenciar poca comunicación entre los equipos, fallas en los tiempos de entrega, baja calidad en los productos, y para intentar solucionar estos inconvenientes, la empresa empezó a experimentar en busca de soluciones, entre otras cosas se agregaron en los equipos más niveles jerárquicos, reestructuraron los procesos, hicieron cambios metodológicos, etc, con resultados que en mi opinión no fueron exitosos.
Durante mi carrera he trabajado con muchos otros equipos, con diferentes estructuras y diferentes productos, sin embargo de mayor o menor manera esa rivalidad ha estado siempre presente, y de hecho esta historia es el común denominador de muchas empresas,
Tiempo después en la empresa donde trabajaba se decidió que debíamos utilizar metodologías ágiles. El comenzar con Scrum no fue para nada fácil, tienes que cambiar muchos paradigmas y para ser sincero yo no creí que fuera a funcionar, aunque de igual forma tuve que dar el salto, la orden de usar Scrum venía desde arriba.
A medida que se progresaba con la implementación de la metodología me di cuenta que ese estatus quo del que era tan difícil salir se diluía poco a poco, hasta que finalmente desapareció, pero, ¿Porqué pasó esto?
El hecho de tener que reunirnos todos los días y que todos los miembros del equipo estuvieran involucrados hizo que poco a poco cada uno de los integrantes de esos “equipos” entendiéramos e internalizáramos que estábamos trabajando para lograr el mismo objetivo.
Nos permitió entender y valorar el trabajo de nuestros compañeros y que cada uno de los miembros del equipo tiene habilidades específicas que le permiten afrontar con mayor destreza cierto tipo de tareas.
Se crea un ambiente de trabajo donde se comprende que el trabajo y esfuerzo de cada uno está reflejado en el software, y que como somos humanos podemos cometer errores, que habrá cosas que no sabemos, que tendremos problemas ajenos al trabajo o indisposiciones de salud, por lo que es necesario que nos ayudemos para que podamos llegar a la meta.
Se establece como requisito indispensable que todos los miembros del equipo estén al tanto de las necesidades del producto y que participen activamente en los procesos para lograr el objetivo, y la única forma de lograrlo es con muy altos niveles de comunicación.
A medida que todo esto se iba aprendiendo, los desarrolladores ya no se sentían agredidos por las personas de QA, entendieron que todo era para mejorar, las personas de QA ya no descalifican el trabajo realizado sino que se enfocan en mejorar el software, y ya no hay evasiones de responsabilidad
Al transcurrir los meses, logramos tener un verdadero y único equipo muy bien consolidado que lograba:
Trabajos entregados con mayor calidad.
Se termina más trabajo que antes en el mismo tiempo.
Se disminuye al mínimo los famosos trasnochos para lograr las entregas.
Las personas salen del trabajo puntuales para compartir con su familia y vivir su vida.
Un ambiente de trabajo armonioso y solidario.
Y esto aunque parece un historia difícil de creer se logra hacer aplicando metodologías ágiles, porque estos marcos de trabajo tienen un enfoque en la comunicación y en ciertas técnicas que potencian la relaciones interpersonales y que promueven este progreso.
Si quieres leer otros artículos escritos por mis compañeros de trabajo (en inglés) puedes hacerlo en esta página http://www.teravisiontech.com/blog/
Aunque hay distintas variantes de cómo conformar los equipos de trabajo en la industria del software, lo más común en las empresas es tener un equipo de desarrollo encargado de crear el software y un equipo de QA (aseguramiento de la calidad) encargado de probar dicho software.
Comencé en el mundo del software hace 10 años aproximadamente, para ese momento trabajé investigando productos e identificando y desarrollando requerimientos para implementar en el software.
Dadas mis responsabilidades debía estar en comunicación constante tanto con el equipo de Desarrollo como con el equipo de QA. Desde un primer momento podía ver que existía una fuerte rivalidad entre ellos, algo así como si fueran fanáticos de diferentes equipos de béisbol (Yankees vs Boston) o fútbol (Real Madrid vs Barcelona) en la final del torneo.
Como eran equipos rivales las acciones de uno perjudicaban al otro, es decir, si el equipo de QA conseguía issues en el software, eso implicaba que el equipo de desarrollo hacía mal su trabajo (punto para QA), por otro lado cualquier razón era buena para poner un issue “Rechazado” o “No se puede reproducir”, un error de redacción, faltó un paso, etc. (punto para desarrollo). Así mismo, presencié y participé en reuniones interminables donde se luchaba a capa espada con argumentos de toda índole para tener la razón sobre la implementación de un requerimiento o un issue que se detectó. Si se conseguía un issue en producción era muy fácil culpar al equipo “contrario”, uno decía “QA no hizo bien las pruebas”, el otro decía “Desarrollo lo hizo mal” o “entregaron tarde”. Era muy sencillo descalificar el trabajo del otro para depositar en otros la responsabilidad.
Con el tiempo se empezó a evidenciar poca comunicación entre los equipos, fallas en los tiempos de entrega, baja calidad en los productos, y para intentar solucionar estos inconvenientes, la empresa empezó a experimentar en busca de soluciones, entre otras cosas se agregaron en los equipos más niveles jerárquicos, reestructuraron los procesos, hicieron cambios metodológicos, etc, con resultados que en mi opinión no fueron exitosos.
Durante mi carrera he trabajado con muchos otros equipos, con diferentes estructuras y diferentes productos, sin embargo de mayor o menor manera esa rivalidad ha estado siempre presente, y de hecho esta historia es el común denominador de muchas empresas,
Tiempo después en la empresa donde trabajaba se decidió que debíamos utilizar metodologías ágiles. El comenzar con Scrum no fue para nada fácil, tienes que cambiar muchos paradigmas y para ser sincero yo no creí que fuera a funcionar, aunque de igual forma tuve que dar el salto, la orden de usar Scrum venía desde arriba.
A medida que se progresaba con la implementación de la metodología me di cuenta que ese estatus quo del que era tan difícil salir se diluía poco a poco, hasta que finalmente desapareció, pero, ¿Porqué pasó esto?
El hecho de tener que reunirnos todos los días y que todos los miembros del equipo estuvieran involucrados hizo que poco a poco cada uno de los integrantes de esos “equipos” entendiéramos e internalizáramos que estábamos trabajando para lograr el mismo objetivo.
Nos permitió entender y valorar el trabajo de nuestros compañeros y que cada uno de los miembros del equipo tiene habilidades específicas que le permiten afrontar con mayor destreza cierto tipo de tareas.
Se crea un ambiente de trabajo donde se comprende que el trabajo y esfuerzo de cada uno está reflejado en el software, y que como somos humanos podemos cometer errores, que habrá cosas que no sabemos, que tendremos problemas ajenos al trabajo o indisposiciones de salud, por lo que es necesario que nos ayudemos para que podamos llegar a la meta.
Se establece como requisito indispensable que todos los miembros del equipo estén al tanto de las necesidades del producto y que participen activamente en los procesos para lograr el objetivo, y la única forma de lograrlo es con muy altos niveles de comunicación.
A medida que todo esto se iba aprendiendo, los desarrolladores ya no se sentían agredidos por las personas de QA, entendieron que todo era para mejorar, las personas de QA ya no descalifican el trabajo realizado sino que se enfocan en mejorar el software, y ya no hay evasiones de responsabilidad
Al transcurrir los meses, logramos tener un verdadero y único equipo muy bien consolidado que lograba:
Trabajos entregados con mayor calidad.
Se termina más trabajo que antes en el mismo tiempo.
Se disminuye al mínimo los famosos trasnochos para lograr las entregas.
Las personas salen del trabajo puntuales para compartir con su familia y vivir su vida.
Un ambiente de trabajo armonioso y solidario.
Y esto aunque parece un historia difícil de creer se logra hacer aplicando metodologías ágiles, porque estos marcos de trabajo tienen un enfoque en la comunicación y en ciertas técnicas que potencian la relaciones interpersonales y que promueven este progreso.
Si quieres leer otros artículos escritos por mis compañeros de trabajo (en inglés) puedes hacerlo en esta página http://www.teravisiontech.com/blog/