Utbrändhet inom programvarutestning: 6 orsaker & hur du åtgärdar det
Är det möjligt att konstruera en situation i ett programvaruutvecklingsteam så att en testare löper mycket stor risk att bli utbränd?
Om ja, vad kan testare lära sig av detta tankeexperiment?
Det visar sig att utbrändhet bland yrkesverksamma inom programvarutestning inte bara är ett tankeexperiment inom programvarutestningsbranschen – det är ett verkligt och utbrett problem som påverkar många utvecklare, ingenjörer och testare.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Jag undersökte frågan om utbrändhet inom programvarutestning och ställde följande frågor:
- Hur yttrar sig utbrändhet i den här branschen?
- Hur stort är problemet?
- Vad skapar system där programvarutestare blir utbrända?
- Hur kan vi bryta ner problemet med utbrändhet – och lösa det?
Svaren – eller åtminstone början på dem – finns i den här artikeln.
Utbrändhet bland yrkesverksamma inom programvarutestning i IT
Arbetsrelaterad stress är något som många av oss i IT-branschen upplever. Jag är säker på att du också har din beskärda del av stress. I mitt sammanhang har utbrändhet tyvärr blivit ett allt mer framträdande ämne under de senaste åren.
Är utbrändhet ett problem?
När jag frågade Jonathon Wright: ”Hur stort problem tycker du att utbrändhet är bland QA-yrkesverksamma?”, svarade han så här:
”Det är ett enormt problem. Ett känt uttryck lyder: Man kan inte spurta hela tiden.”
Jonathon Wright, värd för podcasten The QA Lead
Han fortsatte med att förklara:
”Metoder som Agile och DevOps uppmuntrar tanken på att göra allt ännu ’snabbare’. Hur skapar en QA-yrkesverksam mätbart värde i landskapet där man misslyckas snabbt och lär sig snabbt?
I en nylig podcast på QALead dök uttrycket ’sakta ner för att öka farten’ upp. Om inte företag firar misslyckanden (vilket väldigt få gör), så hjälper du inte resten av teamets arbetstakt varje gång du misslyckas.
Ledtråden finns i titeln på det överanvända nedbränningsdiagrammet. Spelifieringen av att förbinda sig till ett visst antal arbetsinsatspoäng skapar osund konkurrens.
”Du tvingas göra mer med mindre och arbeta utifrån den orealistiska förväntningen att arbetet kan levereras i tvåveckorssprintar.”
Jonathon Wright, värd för podcasten The QA Lead
Hur yttrar sig utbrändhet inom QA?
Utbrändhet är inte ett isolerat fenomen i programvarubranschen – men hur yttrar det sig?
Här är svar från yrkesverksamma inom programvarutestning som visar på vilka sätt utbrändhet uppstår inom QA.
”Vi måste bevisa vårt värde. Team säger till mig att de arbetar agilt och inte behöver testare.”
”Ångest. Det är svårt för QA-yrkesverksamma att inte oroa sig inför en större lansering eller känna sig ansvariga för alla resultat.”
”Tidspress. Testare är alltid sist. Och jag får aldrig den tid jag behöver. Dessutom halveras den eftersom utvecklarna drar över tiden.”
”Orealistiska förväntningar. Jag skulle kunna testa för evigt och ändå inte kunna testa allt. Säg det till en projektledare. Vad är en testare som inte hittar buggar bra för?!”
”Att avgöra vad som ska testas utifrån posterna i backloggen är nästan omöjligt. Och ingen nämner gränsfall.”
”Slöseriet är frustrerande. Utvecklare kan inte återskapa en bugg, backloggposten är inaktuell eller så har de redan åtgärdat den.”
”Många vill inte ha en ärlig rapport, och särskilt inte dåliga nyheter. När du insisterar kan det bli personligt.”
Varför uppstår utbrändhet?
Facklitteraturen räknar upp många faktorer som orsakar stress och ökar sannolikheten för utbrändhet. Det finns individuella faktorer, till exempel personliga drivkrafter som att vara perfekt, skynda sig, anstränga sig för mycket, vara stark eller behaga andra. Läs mer om detta i transaktionsanalysen.
Det finns också stressfaktorer i arbetsmiljön. Hög arbetsbelastning, tidspress, ouppnåeliga mål och förväntningar, brist på kontroll, upptrappade konflikter, rädsla för att förlora jobbet, missnöje med arbetet, mobbning och trakasserier, med mera. Vi känner igen dem.
För en tid sedan började jag se på utbrändhet ur ett systemiskt perspektiv och skapade ett simuleringsspel där spelarna kan påverka ödet för ett mjukvaruutvecklingsteam. De kan bränna ut teammedlemmarna eller skapa det mest givande projektet någonsin.
Spelets kärna är ett utbrändhetssystem, det vill säga ett system som är uppbyggt på ett sådant sätt att vissa medlemmar i ett team till slut kommer att bli utbrända. Du kan få en glimt av spelet på min blogg.
Detta systemiska angreppssätt fungerar även för olika roller i ett team. Jag har gjort detta för yrkesverksamma inom användarupplevelse och blev överraskad över hur enkelt det är att driva dessa personer in i utbrändhetssystemets riskzon. Särskilt när de bryr sig om användarna är de villiga att ta en extra strid och riskera att gå under.
Nedan går jag igenom en berättelse från Alan, som arbetar med kvalitetssäkring, för att bättre förstå och illustrera problemet med utbrändhet i mjukvarubranschen.
Därefter kommer jag att prata om hur utbrändhetssystem skapas och vad vi kan göra för att förbättra dessa system.
En personlig berättelse om utbrändhet
Nu när jag är säker på att jag kan konstruera ett utbrändhetssystem för yrkesverksamma inom kvalitetssäkring vill jag introducera Alan och hans berättelse för dig.
Alan har nästan tio års erfarenhet av mjukvarutestning, särskilt prestandatestning. Han ska ansluta sig till ett utvecklingsteam. Teamet har arbetat i tio sprintar och har ytterligare fyra kvar innan den första versionen släpps.
Hur var Alans första dag i projektet?
Alan: Det finns mycket att göra för mig. Programvaran håller låg kvalitet. Jag förväntar mig många oupptäckta buggar och är rädd för problem om jag inte hittar dem före lanseringen.
Markus: Är det då högsta prioritet för dig att identifiera buggarna för att förbättra kvaliteten?
Alan: Det är en del av det. Vi förväntar oss också många användare. Programvarans prestanda är av största vikt när vi väl lanserar den för allmänheten. Teamet ser fram emot att dra nytta av min expertis på det området.
Hittills är Alan ganska optimistisk om att de åtgärder som överenskommits med teamet kommer att förbättra programvarans kvalitet. Men en sprint senare, med tre sprintar kvar, ser Alan inte särskilt munter ut.
Vad är problemet?
Alan: De två veckorna var intensiva. Jag är inte nöjd med mina framsteg. Jag ville ha ett första, enkelt prestandatest, men jag är långt ifrån att lyckas med det.
Markus: Vad hindrar dig?
Alan: Jag behöver stöd från utvecklarna, men de är överbelastade. Jag behövde också mycket mer tid än förväntat för att lära känna programvaran och rapportera de buggar jag hittade.
Markus: Lyckades du testa de nya ärenden som teamet levererade?
Alan: Inte direkt, teamet var upptaget med att finslipa dem. Av de två dagar som avsatts för testning i slutet av sprinten återstod bara en halv dag. Jag stannade kvar längre och arbetade på lördagen, men jag är långt ifrån klar.
I sprint tolv retrospektiv, med bara två sprintar kvar, är testning det viktigaste ämnet: Produktägaren klagade på antalet buggar som Alan hade hittat.
Utvecklare: De flesta buggar som Alan hittade är antingen obetydliga eller inte buggar alls. Låt oss gå igenom dem först innan vi drar några slutsatser.
Alan: Det var svårt för mig att förstå vad programvaran skulle göra utifrån ärendena i backloggen. En specifikation skulle verkligen hjälpa.
Utvecklare: Över min döda kropp! Vi vill inte ha vattenfallsmodellen. Det mesta handlar om sunt förnuft. Kom bara och fråga oss. Hur går det med prestandatestningen?
Alan: Jag har kört fast. Jag kan inte få verktyget att köras mot tjänstelagret med all den säkerheten. Jag behöver hjälp.
Utvecklare: Vi använde ett annat verktyg i det senaste projektet. Det fungerade perfekt. Jag skickar länken till dig.
Som ett resultat organiserar produktägaren ett snabbt två timmar långt möte under nästa sprint. Målet är att gå igenom buggarna och diskutera vad som ska dokumenteras i ärendena i backloggen för att göra det enklare för nybörjaren Alan. Kan du känna hur Alans frustration växer?
Alans ödesdigra position som syndabock blir ännu tydligare efter sprint tretton, med en sprint kvar. Här är besluten från detta retrospektiv:
- Många buggar hittades i ärenden som Alan borde ha testat i sprinten dessförinnan. Inget ärende får stängas utan att Alan har testat det.
- Fortfarande inget prestandatest. Vi låter en expert titta på det. Alan ska informera honom.
- Kunde inte slutföra två ärenden. Vi förlorade två dagar på att rensa bort oanvändbara buggrapporter. Alan markerar varje bugg med dess relevans. Fråga produktägaren om du är osäker.
Har du upptäckt det? Teamet hann inte färdigställa två berättelser och lyckades lägga skulden på Alan!
Föreställ dig nästa sprint, när berättelser inte stängs eftersom Alan inte hade tid att testa dem! Det är inte konstigt att Alan ser sliten ut.
Alan: Bara två veckor kvar till leveransen och kvaliteten är en mardröm. Säg det till produktägaren! Och de tog faktiskt bort prestandatestningen. Det var anledningen till att jag över huvud taget började i projektet. Min chef är missnöjd. Han ville att jag skulle föregå med gott exempel på hur man inkluderar testare i agila team. Jag måste ändå kämpa igenom det här, mitt rykte på företaget står på spel.
Fyra veckor senare, två veckor efter den första leveransen till en utvald målgrupp, är utbrändhetssystemet fullt operativt.
Alans sammanfattning av sina prestationer hittills:
- Prestandatestning: misslyckades
- Bli erkänd som expert på prestandatestning: misslyckades
- Kunna testa nybyggda saker grundligt: misslyckades
- Kunna testa om det som redan byggts grundligt: misslyckades
- Inkludera testare i agila team: misslyckades
- Inga kritiska fel i leveransen: misslyckades
- Bli rekommenderad: misslyckades
- Arbeta hårt och få skulden: uppnått
- Rädsla för att förlora jobbet: uppnått
- Gå in i väggen: på väg dit i full fart
Det här är ett klassiskt fall av ett utbrändhetssystem. Så vad skapar det här systemet, och hur kan vi motverka det?
Vad skapar ett utbrändhetssystem?
För Alan är det en hopplös situation från början, skulle man kunna säga. Och man skulle ha rätt. Alan befinner sig i ett utbrändhetssystem som har verkat i teamet under ganska lång tid. Utbrändhetssystemet pekar ut Alan på samma sätt som ett rovdjur pekar ut sitt offer. Men vad är det här utbrändhetssystemet och hur gör det?
Ett utbrändhetssystem är en konstellation av människor, drivkrafter och konflikter. Genom en förstärkande cykel skapar det en situation så full av stressfaktorer att vissa människor till slut blir utbrända. Det är särskilt kraftfullt när det kan utlösa människors överlevnadslogik.
1. Energin följer drivkrafterna
I Alans berättelse kan vi se några drivkrafter:
- Ambitionen och fascinationen för favoritämnet prestandatestning får Alan att vilja göra det.
- Oro över att vara ansvarig för en misslyckad leverans får Alan att leta efter fel.
- Något får teammedlemmarna att bygga funktioner i första hand.
Drivkrafter förändrar handlingsförloppet. Människor har mycket svårt att tänka klart kring vad som ska uppnås och hur det ska uppnås. Den energi människor investerar följer drivkraften, inte den plats där den behövs mest. Alans team ifrågasätter aldrig om det är rätt att bygga alla funktioner. Alan ifrågasätter inte heller om det är lämpligt att leta efter fel.
Det svåra för de flesta av oss är att bli medvetna om att en drivkraft har tagit kontrollen. Det är tur för oss att psykologer har studerat dem. När det gäller personliga drivkrafter kan man börja med transaktionsanalys. På teamnivå är grupptänkande en bra utgångspunkt. Där finns mängder av råd att hitta.
Angående oro inför en leverans rådde en erfaren QA-specialist: ”Du behöver bara släppa det och ta det lugnt”. Med ett sådant tankesätt från början skulle Alan förmodligen sträva efter ett annat mål än att hitta alla fel och sätta upp prestandatestning. De högsta prioriteringarna skulle kunna vara att teamet åtgärdar de kritiska felen och generellt levererar högre kvalitet. Ett sätt att minska stressen som är förknippad med repetitiva uppgifter är att dra nytta av förstklassiga verktyg utformade för programvarutestning.
2. Konflikter trappas upp och blir personliga
Tillsammans med drivkrafterna blossar konflikter upp i teamet. Alan behöver till exempel mer tid från utvecklarna än de är beredda att avsätta. Resultat: Alan skapar mycket oväsen och utvecklarna försöker hålla honom borta från sig. Med begränsad hjälp kan Alan inte leva upp till förväntningarna. Han är rädd om sitt rykte, anstränger sig ännu mer och skapar ännu mer oväsen.
Det riktigt dåliga är att konflikter blir personliga. Efter att ha arbetat som testare i tio år är Alan förmodligen ganska kunnig. Ändå ser teamet honom som en oförmögen person och agerar därefter. Ju längre detta pågår, desto djupare blir det. Det påverkar även Alan: han börjar ifrågasätta sin kompetens.
Hur många gånger har du klandrat någon? Hur många personer omkring dig gör inte ett bra jobb? Varje sådan tanke pekar på en konflikt som blev personlig.
De flesta team kan inte lösa konflikter. Det kommer inte lätt. Konflikthantering är nyckelordet för att hitta råd. Det grundläggande budskapet: Team behöver en kultur där idéer kan utbytas öppet, avvikande åsikter välkomnas som möjligheter att skapa nya saker och det uppskattas att hjälpa varandra. En svår sak att uppnå, om man jämför detta med den snabbhetskultur som en intervjuperson beskriver: ”Om inte företag firar misslyckanden hjälper du inte teamets arbetstakt varje gång du misslyckas”.
3. Teamstruktur påverkar teamdynamiken
Alans team avsatte de två sista dagarna av sprinten för testning, avslutning av sprinten och förberedelser inför nästa sprint. Teamet antog helt enkelt att Alan följde denna struktur. Han skulle testa de nyimplementerade funktionerna i slutet av sprinten och göra ytterligare omtestning i nästa sprint samt förbättra testningen överlag. Låter inte så illa, eller hur?
Verkligheten berättar en annan historia. Programvaran är tillgänglig först den sista dagen av sprinten. Backloggposter ger liten hjälp med hur den exakt ska fungera. Medan teamet diskuterar detaljerna kring vad de ska göra i nästa sprint försöker Alan lista ut vad han ska testa från den här sprinten. Sedan ställer han frågor precis innan utvecklarna går hem och testar under helgen. Bra att teamet diskuterar vad som ska skrivas ned. Då kan Alan testa utan att störa utvecklarna. Bingo.
Teamstrukturen isolerar Alan allt mer. Teamet ser inte hur han kämpar. De lägger bara märke till dumma frågor och sena resultat med litet värde. Vilken slagpåse.
Specifikation genom exempel visar på ett tydligt sätt hur testning och testare kan vara en integrerad del av ett agilt team. Testare deltar i förfiningar, hjälper till att skapa en testbar specifikation, fokuserar testinsatserna på det som är viktigt, förbättrar teamets processer, individuella färdigheter och verktyg, och de utför även en del av testningen. Testning utförs kontinuerligt, inte bara i slutet av sprinten.
4. Ignorera grundläggande regler och gå mot problem
Alans team ignorerar grundläggande regler inom programvaruutveckling.
Här är fem av dem:
- Oväntade saker händer. Om man inte lämnar tillräckligt med utrymme för dem leder det till brådska, genvägar, dumma misstag, upptrappade konflikter och därmed långsammare framsteg på lång sikt.
- Press leder till förseningar. Press resulterar i mindre utrymme för oväntade saker.
- Kvalitet växer fram. Teamet behöver ha en kvalitetskultur. Testning är bara en del av pusslet. Och en ensam teammedlem mot alla andra misslyckas vanligtvis.
- Att förändra teamet gör det långsammare. Att bygga förtroende, anpassa processer och lösa fler konflikter: Teamet behöver tid och energi för att integrera nya teammedlemmar. Att lägga till personer i ett försenat projekt gör det ännu senare.
- Defekter är till för att lära sig. När en process producerar för många defekter ska man stoppa den, rätta till den och lära sig av den. Skyll inte på någon och, framför allt, försök inte skynda på processen.
Det finns fler sådana regler, och varje gång människor ignorerar dem blir saker och ting sämre. Och så blev det för Alan.
5. En upplevd pressad situation utlöser det
Hur kommer det sig att teamet ignorerar sådana grundläggande saker? Enkelt. Det är typiskt i en pressad situation där förutsättningarna (leveranserna, den tillgängliga tiden och teamet) inte ger tillräcklig flexibilitet för att hantera oväntade saker. Varit där, gjort det, ett solklart fall. Utbrändhetssystem utnyttjar den enda variabeln i en pressad konstellation: hur hårt teamet arbetar, det vill säga hur mycket energi teammedlemmarna förbrukar från sina batterier.
Den avgörande frågan: befinner sig Alans team verkligen i en pressad situation, och är det bästa sättet att gå vidare att leverera alla funktioner? Vi kan bara anta det. Teamet gjorde samma antagande och skyndade iväg i försöken att bygga alla funktioner.
Det är upplevelsen av pressade situationer som spelar roll. Utlösaren för en sådan upplevelse kan vara en avtalsklausul, ett incitament, en fantastisk marknadsmöjlighet, starka krav från en chef, ett löfte som har getts, en kunds önskemål eller en statlig reglering.
Alan förväntar sig mängder av buggar, och ångesten får honom att jaga dem. Den avgörande frågan för honom: är det verkligen så viktigt att hitta buggarna i det här fallet? Vi kan bara spekulera, och det gjorde Alan också. Han antog att svaret var ja.
Upplevelsen av en pressad situation är en viktig hävstång för att bryta ett utbrändhetssystem. Bakom den finns ytterligare en grundläggande regel inom programvaruutveckling:
- För höga förväntningar. Intressenter – inklusive utvecklarna själva – hoppas på, förväntar sig eller kräver mer än vad ett programvaruteam realistiskt kan leverera.
När jag ser tillbaka på de senaste 25 åren av min projekterfarenhet kan jag inte minnas ett enda projekt där detta inte var fallet. Konflikten mellan vad som förväntas och vad som kan levereras är konfliktens brännpunkt. Ett projekts framgång beror på hur väl de involverade personerna kan lösa denna konflikt. Jag rekommenderar att man går igenom god praxis för intressent- och förväntanshantering, konflikthantering, kravhantering, agilitet och liknande.
Oavsett vilket är det man behöver göra att förstå konfliktens exakta natur. Hur stark är den? Vad driver den? Med vilka behöver du samarbeta? Eller som en av de intervjuade QA-specialisterna uttryckte det: “Jag anser att varje företag behöver fatta ett medvetet beslut kring kvalitet, kostnad och snabbhet”. Varje företag behöver arbeta med sina förväntningar.
QA-specialister befinner sig vanligtvis inte i en position där de kan leda den här diskussionen. De kan försöka bidra. Det kan vara mer givande att hantera de förväntningar de själva möter. En intervjuperson berättade sin metod för mig: “Det är omöjligt att testa allt. Det bästa är att definiera en tidsram och prioriteterna tillsammans med produktägaren. Prioriteringarna återspeglar risken med att inte testa. Om man inte är nöjd ska man omförhandla tidsramen och prioriteringarna.”
6. Agilefällan
Ett starkt team som kontinuerligt anpassar sig efter förändrade behov, ett icke-byråkratiskt sätt att hantera förändringar, enkla metoder för planering och uppföljning av framsteg: den agila rörelsen har fört fram en mängd innovationer som utvecklingsteam gör klokt i att dra nytta av. Ändå verkar agilt arbete trissa upp tempot.
Det börjar redan med benämningarna: Sprint betyder snabbt, hastighet betyder snabbt, man misslyckas snabbt. Agila principer sätter koden främst, och att tänka framåt avfärdas lätt som slöseri. Till och med termen scrum kommer från rugby, en sport där idrottare tacklar varandra i full fart. På så sätt främjar agilitet, trots sina egna övertygelser, snabbhet framför kvalitet. ”Metoder som agilt arbete och DevOps uppmuntrar tanken att göra allt ännu snabbare”, klagade en QA-professionell.
Mekaniken i exempelvis scrum är ännu värre än benämningarna. Det är inte så att de som skapade Scrum ville främja utbrändhet. Men scrum leder teamen vilse.
För det första riktar det teamets uppmärksamhet mot backloggen. Produktägarens uppgift är att lägga saker i backloggen. En teammedlems uppgift är att ta dem och göra dem, en efter en. Scrum masterns uppgift är att se till att detta går snabbare. Dessutom kräver agil uppföljning av framsteg små backloggposter som kan slutföras på några dagar. Gurus rekommenderar också noggrant utarbetade acceptanskriterier före sprinten. Teammedlemmarna får små, exakt definierade delar att leverera. De rapporterar dagligen hur mycket tid de fortfarande behöver för att slutföra dem. Hastigheten berättar för alla hur väl de presterar. Mikrostyrande chefer jublar och kontrollerar varje minut: brist på kontroll, inget kreativt utrymme, pressen att bli snabbare – en råttkapplöpning.
Med detta i åtanke, i en till synes pressad situation, spelar det någon roll om produkten är fantastisk för användarna? Absolut inte, det är UX-teamets jobb. Spelar det någon roll om den är meningsfull? Produktägarens jobb. Spelar det någon roll om acceptanskriterierna är fullständiga? Återigen produktägarens jobb. Är det viktigt att den är fri från buggar? Testarens jobb, när acceptanskriterierna väl har godkänts. Vad spelar då roll? Att jag slutför min backloggpost i tid. Ser du Alans position? Scrum leder team till att göra alla funktioner. Kvalitet är Alans jobb. Den grundläggande regeln överträds, och saker blir värre.
Alans team följer också åtagandet. De fyller sprinten med så många backloggposter som hastigheten anger. Sedan svär de att leverera dem. Nästa grundläggande lag slår till: oförutsedda saker händer. I stället för att bryta löftet tar teamet genvägar och skär bort några delar av testningen. Klart i tid, bra jobbat! En av de intervjuade uttryckte det mycket tydligt: ”Spelifieringen av att åta sig ett visst antal berättelsepoäng skapar osund konkurrens.”
Alans team har fallit i agilefällan. De tillämpar Scrum utan att vara agila. Jämför följande två bilder: den första visar vad Scrum handlar om, den andra visar vad agilt arbete handlar om.
Scrum handlar om processen att omvandla backloggposter till en produkt.
Agilt arbete handlar om att skapa en effekt med en produkt och om samspelet mellan de involverade personerna: de som beställer en produkt, de som använder den och de som skapar den.
Medan Scrum är ett utmärkt verktyg för intrinsiskt motiverade agila team är det förödande i en hierarki med toppstyrning!
Sammanfattning
Inom programvaruindustrin är det viktigt att utveckla försvarsmekanismer mot stress och utbrändhet bland yrkesverksamma inom programvarutestning. I vissa företag mer än i andra. Vissa situationer är verkligen pressade, andra görs avsiktligt pressade. Men de flesta situationer verkar mycket mer pressade än de är. Och detta leder oss till att följa våra drivkrafter, sluta arbeta med konflikterna och ignorera grundläggande regler.
Följande tabell sammanfattar kugghjulen i ett utbrändhetssystem.
Viktiga delar i ett utbrändhetssystem
- Upplevd press är skillnaden mellan det vi uppfattar som vår uppgift och det vi kan leverera. Att upptäcka vad som verkligen är det bästa att uppnå kan montera ned utbrändhetssystemet.
- Drivkrafter bestämmer vart energin flödar och hindrar oss från att handla klokt i en pressad situation. Att upptäcka våra drivkrafter kan hjälpa oss att använda mindre energi och använda den klokare.
- Konflikter trissar upp situationen, gör ett team mindre effektivt och dränerar energi. Låt oss skapa en teamkultur där vi välkomnar konflikter och hjälper varandra.
- Grundläggande regler ignoreras lätt. Att se dem ignoreras är ett säkert tecken på att saker kommer att bli värre. Vi måste agera!
- Teamstruktur låser fast goda och dåliga arbetssätt. Förändrade teamstrukturer kan i grunden ändra vem som gör vad och hur människor samspelar. Det kan förändra spelreglerna helt.
- Ondskefulla cirklar uppstår genom samspelet mellan aktörerna i och runt teamet och gör situationen allt värre. Kan vi upptäcka de onda cirklar som har fångat oss? Vi måste stoppa och åtgärda dem!
- Agilefällan är att införa agila ramverk utan att vara agil. Resultatet blir en råttkapplöpning. Låt oss fokusera på användarna, på att skapa en fantastisk produkt och på hur vi samspelar, i stället för att bränna av backloggposter.
Som QA-professionell kanske du inte har möjlighet att förändra den övergripande situationen till det bättre. Men du kan förmodligen minska en del stress.
Jag frågade Jonathon Wright: ”Var har du sett företag eller team vidta åtgärder för att främja den psykiska hälsan bland QA-professionella? Vad fungerar?”
Han svarade,
”Efter att ha ägnat det senaste året åt att hjälpa den brittiska regeringen att förbereda sig inför brexit blev jag oerhört imponerad av arbetsmoralen. Jag deltog i min första obligatoriska kurs i medveten närvaro, vilket var oerhört givande. De hade specialister på psykisk hälsa på plats och till och med stödgrupper som träffades varje vecka.”
Han påpekade också att QA-specialister kan göra mycket för att hantera sin stress och ångest på ett personligt plan:
”Livet är för kort för att oroa sig över småsaker. Det är svårt för QA-specialister att inte oroa sig inför en större lansering av en ny produkt eller känna ansvar för alla resultat. Men precis som i avsnitt II med Parveen behöver man ibland bara ’släppa det, släppa det’ och inte ’vara cool’.”
Jonathon Wright, värd för podcasten QA-ledaren
”Som någon som har hanterat ångest under hela mitt yrkesliv har det medfört både fallgropar och utmaningar, men jag har alltid kommit ut på andra sidan starkare och i en bättre position att hantera min ångest bättre – och lärt mig mer om mig själv varje gång. Branschen attraherar faktiskt människor som befinner sig på olika delar av spektrumet (och jag räknar mig själv till dem). De mest talangfulla personer jag har haft möjlighet att arbeta med har dock lidit av psykisk ohälsa, vilket är anledningen till att jag ser min psykiska ohälsa som en superkraft!”
Som Jonathon påpekade kan du, med lite tur och rätt inställning, förvandla ett stressigt jobb till ett givande sådant. Jag uppmuntrar dig att ta till dig det perspektiv som erbjuds av konceptet med ett utbrändhetssystem. Släpp ångesten och behåll lugnet. Titta sedan bortom påbud, processer och verktyg. Fokusera på det som verkligen betyder något: hur du och dina kollegor hjälper varandra att skapa fantastiska produkter.
