Выгорание тестировщиков: почему так бывает и что делать

Статей про эмоциональное выгорание много, и часть из них очень даже хорошие. Они фокусируются на работе с людьми: как и что говорить, какие ставить задачи, где вести общение, и вот это всё. Я хочу разобрать более узкую тему: специфичное выгорание тестировщиков. И решения буду предлагать не про людей, а про процессы. Как строить такие процессы разработки, чтобы минимизировать эмоциональное выгорание в команде? Какие баги (в коде и в процессе) надо фиксить? На какие штуки обращать внимание? Рассказывать буду с трёх позиций: что с каждой проблемой может сделать биг‑босс (РМ или собственник бизнеса), тест‑менеджер и сам выгоревший тестировщик. Букв в статье получилось много, сорян ))) Зато вроде полезные? Поехали!

11 марта 2024 года. Вентиляторный завод, село Крюково, Московская область:
— Сергей Петрович, здравствуйте. Я сегодня не смогу выйти на работу, потому что я не в ресурсе.
— Жека, да ты чего? А что с тобой?
— Сергей Петрович, мне совсем не хочется работать, не могу войти в поток, у меня упадок сил.
— Женя, ну ты чё, надо заботиться о себе. Совсем упахался. Ты давно с друзьями на рыбалку ездил? А ванну с бомбочками принимаешь?
— Блин, Сергей Петрович, у меня на такое не было времени. Вот видите, до чего я себя довёл.
— Понятно, Жека. Отдохни обязательно пару дней и возвращайся.

Ну как, верите в то, что возможен такой диалог? Вряд ли кто-то с таким вниманием относится к Евгению: слишком мало от него зависит. Если Женя выйдет на работу не в ресурсе, он будет сидеть, собирать вентиляторы, обдумывать свои жизненные проблемы. У него с похмелья будут дрожать руки и, возможно, он даже допустит какую-то ошибку при сборке вентилятора. В результате процент бракованных товаров этого завода на Озоне повысится с 4% до 5%. Кого это парит? Произойдет ли из-за этого какая-то беда? Да нет, конечно. Во многих сферах вопросы продуктивности, выгорания и вот это вот всё беспокоит руководство в последнюю очередь.

В нашем эксплуататорском (без негативной коннотации) обществе забота о сотруднике зависит от того, насколько ответственная у него работа, насколько высока цена риска и насколько сильно зависят результаты работы от душевного состояния человека. В ИТ-сфере это всё значительно важнее, чем на вентиляторном заводе:

В интеллектуальной работе человек со значительно большей вероятностью допустит ошибку, если он не в духе, не в форме, не в ресурсе, не в потоке или как там это называется.
Цена такой ошибки значительно выше. Например, всем известна история про ракету Ariane 5, проектирование которой обошлось в 7 000 000 000 (семь миллиардов) евро и которая взорвалась через 40 секунд после запуска. Причиной послужила глупая ошибка разработчика с копипастом части кода от Ariane 4.

Поэтому мы с вами, ИТ-боссы, уделяем вопросам эмоционального выгорания сотрудников значительно больше внимания, чем Сергей Петрович из вентиляторного завода в селе Крюково Московской области. И делаем мы это не только из-за искренней заботы о сотрудниках и глобальной любви к человечеству, но ещё и потому, что в противном случае ни о какой качественной работе речи идти не может.

Почему тестировщики?

Эта статья могла бы быть про любых айтишников или в целом про любых людей. Но! Я хочу сфокусироваться именно на тестерах. Ну, во-первых, я их знаю, это моя профессиональная сфера, я сама тестер. А во-вторых, у тестировщиков есть своя специфика, которая чаще других ИТ-шников вызывает у них выгорание.

Почему выгорают тестеры

Всем неприятно, когда его гнобит босс. Всем тяжело, когда сжатые сроки. Всем больно, когда проект не настолько успешен, как хотелось бы команде. Все устают от переработок. А что такого эдакого происходит именно с тестерами?

