Esaurimento dei professionisti dei test del software: 6 cause & come risolverlo

Ho approfondito il problema dell'esaurimento professionale nel collaudo del software, chiedendomi:

• Che aspetto ha l'esaurimento professionale in questo settore?
• Quanto è grande il problema?
• Che cosa crea sistemi in cui i collaudatori di software vanno incontro all'esaurimento professionale?
• Come possiamo scomporre il problema dell'esaurimento professionale e risolverlo?

Le risposte, o almeno il loro inizio, si trovano in questo articolo.

L'esaurimento professionale tra i professionisti del collaudo del software nell'IT 

La tensione legata al luogo di lavoro è qualcosa che molti di noi nel settore IT sperimentano. Sono certo che anche tu abbia la tua parte di tensione. Nel mio contesto, purtroppo, l'esaurimento professionale è diventato un tema sempre più rilevante negli ultimi anni.

L'esaurimento professionale è un problema?

Quando ho chiesto a Jonathon Wright: «Quanto pensa sia grande il problema dell'esaurimento professionale tra i professionisti del controllo qualità?», questa è stata la sua risposta:

«È un problema enorme. Parole famose: non puoi correre a tutta velocità per sempre.»

Jonathon Wright, conduttore del podcast The QA Lead

Ha proseguito spiegando:

«Metodologie come Agile e DevOps incoraggiano l'idea di fare tutto ancora “più velocemente”. Come può un professionista del controllo qualità fornire un valore misurabile in un contesto in cui bisogna fallire rapidamente e imparare velocemente?

In un recente podcast su QALead è emerso il concetto di “rallentare per accelerare”. A meno che le aziende non celebrino il fallimento (e sono davvero poche a farlo), ogni volta che fallisci non stai aiutando la velocità del resto del team. 

Il suggerimento è nel titolo del fin troppo utilizzato grafico di riduzione del lavoro. La ludicizzazione dell'impegno a raggiungere un certo numero di punti storia crea una competizione malsana.

«Sei costretto a fare di più con meno risorse, lavorando secondo un'aspettativa irrealistica secondo cui il lavoro può essere consegnato in iterazioni di due settimane.»

Jonathon Wright, conduttore del podcast The QA Lead

Che aspetto ha l'esaurimento professionale nel controllo qualità?

L'esaurimento professionale non è un caso isolato nel settore del software, ma che aspetto ha?

Ecco le risposte di alcuni professionisti del collaudo del software, che mostrano come si manifesta l'esaurimento professionale nel controllo qualità.

«Dobbiamo dimostrare il nostro valore. I team mi dicono che sono agili e non hanno bisogno di collaudatori.»

«Ansia. Per i professionisti del controllo qualità è difficile non preoccuparsi prima di un rilascio importante o non sentirsi responsabili di qualsiasi risultato.»

«Pressione del tempo. I collaudatori sono sempre gli ultimi. E non ottengo mai il tempo di cui ho bisogno. Inoltre, si dimezza perché gli sviluppatori sforano i tempi.»

«Aspettative irrealistiche. Potrei collaudare per sempre e non riuscirei comunque a collaudare tutto. Prova a dirlo a un responsabile di progetto. A cosa serve un collaudatore che non trova gli errori?!»

«Capire dagli elementi dell'arretrato cosa collaudare è quasi impossibile. E nessuno menziona i casi limite.»

«Lo spreco è frustrante. Gli sviluppatori non riescono a riprodurre un errore, oppure l'elemento dell'arretrato è obsoleto, oppure lo hanno già risolto.»

«Molti non vogliono un rapporto onesto e soprattutto non vogliono cattive notizie. Quando insisti, la questione può diventare personale.»

UNISCITI ALLA COMUNITÀ

Arricchisci la tua casella di posta con più saggezza sulla leadership tecnologica per offrire software e sistemi migliori.

Get Free Access

Have an account? Log In

Perché si verifica l'esaurimento professionale?

La letteratura elenca molti fattori che causano tensione e aumentano la probabilità di esaurimento professionale. Esistono fattori individuali, per esempio spinte personali come essere perfetti, affrettarsi, impegnarsi al massimo, essere forti o compiacere gli altri. Per ulteriori dettagli, consulta l'analisi transazionale. 

