Agotamiento en las pruebas de software: 6 causas y cómo solucionarlo

Analicé en profundidad el problema del agotamiento en las pruebas de software y me pregunté:

• ¿Cómo se manifiesta el agotamiento en esta industria?
• ¿Qué tan grave es el problema?
• ¿Qué crea sistemas en los que los probadores de software sufren agotamiento?
• ¿Cómo podemos desglosar el problema del agotamiento y solucionarlo?

Las respuestas —o al menos el comienzo de estas— se encuentran aquí, en este artículo.

El agotamiento entre los profesionales de las pruebas de software en TI 

El estrés relacionado con el lugar de trabajo es algo que muchos de nosotros experimentamos en la industria de TI. Estoy seguro de que tú también tienes tu parte de estrés. En mi contexto, por desgracia, el agotamiento se ha convertido en un tema cada vez más destacado durante los últimos años.

¿Es el agotamiento un problema?

Cuando le pregunté a Jonathon Wright: «¿Qué tan grave crees que es el agotamiento entre los profesionales de QA?», esto fue lo que respondió:

«Es un problema enorme. Palabras célebres: no puedes estar siempre corriendo a toda velocidad».

Jonathon Wright, presentador del pódcast The QA Lead

Continuó explicando:

«Metodologías como ágil y DevOps fomentan la idea de hacer todo aún “más rápido”. ¿Cómo proporciona un profesional de QA un valor medible en el entorno de fallar rápido y aprender con rapidez?

En un pódcast reciente de QALead surgió el término “reducir la velocidad para aumentarla”. A menos que las empresas celebren el fracaso (lo que muy pocas hacen), cada vez que fallas no estás ayudando a la velocidad del resto del equipo. 

La pista está en el título del sobreutilizado gráfico de trabajo pendiente. La gamificación del compromiso con una cantidad de puntos de historia crea una competencia poco saludable.

«Te obligan a hacer más con menos, trabajando de acuerdo con una expectativa poco realista de que el trabajo puede entregarse en sprints de dos semanas».

Jonathon Wright, presentador del pódcast The QA Lead

¿Cómo se manifiesta el agotamiento en QA?

El agotamiento no es un caso aislado en la industria del software, pero ¿cómo se manifiesta?

Estas son las respuestas de profesionales de las pruebas de software que muestran las formas en que aparece el agotamiento en QA.

«Tenemos que demostrar nuestro valor. Los equipos me dicen que son ágiles y que no necesitan probadores».

«Ansiedad. Es difícil para los profesionales de QA no preocuparse antes de un lanzamiento importante o no sentirse responsables de cualquier resultado».

«Presión de tiempo. Los probadores siempre somos los últimos. Y nunca obtengo el tiempo que necesito. Además, se reduce a la mitad porque los desarrolladores se retrasan».

«Expectativas poco realistas. Podría probar para siempre y aun así no sería capaz de probarlo todo. Díselo a un líder de proyecto. ¿De qué sirve un probador que no encuentra los errores?»

«Determinar qué probar a partir de los elementos del trabajo pendiente es casi imposible. Y nadie menciona los casos límite».

«El desperdicio es frustrante. Los desarrolladores no pueden reproducir un error, el elemento del trabajo pendiente está desactualizado o ya lo han corregido».

«Muchos no quieren un informe honesto y, especialmente, no quieren malas noticias. Cuando insistes, puede convertirse en algo personal».

ÚNETE A LA COMUNIDAD

Mejora tu bandeja de entrada con más sabiduría sobre liderazgo tecnológico para ofrecer mejores programas y sistemas.

Get Free Access

Have an account? Log In

¿Por qué ocurre el agotamiento?

La bibliografía enumera muchos factores que causan estrés y aumentan la probabilidad de agotamiento. Existen factores individuales, por ejemplo, motivadores personales como ser perfecto, darse prisa, esforzarse demasiado, ser fuerte o complacer a los demás. Consulta el análisis transaccional para obtener más detalles. 

También existen factores estresantes derivados del entorno laboral: una gran carga de trabajo, presión de tiempo, objetivos y expectativas inalcanzables, falta de control, conflictos intensos, miedo a perder el empleo, insatisfacción laboral, acoso y hostigamiento, entre otros. Los conocemos.