Работа тестировщиков часто оказывается никому не нужной. Ситуация очень простая: начинаем тестировать софт, находим в нем 18432 ошибки, 16 из них исправляются, остальные 18416 так и уходят на прод. В каждом проекте свои требования к качеству, и мы можем работать в таком, где эти требования очень низкие. Мы вроде бы пыжимся, ищем баги, находим, а смысла в этом нет: наша работа уходит котику под хвостик. Абсолютно любому человеку обидно, когда оказывается, что он выполняет ненужную работу. Но именно у тестировщиков такое встречается особенно часто, спасибо вечно сжатым срокам и бюджетам.
Второсортность тестеров. Сейчас эта штука встречается значительно реже, но когда я только начинала свою работу в этой сфере в 2005 году, это было повсеместно. Тестеры считались неполноценными, и эта работа чаще всего воспринималась как стартовый этап в карьере, через который можно было стать кем-то “по-настоящему профессиональным”: программистом, аналитиком и т.д. Тестеры выполняли роль тыкателей кнопок, и в те стародавние времена тестировщиков часто иллюстрировали как мартышек. С тех пор очень многое поменялось. Во-первых, поменялось отношение к качеству. Стало понятно, что от тестеров зависит коммерческий успех, репутация, сроки выпуска проекта. А еще очень сильно выросли требования к квалификации тестировщиков: теперь тестеры должны уметь читать код для тестирования белого ящика, писать его для разработки автотестов, проводить ревью и верифицировать требования, быть грамотными сисадминами, чтобы настраивать тестовое окружение, и вот это всё. Но старое отношение местами ещё сохранилось, и даже супер-квалифицированных-крутанов иногда считают лошками. Когда в компании складывается такое отношение, тестерам, ясен пень, работать некомфортно.
Многие недолюбливают роль тестировщиков. У тестеров нет задачи хвалить, перед ними стоит конкретная задача – указывать на ошибки. Помните Гэндальфа во «Властелине колец»? На него все наезжали за то, что он приносит дурные вести. Да, он никогда ни к кому не заезжал попить кофейку, поболтать про погоду и обсудить новый эпизод ситкома. Вместо этого он приезжал, когда случалась какая-то проблема, где нужна его помощь. В результате его воспринимали как главного гундоса, ему часто не доверяли, типа ты все время только жалуешься и указываешь на плохое, нам надоело это выслушивать. Тестеры – это такие гэндальфы IT-проектов. Они приходят, когда что-то не так, и рассказывают, что именно не так. Эти слова многие воспринимают следующим образом: “Ты облажался, ты сделал хрень, переделывай. А я тут самый умный, в белом пальто, буду тебя учить, как правильно жить”. Даже если тестеры очень деликатные, а все сотрудники команды заинтересованы в успехе и хотят править баги, они все равно чувствуют: тестировщики — люди, которые их вечно гнобят. И относятся к ним соответствующим образом.
Тестировщики вечно во всем виноваты. Бизнес неправильно понял, что нужно заказчику. Аналитик фигово продумал ТЗ. Разработчик допустил кучу косяков. И вот, какую-то часть из этих багов тестировщик пропустил. Софт выходит на рынок. Пользователь недоволен. Негативные отзывы, возможные финансовые последствия. К кому приходит начальство и на кого ругается за проблемы с качеством? Правильно, на тестеров.
Пятая проблема связана с нашей профессиональной деформацией. Только не смейтесь, но мы, тестеры, очень ранимые люди и воспринимаем многое по-другому. Самый крутой квалифицированный тестировщик, который ищет во всем происходящем хорошее, это плохой тестировщик. Именно он гарантированно пропустит неочевидные проблемы, которые расстроят пользователей. А клёвые тестеры пытаются во всем докопаться до сути: А что, если это пойдет не так? А что, если пользователь тыкнет не туда? А что, если аналитик неправильно понял заказчика? Постепенно наши рабочие задачи перестраивают паттерн мышления, и мы видим плохое во всем. Мы хотим пофиксить весь мир: жён, мужей, сотрудников, коллег, политический строй, грядку у подъезда и сломанную мусорку. Поэтому, когда у нас происходят какие-то проблемы на работе, мы всегда в них видим значительно больше плохого, чем, например, аналитики, паттерны мышления которых обычно сводятся не к поиску проблем, а к поиску возможностей. Да, нам правда тяжелее жить и воспринимать все происходящее. По крайней мере, это относится к хорошим тестировщикам, для которых видеть плохое – это одновременно и дар, и тяжкая ноша (простите за патетику, но вот так вот это чувствуется).
Над тестерами все время довлеют сроки. Даже больше, чем над другими сотрудниками команды. Причина очень простая: мы находимся в конце пищевой цепочки. Заказчик продолбал старт проекта, за ним аналитик продолбал сроки, за ним разработчик продолбал сроки. И вот нам в последний момент, за полчаса до релиза, дали огромный продукт на тестирование. И РМ начинает стоять над душой: почему вы не успеваете все проверить за полчаса? И неважно, что изначально мы закладывали на тестирование 3 недели. Вот, сроки поджимают, проект запаздывает. Мы за эти полчаса находим баги, которые мешают релизу и всех бесят: ой, как не вовремя вы их нашли, у нас нет времени на фиксы, аааа, паника! На вопрос “ну когда же вы закончите?” мы отвечаем, что нам нужно еще время. И складывается ощущение, что мы, тестеры, — главные тормоза проекта.

