Burnout nel collaudo software: 6 cause e come risolverlo
È possibile creare una situazione in un team di sviluppo software in cui un tester sia molto probabilmente destinato a sperimentare il burnout?
Se sì, cosa possono imparare i tester da questo esperimento mentale?
Si scopre che il burnout tra i professionisti del testing software non è solo un esperimento teorico nel settore, ma un problema reale e pervasivo che colpisce molti sviluppatori, ingegneri e tester.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
Ho approfondito la questione del burnout nel testing software, chiedendomi:
- Come si manifesta il burnout in questo settore?
- Quanto è grave il problema?
- Cosa crea sistemi in cui i tester software arrivano al burnout?
- Come possiamo scomporre il problema del burnout—e risolverlo?
Le risposte—o almeno il loro inizio—sono qui in questo articolo.
Burnout tra i professionisti del testing software nell’IT
Lo stress legato al lavoro è qualcosa che molti di noi nel settore IT vivono. Sono sicuro che anche tu abbia la tua parte di stress. Nel mio contesto, purtroppo, il burnout è diventato un tema sempre più centrale negli ultimi anni.
Il burnout è un problema?
Quando ho chiesto a Jonathon Wright, “Quanto pensi sia grave il problema del burnout tra i professionisti QA?”, ecco cosa mi ha risposto:
“È un problema enorme. Parole famose: Non si può correre sempre.”
Jonathon Wright, host di The QA Lead Podcast
Ha poi continuato spiegando,
“Metodologie come Agile e DevOps incoraggiano l’idea di fare tutto ancora più ‘velocemente’. Come può un professionista QA fornire valore misurabile in un ambiente dove fallire in fretta e imparare rapidamente è la norma?
In un recente podcast su QALead è emerso il termine 'rallentare per accelerare'. A meno che le aziende non celebrino il fallimento (e pochissime lo fanno), ogni volta che fallisci non stai aiutando la velocità del resto del team.
Il consiglio è già nel titolo dell’abusato grafico Burndown. La gamification dell’impegno verso un certo numero di story points crea competizione malsana.
"Sei costretto a fare di più con meno, lavorando secondo l’aspettativa irrealistica che il lavoro possa essere consegnato in sprint di due settimane."
Jonathon Wright, host di The QA Lead Podcast
Come si manifesta il burnout nella QA?
Il burnout non è un caso isolato nell’industria del software—ma come si presenta?
Ecco alcune risposte da parte di professionisti del testing che mostrano come il burnout si manifesta nella QA.
“Dobbiamo dimostrare il nostro valore. I team mi dicono che loro sono agili, non hanno bisogno di tester.”
“Ansia. È difficile per i professionisti QA non preoccuparsi in vista di un rilascio importante o non sentirsi responsabili degli esiti.”
“Pressione sul tempo. I tester sono sempre gli ultimi. E non ho mai il tempo che mi serve. E viene dimezzato perché gli sviluppatori sforano.”
“Aspettative irrealistiche. Potrei testare all’infinito e non riuscirei mai a testare tutto. Dillo a un responsabile di progetto. A cosa serve un tester che non trova i bug?!”
“Capire cosa testare a partire dagli elementi di backlog è quasi impossibile. E nessuno menziona i casi limite.”
“Lo spreco è frustrante. Gli sviluppatori non riescono a riprodurre un bug, oppure l’item di backlog è ormai superato, o lo hanno già risolto.”
“Molti non vogliono un rapporto onesto e soprattutto non brutte notizie. Se insisti, può diventare personale.”
Perché succede il burnout?
La letteratura elenca molti fattori che causano stress e aumentano la probabilità di burnout. Ci sono fattori individuali, ad esempio, motivazioni personali come essere perfetti, sbrigarsi, provarci a tutti i costi, essere forti o piacere agli altri. Per maggiori dettagli cerca l’analisi transazionale.
E ci sono fattori di stress che vengono dall’ambiente lavorativo. Carico di lavoro elevato, pressione sui tempi, obiettivi e aspettative irraggiungibili, mancanza di controllo, conflitti accesi, paura di perdere il lavoro, insoddisfazione lavorativa, bullismo, mobbing, e altro ancora. Li conosciamo bene.
Qualche tempo fa ho iniziato a guardare al burnout da un punto di vista sistemico e ho creato un gioco di simulazione in cui i giocatori possono influenzare la fortuna di un team di sviluppo software. Possono portare i membri del team al burnout oppure creare il progetto più gratificante di sempre.
Il cuore della simulazione è un sistema di burnout, cioè un sistema impostato in modo tale che alcuni membri di un team finiranno per andare in burnout. Puoi dare un'occhiata al gioco sul mio blog.
Questo approccio sistemico funziona anche per diversi ruoli in un team. L'ho fatto per i professionisti dell'esperienza utente e sono rimasto sorpreso da quanto sia facile mettere queste persone nel punto critico di un sistema di burnout. Soprattutto quando si prendono cura degli utenti, sono disposti a lottare ancora di più e a rischiare di crollare.
Di seguito, approfondirò una storia di Alan, un professionista QA, per capire e illustrare meglio il problema del burnout nell'industria del software.
Successivamente, parlerò di come vengono creati i sistemi di burnout e di cosa possiamo fare per migliorare questi sistemi.
Una storia personale di burnout
Ora che sono certo di poter creare un sistema di burnout per i professionisti QA, lascia che ti presenti Alan e la sua storia.
Alan ha quasi un decennio di esperienza nel testing del software, soprattutto nei test sulle performance. Sta per unirsi a un team di sviluppo. Il team lavora da dieci sprint e ne rimangono altri quattro prima della prima release.
Com'è stata la prima giornata di Alan nel progetto?
Alan: Ho moltissimo da fare. Il software è di bassa qualità. Mi aspetto molti bug non rilevati e temo problemi se non riuscirò a trovarli prima della release.
Markus: Quindi identificare i bug è la tua priorità per migliorare la qualità?
Alan: Questo è solo un aspetto. Prevediamo anche molti utenti. Le prestazioni del software sono fondamentali quando lo lanceremo al grande pubblico. Il team è impaziente di trarre vantaggio dalla mia esperienza in questo campo.
Per ora, Alan è abbastanza ottimista che le misure concordate con il team miglioreranno la qualità del software. Purtroppo, uno sprint dopo, con tre sprint rimanenti, Alan non appare più così sereno.
Qual è il problema?
Alan: Le ultime due settimane sono state intense. Non sono soddisfatto dei miei progressi. Volevo avere un primo, semplice test sulle performance, ma sono lontano dall'averlo pronto.
Markus: Cosa ti ostacola?
Alan: Ho bisogno del supporto degli sviluppatori, ma sono sovraccarichi. Ho impiegato anche molto più tempo del previsto per capire il software e segnalare i bug che ho trovato.
Markus: Sei riuscito a testare le nuove storie consegnate dal team?
Alan: Non proprio, il team era occupato a rifinirle. Dei due giorni riservati ai test a fine sprint è rimasta solo mezza giornata. Sono rimasto più a lungo e ho lavorato anche sabato, ma sono ancora lontano dal finire.
Nella retrospettiva del dodicesimo sprint, con solo due sprint rimanenti, il testing diventa il tema principale: il product owner si lamenta per il numero di bug trovati da Alan.
Sviluppatore: La maggior parte dei bug trovati da Alan sono insignificanti o non sono nemmeno bug. Rivediamoli prima di trarre conclusioni affrettate.
Alan: Beh, mi è stato difficile capire cosa dovrebbe fare il software partendo dagli item del backlog. Una specifica aiuterebbe davvero.
Sviluppatore: Finché ci sono io, mai! Non vogliamo un approccio a cascata. È per lo più buon senso. Vieni semplicemente a chiederci. Come procede il testing delle performance?
Alan: Sono bloccato. Non riesco a far girare lo strumento contro il servizio con tutta quella sicurezza. Mi serve aiuto.
Sviluppatore: Nell'ultimo progetto abbiamo usato un altro tool. Funzionava benissimo. Ti mando il link.
Come risultato, il PO organizza una riunione di due ore nel prossimo sprint. L'obiettivo è rivedere i bug e discutere cosa annotare nei backlog item per facilitare le cose al nuovo arrivato Alan. Riesci a percepire la frustrazione crescente di Alan?
La posizione fatale di Alan come capro espiatorio diventa ancora più evidente dopo lo sprint tredici, con un solo sprint rimanente. Ecco le decisioni emerse da questa retrospettiva:
- Molti bug trovati nelle storie che Alan avrebbe dovuto testare nello sprint precedente. Nessuna storia può essere chiusa senza il test di Alan.
- Ancora nessun test sulle performance. Un esperto ci darà un'occhiata. Alan dovrà aggiornarlo.
- Non sono state completate due storie. Abbiamo perso due giorni a scartare segnalazioni inutili di bug. Alan dovrà segnalare la rilevanza di ogni bug. In caso di dubbio, chiedere al product owner.
Te ne sei accorto? Il team non ha completato due storie e ha scaricato la colpa su Alan!
Immagina la prossima sprint, quando le storie non vengono chiuse perché Alan non ha avuto il tempo di testarle! Non c'è da meravigliarsi se Alan sembra esausto.
Alan: Solo due settimane al rilascio e la qualità è un incubo. Dillo tu al product owner! E hanno anche tolto il performance testing. Era proprio questa la ragione per cui sono entrato nel progetto. Il mio capo è insoddisfatto. Voleva che fossi d’esempio su come includere i tester nei team agili. Dovrò lottare però, la mia reputazione in azienda è in gioco.
Quattro settimane dopo, due settimane dopo il primo rilascio a un pubblico selezionato, il sistema di burnout è pienamente operativo.
Il riepilogo di Alan sui suoi risultati finora:
- Performance Testing: fallito
- Essere riconosciuto come esperto di performance testing: fallito
- Essere in grado di testare a fondo le nuove funzionalità sviluppate: fallito
- Essere in grado di ritestare a fondo ciò che era già stato realizzato: fallito
- Includere i tester nei team agili: fallito
- Assenza di bug critici nel rilascio: fallito
- Essere raccomandato: fallito
- Lavorare sodo e ricevere la colpa: raggiunto
- Paura di perdere il lavoro: raggiunto
- Burn out: ci sto arrivando a tutta velocità
Questo è un classico esempio di sistema di burnout. Ma cosa genera questo sistema, e come possiamo contrastarlo?
Cosa Crea un Sistema di Burnout?
Per Alan, si potrebbe dire che sia una causa persa fin dall’inizio. E avresti ragione. Alan si trova in un sistema di burnout che condiziona il team già da un po’ di tempo. Il sistema di burnout identifica Alan come un predatore fa con la sua preda. Ma che cos’è questo sistema di burnout e come agisce?
Un sistema di burnout è una combinazione di persone, motivazioni e conflitti. Attraverso un ciclo che si autoalimenta, crea una situazione talmente carica di fattori di stress che alcune persone prima o poi si esauriranno. È particolarmente potente quando riesce a innescare la logica di sopravvivenza delle persone.
1. L’energia Segue le Motivazioni
Nella storia di Alan, possiamo individuare alcune motivazioni:
- Ambizione e passione per il tema del performance testing portano Alan a volerlo fare.
- L’ansia di essere responsabile di un rilascio fallito spinge Alan a cacciare bug.
- Qualcosa spinge i membri del team a costruire funzionalità prima di tutto il resto.
Le motivazioni cambiano il corso delle azioni. Le persone fanno davvero fatica a riflettere lucidamente su cosa raggiungere e come farlo. L’energia che investono segue la motivazione, non dove servirebbe di più. Il team di Alan non si chiede mai se costruire tutte le funzionalità sia la cosa giusta da fare. Né Alan si chiede se cacciare bug sia appropriato.
La cosa difficile per molti di noi è accorgersi che una motivazione ha preso il controllo. Per fortuna gli psicologi le hanno studiate. Per le motivazioni personali, puoi partire dall’analisi transazionale. A livello di team, il groupthink è un buon punto di partenza. Puoi trovare moltissimi consigli a riguardo.
Riguardo all’ansia che precede un rilascio, uno degli esperti QA ha consigliato: “Devi solo lasciar perdere e restare tranquillo”. Con un atteggiamento simile dall’inizio, probabilmente Alan avrebbe perseguito uno scopo diverso rispetto a cacciare tutti i bug e impostare il performance testing. Le priorità principali potrebbero essere che il team elimini i bug critici e garantisca in generale una qualità più alta. Un modo per ridurre lo stress associato alle attività ripetitive è sfruttare i migliori strumenti pensati per il software testing.
2. I Conflitti si Accendono e si Fanno Personali
Insieme alle motivazioni, nel team si accendono conflitti. Ad esempio, Alan ha bisogno di più tempo dai developer di quello che sono disposti a concedere. Risultato: Alan fa molto rumore e gli sviluppatori cercano di tenerlo lontano. Con poco aiuto, Alan non può soddisfare le aspettative. Teme per la sua reputazione, raddoppia gli sforzi, e genera ancora più rumore.
La cosa davvero negativa è che i conflitti diventano personali. Dopo dieci anni come tester, Alan probabilmente è un vero esperto. Eppure il team lo vede come un peso e si comporta di conseguenza. Più a lungo dura, più si inasprisce. Questo colpisce anche Alan: inizia a dubitare della propria competenza.
Quante volte hai dato la colpa a qualcuno? Quante persone attorno a te non stanno facendo un buon lavoro? Ogni pensiero di questo tipo indica un conflitto diventato personale.
La maggior parte dei team non è in grado di risolvere i conflitti. Non è una cosa semplice. Conflict management è la parola chiave per trovare consigli. Il messaggio fondamentale: i team hanno bisogno di una cultura dove le idee possano essere scambiate apertamente, i punti di vista divergenti siano accolti come opportunità per creare novità, e darsi una mano sia apprezzato. Una sfida ardua, se confrontata con la cultura della velocità che un intervistato descrive così: “A meno che le aziende non celebrino il fallimento, ogni volta che sbagli non aiuti la velocità del team”.
3. La Struttura del Team Influenza le Dinamiche di Gruppo
Il team di Alan ha riservato gli ultimi due giorni dello sprint per i test, la chiusura dello sprint e la preparazione del prossimo sprint. Il team semplicemente presumeva che Alan seguisse questa struttura. Lui avrebbe testato le nuove funzioni implementate alla fine dello sprint e avrebbe effettuato alcuni retest nello sprint successivo, oltre a migliorare i test in generale. Non sembra male, vero?
La realtà racconta un'altra storia. Il software è disponibile solo l'ultimo giorno dello sprint. Gli elementi del backlog aiutano poco a capire come dovrebbe funzionare esattamente. Mentre il team discute i dettagli di cosa faranno nello sprint successivo, Alan cerca di capire cosa testare di questo sprint. Poi fa domande proprio prima che gli sviluppatori se ne vadano e testa durante il fine settimana. Fantastico che il team discuta cosa annotare. Così Alan può testare senza disturbare gli sviluppatori. Bingo.
La struttura del team isola sempre di più Alan. Il team non si accorge delle sue difficoltà. Notano solo domande stupide e risultati in ritardo con poco valore. Che papera zoppa.
La specifica tramite esempi mostra abbastanza chiaramente come i test e i tester possano essere parte integrante di un team agile. I tester partecipano alle refinement, aiutano a creare una specifica testabile, focalizzano gli sforzi di testing dove serve, migliorano i processi di team, le competenze individuali, gli strumenti, e fanno persino alcuni dei test. Il testing avviene in maniera continua, non solo alla fine dello sprint.
4. Ignora le Regole Fondamentali e Vai in Contro ai Problemi
Il team di Alan ignora le regole fondamentali dell’ingegneria del software.
Ecco cinque di queste regole:
- Capitano imprevisti. Non lasciare abbastanza margine per essi porta a correre, prendere scorciatoie, fare errori stupidi, creare conflitti accesi e quindi a un progresso più lento alla lunga.
- La pressione rallenta. La pressione riduce lo spazio per gestire gli imprevisti.
- La qualità è emergente. Il team deve avere una cultura della qualità. Il testing è solo una parte del puzzle. E un unico membro del team da solo contro tutti solitamente fallisce.
- Cambiare il team rallenta. Costruire fiducia, adattare i processi, risolvere più conflitti: il team ha bisogno di tempo ed energia per integrare nuovi membri. Aggiungendo persone a un progetto già in ritardo, i ritardi aumentano.
- I difetti sono fonti di apprendimento. Quando un processo produce troppi difetti, fermalo, correggilo e impara. Non incolpare e, soprattutto, non velocizzare.
Ci sono molte altre regole simili e ogni volta che vengono ignorate, le cose peggiorano. Ed è successo anche ad Alan.
5. Una Situazione Stretta Percepita La Fa Scattare
Come mai il team ignora cose così fondamentali? Facile. Tipico di una situazione stretta in cui i dati fissi (deliverable, tempo disponibile e team) non lasciano abbastanza flessibilità per gestire l’imprevisto. Ci sono passato, lo conosco bene. I sistemi "burnout" sfruttano l’unica variabile in una situazione bloccata: quanto lavora sodo il team, cioè quanta energia i membri consumano dalle proprie batterie.
La domanda chiave: il team di Alan è davvero in una situazione stretta e consegnare tutte le funzionalità è davvero la strada migliore? Possiamo solo supporre. Anche il team ha fatto così ed è partito di corsa per tentare di costruire tutte le funzionalità.
È la percezione di una situazione stretta che conta. Il fattore scatenante può essere una clausola contrattuale, un incentivo, una grande opportunità di mercato, una richiesta forte di un capo, una promessa fatta, il desiderio di un cliente, una normativa di legge.
Alan si aspetta una marea di bug e l’ansia lo porta a cacciarli. La domanda chiave per lui: trovare i bug è davvero un passaggio così importante in questo caso? Possiamo solo ipotizzare, e così ha fatto Alan. Ha presunto di sì.
La percezione di una situazione stretta è una leva importante per spezzare un sistema burnout. Dietro c’è un'altra regola fondamentale dell’ingegneria del software:
- Aspettative troppo alte. Gli stakeholder, inclusi gli sviluppatori stessi, sperano, si aspettano o pretendono più di quanto un team software possa realisticamente consegnare.
Guardando agli ultimi 25 anni della mia esperienza di progetto, non ricordo un solo progetto in cui non fosse così. Il conflitto tra ciò che ci si aspetta e ciò che è possibile consegnare è il punto caldo. Il successo di un progetto dipende da quanto bene chi è coinvolto riesce a risolvere questo conflitto. Raccomanderei di rivedere le buone pratiche sulla gestione degli stakeholder e delle aspettative, la gestione dei conflitti, il requirements engineering, l’agilità e simili.
In ogni caso, la cosa da fare è capire la natura esatta del conflitto. Quanto è forte? Cosa lo guida? Con chi bisogna lavorare? O, come ha detto uno dei QA intervistati: “Credo che ogni azienda debba prendere una decisione consapevole riguardo a qualità, costo e velocità”. Ogni azienda deve lavorare sulle proprie aspettative.
I professionisti QA di solito non sono nella posizione di guidare questa discussione. Possono provare a contribuire. Potrebbe essere più fruttuoso gestire le aspettative che si trovano a dover affrontare personalmente. Una delle intervistate mi ha raccontato la sua ricetta: “Impossibile testare tutto. La cosa migliore è definire un time box e le priorità col product owner. Le priorità riflettono il rischio di non testare. Se non si è soddisfatti, si rinegozia time box e priorità.”
6. Trappola Agile
Un team forte che si adatta continuamente ai bisogni che cambiano, un approccio non burocratico al cambiamento, strumenti semplici per la pianificazione e il controllo dei progressi: il movimento agile ha portato molte innovazioni da cui i team di sviluppo farebbero bene a trarre vantaggio. Eppure l’agile sembra esasperare questo aspetto.
Tutto parte dal nome: Sprint significa veloce, velocity significa veloce, si fallisce velocemente. I principi agili mettono il codice al primo posto, mentre il pensare in anticipo viene spesso liquidato come un’inutile perdita di tempo. Anche il termine scrum viene dal rugby, uno sport in cui gli atleti si affrontano a tutta velocità. Così l’agilità, anche contro le intenzioni, finisce per favorire la velocità rispetto alla qualità. “Le metodologie come Agile e DevOps incoraggiano l’idea di fare tutto ancora più in fretta”, si è lamentato un professionista del QA.
Le meccaniche di, ad esempio, scrum sono perfino peggiori dei nomi. Non è che chi ha creato Scrum volesse favorire il burnout. Ma scrum porta i team fuori strada.
Per cominciare, mette al centro l’attenzione della squadra sul backlog. Il compito del product owner è inserire cose nel backlog. Il compito di un membro del team è prenderle e farle una alla volta. Il compito dello scrum master è fare in modo che si proceda sempre più velocemente. Inoltre, il controllo dei progressi agile richiede che gli elementi del backlog siano piccoli e facilmente completabili in pochi giorni. I guru raccomandano anche criteri di accettazione definiti in dettaglio prima dello sprint. Ai membri del team vengono affidati compiti molto definiti e piccoli da consegnare. Ogni giorno devono riferire quanto tempo manca al completamento. La velocity dice a tutti quanto stanno performando. I micro-manager esultano controllando ogni minuto: mancanza di controllo, nessuno spazio creativo, pressione a fare più in fretta: una corsa al ribasso.
In questa situazione apparentemente stretta, importa se il prodotto è davvero utile agli utenti? Assolutamente no, questo è compito del team UX. Importa se ha senso? Compito del product owner. Sono importanti criteri di accettazione completi? Di nuovo, competenza del product owner. L’assenza di bug è importante? È affare del tester, dopo che i criteri di accettazione sono stati superati. Cosa conta davvero? Che io chiuda il mio compito in tempo. Capite la posizione di Alan? Scrum porta i team a fare tutte le funzionalità. La qualità è compito di Alan. La regola fondamentale viene violata e la situazione peggiora.
Il team di Alan rispetta anche il commitment. Riempiono lo sprint con tutti i backlog item consentiti dalla velocity. Poi fanno un vero e proprio giuramento di consegnare quei risultati. La successiva legge fondamentale li colpisce: succedono imprevisti. Invece di rompere il giuramento, il team sceglie scorciatoie togliendo magari qualcosa ai test. Compito chiuso in tempo, ben fatto! Un intervistato lo ha dichiarato apertamente: “La gamification dell’impegno su un certo numero di story point crea una competizione malsana.”
Il team di Alan è caduto nella trappola agile. Applicano Scrum senza essere agili. Confronta le seguenti due immagini: la prima riguarda Scrum, la seconda è ciò che significa veramente essere agili.
Scrum riguarda il processo per trasformare gli elementi del backlog in un prodotto.
Agile riguarda il creare un impatto con un prodotto e le interazioni tra le persone coinvolte: chi ordina un prodotto, chi lo usa e chi lo crea.
Se Scrum è uno strumento potente per team agili e motivati dall’interno, può essere disastroso in una gerarchia di comando top-down!
Conclusioni
Nell’industria del software è importante sviluppare meccanismi di difesa contro stress e burnout tra i professionisti del testing. In alcune aziende più che in altre. Alcune situazioni sono davvero strette, altre vengono rese artificialmente strette. Ma la maggior parte delle situazioni sembra molto più critica di quanto sia in realtà. Questo ci porta a seguire i nostri driver, smettere di lavorare sui conflitti e ignorare le regole fondamentali.
La tabella seguente riassume gli ingranaggi di un sistema di burnout.
Elementi Chiave di un Sistema di Burnout
- Stretta percepita è la distanza tra ciò che ci sembra il nostro compito e ciò che possiamo davvero consegnare. Scoprire cosa sia davvero meglio ottenere può smontare il sistema di burnout.
- Driver definiscono dove va l’energia e ci impediscono di agire saggiamente in una situazione difficile. Scoprire quali sono i nostri driver ci aiuta a risparmiare energia e usarla meglio.
- Conflitti peggiorano la situazione, rendono il team meno efficace e prosciugano energia. Costruiamo una cultura di team in cui i conflitti vengano accolti e sia normale aiutarsi.
- Regole fondamentali sono facilmente ignorate. Vederle trascurate indica che le cose peggioreranno. Dobbiamo intervenire!
- Struttura del team cementa buone e cattive pratiche. Cambiare la struttura può cambiare fondamentalmente chi fa cosa e come le persone interagiscono. Può cambiare completamente le regole del gioco.
- Cicli viziosi nascono dall’interazione tra gli attori dentro e intorno al team e peggiorano sempre più la situazione. Riusciamo a individuare i cicli viziosi in cui ci siamo impantanati? Dobbiamo fermarli e correggerli!
- Trappola agile significa adottare framework agili senza essere davvero agili. Il risultato è una corsa forsennata. Concentriamoci sugli utenti, sul creare un ottimo prodotto e sulle interazioni, invece di bruciare task dal backlog.
Come professionista del QA, potresti non essere in posizione di cambiare completamente la situazione. Ma probabilmente puoi ridurre un po’ di stress.
Ho chiesto a Jonathon Wright: “Dove hai visto aziende o team prendere iniziative per promuovere il benessere mentale tra i professionisti QA? Cosa funziona davvero?”
Ha risposto,
“Dopo aver trascorso l’ultimo anno aiutando il Governo del Regno Unito a prepararsi per la Brexit, sono rimasto estremamente colpito dall’etica del lavoro. Ho partecipato al mio primo corso obbligatorio di consapevolezza, che è stato estremamente utile; c’erano specialisti della salute mentale in sede e perfino gruppi di supporto che si riunivano settimanalmente.”
Ha anche fatto notare che i QA possono fare molto per gestire lo stress e l’ansia a livello personale:
“La vita è troppo breve per preoccuparsi delle piccole cose. È difficile per i professionisti QA non preoccuparsi prima di un importante rilascio di un nuovo prodotto o non sentirsi responsabili degli eventuali risultati. Ma come nell’Episodio II con Parveen, a volte bisogna semplicemente ‘lasciar andare, lasciar andare’ e non ‘mantenere la calma’.”
Jonathon Wright, conduttore del podcast The QA Lead
"Essendo una persona che ha gestito l’ansia durante tutta la sua carriera professionale, ci sono stati ostacoli e sfide, ma ne sono sempre uscito più forte e in una posizione migliore per gestire la mia ansia, imparando ogni volta qualcosa in più su me stesso. Il settore attrae persone che si trovano a diversi livelli dello spettro (mi includo anch’io). Tuttavia, le persone più talentuose con cui ho avuto l’opportunità di lavorare hanno sofferto di problemi di salute mentale, ed è per questo che considero la mia malattia mentale un superpotere!”
Come ha sottolineato Jonathon, con un po’ di fortuna e l’atteggiamento giusto, un lavoro stressante può diventare gratificante. Ti invito a prendere in considerazione la prospettiva offerta dal concetto di sistema di burnout. Lascia andare l’ansia, mantieni la calma. Poi guarda oltre i comandamenti, i processi e gli strumenti. Concentrati su ciò che conta davvero: come tu e i tuoi colleghi vi aiutate a vicenda per creare ottimi prodotti.