Hace algún tiempo empecé a analizar el agotamiento desde un punto de vista sistémico y creé un juego de simulación en el que los jugadores pueden influir en el destino de un equipo de desarrollo de software. Pueden agotar a los miembros del equipo o crear el proyecto más gratificante de todos. 

El núcleo de la simulación es un sistema de agotamiento, es decir, un sistema configurado de tal manera que algunos miembros de un equipo acabarán agotándose. Puedes ver un adelanto del juego en mi blog.

Este enfoque sistémico también funciona para diferentes roles dentro de un equipo. Lo he hecho para profesionales de la experiencia de usuario y me sorprendió lo fácil que es empujar a estas personas hacia el punto crítico de un sistema de agotamiento. Especialmente cuando se preocupan por los usuarios, están dispuestos a librar una batalla adicional y arriesgarse a venirse abajo.

A continuación, profundizaré en una historia de Alan, un profesional de control de calidad, para comprender e ilustrar mejor el problema del agotamiento en la industria del software. 

Después, hablaré sobre cómo se crean los sistemas de agotamiento y qué podemos hacer para mejorar estos sistemas.

Una historia personal sobre el agotamiento

Ahora que estoy seguro de que puedo fabricar un sistema de agotamiento para profesionales de control de calidad, permíteme presentarte a Alan y su historia. 

Alan tiene casi una década de experiencia en pruebas de software y, especialmente, en pruebas de rendimiento. Está a punto de incorporarse a un equipo de desarrollo. El equipo lleva diez sprints de trabajo y le quedan otros cuatro para realizar una primera entrega. 

¿Cómo fue el primer día de Alan en el proyecto?

Alan: Tengo mucho que hacer. El software es de baja calidad. Espero que haya muchos errores no detectados y temo que haya problemas si no puedo encontrarlos antes de la entrega.

Markus: Entonces, ¿identificar los errores es tu máxima prioridad para mejorar la calidad?

Alan: Esa es una parte. También esperamos muchos usuarios. El rendimiento del software es de suma importancia una vez que lo lancemos al público general. El equipo está deseando aprovechar mi experiencia en ese ámbito.

Hasta ahora, Alan es bastante optimista respecto a que las medidas acordadas con el equipo mejorarán la calidad del software. Sin embargo, un sprint después, cuando quedan tres sprints, Alan no parece demasiado alegre. 

¿Cuál es el problema?

Alan: Las dos semanas fueron intensas. No estoy contento con mis progresos. Quería realizar una primera prueba de rendimiento, sencilla, pero estoy muy lejos de conseguirlo.

Markus: ¿Qué te lo impide?

Alan: Necesito el apoyo de los desarrolladores, pero están saturados. También necesité mucho más tiempo del esperado para conocer el software e informar de los errores que encontré.

Markus: ¿Pudiste probar las nuevas historias entregadas por el equipo?

Alan: En realidad no, el equipo estaba ocupado puliéndolas. De los dos días reservados para las pruebas al final del sprint, solo quedó medio día. Me quedé más tiempo y trabajé el sábado, pero estoy muy lejos de terminar.

En la retrospectiva del sprint doce, cuando quedan solo dos sprints, las pruebas son el tema número uno: el propietario del producto se quejó de la cantidad de errores que encontró Alan.

Desarrollador: La mayoría de los errores que encontró Alan son insignificantes o ni siquiera son errores. Primero revisémoslos antes de sacar conclusiones precipitadas.

Alan: Bueno, me resultó difícil entender qué debería hacer el software a partir de los elementos del backlog. Una especificación ayudaría mucho.

Desarrollador: ¡Sobre mi cadáver! No queremos una metodología en cascada. En su mayor parte es cuestión de sentido común. Venid a preguntarnos. ¿Cómo van las pruebas de rendimiento?

Alan:Estoy estancado. No consigo que la herramienta se ejecute contra la capa de servicios con toda esa seguridad. Necesito ayuda.

Desarrollador: Usamos otra herramienta en el último proyecto. Funcionó de maravilla. Te enviaré el enlace.

