Wypalenie zawodowe w testowaniu oprogramowania: 6 przyczyn & jak sobie z nim poradzić

Czy można sfabrykować sytuację w zespole tworzącym oprogramowanie, tak aby tester z dużym prawdopodobieństwem się wypalił? 

Jeśli tak, czego testerzy mogą nauczyć się z tego eksperymentu myślowego? 

Okazuje się, że wypalenie zawodowe wśród specjalistów ds. testowania oprogramowania nie jest tylko eksperymentem myślowym w branży testowania oprogramowania — to realny i powszechny problem dotykający wielu programistów, inżynierów i testerów.

Zagłębiłem się w problem wypalenia zawodowego w testowaniu oprogramowania, zadając pytania:

• Jak wygląda wypalenie zawodowe w tej branży?
• Jak duży jest to problem?
• Co tworzy systemy, w których testerzy oprogramowania się wypalają?
• Jak możemy rozłożyć problem wypalenia zawodowego na części — i go rozwiązać?

Odpowiedzi — a przynajmniej ich początek — znajdują się w tym artykule.

Wypalenie zawodowe wśród specjalistów ds. testowania oprogramowania w branży IT 

Stres związany z miejscem pracy to coś, czego doświadcza wielu z nas w branży IT. Jestem pewien, że Ciebie również dotyka stres. W moim otoczeniu niestety wypalenie zawodowe stało się w ostatnich latach coraz bardziej eksponowanym tematem.

Czy wypalenie zawodowe jest problemem?

Kiedy zapytałem Jonathona Wrighta: „Jak dużym problemem, Twoim zdaniem, jest wypalenie zawodowe wśród specjalistów QA?”, odpowiedział:

„To ogromny problem. Słynne słowa: Nie można cały czas biec sprintem.”

Jonathon Wright, prowadzący podcast The QA Lead

Kontynuował wyjaśnienia:

„Metodyki takie jak Agile i DevOps promują ideę robienia wszystkiego jeszcze „szybciej”. Jak specjalista QA ma dostarczać mierzalną wartość w środowisku szybkiego ponoszenia porażek i szybkiego uczenia się?

W niedawnym podcaście QALead pojawiło się określenie „zwolnij, aby przyspieszyć”. Jeśli firmy nie świętują porażek (a robi to bardzo niewiele z nich), to za każdym razem, gdy ponosisz porażkę, nie pomagasz zwiększać tempa pracy reszty zespołu. 

Wskazówka znajduje się w tytule nadużywanego wykresu spalania. Grywalizacja polegająca na zobowiązywaniu się do realizacji określonej liczby punktów historyjek tworzy niezdrową rywalizację.

„Zmusza się nas do robienia więcej mniejszym kosztem, zgodnie z nierealistycznym oczekiwaniem, że pracę można dostarczać w dwutygodniowych sprintach.”

Jonathon Wright, prowadzący podcast The QA Lead

Jak wygląda wypalenie zawodowe w QA?

Wypalenie zawodowe nie jest odosobnionym przypadkiem w branży oprogramowania — ale jak się objawia?

Oto odpowiedzi specjalistów ds. testowania oprogramowania pokazujące, w jaki sposób wypalenie zawodowe pojawia się w QA.

„Musimy udowadniać swoją wartość. Zespoły mówią mi, że pracują zwinnie i nie potrzebują testerów.”

„Lęk. Specjalistom QA trudno nie martwić się przed dużym wydaniem ani nie czuć odpowiedzialności za jego skutki.”

„Presja czasu. Testerzy zawsze są ostatni. Nigdy nie dostaję czasu, którego potrzebuję. A do tego jest on skracany o połowę, ponieważ programiści przekraczają terminy.”

„Nierealistyczne oczekiwania. Mógłbym testować w nieskończoność i nadal nie byłbym w stanie sprawdzić wszystkiego. Powiedz to kierownikowi projektu. Jaki pożytek z testera, który nie znajduje błędów?!”

„Ustalenie na podstawie elementów rejestru zadań, co należy przetestować, jest niemal niemożliwe. Nikt też nie wspomina o przypadkach brzegowych.”

„Marnotrawstwo jest frustrujące. Programiści nie potrafią odtworzyć błędu, element rejestru zadań jest nieaktualny albo został już naprawiony.”

