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

Выгорание как клинический конструкт
В быту выгоранием называют практически любую усталость — например, проснуться в понедельник с мыслью «опять эта галера». Однако у профессионального выгорания есть четкие критерии. Золотой стандарт его измерения — опросник профессионального выгорания Маслач (Maslach Burnout Inventory, MBI). Согласно многофакторной теории выгорания этого же исследователя, это состояние держится на трех основных симптомах:
Эмоциональное истощение — ресурс исчерпан, а сон или выходные уже не восстанавливают работоспособность.
Деперсонализация — защитная реакция психики, при которой все компоненты работы (коллеги, пользователи, документация и даже собственный код) воспринимаются отстраненно, с холодным безразличием или даже раздражением.
Редукция профессиональных достижений — снижение чувства собственной компетентности и продуктивности, обусловленное невозможностью справиться с требованиями на работе и обостряющееся при отсутствии социальной поддержки и возможностей профессионального развития.
Почему так важно отличать выгорание от усталости? Обычная усталость — штука понятная и предсказуемая. Выходные, нормальный сон, в крайнем случае отпуск, и организм восстанавливается. С выгоранием такой финт не проходит — это полноценный сбой.
Хронический стресс нарушает регуляцию оси ГГН (гипоталамус–гипофиз–надпочечники). Как устроен механизм выгорания с точки зрения физиологии:
Стадия тревоги. Гипоталамус сигнализирует о некоторой опасности, гипофиз передает сигнал, надпочечники выбрасывают в кровь кортизол и адреналин. Силы организма мобилизуются.
Стадия сопротивления. Если угроза не уходит, надпочечники начинают работать на износ, в результате чего сохраняется высокий уровень кортизола. В этот момент человек ощущает постоянную раздражительность, тревогу, нарушается сон.
Стадия истощения (то самое выгорание, привет!). Ресурсы надпочечников исчерпываются, и выработка кортизола падает. Но в этот момент система безопасности организма сломана и перестает выключатся. Сил не остается буквально ни на что.
Постоянно высокий уровень кортизола бьет по двум областям мозга — гиппокампу, который в нашем организме играет роль центра обучения, и префронтальной коре, ослабляя ее синаптические связи. Одновременно с этим усиливается активность миндалевидного тела, отвечающего за страх. Из вдумчивого режима работы организм переключается в режим выживания. Мозг переключается в режим энергосбережения, снижается нейрогенез, серьезно ухудшается память.