Como resultado, el propietario del producto organiza una reunión rápida de dos horas en el siguiente sprint. El objetivo es revisar los errores y debatir qué registrar en los elementos del backlog para facilitarle las cosas al novato Alan. ¿Puedes sentir cómo aumenta la frustración de Alan?

La posición fatal de Alan como chivo expiatorio se vuelve más evidente después del sprint trece, cuando queda un sprint. Estas son las decisiones de esta retrospectiva:

• Se encontraron muchos errores en historias que Alan debería haber probado en el sprint anterior. No se cerrará ninguna historia sin que Alan la haya probado.
• Seguimos sin tener una prueba de rendimiento. Haremos que un experto se encargue de ello. Alan deberá informarle.
• No se pudieron terminar dos historias. Perdimos dos días descartando informes de errores inútiles. Alan marcará la relevancia de cada error. En caso de duda, preguntará al propietario del producto.

¿Lo has visto? El equipo no terminó dos historias y consiguió culpar a Alan. 

Imagina el próximo sprint, cuando las historias no se cierren porque Alan no tuvo tiempo de probarlas. No es de extrañar que Alan parezca agotado.

Alan: Solo quedan dos semanas para el lanzamiento y la calidad es una pesadilla. ¡Díselo al responsable del producto! Además, eliminaron las pruebas de rendimiento. Esa era la razón por la que me incorporé al proyecto. Mi jefe está descontento. Quería que diera ejemplo sobre cómo incluir a los probadores en los equipos ágiles. Sin embargo, tendré que luchar para sacarlo adelante; mi reputación en la empresa está en juego.

Cuatro semanas después, dos semanas después del primer lanzamiento para un público seleccionado, el sistema de agotamiento está plenamente operativo. 

Resumen de Alan sobre sus logros hasta el momento:

• Pruebas de rendimiento: suspendidas
• Ser reconocido como experto en pruebas de rendimiento: suspendido
• Ser capaz de probar exhaustivamente lo recién construido: suspendido
• Ser capaz de volver a probar exhaustivamente lo ya construido: suspendido
• Incorporar probadores en los equipos ágiles: suspendido
• Ningún error crítico en el lanzamiento: suspendido
• Ser recomendado: suspendido
• Trabajar duro y ser culpado: conseguido
• Miedo a perder el trabajo: conseguido
• Agotamiento: avanzando hacia él a toda velocidad

Este es un caso clásico de un sistema de agotamiento. Entonces, ¿qué crea este sistema y cómo podemos mitigarlo?

¿Qué crea un sistema de agotamiento?

Podría decirse que, para Alan, es una causa perdida desde el principio. Y tendrías razón. Alan se encuentra en un sistema de agotamiento que lleva bastante tiempo funcionando en el equipo. El sistema de agotamiento señala a Alan como un depredador que acecha a su víctima. Pero ¿qué es este sistema de agotamiento y cómo lo consigue?

Un sistema de agotamiento es una constelación de personas, factores impulsores y conflictos. Mediante un ciclo de refuerzo, crea una situación tan llena de factores estresantes que algunas personas acabarán agotándose. Es especialmente poderoso cuando puede activar la lógica de supervivencia de las personas.

1. La energía sigue a los factores impulsores

En la historia de Alan, podemos identificar algunos factores impulsores:

• La ambición y la fascinación por el tema favorito de las pruebas de rendimiento hacen que Alan quiera encargarse de ellas.
• La ansiedad por ser responsable de un lanzamiento fallido hace que Alan busque errores.
• Algo hace que los miembros del equipo construyan funcionalidades antes que cualquier otra cosa.

Los factores impulsores cambian el curso de la acción. A las personas les resulta realmente difícil pensar con claridad sobre qué conseguir y cómo conseguirlo. La energía que invierten sigue al factor impulsor, no a aquello que más la necesita. El equipo de Alan nunca se pregunta si construir todas las funcionalidades es lo correcto. Alan tampoco cuestiona si buscar errores es apropiado.

Lo difícil para la mayoría de nosotros es ser conscientes de que un factor impulsor ha tomado el control. Por suerte, los psicólogos los han estudiado. Para los factores impulsores personales, empieza con el análisis transaccional. A nivel de equipo, el pensamiento grupal es un buen punto de partida. Allí encontrarás muchos consejos.