„Wiele osób nie chce szczerego raportu, a zwłaszcza złych wiadomości. Kiedy nalegasz, sprawa może stać się osobista.”

Dlaczego dochodzi do wypalenia zawodowego?

Literatura wymienia wiele czynników, które powodują stres i zwiększają prawdopodobieństwo wypalenia zawodowego. Istnieją czynniki indywidualne, na przykład osobiste motywatory, takie jak: bądź idealny, spiesz się, staraj się bardziej, bądź silny lub zadowalaj innych. Więcej szczegółów znajdziesz w analizie transakcyjnej. 

Istnieją również czynniki stresogenne w środowisku pracy. Duże obciążenie pracą, presja czasu, nieosiągalne cele i oczekiwania, brak kontroli, zaognione konflikty, obawa przed utratą pracy, niezadowolenie z pracy, zastraszanie i mobbing oraz wiele innych. Znamy je.

Jakiś czas temu zacząłem przyglądać się wypaleniu zawodowemu z systemowego punktu widzenia i stworzyłem grę symulacyjną, w której gracze mogą wpływać na losy zespołu programistycznego. Mogą doprowadzić członków zespołu do wypalenia zawodowego albo stworzyć najbardziej satysfakcjonujący projekt w historii. 

Sercem symulacji jest system wypalenia zawodowego, czyli system skonfigurowany w taki sposób, że niektórzy członkowie zespołu ostatecznie się wypalą. Na moim blogu możesz zobaczyć, jak wygląda ta gra.

To systemowe podejście sprawdza się również w przypadku różnych ról w zespole. Zrobiłem to w przypadku specjalistów ds. doświadczeń użytkownika i byłem zaskoczony, jak łatwo można wepchnąć te osoby w sam środek systemu wypalenia zawodowego. Zwłaszcza gdy troszczą się o użytkowników, są gotowe podjąć dodatkową walkę i ryzykować całkowite wyczerpanie.

Poniżej zagłębię się w historię Alana, specjalisty ds. zapewniania jakości, aby lepiej zrozumieć i zilustrować problem wypalenia zawodowego w branży oprogramowania. 

Następnie opowiem o tym, jak tworzone są systemy wypalenia zawodowego i co możemy zrobić, aby je udoskonalić.

Osobista historia wypalenia zawodowego

Skoro mam już pewność, że potrafię stworzyć system wypalenia zawodowego dla specjalistów ds. zapewniania jakości, pozwólcie, że przedstawię wam Alana i jego historię. 

Alan ma prawie dziesięcioletnie doświadczenie w testowaniu oprogramowania, a szczególnie w testach wydajnościowych. Wkrótce dołączy do zespołu programistycznego. Zespół pracuje już od dziesięciu sprintów, a do pierwszego wydania pozostały jeszcze cztery. 

Jak wyglądał pierwszy dzień Alana w projekcie?

Alan: Mam bardzo dużo do zrobienia. Oprogramowanie jest niskiej jakości. Spodziewam się wielu niewykrytych błędów i obawiam się problemów, jeśli nie uda mi się ich znaleźć przed wydaniem.

Markus: Zidentyfikowanie błędów jest więc twoim najwyższym priorytetem, aby poprawić jakość?

Alan: To tylko jedna część. Spodziewamy się również wielu użytkowników. Wydajność oprogramowania będzie niezwykle ważna, gdy udostępnimy je szerszej publiczności. Zespół liczy na to, że skorzysta z mojego doświadczenia w tym zakresie.

Jak dotąd Alan jest dość optymistycznie nastawiony i sądzi, że uzgodnione z zespołem działania poprawią jakość oprogramowania. Niestety, jeden sprint później, gdy do końca pozostały trzy sprinty, Alan nie wygląda już na zbyt zadowolonego. 

W czym tkwi problem?

Alan: Te dwa tygodnie były intensywne. Nie jestem zadowolony z postępów. Chciałem przeprowadzić pierwszy, prosty test wydajnościowy, ale jestem daleko od osiągnięcia tego celu.

Markus: Co ci przeszkadza?

Alan: Potrzebuję wsparcia programistów, ale są bardzo zajęci. Potrzebowałem również znacznie więcej czasu, niż się spodziewałem, aby poznać oprogramowanie i zgłosić znalezione błędy.

Markus: Czy udało ci się przetestować nowe zadania dostarczone przez zespół?