Esistono poi fattori di tensione derivanti dall'ambiente di lavoro: carico di lavoro elevato, pressione del tempo, obiettivi e aspettative irraggiungibili, mancanza di controllo, conflitti accesi, paura di perdere il lavoro, insoddisfazione professionale, bullismo e mobbing, e molto altro. Li conosciamo.

Qualche tempo fa ho iniziato a esaminare il burnout da un punto di vista sistemico e ho creato un gioco di simulazione in cui i giocatori possono influenzare il destino 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 configurato in modo tale che alcuni membri di un team finiscano per esaurirsi. Puoi dare un'occhiata al gioco sul mio blog.

Questo approccio sistemico funziona anche per ruoli diversi all'interno di un team. Ho fatto lo stesso per i professionisti dell'esperienza utente e sono rimasto sorpreso da quanto sia facile spingere queste persone nel punto critico di un sistema di burnout. Soprattutto quando si prendono cura degli utenti, sono disposti ad affrontare una sfida in più e a rischiare di crollare.

Di seguito analizzerò una storia raccontata da Alan, un professionista QA, per comprendere e illustrare meglio il problema del burnout nel settore del software. 

Parlerò poi di come vengono creati i sistemi di burnout e di cosa possiamo fare per migliorare questi sistemi.

Una storia personale sul burnout

Ora che ho la certezza di poter creare un sistema di burnout per i professionisti QA, permettetemi di presentarvi Alan e la sua storia. 

Alan ha quasi dieci anni di esperienza nel testing del software, in particolare nei test delle prestazioni. Sta per unirsi a un team di sviluppo. Il team ha lavorato per dieci sprint e ne restano altri quattro prima del primo rilascio. 

Com'è stato il primo giorno di Alan nel progetto?

Alan: Ho molto da fare. Il software è di bassa qualità. Mi aspetto molti bug non rilevati e temo che ci saranno problemi se non riuscirò a trovarli prima del rilascio.

Markus: Quindi identificare i bug è la tua priorità principale per migliorare la qualità?

Alan: È una parte del lavoro. Ci aspettiamo anche molti utenti. Le prestazioni del software saranno della massima importanza quando lo renderemo disponibile al pubblico più ampio. Il team è ansioso di trarre vantaggio dalla mia esperienza in questo ambito.

Finora Alan è piuttosto ottimista sul fatto che le misure concordate con il team miglioreranno la qualità del software. Purtroppo, uno sprint dopo, con tre sprint ancora da completare, Alan non sembra più così allegro. 

Qual è il problema?

Alan: Le due settimane sono state intense. Non sono soddisfatto dei miei progressi. Volevo realizzare un primo, semplice test delle prestazioni, ma sono ben lontano dal riuscirci.

Markus: Cosa ti ostacola?

Alan: Ho bisogno del supporto degli sviluppatori, ma sono oberati di lavoro. Inoltre, ho avuto bisogno di molto più tempo del previsto per conoscere 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 impegnato a perfezionarle. Dei due giorni riservati ai test alla fine dello sprint è rimasta solo mezza giornata. Sono rimasto più a lungo e ho lavorato anche sabato, ma sono ben lontano dall'aver finito.

Nella retrospettiva dello sprint dodici, con solo due sprint ancora da completare, il testing è l'argomento principale: il product owner si è lamentato del numero di bug trovati da Alan.

Sviluppatore: La maggior parte dei bug trovati da Alan è insignificante oppure non costituisce affatto un bug. Esaminiamoli prima uno per uno, prima di saltare a qualsiasi conclusione.

Alan: Beh, per me è stato difficile capire dai requisiti del backlog cosa avrebbe dovuto fare il software. Una specifica sarebbe davvero utile.

Sviluppatore: Dovrete passare sul mio cadavere! Non vogliamo il modello Waterfall. È soprattutto una questione di buon senso. Vieni semplicemente a chiederlo a noi. Come procede il test delle prestazioni?

Alan: Sono a un punto morto. Non riesco a far funzionare lo strumento sul livello dei servizi a causa di tutta questa sicurezza. Ho bisogno di aiuto.

Sviluppatore: Nell'ultimo progetto abbiamo usato un altro strumento. Ha funzionato alla perfezione. Ti manderò il link.

Di conseguenza, il PO organizza una riunione rapida di due ore nello sprint successivo. L'obiettivo è esaminare i bug e discutere cosa annotare negli elementi del backlog per semplificare le cose al nuovo arrivato Alan. Riuscite a percepire la frustrazione crescente di Alan?