En relación con la ansiedad antes de un lanzamiento, uno de los profesionales experimentados de control de calidad aconsejó: «Solo tienes que dejarlo pasar y mantener la calma». Con una mentalidad así desde el principio, probablemente Alan perseguiría un objetivo diferente al de eliminar todos los errores y establecer pruebas de rendimiento. Las prioridades principales podrían ser que el equipo elimine los errores críticos y ofrezca, en general, una mayor calidad. Una forma de reducir el estrés asociado a las tareas repetitivas es aprovechar herramientas de primer nivel diseñadas para las pruebas de software.

2. Los conflictos intensifican la situación y se vuelven personales

Junto con los factores impulsores, los conflictos estallan en el equipo. Por ejemplo, Alan necesita más tiempo de los desarrolladores del que están dispuestos a dedicar. Resultado: Alan genera mucho ruido y los desarrolladores intentan mantenerlo alejado. Al contar con poca ayuda, Alan no puede cumplir las expectativas. Teme por su reputación, redobla sus esfuerzos y genera aún más ruido.

Lo realmente malo es que los conflictos se vuelven personales. Tras haber trabajado como probador durante diez años, Alan probablemente sea todo un experto. Aun así, el equipo lo ve como un inútil y actúa en consecuencia. Cuanto más tiempo dura esto, más se profundiza. Esto también afecta a Alan: empieza a cuestionar su competencia.

¿Cuántas veces has culpado a alguien? ¿Cuántas personas a tu alrededor no están haciendo un buen trabajo? Cada uno de esos pensamientos apunta a un conflicto que se volvió personal.

La mayoría de los equipos son incapaces de resolver conflictos. No es fácil. La gestión de conflictos es la palabra clave para encontrar consejos. El mensaje básico es el siguiente: los equipos necesitan una cultura en la que las ideas puedan intercambiarse abiertamente, las opiniones divergentes sean bienvenidas como oportunidades para crear cosas nuevas y se valore la ayuda mutua. Algo difícil de conseguir si se compara con la cultura de la velocidad que describe uno de los entrevistados: «A menos que las empresas celebren el fracaso, cada vez que fracasas no estás ayudando a la velocidad del equipo».

3. La estructura del equipo afecta a la dinámica del equipo

El equipo de Alan reservó los dos últimos días del sprint para las pruebas, cerrar el sprint y preparar el siguiente sprint. El equipo simplemente asumió que Alan seguiría esta estructura. Probaría las funciones recién implementadas al final del sprint y volvería a probarlas en el siguiente sprint, además de mejorar las pruebas en general. No suena mal, ¿verdad?

La realidad cuenta una historia diferente. El software solo está disponible el último día del sprint. Los elementos del backlog ofrecen poca ayuda sobre cómo debería funcionar exactamente. Mientras el equipo debate los detalles de lo que hará en el siguiente sprint, Alan intenta averiguar qué probar del sprint actual. Luego hace preguntas justo antes de que los desarrolladores se marchen y prueba durante el fin de semana. Qué bien que el equipo hable sobre qué escribir. Así Alan puede probar sin molestar a los desarrolladores. ¡Bingo!

La estructura del equipo aísla cada vez más a Alan. El equipo no ve sus dificultades. Solo percibe preguntas estúpidas y resultados tardíos de poco valor. Qué elemento tan inútil.

La especificación mediante ejemplos muestra claramente cómo las pruebas y los profesionales de pruebas pueden ser una parte integral de un equipo ágil. Los profesionales de pruebas participan en los refinamientos, ayudan a crear una especificación comprobable, centran los esfuerzos de prueba en aquello que importa, mejoran los procesos del equipo, las habilidades individuales y las herramientas, e incluso realizan algunas de las pruebas. Las pruebas se realizan de forma continua, no solo al final del sprint.

4. Ignorar las reglas fundamentales conduce a problemas

El equipo de Alan ignora reglas fundamentales de la ingeniería de software. 

Estas son cinco de ellas:

1. Ocurren cosas inesperadas. No dejar suficiente margen para ellas conduce a las prisas, los atajos, los errores estúpidos, los conflictos acalorados y, por tanto, a un progreso más lento a largo plazo.
2. La presión provoca retrasos. La presión deja menos margen para las cosas inesperadas.
3. La calidad surge de manera emergente. El equipo necesita tener una cultura de calidad. Las pruebas son solo una pieza del rompecabezas. Y un único miembro del equipo enfrentado a todos los demás suele fracasar.
4. Cambiar el equipo ralentiza el trabajo. Crear confianza, adaptar procesos y resolver más conflictos: el equipo necesita tiempo y energía para integrar a los nuevos miembros. Añadir personas a un proyecto atrasado hace que se atrase aún más.
5. Los defectos sirven para aprender. Cuando un proceso produce demasiados defectos, hay que detenerlo, corregirlo y aprender de él. No hay que culpar a nadie y, lo más importante, no hay que acelerarlo.

Hay más reglas de este tipo y, siempre que las personas las ignoran, las cosas empeoran. Y eso es lo que le ocurrió a Alan.

5. La percepción de una situación apremiante lo desencadena

¿Cómo es que el equipo ignora cuestiones tan fundamentales? Es fácil. Es algo típico en una situación apremiante, en la que las condiciones dadas (los entregables, el tiempo disponible y el equipo) no dejan suficiente flexibilidad para afrontar las cosas inesperadas. Todos hemos pasado por eso; es un caso evidente. Los sistemas de agotamiento explotan la única variable de una configuración apremiante: cuánto se esfuerza el equipo, es decir, cuánta energía consumen los miembros del equipo de sus reservas.

La pregunta clave: ¿se encuentra realmente el equipo de Alan en una situación apremiante y es entregar todas las funcionalidades la mejor opción? Solo podemos suponerlo. El equipo hizo lo mismo y se apresuró a intentar desarrollar todas las funcionalidades.

Lo que importa es la percepción de las situaciones apremiantes. El desencadenante de esa percepción puede ser una cláusula contractual, un incentivo, una gran oportunidad de mercado, una fuerte exigencia de un jefe, una promesa hecha, el deseo de un cliente o una normativa gubernamental.

Alan espera una gran cantidad de errores y la ansiedad hace que los persiga. La pregunta clave para él: ¿en este caso es realmente tan importante encontrar los errores? Solo podemos especular, y eso es lo que hizo Alan. Supuso que sí.

La percepción de una situación apremiante es una palanca importante para romper un sistema de agotamiento. Detrás de ella hay otra regla fundamental de la ingeniería de software:

• Expectativas demasiado elevadas. Las partes interesadas —incluidos los propios desarrolladores— esperan, creen o exigen más de lo que un equipo de software puede entregar de forma realista.

Al analizar los últimos 25 años de mi experiencia en proyectos, no recuerdo ni uno solo en el que no fuera así. El conflicto entre lo que se espera y lo que se puede entregar es el punto crítico. El éxito de un proyecto depende de lo bien que las personas involucradas puedan resolver este conflicto. Recomendaría revisar las buenas prácticas sobre la gestión de las partes interesadas y de las expectativas, la gestión de conflictos, la ingeniería de requisitos, la agilidad y otros temas similares.

En cualquier caso, lo que hay que hacer es comprender la naturaleza exacta del conflicto. ¿Qué intensidad tiene? ¿Qué lo impulsa? ¿Con quién hay que trabajar? O, como dijo uno de los profesionales de QA entrevistados: “Creo que toda empresa debe tomar una decisión consciente en torno a la calidad, el coste y la velocidad”. Toda empresa necesita trabajar en sus expectativas.

Por lo general, los profesionales de QA no están en una posición que les permita liderar esta conversación. Pueden intentar contribuir. Puede ser más fructífero gestionar las expectativas a las que se enfrentan personalmente. Una de las personas entrevistadas me contó su receta: “Es imposible probarlo todo. Lo mejor es definir un plazo fijo y las prioridades con el responsable del producto. Las prioridades reflejan el riesgo de no realizar las pruebas. Si no estamos satisfechos, hay que renegociar el plazo fijo y las prioridades”.

More Articles

• Cómo prepararse para, y sobrevivir a, decisiones de Lanzar/No Lanzar
• Cómo las habilidades de testing me convirtieron en un mejor desarrollador de automatización
• 6 Trucos de Ingeniería de Calidad para Equipos de Desarrolladores Remotos
• Trae tus propias herramientas… Pero primero, piénsalo dos veces
• 14 artículos imprescindibles sobre pruebas de software para inspirarte