Alan: Niezupełnie, zespół był zajęty ich dopracowywaniem. Z dwóch dni zarezerwowanych na testowanie pod koniec sprintu pozostało tylko pół dnia. Zostałem dłużej i pracowałem w sobotę, ale wciąż jestem daleko od ukończenia pracy.

Podczas retrospektywy dwunastego sprintu, gdy do końca pozostały zaledwie dwa sprinty, testowanie jest najważniejszym tematem: właściciel produktu skarżył się na liczbę błędów znalezionych przez Alana.

Programista: Większość błędów znalezionych przez Alana jest albo nieistotna, albo w ogóle nie stanowi błędów. Najpierw je przejrzyjmy, zanim wyciągniemy jakiekolwiek wnioski.

Alan: Cóż, trudno było mi zrozumieć na podstawie elementów backlogu, jak powinno działać oprogramowanie. Specyfikacja naprawdę by pomogła.

Programista: Po moim trupie! Nie chcemy modelu kaskadowego. To w większości kwestia zdrowego rozsądku. Po prostu przyjdź i zapytaj nas. Jak idą testy wydajnościowe?

Alan: Utknąłem w martwym punkcie. Nie mogę uruchomić narzędzia względem warstwy usług z powodu tych wszystkich zabezpieczeń. Potrzebuję pomocy.

Programista: W ostatnim projekcie używaliśmy innego narzędzia. Sprawdzało się doskonale. Wyślę ci link.

W rezultacie właściciel produktu organizuje w następnym sprincie krótkie, dwugodzinne spotkanie. Celem jest przejrzenie błędów i omówienie tego, co należy zapisać w elementach backlogu, aby ułatwić pracę nowemu Alanowi. Czy czujecie, jak narasta frustracja Alana?

Po trzynastym sprincie, gdy do końca pozostał jeden sprint, fatalna sytuacja Alana jako kozła ofiarnego staje się jeszcze bardziej oczywista. Oto decyzje z tej retrospektywy:

• Wiele błędów znaleziono w zadaniach, które Alan powinien był przetestować w poprzednim sprincie. Żadne zadanie nie zostanie zamknięte, dopóki Alan go nie przetestuje.
• Nadal nie ma testu wydajnościowego. Zajmie się tym ekspert. Alan ma go wprowadzić w temat.
• Nie udało się ukończyć dwóch zadań. Straciliśmy dwa dni na odrzucanie bezużytecznych raportów o błędach. Alan oznacza każdy błąd pod względem istotności. W razie wątpliwości należy zapytać właściciela produktu.

Zauważyłeś to? Zespół nie ukończył dwóch historyjek i zdołał zrzucić winę na Alana! 

Wyobraź sobie następny sprint, w którym historyjki nie zostaną zamknięte, ponieważ Alan nie miał czasu ich przetestować! Nic dziwnego, że Alan wygląda na wyczerpanego.

Alan: Do wydania zostały tylko dwa tygodnie, a jakość to koszmar. Powiedz to właścicielowi produktu! A do tego odebrano mi testy wydajnościowe. To właśnie z ich powodu w ogóle dołączyłem do projektu. Mój szef jest niezadowolony. Chciał, żebym pokazał, jak włączać testerów do zwinnych zespołów. Mimo wszystko będę musiał to przeforsować, bo na szali leży moja reputacja w firmie.

Cztery tygodnie później, dwa tygodnie po pierwszym wydaniu dla wybranej grupy odbiorców, system wypalenia działa już w pełni. 

Podsumowanie dotychczasowych osiągnięć Alana:

• Testy wydajnościowe: niepowodzenie
• Uznanie za eksperta w dziedzinie testów wydajnościowych: niepowodzenie
• Możliwość dokładnego testowania nowo zbudowanych elementów: niepowodzenie
• Możliwość dokładnego ponownego testowania już zbudowanych elementów: niepowodzenie
• Włączanie testerów do zwinnych zespołów: niepowodzenie
• Brak krytycznych błędów w wydaniu: niepowodzenie
• Otrzymanie rekomendacji: niepowodzenie
• Ciężka praca i zrzucanie na mnie winy: osiągnięto
• Obawa przed utratą pracy: osiągnięto
• Wypalenie: zmierzam tam pełną prędkością