Диагностика поломок тестировщиков

Все мы иногда грустим, устаём, отвлекаемся на нерабочее. Но как понять, что сотрудник не просто “не в духе”, а эмоционально выгорает? Давайте рассмотрим датчики поломок тестировщиков:

Наверное, этот симптом самый главный: тестеры засовывают свое критическое мышление куда поглубже. Они не хотят заводить баги, которые все равно не будут пофикшены. Они тестируют поверхностно. Они боятся жаловаться на проблемы и перестают вечно гундеть о том, что что-то не так, хотя, казалось бы, это их главная миссия.
Противоположное проявление эмоциональных проблем тестировщиков — это потеря толерантности в высказываниях. Вместо того, чтобы четко рассказывать о конкретных проблемах и совместно искать пути их решения, тестировщики начинают говорить “все плохо, наш продукт — полная хрень” и так далее. Это верный признак того, что люди перестали верить в то, что найденные проблемы будут решены и вместо борьбы за качество они просто бухтят.
Они перестают уделять достаточно внимания профессиональному развитию. Такое происходит, если тестировщики разочаровались в своей профессиональной деятельности и сами поверили, что тестеры — второсортники. В этом случае они перестают читать новые книжки, посещать конференции, внедрять новые техники и инструменты. Такие ребята в итоге и сами затухают, и коллег начинают тянуть в болото неразвития.

Ну и, конечно, общие для всех симптомы: чаще опаздывать, чаще болеть, чаще допускать косяки в своей работе, становиться менее внимательным и даже просто реже улыбаться.

Как починить выгоревшего тестировщика? Лечение и профилактика

Прежде чем рассказывать о конкретных решениях — два момента:

Вроде очевидно, что значительно проще не допускать выгорание, чем потом лечить. Если человек уже “сломался”, что-то с этим делать очень сложно. Иногда ему может помочь смена работы, а иногда уже ничего не поможет. К огромному сожалению, как бы стрёмно это ни звучало, такое правда бывает: я встречала полностью сломанных людей, которые не верят в свою работу и вообще в себя. Вот уже кучу лет они ходят на работу только за зарплатой, не испытывая удовольствия, не стараясь, не развиваясь. К счастью для них, есть множество компаний, где такие “зомби-команды” — норма. Но раз вы эту статью читаете, значит, вряд ли это про ваш случай.
Успех починки очень сильно зависит от того, какая у тебя должность и какие у тебя есть возможности что-то сделать. Я постараюсь классифицировать свои советы в соответствии с тремя ролями :
- ты — большой начальник в компании или руководитель проекта, у тебя широкие возможности воздействия на процессы и команду.
- ты — тест-менеджер: руководитель большого департамента тестирования или тимлид маленькой команды из двух человек.
- ты — тестировщик, которого все задолбало, но вместо того, чтобы жаловаться на жизнь и ждать решений от своего руководства, ты сам хочешь вырулить и сделать свои условия работы нормальными.

Шаг 1: Адекватное понимание качества

Здесь я буду категоричной: если на проекте всем пофиг на качество, то на нём гарантированно не будет ни грамотных тестировщиков, ни грамотного тестирования (я видела сотни проектов, и это не преувеличение). Крутые люди с таких проектов либо быстро уходят, либо ломаются и начинают работать из-под палки. На проектах с распилом бюджета всё понятно: качество не нужно, ну и париться тоже не нужно (зачем вы тогда всё это читаете??). Но бывает другая история: мы вроде как декларируем высокие требования к качеству, но по факту на проекте для этого ничего не делается, и атмосфера и восприятие командой — соответствующие. Тогда давайте чинить.

