Palmarket

I wrote this article for the company's blog where I'm working now and I want to share it with you in my blog too. Although there are different variants of how to form teams in the software industry, the most common in companies is to have a application development team responsible for creating software and a QA (quality assurance) team responsible for testing that software. I started in the software world about 10 years ago, by that time, I worked on researching products, and on identifying and developing requirements to implement in the software. Due to my responsibilities, I should be in constant communication with the development team and the quality assurance team. From the beginning you could see a strong rivalry between them, such as being fanatics of different baseball teams (New York Yankees vs Boston Red Sox) or soccer teams (Real Madrid vs Barcelona) in the final tournament. Due to this rivality, the actions of one harmed the other, that is, if the quality assurance team found issues in the software, that meant that the development team did a bad job (point to QA), on the other hand any reason was good to put an issue "Rejected" or "Can't Reproduce", a drafting error, missing a step, etc. (Point to Development). I also witnessed and participated in endless meetings where they fought fiercely with all kinds of arguments on who was right about the implementation of a requirement or a detected issue. If an issue in production was detected it was very easy to blame the "opposite" team, one said "QA didn't test well", the others said "Development did it wrong" or "delivered late." It was very simple to discredit each other's work and to place the responsibility on the others. Over time they began to show miscommunication between equipment, failures in delivery times, low quality application development, and to try to solve these problems, the company began experimenting in search of solutions. Among other things, additional hierarchical levels were added to the teams, processes were restructured, methodological changes, etc. Which in my opinion resulted in very little success. During my career I have worked with many teams, with different structures and different products, however in a major or minor way that rivalry has always been present, and in fact this story is the common denominator of many companies. Later in the company where I worked it was decided that we should use agile methodologies. We would start to work using the Scrum methodology which was not at all easy, you have to change many paradigms, and to be honest I didn't think it would work, although I had to take the leap, the order to use Scrum came from above. As we progressed with the implementation of the methodology I realized that the status quo that was so hard to leave, was gradually diluted until it finally disappeared, but, Why did this happen? The fact of having meetings every day and that all team members were involved, did that each of the “teams” members gradually understood and internalize that we were working towards the same goal. It allowed us to understand and appreciate the work of our colleagues and that each of the team members have specific skills that enable them to cope with a greater dexterity certain types of tasks. This created a work environment where it was understood that the work and effort of each one is reflected in the developed software. Due to that we are humans, we make mistakes, there will be things we do not know, we'll have problems unrelated to our work, so it's necessary to help each other to achieve the project goal. It is an indispensable requirement that all team members are aware of the needs of a product and actively participate in the process to achieve that goal. The only way to achieve this is with a very high level of communication. Over time, developers no longer felt attacked by the people from QA, they understood that everything was just meant to improve. The QA people no longer disqualifies the work that was done and they are now focused on improving the software, improving the application development process and no team member evade their responsibilities. As the months passed, the team became in a unique and well established team that achieved: Work delivered with high quality More work was completed within the same timeframe. The nighters to achieve deliveries were minimized. People leave the office in time to share with their families and live their lives. A harmonious and solidarity work environment. Although this seems like a difficult story to believe, this is achieved by applying agile methodologies, because these frameworks have a focus on communication and certain techniques that enhance interpersonal relationships and promotes this progress. If you want to read other articles of my coworkers you can find them here http://www.teravisiontech.com/blog/

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/

Hoy voy a escribir mi opinión sobre algo que actualmente hacen mucho las parejas, discutir a través de mensajes o chat. Escribo de este tema simplemente porque me ha pasado y quiero compartirlo. http://www.today.com/id/30851168/ns/today-parenting_and_family/t/parents-turn-cell-phones-high-tech-rattles/ Discutir, pelear, argumentar, como lo quieran llamar a través de mensajes de texto, whatsapp, gtalk o hangouts, lime, messenger, yahoo, telegram, etc, es algo nuevo, nuestros padres y abuelos no podían hacer esto simplemente porque no tenían la tecnología!! El hecho es que hoy en día estas herramientas de comunicación instantánea crean ciertos problemas de "comunicación", y esto se puede dar por varias causas pero cuyo origen va en una sola dirección y es que hay parte del mensaje que se esta perdiendo. En primer lugar por agilizar la escritura utilizamos una nueva jerga de abreviaciones y no aplicamos ningún tipo de cuidado gramatical u ortográfico, algunos dicen que es la forma correcta de escribir a través de dichos medios, pero sin embargo le estamos quitando la entonación y el énfasis a las palabras, por lo cual es el receptor el que agrega estos al mensaje y es ahí donde se vuelve un problema. Si estás discutiendo y la otra persona esta enojada hay una tendencia a mal interpretar no solo las palabras sino el tono y énfasis del mensaje lo cual en muchas ocasiones solo empeora la situación. Personalmente recomiendo que si quieres tratar algo que te molestó con tu pareja es preferible aguardar y hacerlo en persona o en dado caso hacer una llamada telefónica. Muchas veces es difícil pero es más saludable para la relación. Hasta una próxima entrada