To klasyczny przypadek systemu wypalenia. Co zatem tworzy taki system i jak możemy przeciwdziałać jego działaniu?

Co tworzy system wypalenia?

Można powiedzieć, że w przypadku Alana od samego początku była to przegrana sprawa. I byłoby to trafne stwierdzenie. Alan znalazł się w systemie wypalenia, który od dłuższego czasu działa w zespole. System wypalenia wskazuje Alana jako swoją ofiarę. Czym jednak jest ten system wypalenia i jak działa?

System wypalenia to układ ludzi, czynników napędzających i konfliktów. Poprzez wzmacniający się cykl tworzy sytuację pełną stresorów, w której niektórzy ludzie ostatecznie się wypalą. Jest szczególnie silny, gdy może uruchomić u ludzi mechanizmy przetrwania.

1. Energia podąża za czynnikami napędzającymi

W historii Alana możemy dostrzec kilka takich czynników:

• Ambicja i fascynacja ulubionym tematem, jakim są testy wydajnościowe, sprawiają, że Alan chce się nimi zajmować.
• Lęk przed odpowiedzialnością za nieudane wydanie sprawia, że Alan szuka błędów.
• Coś sprawia, że członkowie zespołu w pierwszej kolejności tworzą funkcje.

Czynniki napędzające zmieniają kierunek działania. Ludzie mają ogromne trudności z jasnym myśleniem o tym, co należy osiągnąć i jak to osiągnąć. Energia, którą ludzie inwestują, podąża za czynnikiem napędzającym, a nie za tym, gdzie jest najbardziej potrzebna. Zespół Alana nigdy nie zastanawia się, czy zbudowanie wszystkich funkcji jest właściwym rozwiązaniem. Alan również nie pyta, czy wyszukiwanie błędów jest odpowiednim działaniem.

Najtrudniejsze dla większości z nas jest uświadomienie sobie, że czynnik napędzający przejął kontrolę. Na szczęście psychologowie je zbadali. W przypadku czynników osobistych warto zacząć od analizy transakcyjnej. Na poziomie zespołu dobrym punktem wyjścia jest myślenie grupowe. Można tam znaleźć mnóstwo porad.

W odniesieniu do niepokoju przed wydaniem jeden z doświadczonych specjalistów ds. zapewniania jakości poradził: „Musisz po prostu odpuścić i zachować spokój”. Przy takim nastawieniu od samego początku Alan prawdopodobnie obrałby inny cel niż wyszukiwanie wszystkich błędów i skonfigurowałby testy wydajnościowe. Najważniejszymi priorytetami mogłyby być usunięcie przez zespół błędów krytycznych oraz ogólna poprawa jakości. Jednym ze sposobów ograniczenia stresu związanego z powtarzalnymi zadaniami jest wykorzystanie najwyższej klasy narzędzi przeznaczonych do testowania oprogramowania.

2. Konflikty zaostrzają sytuację i stają się osobiste

Oprócz czynników napędzających w zespole wybuchają konflikty. Na przykład Alan potrzebuje od programistów więcej czasu, niż są gotowi mu poświęcić. Rezultat: Alan powoduje dużo zamieszania, a programiści próbują się od niego opędzić. Pozostawiony z niewielką pomocą Alan nie jest w stanie spełnić oczekiwań. Obawia się o swoją reputację, podwaja wysiłki i powoduje jeszcze więcej zamieszania.

Naprawdę złe jest to, że konflikty stają się osobiste. Pracując jako tester przez dziesięć lat, Alan prawdopodobnie jest całkiem dobrym ekspertem. Mimo to zespół postrzega go jako nieudacznika i tak też go traktuje. Im dłużej to trwa, tym bardziej sytuacja się pogłębia. Wpływa to nawet na Alana: zaczyna kwestionować swoje kompetencje.

Ile razy obwiniałeś kogoś? Ile osób wokół ciebie nie wykonuje swojej pracy dobrze? Każda taka myśl wskazuje na konflikt, który stał się osobisty.