6. La trampa ágil

Un equipo sólido que se adapta continuamente a las necesidades cambiantes, una forma no burocrática de afrontar el cambio, medios sencillos de planificación y control del progreso: el movimiento ágil ha aportado una gran cantidad de innovaciones de las que los equipos de desarrollo harían bien en beneficiarse. Aun así, parece que lo ágil está intensificando la situación.

Empieza por el nombre: iteración significa rapidez, velocidad significa rapidez, uno falla rápido. Los principios ágiles ponen el código en primer lugar, y pensar por adelantado se descarta fácilmente como un desperdicio. Incluso el término Scrum proviene del rugby, un deporte en el que los atletas se placan entre sí a toda velocidad. Así, la agilidad, incluso en contra de sus convicciones, promueve la velocidad por encima de la calidad. «Metodologías como las ágiles y DevOps fomentan la idea de hacerlo todo aún más rápido», se quejó un profesional de QA.

La mecánica, por ejemplo, de Scrum es incluso peor que el nombre. No es que quienes crearon Scrum quisieran fomentar el agotamiento. Pero Scrum lleva a los equipos por el camino equivocado.

En primer lugar, centra la atención del equipo en la lista de pendientes. El trabajo del propietario del producto consiste en poner elementos en la lista de pendientes. El trabajo de un miembro del equipo consiste en tomarlos y hacerlos uno por uno. El trabajo del maestro de Scrum consiste en asegurarse de que esto se haga más rápido. Además, el control ágil del progreso necesita elementos pequeños de la lista de pendientes que puedan realizarse en unos pocos días. Los expertos también recomiendan definir con precisión los criterios de aceptación antes de la iteración. Los miembros del equipo reciben pequeños fragmentos definidos con precisión para entregar. Informan a diario de cuánto tiempo necesitan todavía para terminarlos. La velocidad indica a todos qué tan bien se desempeñan. Los microgestores se regocijan y controlan cada minuto: falta de control, ausencia de espacio creativo, presión para ir más rápido: una carrera de ratas.

Dada esta situación, aparentemente tan tensa, ¿importa si el producto es excelente para los usuarios? Claro que no, ese es el trabajo del equipo de UX. ¿Importa si tiene sentido? Es trabajo del propietario del producto. ¿Importa si los criterios de aceptación están completos? De nuevo, es trabajo del propietario del producto. ¿Es importante que no haya errores? Es trabajo del probador, una vez superados los criterios de aceptación. ¿Qué importa entonces? Que termine a tiempo mi elemento de la lista de pendientes. ¿Ves la posición de Alan? Scrum lleva a los equipos a implementar todas las funcionalidades. La calidad es responsabilidad de Alan. Se infringe la regla fundamental y las cosas empeoran.

El equipo de Alan también obedece al compromiso. Llenan la iteración con tantos elementos de la lista de pendientes como indica la velocidad. Después juran entregarlos. La siguiente ley fundamental los golpea: suceden cosas imprevistas. En lugar de romper el juramento, el equipo toma atajos y recorta algunas partes de las pruebas. ¡Terminado a tiempo, bien hecho! Uno de los entrevistados lo explicó con bastante claridad: «La gamificación de comprometerse con un número de puntos de historia crea una competencia poco saludable».

El equipo de Alan ha caído en la trampa ágil. Aplican Scrum sin ser ágiles. Compara las dos imágenes siguientes: la primera muestra de qué trata Scrum y la segunda muestra de qué trata realmente lo ágil.

Scrum trata del proceso de convertir los elementos de la lista de pendientes en un producto.

Lo ágil trata de crear un impacto con un producto y de las interacciones de las personas implicadas: quienes encargan un producto, quienes lo utilizan y quienes lo crean.

¡Aunque Scrum es una excelente herramienta para equipos ágiles motivados intrínsecamente, resulta fatal en una jerarquía de mando descendente!

Conclusiones