Если ты большой-большой начальник и тебя волнуют вопросы качества, тебе важно это проговаривать с командой, причём не только на словах, но и определить конкретные (желательно измеримые) критерии качества. Самый базовый критерий с точки зрения вышестоящего руководства — это, конечно, коммерческая успешность проекта. А ещё — удовлетворение продуктом и отзывы пользователей. В заказной разработке это значит, что наш продукт быстро проходит приёмку и мы вовремя получаем за него оплату. В продуктовой разработке это значит, что у нас хорошие отзывы, рост продаж, отличные показатели сарафана и низкие затраты на техподдержку.

Я попыталась в паре абзацев описать, как формировать требования к качеству, согласовывать с тестированием и определять “сколько мы готовы за это платить?”, но что-то как-то совсем не умещается. Чтобы не выходить за рамки этой статьи, напишу отдельную. А здесь — вкратце: определи требования к качеству. Согласуй их с отделом тестирования. Спроси “что для этого нужно?”. Это может быть сдвиг сроков, разработка внутренних инструментов и интерфейсов для тестирования, юнит-тесты, выделенные сервера, внедрение обязательного код-фриза и т.д. Подумай, готов ли ты платить такую цену. Чаще всего зарплата пары дополнительных тестировщиков и выделение им достаточного времени несопоставимо ниже полученных от этого проектных выгод.

А ещё — обязательно держи команду в информационном тонусе по качественным показателям. Похвалил заказчик? Об этом должны знать все. Выросла конверсия после юзабилити-аудита? Поделись конкретными цифрами. Оценка в сторе выросла с 3,4 до 4,6? Отведи всех в бар. Команда должна знать, что от их работы есть конкретные измеримые результаты. Понимая связь своей работы с бизнесом сотрудники будут глубже включаться в работу и чувствовать ответственность нового уровня.

Если ты тест-менеджер, то что-то менять сложнее — сначала надо обосновать тому самому биг-боссу. А чтобы кому-то что-то продать, надо говорить на его языке. Какую ценность имеют тест-планы, чек-листы, баги? Ну примерно никакую. Поэтому важно перевести их ценность в плоскость конкретных бизнес-результатов.

Сейчас расскажу абсолютно реальный кейс, который произошел у нас в Лаборатории Качества. Приходим в крупную страховую компанию, у которой нет отдела тестирования. Прям вот совсем нет, и подрядчиков нет. Предлагаем свои услуги, и слышим в ответ вполне логичное “мы работаем уже десятки лет, тестеров нет, аналитики всё проверяют сами. Зачем нам вдруг начинать платить кому-то деньги?”. Ну ок, решили мы, так просто не сдадимся. Заходим на их сайт, скачиваем огромный документ с правилами страхования мелким шрифтом. Готовим по нему продвинутый тест-анализ. Открываем доступный калькулятор расчёта страховок и тестируем. На выходе — куча ошибок в расчётах. Идём к ним опять и говорим “мы нашли кучу ошибок в расчётах!”. В ответ опять вполне логичное “ну и что, зачем нам эти ошибки, никто не жалуется”. И тут мы начинаем переводить эти ошибки на язык бизнеса. Сколько продаётся страховок в месяц? Сколько рублей теряется с каждой страховки? Перемножили и получилось, что за месяц компания теряет почти 8 миллионов рублей. Пошли третий раз, рассказали об этом. Нам конечно не поверили, но интерес мы вызвали. Сели показывать таблицы, расчёты, ошибки. В общем, мы уже много лет с ними работаем, потому что наши услуги значительно дешевле, чем 8 миллионов в месяц. Чувствуете фишку? Переводим на язык денег: вложите 500 тысяч и сэкономьте 8 миллионов. Нет, не обман и не преувеличение, вот расчёты и обоснования.

Абсолютно в любой компании, даже если она не связана с какими-то финансовыми расчетами, тестирование может влиять на коммерческую выгоду. И большая часть ваших руководителей именно эти аргументы примет в первую очередь:

Как изменится прибыль при повышении конверсии по итогам юзабилити-аудита?
Как изменятся продажи при повышении средней оценки в сторах?
Какие штрафные санкции от заказчиков удастся избежать?
Насколько дешевле будет исправить баги, найденные на ранних этапах, а не после релиза в прод?