Większość zespołów nie potrafi rozwiązywać konfliktów. Nie przychodzi to łatwo. Warto poszukać porad dotyczących zarządzania konfliktami. Podstawowy przekaz jest następujący: zespoły potrzebują kultury, w której można otwarcie wymieniać się pomysłami, odmienne poglądy są mile widziane jako okazje do tworzenia nowych rzeczy, a wzajemna pomoc jest doceniana. To trudne do osiągnięcia, jeśli porównać to z kulturą szybkości opisaną przez jednego z rozmówców: „Jeśli firmy nie świętują porażek, to za każdym razem, gdy ponosisz porażkę, nie pomagasz w zwiększaniu tempa pracy zespołu”.

3. Struktura zespołu wpływa na dynamikę zespołu

Zespół Alana przeznaczył dwa ostatnie dni sprintu na testowanie, zamknięcie sprintu i przygotowanie kolejnego sprintu. Zespół po prostu założył, że Alan będzie działał zgodnie z tą strukturą. Testowałby nowo zaimplementowane funkcje pod koniec sprintu, a w kolejnym sprincie ponownie by je przetestował, a także ogólnie usprawniłby testowanie. Nie brzmi źle, prawda?

Rzeczywistość wygląda inaczej. Oprogramowanie jest dostępne dopiero ostatniego dnia sprintu. Elementy backlogu niewiele pomagają w dokładnym określeniu jego działania. Podczas gdy zespół omawia szczegóły tego, co zrobi w kolejnym sprincie, Alan próbuje ustalić, co ma przetestować w ramach bieżącego sprintu. Następnie zadaje pytania tuż przed wyjściem deweloperów i testuje w weekend. Dobrze, że zespół omawia, co należy zapisać. Alan może wtedy testować bez zawracania głowy deweloperom. Bingo.

Struktura zespołu coraz bardziej izoluje Alana. Zespół nie widzi jego trudności. Dostrzega jedynie głupie pytania i spóźnione wyniki o niewielkiej wartości. Ależ z niego nieudacznik.

Specyfikacja przez przykłady bardzo dobrze pokazuje, jak testowanie i testerzy mogą stać się integralną częścią zwinnego zespołu. Testerzy uczestniczą w doprecyzowywaniu wymagań, pomagają tworzyć specyfikację możliwą do przetestowania, koncentrują wysiłki testowe na tym, co ma znaczenie, usprawniają procesy zespołowe, indywidualne umiejętności i narzędzia, a nawet sami wykonują część testów. Testowanie odbywa się w sposób ciągły, a nie tylko pod koniec sprintu.

4. Ignorowanie podstawowych zasad prowadzi do problemów

Zespół Alana ignoruje podstawowe zasady inżynierii oprogramowania. 

Oto pięć z nich:

1. Nieoczekiwane rzeczy się zdarzają. Brak wystarczającej przestrzeni na takie sytuacje prowadzi do pośpiechu, chodzenia na skróty, głupich błędów, zaostrzonych konfliktów, a tym samym do wolniejszych postępów w dłuższej perspektywie.
2. Presja powoduje opóźnienia. Presja oznacza mniej przestrzeni na nieoczekiwane sytuacje.
3. Jakość wyłania się w toku pracy. Zespół musi mieć kulturę jakości. Testowanie jest tylko jednym elementem układanki. Samotny członek zespołu przeciwko wszystkim pozostałym zwykle ponosi porażkę.
4. Zmiana składu zespołu spowalnia pracę. Budowanie zaufania, dostosowywanie procesów, rozwiązywanie kolejnych konfliktów: zespół potrzebuje czasu i energii, aby zintegrować nowych członków. Dodanie ludzi do opóźnionego projektu sprawia, że opóźnia się on jeszcze bardziej.
5. Wady służą do nauki. Gdy proces generuje zbyt wiele wad, należy go zatrzymać, naprawić i wyciągnąć z niego wnioski. Nie obwiniaj nikogo, a przede wszystkim nie przyspieszaj tego procesu.

Istnieje więcej takich zasad i za każdym razem, gdy ludzie je ignorują, sytuacja się pogarsza. Tak właśnie stało się z Alanem.

5. Postrzeganie napiętej sytuacji uruchamia ten mechanizm

Dlaczego zespół ignoruje tak fundamentalne kwestie? To proste. Jest to typowe dla napiętej sytuacji, w której dane wejściowe (produkty dostarczane, dostępny czas i zespół) nie zapewniają wystarczającej elastyczności, aby poradzić sobie z nieoczekiwanymi zdarzeniami. Każdy przez to przechodził, każdy to zna — sprawa jest oczywista. Systemy wypalenia wykorzystują jedyną zmienną w napiętej konfiguracji: to, jak ciężko pracuje zespół, czyli ile energii członkowie zespołu zużywają ze swoich akumulatorów.