Уникальность выгорания у разработчиков
Если пропустить через опросник MBI выборки врачей, учителей и программистов, выяснится, что у специалистов, чья работа напрямую завязана на людях, доминирует эмоциональное истощение. Психика перегорает от постоянного контакта с чужими проблемами. У айтишников на первое место стабильно выходит обесценивание собственного вклада.
Причина кроется в природе самого продукта программирования. Оно дает отложенный и часто безликий результат. Можно неделю разбирать легаси или оптимизировать запросы. Пользователь разницы не заметит, задачу закроют. А через год ваш чистый код может обрасти чужими конструкциями, и никто уже не вспомнит, кто вообще над ним трудился. Мозг, ожидающий, но не получающий адекватной усилиям обратной связи, сделает вывод, что работал впустую. Именно это ощущение и запускает механизм редукции достижений, который в итоге является компонентом выгорания.
«Программисты более склонны к негативизму по отношению к своим служебным возможностям, чем работники социальных профессий. Это может говорить о том, что именно показатель редукции личных достижений вносит больший вклад по сравнению с другими показателями в выгорание у программистов. Эти результаты являются еще одним подтверждением обоснованности нашей гипотезы о специфичности выгорания в профессии программиста, которая выражается в особой роли редукции личных достижений как компонента, который вносит больший вклад в выгорание программистов по сравнению с компонентами «Эмоциональное истощение» и «Деперсонализация»». — «Профессиональное выгорание программистов: специфичность феномена», О.И. Муравьева, К.В. Козлова
Исследования показывают, что для айтишников важнее не то, сколько часов они отработали, а то, что их вклад кто-то заметил. В исследовании с 3000+ разработчиков выявили и такую закономерность — когда человек чувствует себя частью команды, растет его удовлетворенность работой, и риск выгорания наоборот падает. Если работа превращается в механический поиск ошибок, а результат труда растворяется, разработчик постепенно теряет чувство авторства. Без этого выгорание приходит даже при идеальном тайм-менеджменте и комфортной зарплате — мозг просто перестает видеть смысл в усилиях, которые не конвертируются в чувство внутренней удовлетворенности результатом.
Триггеры выгорания
Выгорание не возникает на пустом месте — исследователи выделяют конкретные факторы, которые статистически значимо коррелируют с ростом симптомов. Их можно разделить на три уровня.
Системные и процессные
Нереалистичные дедлайны, хронический технический долг и конвейерная разработка без обратной связи создают постоянную когнитивную перегрузку. Мозг работает в режиме «тушения пожаров», что истощает ресурсы быстрее, чем сложные архитектурные задачи. Если работа сводится к закрытию тикетов без реально ощутимого результата, включается механизм редукции достижений, который мы уже обсудили выше.
Организационные и культурные
Согласно тому же исследованию по ссылке выше, важную роль играют такие составляющие, как культура обучения и чувство принадлежности к команде. Проще говоря, там, где ошибки разбирают без порки и занесения в личное дело, открыто делятся знаниями, сотрудник чувствует, что он не просто винтик в системе, а часть чего-то живого и настоящего. Следом подтягивается удовлетворенность от работы — и у риск выгорания заметно снижается.
При этом некоторые личные факторы вроде перфекционизма или неумения говорить «нет» чаще выступают не первопричиной, а лишь усилителем, обостряя ситуацию, когда системные и организационные триггеры уже запущены. И, к сожалению, чинить голову отдельного разработчика бессмысленно, если сам рабочий процесс настроен на выжимание ресурса.
Мифы о выгорании, которые опровергает наука
Вокруг выгорания сформировался устойчивый фольклор. Разберем четыре самых живучих заблуждения и посмотрим, что на самом деле показывают данные.
Выгорание — это лень или слабая воля
Выгорание — физиологический сбой. Как бы вы ни собирали волю в кулак, мозг к нормальному режиму работы от этого не вернется.
Опытные разработчики не выгорают
Возраст и стаж не коррелируют с риском выгорания. Согласно научным исследованиям, «не наблюдается корреляционной связи проявлений выгорания с возрастом и стажем работы».
Удаленка может снизить уровень выгорания
Для кого-то это и сработает. Однако согласно этому исследованию, удаленный формат может выступить триггером к возникновению ментальных расстройств, особенно при отсутствии четких ритуалов завершения рабочего дня и живого социального контакта в команде.
Больше часов работы — больше кода
Экономически и физиологически несостоятельно — после определенного порога переработки начинают накапливаться ошибки, а скорость падает. Согласно этому исследованию, увеличение рабочего времени на 1% приводит лишь к росту производительности всего на 0,9%. А при 10%-ом увеличении рабочего времени общая производительность снижается на 2-4%. Это особенно актуально для сложных технических задач, которые сильно нагружают префронтальную кору головного мозга, отвечающую за концентрацию внимания и решение проблем.
Что реально работает
Советы вроде «возьми отпуск/найди хобби/выбери йогу и медитацию» могут снять симптомы, но не устранят причину выгорания. Бороться с ним нужно сразу на трех уровнях.
На уровне компании
Как мы уже сказали выше, в командах с благоприятной средой (и речь здесь не про корпоративного психолога или ДМС) уровень выгорания ниже, чем там, где карают за ошибки и не дают фидбека. Адекватная защита от регулярных переработок, публичное признание личного вклада и пересмотр метрик успеха могут помочь разработчикам сохранить нормальное состояние психики и организма в целом.
На уровне команды
Команда, конечно, не может в одиночку починить кривые корпоративные процессы, но частично компенсировать системные проблемы все-таки способна. Для этого достаточно внутри своего коллектива договориться о понятных правилах игры. Например, ввести один-два дня в неделю без созвонов, чтобы можно было спокойно погрузиться в код и не дергаться каждые полчаса. Или перестать играть в игру «кто больше затащит» и распределять нагрузку так, чтобы она действительно была реалистичной.
На уровне личных границ
Если система не дает обратной связи, ее придется создавать себе самостоятельно. Мозгу ведь все равно, откуда пришел сигнал «я сделал что-то полезное» — от благодарного пользователя или от галочки в собственном блокноте. Не ждите, пока кто-то погладит по голове, а сами себе напоминайте — вот эту задачу сегодня добил, вот этот баг починил, а вот это отрефакторил. Возможно, это звучит как примитивный лайфхак из паблика про саморазвитие, но на практике это может помочь замкнуть петлю между усилиями и достижениями.
Если узнали себя — это не повод писать заявление и уходить в закат. Лучше задайте себе пару неудобных вопросов. Вы устали от работы или от того, что ее результаты никто не замечает? Когда вы в последний раз получали нормальную обратную связь?
Будем рады, если в комментариях поделитесь рабочими способами, которые помогают лично вам!
dyadyaSerezha
Если с отложенным я ещё могу как-то частично согласиться, то с безликим - нет. Безликим его делает не некая природа программирования, а менеджеры, отрывая группу разработки от пользователей и ставя между ними целую цепочку посредников, каждый из которых к тому же ещё и работает испорченным телефоном.
Это вообще одна из главных проблем и ошибок менеджеров - они не дают прямой обратной связи от пользователей, а про прямой контакт с пользователями я просто молчу, это где-то на грани фантастики. Поэтому почти всегда у группы разработки возникает такое ощущение: группа старается, что-то делает, тестирует, исправляет… А дальше продукт бухается в какую-то черную дыру и совершенно непонятно, как их работа помогла или улучшила реальную работу.
И совершенно таким же образом происходит сообщение о новых требованиях. Хорошо ещё, если требования эти из-за новых законов - ну тут хотя бы всё более менее ясно - надо исполнять и соответствовать. А вот если это пожелания пользователей или некое видение большого босса, то всегда запросы на новый функционал приходят от одного человека в группе (тимлид или аналитик, или ещё кто-то) и он становится неким гонцом от той же черной дыры. То есть, он как по волшебству достаёт из кармана некий список и все должны его делать. Сделали - продукт улетел в черную дыру.
Всё это крайне демотивирует и вызывает то самое чувство абсолютного безразличия и ощущения себя как ненужного мелкого винтика или даже ощущения бессмысленности своего труда.
А выход крайне прост и очевиден - дать группе это ощущение нужности, это ощущение максимально близкой связи с пользователями, видеть их реакцию и фидбэк на продукт и его изменения, всегда чётко объяснять планы и что в них и зачем нужно.
Метод прост, но почти нигде его не используют, увы.
AndronNSK
Я очень рад, что в нашей компании процессы наконец-то выстроились таким образом, что разработчикам (почти) не приходится общаться с очень интересными пользователям в очень интересных местах.
А других пользователей у нашей компании нет.
Dmitry_604
Во всем хорош баланс, я вот без обратной связи бы стух тоже по мотивации, но как правило это обратная связь от наших установщиков на проде и их общения с пользователями, а не конечных пользователей напрямую. Иногда перегибы бывают тоже, но в целом поскольку процессы более менее отлажены - то не так это и плохо.
iprs
Сильно зависит от специфики. Если пользователи каждый день новые - соглашусь, что лучше их не видеть.
А вот если это примерно одни и те же люди в течении всего срока работы (соответственно, и проектов тоже один-два, а не гребля на галере) - совершенно другое ощущение. Чувство морального удовлетворения от рассыпающегося в искренней благодарности заказчика, которому ты своей работой облегчил жизнь - бесценно, и к тому же неплохо мотивирует и дальше качественно писать свой код и развивать навыки, а не ежедневно страдать от кажущейся бессмысленности своих задач.
dyadyaSerezha
Я не про живое общение, а хотя бы про агрегированные данные от пользователей и, может быть, некоторые цитаты из обратной связи по конктерным фичам.
xirustam
На одной из прошлых работ мне приходилось ездить в командировки и иногда сидеть прямо за соседним столом с человеком, который использовал мой софт. Это невероятное чувство, даёт столько мотивации и идей, как улучшить программу... К сожалению, больше такого не было, и программы пишутся в пустоту без обратной связи...
dyadyaSerezha
Во многих проектах в бигтехах мы, разработчики, даже толком не знали, как пользоваться нашей программой. Знали, как работает каждый элемент в отдельности, но не знали общей картины, частоты использования того или иного функционала, его важности и так далее. О какой при этом мотивированности можно говорить?
Camundaslav
По моим наблюдениям, многие менеджеры специально ограждают команду от внешнего мира, чтобы создать иллюзию своей полезности. Аккумулируют у себя весь фидбек от пользователей или продакт оунеров, чтобы сделать себя единственным источником правды.
Все это подается под соусом заботы о ментальном здоровье команды, правда саму команду естественно никто не спрашивал, нужна ли им такая забота.
Redos
Прочитал Ваш комментарий и даже захотелось ответить. Не в упрек будет сказано, но мне кажется это также подача лишь с одной стороны: у меня в команде 10 человек и каждый со своим уровнем “exposure”. А причина проста - далеко не всем требуется именно прямая связь с клиентами (стейкхолдерами, называйте как хотите). Упирается все вновь в уровень софт скиллов - кому-то приятно работать напрямую с обратной связью, а кто-то испытывает трудности из-за домена и понимания что же конкретно бизнес делает. Поэтому, на мой взгляд, зависит все, как обычно, от конкретного человека и нельзя с уверенностью утверждать что все хочется видеть прямой фидбек.
Redos
.
dyadyaSerezha
Да я не про то, чтобы с клиентами в барах драться, грубо говоря, а про то, чтобы разработчик чувствовал и видел как-то влияние того, что он сделал. Я уже написал в одном из комментов тут про это.