В подавляющем большинстве случаев тестирование — это инвестиция, которая окупается, но многие руководители проектов и собственники бизнеса просто не умеют это считать и не осознают это. В таком случае, задача тест-менеджера — посчитать и презентовать.

Если ты тестировщик, то очень многое зависит от того, как устроены коммуникации на проекте. Если у тебя есть возможность пойти по пути тест-менеджера, начать всем продавать тестирование и аргументировать важность качества, то, конечно, иди и сделай это. А если у тебя нет такой возможности, а на качество всем наплевать — ищи новое место работы. Там будет и возможностей больше, и климат приятнее, и развитие быстрее.

Шаг 2. Нормирование нагрузки на проекте

Очень часто на казалось бы крутых проектах вижу неравномерную нагрузку тестировщиков. Вот они сидят и ждут сборку на тестирование. Если есть достаточно подробное ТЗ — готовят тест-дизайн. Атмосфера релакса и иногда даже скуки. И тут тыдыщ! — появляется тестовый билд. Все срочно хотят его в релиз, тестерам надо напрягаться и перерабатывать. Эмоциональное выгорание наступает и от скуки, и от переработок, и тем более от таких качелей. Ну и в целом эффективность работы на проекте с таким графиком всегда будет ниже, обычно разработчики тоже попадают на качели, только в противофазу.

Если ты биг-босс, то любые моменты с неравномерной нагрузкой сотрудников надо (и ты можешь) чинить на уровне процесса:

внедрить модульное и интеграционное тестирование (не помню ни одного проекта, на котором внедрение модульного тестирования не повысило бы сроки выпуска новых версий, так что здесь дабл-вин).
внедрить автоматизацию регрессионного тестирования. Иногда для этого придётся вложиться и разработать интерфейсы, но и это тоже дабл-вин — проверка сборки ускорится.
обеспечить более раннюю выдачу сырых сборок в тест (да, разработчики очень не любят, когда на них заводят известные им баги, но в то же время будут находиться и неизвестные, а отдел тестирования познакомится вживую с новыми доработками).
постарайся устроить code-freeze. Да, знаю, в аджайле это не модно, но от этого не менее эффективно. Правила простые: пока тестировщики проверяют сборку, в неё никто не вносит изменения (ну, не пинают балду, а работают над другой веткой). Если по итогам тестирования критичных багов не нашли — релизим, как есть. Если нашли — повторяем всю процедуру заново. Пофиксили — ушли опять на полный цикл тестирования с код фриз. Так будет понятный фиксированный объём работ по тестингу, не придётся ретестить каждый фикс по отдельности, и риски пропуска регрессионных ошибок упадут в разы.

Если ты тест-менеджер, то, допустим, ты не можешь влиять на общие процессы проекта (хотя и постарайся обосновать необходимость изменений). Зато, ты точно можешь влиять на процессы самого тестирования. Упакуй нагрузку так, чтобы в момент появления сборки команда была максимально подготовлена.

Вообще тестирование условно можно поделить на две составные части:

интеллектуальная, когда мы придумываем, как правильно тестировать
ручная, когда мы выполняем эти понапридуманные задачи.

Миссия тест-менеджера во многом сводится к тому, чтобы максимально повышать длительность и качество первого этапа, чтобы максимально сокращать длительность второго этапа.

Как это можно сделать:

понавнедрять автоматизацию и сократить ручной труд в самые нагруженные моменты
понавнедрять крутой тест-анализ. Многие комбинаторные техники, например, Pairwise, позволяют повышать тестовое покрытие и при этом сокращать затраты на непосредственное выполнение ручных тестов. Посмотри, насколько это применимо на твоем проекте и продукте, и постарайся внедрить по максимуму, развивая в тестерах навык тест-анализа. Тут сразу куча плюсов, это ещё и повышение тестового покрытия, и развитие команды, и более творческие задачи. Пока сборки нет — пилим крутые таблички с тестами, сокращая их число с 100500 до 143 (не снижая покрытие!) Появилась сборка — быстренько кликаем и собираем урожай.
устроить коллаборацию тестировщиков с аналитиками. По ТЗ можно понять много сухих конкретных вещей, но сложно “почувствовать” продукт, а это тоже очень важно. Получаем сборку на тестирование и начинаем знакомиться, вникать. Чтобы перенести эти затраты на знакомство с горячей поры на прохладную — устраивайте заранее обсуждение фич с аналитиком. Что это, зачем, как должно работать, как будет использовать клиент. Такие штуки значительно эффективнее проводить устно перед этапом подготовки тест-анализа. И кстати почти всегда мы находим на этом обсуждении аналитические баги, пока они не попали в код — тоже приятный бонус. Опять инвестиция: час потрындели с аналитиком, сэкономили 10 часов на фиксе багов и 2 часа на тыкании продукта.