Kluczowe pytanie brzmi: czy zespół Alana rzeczywiście znajduje się w napiętej sytuacji i czy dostarczanie wszystkich funkcji jest najlepszym rozwiązaniem? Możemy tylko przypuszczać. Zespół zrobił to samo i ruszył do pracy, próbując zbudować wszystkie funkcje.

Liczy się postrzeganie napiętej sytuacji. Wyzwalaczem takiego postrzegania może być klauzula umowna, zachęta, doskonała okazja rynkowa, silne żądanie szefa, złożona obietnica, życzenie klienta lub regulacja rządowa.

Alan spodziewa się masy błędów, a niepokój sprawia, że ich zawzięcie szuka. Kluczowe pytanie dotyczące jego sytuacji brzmi: czy znalezienie błędów jest w tym przypadku naprawdę tak ważnym krokiem? Możemy tylko spekulować — Alan zrobił to samo. Założył, że tak.

Postrzeganie napiętej sytuacji jest ważną dźwignią umożliwiającą przerwanie systemu wypalenia. Kryje się za tym kolejna podstawowa zasada inżynierii oprogramowania:

• Zbyt wysokie oczekiwania. Interesariusze — w tym sami deweloperzy — mają nadzieję, oczekują lub żądają więcej, niż zespół programistyczny może realistycznie dostarczyć.

Patrząc na ostatnie 25 lat mojego doświadczenia projektowego, nie potrafię przypomnieć sobie ani jednego projektu, w którym nie byłoby takiej sytuacji. Konflikt między tym, czego się oczekuje, a tym, co można dostarczyć, stanowi punkt zapalny. Sukces projektu zależy od tego, jak dobrze zaangażowane osoby potrafią rozwiązać ten konflikt. Zalecałbym zapoznanie się z dobrymi praktykami dotyczącymi zarządzania interesariuszami i oczekiwaniami, zarządzania konfliktami, inżynierii wymagań, zwinności i podobnych obszarów.

W każdym przypadku należy zrozumieć dokładną naturę konfliktu. Jak silny jest ten konflikt? Co go napędza? Z kim trzeba współpracować? Albo, jak ujął to jeden z ankietowanych specjalistów ds. zapewniania jakości: „Uważam, że każda firma musi świadomie podjąć decyzję dotyczącą jakości, kosztów i szybkości”. Każda firma musi pracować nad swoimi oczekiwaniami.

Specjaliści ds. zapewniania jakości zwykle nie są w pozycji, która pozwalałaby im prowadzić tę dyskusję. Mogą jednak spróbować wnieść do niej swój wkład. Bardziej owocne może być zarządzanie oczekiwaniami, z którymi mierzą się osobiście. Jedna z rozmówczyń przedstawiła mi swoją receptę: „Nie da się przetestować wszystkiego. Najlepiej ustalić przedział czasowy i priorytety z właścicielem produktu. Priorytety odzwierciedlają ryzyko związane z brakiem testów. Jeśli nie jesteś zadowolony, renegocjuj przedział czasowy i priorytety”.

6. Pułapka zwinności

Silny zespół, który nieustannie dostosowuje się do zmieniających się potrzeb, niebiurokratyczny sposób radzenia sobie ze zmianami, proste metody planowania i kontroli postępów: ruch zwinny przyniósł wiele innowacji, z których zespoły programistyczne powinny rozsądnie korzystać. Mimo to zwinność zdaje się podgrzewać atmosferę.

Zaczyna się od nazewnictwa: sprint oznacza szybkość, prędkość oznacza szybkość, szybko ponosi się porażkę. Zasady zwinne stawiają kod na pierwszym miejscu, a myślenie z wyprzedzeniem łatwo uznają za marnotrawstwo. Nawet termin scrum pochodzi z rugby, sportu, w którym zawodnicy atakują się z pełną prędkością. W ten sposób zwinność, nawet wbrew własnym założeniom, promuje szybkość kosztem jakości. „Metodyki takie jak zwinne i DevOps sprzyjają przekonaniu, że wszystko należy robić jeszcze szybciej” — skarżył się pewien specjalista QA.