La posizione compromessa di Alan come capro espiatorio diventa ancora più evidente dopo lo sprint tredici, con un solo sprint ancora da completare. Ecco le decisioni prese in questa retrospettiva:

• Molti bug sono stati trovati nelle storie che Alan avrebbe dovuto testare nello sprint precedente. Nessuna storia dovrà essere chiusa senza che Alan l'abbia testata.
• Ancora nessun test delle prestazioni. Faremo esaminare la questione a un esperto. Alan dovrà illustrargli la situazione.
• Non siamo riusciti a completare due storie. Abbiamo perso due giorni per scartare segnalazioni di bug inutili. Alan indica la rilevanza di ogni bug. In caso di dubbio, chiedere al product owner.

Te ne sei accorto? Il team non ha terminato due storie ed è riuscito a dare la colpa ad Alan! 

Immagina il prossimo sprint, quando le storie non vengono chiuse perché Alan non ha avuto il tempo di testarle! Non c'è da stupirsi che Alan sembri esausto.

Alan: Mancano solo due settimane al rilascio e la qualità è un incubo. Dillo al product owner! E hanno anche eliminato i test delle prestazioni. Era proprio il motivo per cui avevo aderito al progetto. Il mio capo è scontento. Voleva che dessi l'esempio su come includere i tester nei team agili. Dovrò comunque portare avanti la mia battaglia, perché la mia reputazione in azienda è in gioco.

Quattro settimane dopo, due settimane dopo il primo rilascio a un pubblico selezionato, il sistema di esaurimento è pienamente operativo. 

Il riepilogo dei risultati ottenuti finora da Alan:

• Test delle prestazioni: fallito
• Essere riconosciuto come esperto di test delle prestazioni: fallito
• Essere in grado di testare accuratamente ciò che è stato appena sviluppato: fallito
• Essere in grado di ripetere accuratamente i test su ciò che è già stato sviluppato: fallito
• Includere i tester nei team agili: fallito
• Nessun bug critico nel rilascio: fallito
• Essere raccomandato: fallito
• Lavorare duramente e venire accusato: raggiunto
• Paura di perdere il lavoro: raggiunto
• Esaurimento: ci sta arrivando a tutta velocità

Questo è un caso classico di sistema di esaurimento. Ma cosa crea questo sistema e come possiamo contrastarlo?

Cosa crea un sistema di esaurimento?

Per Alan, si potrebbe dire che è una causa persa fin dall'inizio. E sarebbe vero. Alan si trova in un sistema di esaurimento che opera nel team da parecchio tempo. Il sistema di esaurimento individua in Alan la sua vittima, come un predatore. Ma cos'è questo sistema di esaurimento e come agisce?

Un sistema di esaurimento è una costellazione di persone, motivazioni e conflitti. Attraverso un ciclo di rinforzo, crea una situazione così piena di fattori di stress che alla fine alcune persone si esauriranno. È particolarmente potente quando riesce ad attivare la logica di sopravvivenza delle persone.

1. L'energia segue le motivazioni

Nella storia di Alan possiamo individuare alcune motivazioni:

• L'ambizione e la passione per il suo argomento preferito, i test delle prestazioni, spingono Alan a occuparsene.
• L'ansia di essere responsabile di un rilascio fallito spinge Alan a cercare i bug.
• Qualcosa spinge i membri del team a sviluppare prima di tutto le funzionalità.

Le motivazioni cambiano il corso delle azioni. Le persone fanno davvero fatica a pensare con chiarezza a cosa raggiungere e a come raggiungerlo. L'energia che le persone investono segue la motivazione, non il punto in cui è maggiormente necessaria. Il team di Alan non si chiede mai se sviluppare tutte le funzionalità sia la cosa giusta da fare. Né Alan si chiede se cercare i bug sia appropriato.

La difficoltà principale per la maggior parte di noi consiste nel diventare consapevoli che una motivazione ha preso il controllo. Per fortuna, gli psicologi le hanno studiate. Per le motivazioni personali, si può iniziare dall'analisi transazionale. A livello di team, il pensiero di gruppo è un buon punto di partenza. È possibile trovare moltissimi consigli al riguardo.