Если ты тестер, то тоже посмотри, пожалуйста, что ты можешь сделать для улучшения тестирования ещё до того, как у тебя на руках появилась тестовая сборка. Часто такое бывает, что мы откладываем подготовку, вроде как пока и не срочно, это может быть даже просто проявлением прокрастинации. Нормальная отмазка: софта пока что нет и тестить нечего. Нууу…. Неправда! Кучу работы можно сделать заранее. Готовить тестовые среды, прорабатывать тест-дизайн, изучать конкурентов, ну и конечно развиваться. Тестировщик — самое заинтересованное лицо в интеллектуализации своей работы.

Шаг 3. Развитие

Здесь, кажется, всё понятно.

Если ты большой руководитель — направляй развитие сотрудников туда, где это нужно проекту. Это не так очевидно и просто, как кажется. Сначала нужны цели: что ты хочешь, чтобы сотрудники делали лучше? Исходя из этого уже решать, какие тут пригодятся знания. Иногда бывает полезно позвать опытного тест-менеджера со стороны, чтобы за часок оценить, каких знаний не хватает вашей команде.

Если ты тест-менеджер — всё то же самое, направляй через цели. И помогай обязательно с ответом на вопрос “как этому учиться?”, “где получить эти знания?”, “как я помогу тебе закрепить их в работе”.

Если тестировщик — спроси у ТМ-а. Спроси у биг-босса. Спроси у коллег из разработки и аналитики, что они хотели бы увидеть в твоей работе. Обязательно ходи иногда на конференции, там можно не только умные вещи слушать и быть в трендах, но ещё и знакомиться в кулуарах с коллегами и узнавать их боли. Если совсем не получается с конфами — к счастью, почти все записи публикуются на ютубе.

Ну и как всегда, категоричный совет: если учиться хочешь, можешь, учишься, но знания применять негде и никому они не нужны — меняй работу!

Шаг 4. Презентация тестирования

Ну и конечно не забываем о повышении авторитета тестировщиков в команде.

Как-то раз я работала в крупной международной компании, известный проект, 40 тестировщиков. И наши разработчики упорно считали нас лошками, которые просто тыкают кнопочки (ну, я уже описывала эту ситуацию и такое отношение). Честно скажу, наша тест-команда была настоящими джедаями. Но у разработчиков был негативный опыт с предыдущей командой, и нам очень важно было сломать эти предубеждения. Что мы сделали: мы начали устраивать презентации для всей команды. Если просто подойти и сказать разработчикам “давай я покажу, как я здорово тестирую, какой я молодец” это вряд ли кто-то оценит. Поэтому задача “похвалиться” была завуалирована: “Ребята, вот мы тут подготовили тест-анализ на новую фичу. Помогите пожалуйста оценить, что можно улучшить? Вот здесь мы использовали pairwise, здесь triplewise. Да, сейчас объясним, как это. Ага, понятно? Ну так вот, смотрите, мы выявили 64 (!) параметра для выполнения ключевой операции, и благодаря техникам упаковали проверки в 50 тестов”. Первой их реакцией было как всегда “всё фигня”, но потом они начали вникать. Конечно, предложили полезные идеи, мы ещё расширили список параметров, так что тесты реально стали лучше. Но и побочная цель самопрезентации тоже удалась: ого, ортогональные матрицы, как это, ого, как вы это круто скомбинировали, ого, так много проверок и так мало тестов, ого, ого, ого. Постепенно наши отношения изменились абсолютно! Мы устраивали похожие штуки с аналитиками, благодаря чему стали значительно лучше понимать и чувствовать продукт. Здесь пошёл цикл: мы показали, какие мы молодцы. Узнали полезную информацию, стали тестировать лучше. Стали ещё большими молодцами. Презентовали. В итоге вся проектная команда стала вовлечена в тестирование, которое оказалось не “тыканием”, а “ухтышка сложной и важной активностью”.