Mechanika na przykład Scruma jest jeszcze gorsza niż samo nazewnictwo. Nie chodzi o to, że osoby, które stworzyły Scrum, chciały sprzyjać wypaleniu zawodowemu. Jednak Scrum prowadzi zespoły na manowce.

Po pierwsze, skupia uwagę zespołu na rejestrze zadań. Zadaniem właściciela produktu jest umieszczanie rzeczy w rejestrze zadań. Zadaniem członka zespołu jest pobieranie ich i wykonywanie po kolei. Zadaniem mistrza Scruma jest dopilnowanie, aby odbywało się to szybciej. Następnie zwinna kontrola postępów wymaga małych elementów rejestru zadań, które można wykonać w ciągu kilku dni. Guru zalecają również dokładne opracowanie kryteriów akceptacji przed rozpoczęciem sprintu. Członkowie zespołu otrzymują precyzyjnie zdefiniowane i niewielkie fragmenty do dostarczenia. Codziennie informują, ile czasu nadal potrzebują, aby je ukończyć. Prędkość informuje wszystkich, jak dobrze sobie radzą. Mikromenedżerowie triumfują i kontrolują każdą minutę: brak kontroli, brak przestrzeni na kreatywność, presja, by działać szybciej — wyścig szczurów.

W takiej sytuacji, pozornie napiętej do granic możliwości, czy ma znaczenie, że produkt jest świetny dla użytkowników? Oczywiście, że nie — za to odpowiada zespół UX. Czy ma znaczenie, że produkt ma sens? To zadanie właściciela produktu. Czy ma znaczenie, że kryteria akceptacji są kompletne? Ponownie — zadanie właściciela produktu. Czy brak błędów jest ważny? To zadanie testera, gdy kryteria akceptacji zostaną spełnione. Co ma znaczenie? To, że ukończę swój element rejestru zadań na czas. Czy widzisz, w jakiej sytuacji znalazł się Alan? Scrum prowadzi zespoły do realizacji wszystkich funkcji. Za jakość odpowiada Alan. Zostaje naruszona fundamentalna zasada, a sytuacja się pogarsza.

Zespół Alana przestrzega również zobowiązania. Wypełnia sprint taką liczbą elementów rejestru zadań, jaką wskazuje prędkość. Następnie przysięga je dostarczyć. Uderza w nich kolejna fundamentalna zasada: zdarzają się nieprzewidziane sytuacje. Zamiast złamać przysięgę, zespół idzie na skróty i pomija kilka elementów testowania. Ukończone na czas — dobra robota! Jeden z rozmówców ujął to bardzo dosadnie: „Grywalizacja zobowiązywania się do określonej liczby punktów historyjek tworzy niezdrową rywalizację”.

Zespół Alana wpadł w pułapkę zwinności. Stosuje Scrum, nie będąc zwinnym. Porównaj poniższe dwa obrazy: pierwszy pokazuje, czym jest Scrum, a drugi — na czym polega zwinność.

Scrum dotyczy procesu przekształcania elementów rejestru zadań w produkt.

Zwinność polega na wywieraniu wpływu za pomocą produktu oraz na interakcjach między zaangażowanymi osobami: tymi, którzy zamawiają produkt, tymi, którzy go używają, i tymi, którzy go tworzą.

Chociaż Scrum jest świetnym narzędziem dla wewnętrznie zmotywowanych zwinnych zespołów, w hierarchii zarządzania odgórnego jest zabójczy!

Najważniejsze wnioski

W branży oprogramowania ważne jest opracowanie mechanizmów obronnych przed stresem i wypaleniem zawodowym wśród specjalistów zajmujących się testowaniem oprogramowania. W niektórych firmach jest to ważniejsze niż w innych. Niektóre sytuacje są naprawdę napięte, a inne celowo się takimi czyni. Jednak większość sytuacji wydaje się znacznie bardziej napięta, niż jest w rzeczywistości. Prowadzi nas to do podążania za naszymi wewnętrznymi nakazami, zaprzestania pracy nad konfliktami i ignorowania fundamentalnych zasad. 

Poniższa tabela podsumowuje koła zębate systemu wypalenia zawodowego.

Kluczowe elementy systemu wypalenia zawodowego