In relazione all'ansia prima di un rilascio, uno dei professionisti QA più esperti ha consigliato: “Devi solo lasciar perdere e stare tranquillo”. Con una simile mentalità fin dall'inizio, probabilmente Alan perseguirebbe un obiettivo diverso dal trovare tutti i bug e imposterebbe i test delle prestazioni. Le priorità principali potrebbero essere la rimozione dei bug critici da parte del team e una qualità generalmente superiore. Un modo per ridurre lo stress associato alle attività ripetitive consiste nell'utilizzare strumenti di alto livello progettati per i test del software.

2. I conflitti alimentano la tensione e diventano personali

Insieme alle motivazioni, nel team divampano i conflitti. Per esempio, Alan ha bisogno di più tempo dagli sviluppatori di quanto loro siano disposti a concedergli. Risultato: Alan crea molto rumore e gli sviluppatori cercano di toglierselo di torno. Rimasto con poco aiuto, Alan non riesce a soddisfare le aspettative. Teme per la propria reputazione, raddoppia gli sforzi e genera ancora più rumore.

La cosa davvero negativa è che i conflitti diventano personali. Avendo lavorato come tester per dieci anni, probabilmente Alan è un vero esperto. Tuttavia, il team lo considera un incapace e si comporta di conseguenza. Più a lungo va avanti, più la situazione si aggrava. Questo influisce persino su Alan: inizia a mettere in discussione le proprie competenze.

Quante volte hai dato la colpa a qualcuno? Quante persone intorno a te non stanno svolgendo bene il proprio lavoro? Ogni pensiero di questo tipo indica un conflitto diventato personale.

La maggior parte dei team non è in grado di risolvere i conflitti. Non è facile. La gestione dei conflitti è la parola chiave per trovare consigli. Il messaggio fondamentale è questo: i team hanno bisogno di una cultura in cui le idee possano essere scambiate apertamente, i punti di vista divergenti siano accolti come opportunità per creare cose nuove e aiutarsi a vicenda sia apprezzato. Un obiettivo difficile da raggiungere, se lo si confronta con la cultura della velocità descritta da uno degli intervistati: “A meno che le aziende non celebrino il fallimento, ogni volta che fallisci non stai aiutando la velocità del team”.

3. La struttura del team influisce sulle dinamiche del team

Il team di Alan riservava gli ultimi due giorni dello sprint ai test, alla chiusura dello sprint e alla preparazione dello sprint successivo. Il team dava semplicemente per scontato che Alan seguisse questa struttura. Avrebbe testato le funzioni appena implementate alla fine dello sprint, eseguito anche alcuni nuovi test nello sprint successivo e migliorato complessivamente i test. Non sembra poi così male, vero?

La realtà racconta una storia diversa. Il software è disponibile solo l'ultimo giorno dello sprint. Gli elementi del backlog aiutano poco a capire esattamente come dovrebbe funzionare. Mentre il team discute i dettagli di ciò che farà nello sprint successivo, Alan cerca di capire cosa testare dello sprint in corso. Poi fa domande appena prima che gli sviluppatori se ne vadano e testa durante il fine settimana. Bene che il team discuta cosa mettere per iscritto. Alan può così testare senza disturbare gli sviluppatori. Centro.

La struttura del team isola sempre più Alan. Il team non si accorge delle sue difficoltà. Nota soltanto domande stupide e risultati tardivi di scarso valore. Che fallito.

La specifica mediante esempi mostra molto bene come i test e i tester possano essere parte integrante di un team agile. I tester partecipano alle sessioni di perfezionamento, aiutano a creare una specifica verificabile, concentrano gli sforzi di test sugli aspetti più importanti, migliorano i processi del team, le competenze individuali e gli strumenti, e si occupano anche di alcuni test. I test vengono eseguiti continuamente, non solo alla fine dello sprint.

4. Ignorare le regole fondamentali porta ai guai

Il team di Alan ignora le regole fondamentali dell'ingegneria del software. 

Eccone cinque:

1. Le cose inaspettate accadono. Non lasciare abbastanza spazio per gestirle porta a lavorare di fretta, ricorrere a scorciatoie, commettere errori stupidi, inasprire i conflitti e quindi rallentare i progressi nel lungo periodo.
2. La pressione causa ritardi. La pressione lascia meno spazio per gestire le cose inaspettate.
3. La qualità emerge. Il team deve avere una cultura della qualità. I test sono solo un tassello del puzzle. E un singolo membro del team contrapposto a tutti gli altri solitamente fallisce.
4. Cambiare il team rallenta il lavoro. Costruire la fiducia, adattare i processi, risolvere più conflitti: il team ha bisogno di tempo ed energie per integrare i nuovi membri. Aggiungere persone a un progetto in ritardo lo fa ritardare ulteriormente.
5. Dai difetti si impara. Quando un processo produce troppi difetti, fermalo, correggilo e impara da esso. Non dare la colpa a qualcuno e, cosa ancora più importante, non accelerarlo.

Esistono altre regole di questo tipo e ogni volta che le persone le ignorano, le cose peggiorano. E così è stato per Alan.

5. La percezione di una situazione critica fa scattare tutto

Come mai il team ignora aspetti così fondamentali? È facile. È tipico di una situazione sotto pressione, in cui i dati di partenza (risultati da consegnare, tempo disponibile e team) non lasciano sufficiente flessibilità per gestire gli imprevisti. Ci siamo passati tutti, è un caso evidente. I sistemi di logoramento sfruttano l'unica variabile in una situazione critica: quanto duramente lavora il team, cioè quanta energia i membri del team consumano dalle proprie riserve.

La domanda fondamentale è: il team di Alan si trova davvero in una situazione critica e consegnare tutte le funzionalità è davvero la strada migliore? Possiamo solo supporlo. Il team ha fatto lo stesso e si è affrettato nel tentativo di sviluppare tutte le funzionalità.

È la percezione delle situazioni critiche a fare la differenza. Il fattore scatenante di tale percezione può essere una clausola contrattuale, un incentivo, una grande opportunità di mercato, una forte richiesta da parte di un responsabile, una promessa fatta, il desiderio di un cliente o una normativa governativa.

Alan si aspetta una gran quantità di difetti e l'ansia lo spinge a cercarli. La domanda fondamentale per lui è: trovare i difetti è davvero un passaggio così importante in questo caso? Possiamo solo fare supposizioni e Alan ha fatto lo stesso. Ha dato per scontato di sì.

La percezione di una situazione critica è una leva importante per interrompere un sistema di logoramento. Alla base c'è un'altra regola fondamentale dell'ingegneria del software:

• Aspettative eccessive. I portatori di interesse, inclusi gli stessi sviluppatori, sperano, si aspettano o pretendono più di quanto un team software possa realisticamente consegnare.

Ripensando agli ultimi 25 anni della mia esperienza nei progetti, non riesco a ricordarne nemmeno uno in cui questo non fosse vero. Il conflitto tra ciò che ci si aspetta e ciò che può essere consegnato è il punto critico. Il successo di un progetto dipende dalla capacità delle persone coinvolte di risolvere questo conflitto. Consiglierei di rivedere le buone pratiche relative alla gestione dei portatori di interesse e delle aspettative, alla gestione dei conflitti, all'ingegneria dei requisiti, all'agilità e ad ambiti simili.

In ogni caso, bisogna comprendere l'esatta natura del conflitto. Quanto è forte? Cosa lo alimenta? Con chi è necessario collaborare? Oppure, come ha affermato uno dei professionisti QA intervistati: “Credo che ogni azienda debba prendere una decisione consapevole riguardo a qualità, costi e velocità”. Ogni azienda deve lavorare sulle proprie aspettative.

I professionisti QA solitamente non sono nella posizione di guidare questa discussione. Possono cercare di contribuire. Potrebbe essere più proficuo gestire le aspettative che devono affrontare personalmente. Una delle persone intervistate mi ha raccontato la sua ricetta: “È impossibile testare tutto. È meglio definire un intervallo di tempo e le priorità insieme al responsabile del prodotto. Le priorità riflettono il rischio di non eseguire i test. Se non si è soddisfatti, si rinegoziano l'intervallo di tempo e le priorità”.

More Articles

• Come prepararsi e sopravvivere alle decisioni Ship/No-Ship
• Come le Competenze di Testing mi Hanno Reso un Sviluppatore di Automazione Migliore
• 6 Trucchi di Ingegneria della Qualità per Team di Sviluppatori da Remoto
• 14 Articoli sul Test del Software da Leggere Assolutamente per Ispirazione
• Porta i Tuoi Strumenti…Ma Prima, Pensa Due Volte