Поэтому, если ты тестировщик или тест-менеджер, пожалуйста, не забывай презентовать свою крутость. Я понимаю, что мы айтишники, а не продаваны, но показывать себя с лучшей стороны тоже иногда бывает необходимо.

А если ты биг-босс, то придумай вместе с тест-командой, как наилучшим образом организовать такую вот передачу знаний и как вовлечь всю команду в тестирование.

Как починить, если кто-то уже сломался?

Вот ты видишь, что у тебя кто-то очень сильно демотивирован, ты хочешь его починить. Пожалуйста, не додумывай за него причины, по которым он попал в это состояние. Мы очень часто проецируем своё восприятие и в итоге можем додумать несуществующее. Поэтому для начала просто спроси, что ему нравится, что не нравится. Учитывай, пожалуйста, что многие сотрудники, тем более рядовые, тем более, начинающие джуниор-тестировщики, даже сами не смогут для себя сформулировать, вербализовать, и уж тем более они не скажут тебе об этом. Например, как ты думаешь, какой тестер скажет “у меня эмоциональное выгорание, потому что разработчики меня недооценивают”? Зуб даю, никто так не скажет, даже те редкие осознанные сотрудники, которые это понимают. Поэтому лови, пожалуйста, такие штуки по коннотациям, которые в разговоре будет использовать твой сотрудник. И уже исходя из этого, принимай решение, как и что можно починить. Какой из разобранных выше косяков влияет на человека больше всего? Бессмысленно человека утешать, надо чинить процессы, чтобы человеку стало комфортно работать.

И да, есть ситуации, на которые мы повлиять не можем. Первый вариант — когда сотрудник сломан непоправимо. К сожалению, такое бывает. И я очень советую с ним попрощаться, потому что иначе это повлияет на корпоративную культуру и атмосферу во всём коллективе. И второе: бывают компании, которым абсолютно плевать на качество, или в которых руководители такие раздолбаи, что оптимизировать процесс они не готовы, и аргументировать им, почему и зачем это нужно, у тебя просто не получится. Конечно, можно бороться с ветряными мельницами, можно все время экспериментировать и прокачивать в себе коммуникативные навыки, но в какой-то момент все равно это надоедает, а выхлоп небольшой. Так что иногда уйти — лучший вариант для роста.

Бонус: как бороться с рабочим FOMO

Не могу сдержаться, поделюсь маленьким читом совсем не про тестирование. Очень часто у сотрудников (особенно ответственных) бывает FOMO — Fear of Missing Out. То есть, мы боимся что‑то пропустить. Вот у меня рабочий день в 19:00 закончился, я ноутбук закрыла, и сейчас там обязательно без меня что‑то сломается, и мне надо бежать спасать любимый проект. Поэтому мониторим все мессенджеры, почту, 24/7. Не можем расслабиться во внерабочее время — не отдыхаем — привет, эмоциональное выгорание.

У этой штуки есть очень простое решение: договоритесь в своей команде «что делать, если ты мне срочно нужен?». Запишите телефоны и номера друг друга, и в случае, если происходит действительно экстренная ситуация, звоните друг другу по телефону. Вроде очевидно, да? Но нет, мы все привыкли быть вечно доступны в мессенджерах. А теперь внедрите это правило. Несколько раз найдите повод правда позвонить, чтобы люди поняли, что правило работает. И после этого у всех появляется чувство «если мне никто не звонит, значит, я никому прямо сейчас смертельно не нужен». Как только это чувство закрепляется — сразу пропадает паническое желание проверять рабочие чаты вечером в субботу.

Выводы

В такой творческой и ответственной сфере, как тестирование, хорошее эмоциональное состояние сотрудников — необходимость, а не “хотелось бы”.
Помимо общечеловеческих причин эмоционального выгорания у тестировщиков есть своя специфика.
Не допускать эмоциональное выгорание — значит, строить более зрелые процессы, а не гладить людей по голове.
Зрелые процессы это качественные продукты и успешные проекты.
Решать (полностью или частично) причины возможного выгорания можно на любой должности, но иногда у вас это всё равно не получится — тут проще будет работу менять, а не религию руководства.

Всем добра!

Наташа, 28.07.2024, село Крюково Московской области.

ссылка на оригинал статьи https://habr.com/ru/articles/832088/