Термин «выгорание» вошёл в мою жизнь как-то неожиданно. Работал я. Работал много лет: сначала кодил, потом свои проекты делал, команды собирал, бизнес налаживал… И тут — Бац! Куча мемов на эту тему во всех связанных с IT-ресурсах. Не знаю, то ли я в какой-то тундре жил, то ли тундра жила во мне. Но да ладно: мемы почитал, поржал и забыл. А тут неожиданно этот термин вошёл в обиход моих ребят. Где-то как бы в шутку, где-то в серьёз. А мы все знаем: в каждой шутке есть доля шутки, а остальное — чистая правда.  Это начало влиять на рабочий процесс. Простые задачи стали требовать больше ресурсов, некоторые затягиваться на ровном месте. Люди начали чувствовать себя дискомфортно. При этом я заметил, что чем моложе команды (в плане рабочего стажа), тем больше тема выгорания поднималась и тем активнее в них стали развиваться проблемы.  Признаюсь, поначалу я закипел. Для меня было очевидно, что проблемы элементарны. Время и ресурс, которые уходят на разговоры про выгорание, можно было потратить на их решение, и проблем бы просто не было. Для меня это выглядело так: люди сами себе создали проблемы, а теперь говорят, что им дискомфортно. Накатил типичный сеньорский снобизм:  «Вот я в своё время по 10 часов работал без выходных и отпусков. Скучные проекты пилил, ночью на проде хотфиксил и т.д. и т.п. У ребят же условия другие: график нормированный (авралы, конечно, бывают, но всё в рамках), переработки оплачиваются х1,5-х2 (всё по ТК), проекты интересные. Премии! Отпуска! Работа, блин, командная! Не как дурак сидишь и всё в одного пилишь, а в коллективе ответственных товарищей. Какое, мол, выгорание? Я вам сейчас расскажу про выгорание!» Ну и прочая блажь в том же духе. Впрочем, внутренняя сеньорская обезьяна перебесилась, и включился мозг. На всякий случай перепроверив график отпусков, выплаты зарплат и всякие наши бонусы (а то вдруг я чего-то не знаю) и убедившись, что интересные проекты никуда не делись, я затаился и начал пристально наблюдать за этим явлением.  Пока я наблюдал, ещё успел проявить экспертность :) и посёрфил интернет. Естественно, я наткнулся на всякую блажь вроде «40 инсайтов противодействия выгоранию» и прочую инфоцыганщину. Товарищи, ответственно заявляю: любой мануал на эту тему, где заботу о выгорании предлагают поручить HR или ИИ (он же Искусственный Идиот) — надо срочно сжигать! Ниже я объясню почему.  Но всё же выгорание включено в Международный Классификатор Болезней, который выпускается ВОЗ, а значит, это дело и профессиональных сообществ. Я изучил как первые работы (инфоцыганские), так и профессиональные труды, и сопоставил их со своими наблюдениями за коллективом. А также успел провести практические опыты и получил важную практику, которой хочу поделиться с тимлидами и менеджерами проектов.  Для начала определяем, что статья «цыганская». Как? Очень просто! Вас будут убеждать, что выгорание — это про усталость, обесценивание и токсичность атмосферы. Чем больше подобных терминов, тем более глупой кажется каждая такая статья. В качестве выхода из выгорания они будут предлагать: больше отдыхать и ходить на массаж. К сожалению, такая постановка вопроса не просто бесполезна в практическом плане, но и напрямую вредна. На всякий случай поясню: я только «за», чтобы люди больше отдыхали и ходили на массаж, но мои практические наблюдения говорят, что это не помогает. Я несколько раз наблюдал, как выгоревшие или близкие к этому сотрудники ходили в полноценный отпуск, где их никто не трогал, но возвращались в ещё большем стрессе. То есть проблемы вроде перегрузки, несомненно, способствуют выгоранию, но, на мой взгляд, не являются его причиной. При этом, если сотрудник нашёл в «цыганской» статье обоснование своего стресса через обесценивание или токсичность, он… будет искать это во всём, даже если в реальности этих явлений нет. А не найдя ничего, он будет создавать эти явления самостоятельно, тем самым увеличивая свой стресс и создавая его для окружающих. Доходить может до смешного: похвала одного сотрудника воспринимается как обесценивание работы другого. Начитались умных слов, блин :) Гораздо более полезную информацию я нашёл в научных работах (какая неожиданность!). Мне очень понравилась одна диссертация[1]. Можно даже сказать, что я нашёл её эмпирические подтверждения в своей компании. Простая магистерская некого Вейбера Н.Ю. устанавливает прямую корреляцию между конфликтной компетенцией и выгоранием в командах. И из моего опыта: элементарное разъяснение сотрудникам термина «Рабочий конфликт» и объяснения простейших методов работы с ним снимает выгорание, как зелёнка микробы. Итак, перейдём, наконец, к практике и инструментам.   Сразу скажу, что я не конфликтолог. Всем, кто хочет научной теории, необходимо обратиться к профессионалам в этой сфере. Я же всего лишь делюсь личными идеями, наблюдениями и практическими выводами. И я определяю рабочий конфликт как конфликт, который возникает между двумя и более людьми, находящимися в функциональных ролях. То есть это конфликт не между Машей и Петей, а между разработчиком Петей и менеджером Машей. При этом Маша и Петя могут быть друзьями, вместе ходить на тусовки и играть в онлайн игры, но конфликтовать именно как разработчик и менеджер.  Хочу заметить, что личные дружеские отношения могут только усугубить рабочий конфликт. К примеру, Маша может постесняться указать Пете на недостатки в его работе именно из-за дружеских отношений или тем более лишить части премии. Как так-то? Они ведь друзья! При этом, если руководитель вроде тимлида или менеджера работает в парадигме «начальник — подчиненный» и может просто «держать дистанцию», то каждому сотруднику это не объяснить. Соответственно, в моём понимании личный конфликт — это уже конфликт непосредственно между Машей и Петей. При этом каждый нерешенный рабочий конфликт со временем перерастает в личный. Как отличить? Очень просто. Пока конфликт ещё рабочий, Петя будет говорить «у нас плохой менеджмент». Когда конфликт личный, Петя скажет «Маша дура!».  Очень интересным способом рабочий конфликт превращается в личный, если Маша и Петя — друзья. Тогда они совместно решат, что дурак, к примеру, технический директор. Будучи вообще не замешанным в этой истории, он может очень удивиться :) Разберём, как это работает на конкретном примере: Вот у нас есть два разработчика в молодой небольшой команде человек на 5-10. Один, допустим, бэкендер Иван, другой фронтендер Миша. Фронтендер осуществляет интеграцию с API, которое сделал бэкендер. Говоря по-простому, работа Миши зависит от работы Ивана. Менеджер на обоих давит по срокам выполнения работ. Иван под давлением сроков выпускает свою часть работы с набором ошибок. То есть в целом всё работает, но то тут, то там нужны небольшие исправления. И Иван такой говорит Мише: «ты обращайся, если что, я поправлю». И всё бы хорошо, только такой расклад дел повлияет на работу Михаила. И из-за этих «правок» он не успеет сдать свою работу вовремя. И тут возникает рабочий конфликт:  либо Михаил возвращает работу Ивану, и тогда получается, что Иван не справился, либо уже не справится Михаил. Ну во-первых, Иван вообще не должен так поступать. Если ты по каким-то причинам не можешь справиться с задачей, это необходимо выносить на менеджера или старших товарищей, а не перекладывать свои проблемы на других. Но если уж Иван так поступил, Михаил не должен начинать свою работу в такой ситуации. Уже Михаил может вынести это на менеджера, и они могут найти несколько решений. К примеру: увеличить срок для Михаила, вернуть Ивану на доработку, разобраться, в чем трудность у Ивана с тем, чтобы сделать работу качественно, и так далее. Да может быть, просто оценка задач была сделана неверно!  Но если они не умеют адекватно разрешать такие ситуации, может возникнуть несколько плохих сценариев. Самый плохой из них как раз возникает тогда, когда Михаил молча берёт это всё в работу, потому что не хочет конфликтовать с Иваном. Тогда такой конфликт становится скрытым (о нём не знает никто, кроме Ивана и Михаила). Эту историю может пропустить даже опытный менеджер, не говоря уже о неопытном. Когда в команде накапливается множество таких скрытых конфликтов, вся работа превращается в сплошные переработки и прочий производственный ад. То есть, на мой взгляд, те проблемы, о которых пишут в статьях про выгорание, являются симптомами, и лечить их бесполезно. Заливать их деньгами и бонусами — это просто удерживать человека в дискомфортных для него условиях. А причина — это именно такие вот скрытые рабочие конфликты, которые могут сделать нерабочим любой, даже самый лучший процесс.  Дисклеймер для Эффективного Менеджера Совы: платить людям хорошие деньги и организовывать различные бонусы обязательно надо! Люди должны чувствовать отдачу от своего труда, тогда вы с ними будете работать долго и счастливо. Но заливать деньгами нерешенные рабочие конфликты — это значит надежно закрутить крышку скороварки, которая потом обязательно взорвется. Итак, ещё раз. Для команды было бы гораздо полезнее, если бы Михаил открыто поругался с Иваном. Тогда к этой проблеме было бы привлечено внимание, и появился бы какой-то шанс её решить. Но надо ли ругаться с коллегами из-за рабочих конфликтов? Нет! И ещё раз нет! Давайте поговорим, как их решать. Рабочий конфликт необходимо решать в двух плоскостях. В организационной и в личной. Именно поэтому вы не можете переложить их решение на HR. Грамотный отдел HR, который занимается не только рекрутингом, но и работой с коллективом, может поддерживать общую атмосферу, не более (но и не менее).  Итак, приведем пример организационного решения описанного конфликта между Иваном и Михаилом: Самый простой вариант — «в лоб»: поставить между ними тестировщика, который проверял бы работу Ивана, прежде чем она пойдет дальше. Но мы находимся в рабочем конфликте, и это может быть недостаточно. Иван может легко перенести конфликт на тестировщика.  В дополнение к этому действию нужно проработать конфликт и с Иваном, и с Михаилом: элементарно объяснить Ивану, что он не должен провоцировать такие ситуации, и обязательно дать ему организационные решения его проблемы. Просто сказать «так больше не делай» не получится. Возможно, Ивану попали сроки, оцененные мидлом, а он — джун. Надо понять, как так получилось, устранить дальнейшую возможность повторения и объяснить, что в случае повторения проблемы он должен обращаться к тимлиду. Михаилу же необходимо объяснить, что если он будет брать такие задачи в работу, это: Медвежья услуга для Ивана. Губительно для проекта. Губительно для самого Михаила. Проблема в том, что рабочие конфликты склонны складываться в цепочку. Пытаясь решить конфликт, мы можем выяснить, что Тимлид ведёт себя агрессивно по отношению к подчиненным, с ним невозможно обсуждать сроки. Что ж, похоже, у нас следующий конфликт. Переходим к нему :)    Также важно понимать, что люди должны быть мотивированы на решение конфликта. Ивану может быть вполне комфортно в его ситуации. И вам придется ему объяснить:  так работать дальше не получится, потому что проекту нужен конечный результат, а не это вот всё с перекладыванием ответственности. Как определить, комфортно ли Ивану? Ведь он в любом случае будет рассказывать всем, как ему плохо. Очень просто — судите по делам, а не по словам. Если человеку плохо на рабочем месте, но он сопротивляется любым попыткам улучшения, значит, его на самом деле всё устраивает.  В общем, вас ждёт много, очень много one-to-one мероприятий. Или что, думали этим только HR должны заниматься? :) Разговаривайте с людьми — разговаривайте лично. С толпой в этом смысле говорить бесполезно. Самое главное — это не злиться на людей. Всё, что я пишу выше, для меня давно очевидно. Но приходится объяснять очевидные вещи раз за разом — это жизнь. Поверьте, если хорошо подумать, вы поймете, что кто-то очевидные вещи объясняет вам :) Но, если вы потратите достаточно усилий и распутаете большинство конфликтных цепочек, вы увидите как на работе станет спокойно, переработки резко сократятся, а люди станут чаще улыбаться :) Выгорание, на мой взгляд, — это следствие накопившихся рабочих конфликтов. Они создают невозможные условия работы даже при внешнем благополучии. Переработки и прочие проблемы — это симптом. «Вылечить» его можно только системным устранением конфликтов. Также очень важно понимать, что здоровая команда решает конфликты самостоятельно. Менеджеры и тимлиды нужны для настройки, но они не должны судорожно бегать по команде, решая те или иные проблемы. На худой конец, в запущенных случаях они могут выступать модераторами. Так что здесь ответственность совокупная: с одной стороны, руководитель должен организовать работу так, чтобы у команды были знания, как грамотно разрешить рабочий вопрос / конфликт; с другой стороны, команда должна ими активно пользоваться. Всех благ и здоровых рабочих отношений! :) P.S.   [1] — Ссылка на диссертацию: clck.ru/bFsYs  Разработчик, Тимлид, Директор :)