6. La trappola dell’agilità

Una squadra solida che si adatta continuamente alle esigenze mutevoli, un modo non burocratico di gestire il cambiamento, semplici strumenti di pianificazione e controllo dei progressi: il movimento agile ha portato una grande quantità di innovazioni di cui le squadre di sviluppo farebbero bene ad approfittare. Eppure l’agilità sembra rendere la situazione ancora più tesa.

Si comincia dal nome: l’iterazione significa velocità, la velocità significa velocità, si fallisce rapidamente. I principi agili mettono il codice al primo posto e pensare in anticipo viene facilmente liquidato come uno spreco. Persino il termine Scrum deriva dal rugby, uno sport in cui gli atleti si affrontano alla massima velocità. Così l’agilità, anche contro le proprie convinzioni, promuove la velocità a scapito della qualità. «Le metodologie agili e DevOps incoraggiano l’idea di fare tutto ancora più velocemente», si è lamentato un professionista del controllo qualità.

La meccanica, per esempio, di Scrum è persino peggiore del nome. Non è che chi ha creato Scrum volesse favorire l’esaurimento professionale. Ma Scrum conduce le squadre su una strada che porta fuori rotta.

Innanzitutto, concentra l’attenzione della squadra sull’elenco delle attività. Il compito del responsabile del prodotto è inserire elementi nell’elenco delle attività. Il compito di un membro della squadra è prenderli e svolgerli uno alla volta. Il compito del responsabile Scrum è assicurarsi che ciò avvenga più velocemente. Inoltre, il controllo dei progressi agile richiede elementi dell’elenco delle attività piccoli e realizzabili in pochi giorni. Gli esperti raccomandano anche criteri di accettazione definiti nei minimi dettagli prima dell’iterazione. I membri della squadra ricevono attività piccole e definite con precisione da consegnare. Ogni giorno riferiscono quanto tempo serve ancora per completarle. La velocità indica a tutti quanto bene stanno lavorando. I responsabili del controllo minuzioso esultano e controllano ogni minuto: mancanza di controllo, nessuno spazio creativo, pressione per diventare più veloci: una corsa dei topi.

Alla luce di tutto questo, in una situazione apparentemente molto tesa, importa se il prodotto è eccellente per gli utenti? Certo che no, è compito della squadra UX. Importa se ha senso? È compito del responsabile del prodotto. Importa se i criteri di accettazione sono completi? Ancora una volta, è compito del responsabile del prodotto. È importante che non ci siano bug? È compito del collaudatore, una volta superati i criteri di accettazione. Che cosa importa? Che io finisca in tempo il mio elemento dell’elenco delle attività. Capite la posizione di Alan? Scrum spinge le squadre a realizzare tutte le funzionalità. La qualità è compito di Alan. La regola fondamentale viene violata e le cose peggiorano.

Anche la squadra di Alan rispetta l’impegno preso. Riempie l’iterazione con tanti elementi dell’elenco delle attività quanti ne indica la velocità. Poi giura di consegnarli. Li colpisce la legge fondamentale successiva: accadono imprevisti. Anziché rompere il giuramento, la squadra prende scorciatoie e taglia qualche parte dei test. Finito in tempo, ben fatto! Uno degli intervistati lo ha detto molto chiaramente: «La ludicizzazione dell’impegno a realizzare un certo numero di punti della storia crea una competizione malsana».

La squadra di Alan è caduta nella trappola dell’agilità. Applica Scrum senza essere agile. Confrontate le due immagini seguenti: la prima mostra di cosa si occupa Scrum, la seconda di cosa si occupa l’agilità.

Scrum riguarda il processo per trasformare gli elementi dell’elenco delle attività in un prodotto.

L’agilità riguarda la creazione di un impatto con un prodotto e le interazioni tra le persone coinvolte: chi ordina un prodotto, chi lo utilizza e chi lo crea.

Sebbene Scrum sia un ottimo strumento per squadre agili intrinsecamente motivate, è fatale in una gerarchia di comando dall’alto verso il basso!

Conclusioni

Nel settore del software è importante sviluppare meccanismi di difesa contro lo stress e l’esaurimento professionale tra i professionisti del collaudo del software. In alcune aziende più che in altre. Alcune situazioni sono davvero molto tese, altre vengono rese tali di proposito. Ma la maggior parte delle situazioni sembra molto più tesa di quanto non sia. E questo ci porta a seguire i nostri condizionamenti, a smettere di lavorare sui conflitti e a ignorare le regole fondamentali. 