En la industria del software, es importante desarrollar mecanismos de defensa contra el estrés y el agotamiento entre los profesionales de las pruebas de software. En algunas empresas más que en otras. Algunas situaciones son realmente tensas; otras se vuelven tensas a propósito. Pero la mayoría de las situaciones parecen mucho más tensas de lo que son. Y esto nos lleva a seguir nuestros impulsos, dejar de trabajar en los conflictos e ignorar las reglas fundamentales. 

La siguiente tabla resume las ruedas dentadas de un sistema de agotamiento.

Elementos clave de un sistema de agotamiento

• Percepción de tensión es la brecha entre lo que consideramos nuestra tarea y lo que podemos entregar. Descubrir cuál es realmente el mejor objetivo que alcanzar puede desmantelar el sistema de agotamiento.
• Los impulsos definen hacia dónde fluye la energía y nos impiden actuar con sensatez en una situación tensa. Descubrir cuáles son nuestros impulsos puede ayudarnos a gastar menos energía y emplearla con mayor sensatez.
• Los conflictos intensifican la situación, hacen que un equipo sea menos eficaz y agotan la energía. Creemos una cultura de equipo en la que demos la bienvenida a los conflictos y nos ayudemos mutuamente.
• Las reglas fundamentales se ignoran fácilmente. Ver que se ignoran es una señal segura de que las cosas empeorarán. ¡Debemos actuar!
• La estructura del equipo congela las buenas y malas prácticas. Cambiar las estructuras de los equipos puede modificar fundamentalmente quién hace qué y cómo interactúan las personas. Puede cambiar por completo las reglas del juego.
• Los ciclos viciosos surgen de la interacción de los actores dentro y alrededor del equipo, y hacen que la situación empeore cada vez más. ¿Podemos identificar los ciclos viciosos que nos atraparon? ¡Tenemos que detenerlos y corregirlos!
• La trampa ágil consiste en adoptar marcos ágiles sin ser ágiles. El resultado es una carrera de ratas. Centrémonos en los usuarios, en crear un producto excelente y en cómo interactuamos, en lugar de consumirnos eliminando elementos de la lista de pendientes.

Como profesional de QA, quizá no estés en posición de cambiar la situación general para mejor. Pero probablemente sí puedas reducir parte del estrés. 

Le pregunté a Jonathon Wright: «¿Dónde has visto que empresas o equipos tomen medidas para promover la salud mental entre los profesionales de QA? ¿Qué funciona?»

Él respondió: 

“Después de pasar el último año ayudando al Gobierno del Reino Unido a prepararse para el Brexit, me impresionó muchísimo la ética de trabajo. Asistí a mi primer curso obligatorio de atención plena, que fue extremadamente útil; tenían especialistas en salud mental en el lugar e incluso grupos de apoyo que se reunían semanalmente.”

También señaló que los profesionales de QA pueden hacer mucho para gestionar su estrés y ansiedad a nivel personal:

“La vida es demasiado corta para preocuparse por las cosas pequeñas. Es difícil para los profesionales de QA no preocuparse antes del lanzamiento importante de un producto nuevo o no sentirse responsables de cualquier resultado. Pero, como en el Episodio II con Parveen, a veces solo tienes que ‘dejarlo ir, dejarlo ir’ y no ‘mantener la calma’”.

Jonathon Wright, presentador del pódcast El líder de QA

"Como alguien que ha gestionado la ansiedad durante toda su carrera profesional, esta ha tenido sus dificultades y desafíos, pero siempre he salido del otro lado más fuerte y en una mejor posición para gestionar mejor mi ansiedad, aprendiendo más sobre mí mismo cada vez. La industria sí atrae a personas que se encuentran en distintos grados del espectro (y yo me incluyo). Sin embargo, las personas más talentosas con las que he tenido la oportunidad de trabajar han sufrido enfermedades mentales, por lo que trato mi enfermedad mental como un superpoder!”

Como señaló Jonathon, con un poco de suerte y la actitud adecuada, puedes convertir un trabajo estresante en uno gratificante. Te animo a adoptar el punto de vista que ofrece el concepto de un sistema de agotamiento. Deja ir tu ansiedad y mantén la calma. Después, mira más allá de los mandamientos, los procesos y las herramientas. Concéntrate en lo que realmente importa: cómo tú y tus compañeros de equipo se ayudan mutuamente a crear productos excelentes.