• Postrzegane napięcie to różnica między tym, co uznajemy za nasze zadanie, a tym, co możemy dostarczyć. Odkrycie, co naprawdę jest najlepszym rezultatem do osiągnięcia, może rozmontować system wypalenia zawodowego.
• Wewnętrzne nakazy określają, dokąd płynie energia, i uniemożliwiają nam rozsądne działanie w napiętej sytuacji. Odkrycie naszych wewnętrznych nakazów może pomóc nam zużywać mniej energii i wykorzystywać ją mądrzej.
• Konflikty podgrzewają atmosferę, zmniejszają skuteczność zespołu i wyczerpują energię. Stwórzmy kulturę zespołową, w której konflikty są mile widziane, a my pomagamy sobie nawzajem.
• Fundamentalne zasady są łatwo ignorowane. Dostrzeganie, że są ignorowane, to pewny znak, że sytuacja się pogorszy. Musimy działać!
• Struktura zespołu utrwala dobre i złe praktyki. Zmiana struktur zespołowych może zasadniczo zmienić to, kto co robi i jak ludzie wchodzą ze sobą w interakcje. Może całkowicie zmienić zasady gry.
• Błędne koła powstają w wyniku wzajemnego oddziaływania osób działających w zespole i wokół niego, sprawiając, że sytuacja staje się coraz gorsza. Czy potrafimy dostrzec błędne koła, które nas uwięziły? Musimy je zatrzymać i naprawić!
• Pułapka zwinności polega na przyjmowaniu zwinnych struktur bez bycia zwinnym. Rezultatem jest wyścig szczurów. Skupmy się na użytkownikach, tworzeniu świetnego produktu i sposobie, w jaki wchodzimy ze sobą w interakcje, zamiast bezmyślnie redukować elementy rejestru zadań.

Jako specjalista QA możesz nie mieć możliwości zmiany całej sytuacji na lepsze. Prawdopodobnie możesz jednak zmniejszyć część stresu. 

Zapytałem Jonathona Wrighta: „Gdzie widziałeś firmy lub zespoły podejmujące działania na rzecz zdrowia psychicznego specjalistów QA? Co działa?”

Odpowiedział, 

„Po spędzeniu ostatniego roku na pomaganiu rządowi Wielkiej Brytanii w przygotowaniach do brexitu byłem pod ogromnym wrażeniem etyki pracy. Uczestniczyłem w swoim pierwszym obowiązkowym kursie uważności, który był niezwykle przydatny; na miejscu byli specjaliści ds. zdrowia psychicznego, a nawet grupy wsparcia spotykające się co tydzień.”

Zwrócił również uwagę, że specjaliści QA mogą wiele zrobić, aby radzić sobie ze stresem i lękiem na poziomie osobistym:

„Życie jest zbyt krótkie, by martwić się drobiazgami. Specjalistom QA trudno nie martwić się przed premierą nowego produktu ani nie czuć się odpowiedzialnymi za wszelkie rezultaty. Jednak, podobnie jak w odcinku II z Parveen, czasami po prostu trzeba «odpuścić, odpuścić» i nie «zachowywać się na luzie».”

Jonathon Wright, prowadzący podcastu Lider QA

„Jako osoba, która przez całą swoją karierę zawodową zmagała się z lękiem, doświadczyłem różnych trudności i wyzwań, ale zawsze wychodziłem z tego silniejszy i w lepszej sytuacji, by skuteczniej radzić sobie z lękiem — za każdym razem dowiadując się więcej o sobie. Ta branża przyciąga osoby znajdujące się na różnych poziomach spektrum (do których sam się zaliczam). Jednak najbardziej utalentowani ludzie, z którymi miałem okazję pracować, cierpieli na choroby psychiczne, dlatego traktuję swoją chorobę psychiczną jako supermoc!”

Jak zauważył Jonathon, przy odrobinie szczęścia i odpowiednim nastawieniu można zamienić stresującą pracę w satysfakcjonującą. Zachęcam cię do przyjęcia perspektywy oferowanej przez koncepcję systemu wypalenia zawodowego. Pozwól, by lęk odszedł, zachowaj spokój. Następnie spójrz poza nakazy, procesy i narzędzia. Skup się na tym, co naprawdę ma znaczenie: na tym, jak ty i twoi koledzy z zespołu pomagacie sobie nawzajem w tworzeniu świetnych produktów.