La tabella seguente riassume gli ingranaggi di un sistema di esaurimento professionale.

Elementi chiave di un sistema di esaurimento professionale

• Tensione percepita è il divario tra ciò che consideriamo il nostro compito e ciò che possiamo realizzare. Scoprire quale sia davvero il risultato migliore da raggiungere può smantellare il sistema di esaurimento professionale.
• Condizionamenti definiscono dove fluisce l’energia e ci impediscono di agire saggiamente in una situazione tesa. Scoprire i nostri condizionamenti può aiutarci a spendere meno energia e a usarla in modo più efficace.
• Conflitti rendono la situazione più tesa, rendono una squadra meno efficace e consumano energia. Creiamo una cultura della squadra in cui accogliamo i conflitti e ci aiutiamo a vicenda.
• Regole fondamentali vengono facilmente ignorate. Vederle ignorate è un segnale certo che le cose peggioreranno. Dobbiamo agire!
• Struttura della squadra congela le pratiche buone e quelle cattive. Cambiare la struttura della squadra può modificare radicalmente chi fa cosa e il modo in cui le persone interagiscono. Può cambiare completamente le regole del gioco.
• Cicli viziosi emergono dall’interazione degli attori all’interno e intorno alla squadra e rendono la situazione sempre peggiore. Riusciamo a individuare i cicli viziosi che ci hanno intrappolato? Dobbiamo fermarli e risolverli!
• La trappola dell’agilità consiste nell’adottare strutture metodologiche agili senza essere agili. Il risultato è una corsa dei topi. Concentriamoci sugli utenti, sulla creazione di un prodotto eccellente e sul modo in cui interagiamo, invece di bruciare gli elementi dell’elenco delle attività.

In qualità di professionista del controllo qualità, potresti non essere nella posizione di cambiare in meglio la situazione generale. Ma probabilmente puoi ridurre un po’ lo stress. 

Ho chiesto a Jonathon Wright: «Dove hai visto aziende o squadre intraprendere azioni per promuovere la salute mentale tra i professionisti del controllo qualità? Che cosa funziona?»

Ha risposto, 

“Dopo aver trascorso l’ultimo anno ad aiutare il Governo britannico a prepararsi alla Brexit, sono rimasto estremamente colpito dall’etica professionale. Ho frequentato il mio primo corso obbligatorio di mindfulness, che si è rivelato estremamente utile; erano presenti specialisti della salute mentale e persino gruppi di supporto che si riunivano ogni settimana.”

Ha inoltre sottolineato che i professionisti QA possono fare molto per gestire lo stress e l’ansia a livello personale:

“La vita è troppo breve per preoccuparsi delle piccole cose. Per i professionisti QA è difficile non preoccuparsi prima del rilascio importante di un nuovo prodotto o non sentirsi responsabili di qualsiasi risultato. Ma, come nell’Episodio II con Parveen, a volte devi semplicemente ‘lasciar perdere, lasciar perdere’ e non ‘fare il duro’.”

Jonathon Wright, conduttore del podcast Il responsabile della QA

"Avendo gestito l’ansia per tutta la mia carriera professionale, ho incontrato ostacoli e difficoltà, ma ne sono sempre uscito più forte e in una posizione migliore per gestire meglio la mia ansia, imparando ogni volta qualcosa in più su me stesso. Il settore attrae persone che si trovano a vari livelli dello spettro (e includo anche me stesso). Tuttavia, le persone più talentuose con cui ho avuto l’opportunità di lavorare hanno sofferto di disturbi mentali, motivo per cui considero la mia malattia mentale un superpotere!”

Come ha sottolineato Jonathon, con un po’ di fortuna e il giusto atteggiamento, è possibile trasformare un lavoro stressante in un’esperienza gratificante. Ti invito ad adottare il punto di vista offerto dal concetto di sistema di burnout. Lascia andare l’ansia e mantieni la calma. Poi guarda oltre comandamenti, processi e strumenti. Concentrati su ciò che conta davvero: il modo in cui tu e i tuoi compagni di squadra vi aiutate a vicenda per creare prodotti eccellenti.