Проблема выгорания на работе актуальна для всех профессий. И как бы не казалось странным, особенно для работников ИТ-компаний. Почему программисты чаще всего выгорают на работе рассказывает Евгений Рюмин, руководитель отдела разработки StormWall.
По каким причинам программисты чаще выгорают на работе
О проблеме выгорания я знаю не понаслышке. Как-то раз в течение полутора лет я тянул в одиночку активно развивающийся продукт, на мне было все, начиная с обсуждения фич с заказчиком, до их реализации, выкатки на прод и тестирования.. Как мне тогда казалось это была моя сильная сторона, я мог в одиночку сделать то, что по хорошему нужно делать целой командой. Так и бизнесу дешевле и мне проще, думал я. Но были моменты, которые породили во мне чувство страха, это чувство в конечном итоге и привело меня к выгоранию.
Администрирование серверов прода было тоже на мне, и был случай когда я уснул, забыв поставить телефон на зарядку, и в эту ночь неожиданно упали сервера прода, оповещения от пингера я естественно не получил, т.к. Телефон был выключен и, проснувшись утром, получил волну негатива от заказчика – еще бы 5 часов простоя (потери для бизнеса были ощутимы)! В тот день я быстро все исправил, нашел в чем была ошибка, работы было на 5 минут.
Но внутри, как у собаки Павлова, остался рефлекс, и каждый вечер я ворочался в кровати в попытке уснуть, но меня не отпускали мысли о том, что сервер может упасть в любую секунду. Я начал искать выход, сообщил свои все номера телефонов заказчику, дал номер жены, чтобы если я не на связи они звонили ей. Также настроил на телефон жены оповещения от пингера. Немного стало легче, но как говориться осадочек остался. Я не мог устроить себе банальный выходной, даже на отдыхе мои мысли были о проекте, и иногда проскальзывала мысль об упавших серверах, которая вызывала внутренний дискомфорт и тревогу.
В целом все было хорошо, продукт активно развивался, но в один день, примерно по прошествию одного года со старта, я начал испытывать полное отвращение от этого проекта, мне надоели задачи, люди с которыми я сотрудничал, я обратил на это свое внимание, взял себя в руки и выработал план.
Он заключался в том, чтобы выйти из проекта (меня это печалило, но другого выхода не было), я сделал все аккуратно, сообщил заказчику и предложил выход – я подберу персонал и передам все им, а сам уйду на какое-то время, чтобы разобраться в себе. Сначала он не принял это всерьез, но я настоял и дал ему понять, что все достаточно серьезно.
В итоге следующие полгода я передавал дела, обучал молодых разработчиков. И после моего ухода, я занялся своей семьей, нанял репетитора по английскому и занимался с ним минимум дважды в неделю, ну и конечно занимался исследованиями в программировании. Например, хорошо освоил TypeScript, пощупал и изучил все топовые Фреймворки, базы данных, посещал конференции и вебинары. Полученные знания применял но только в своих домашних проектах. И вот, в один прекрасный день, я почувствовал, что я опять в деле и нужно действовать.
В итоге я излечился, на это ушло около шести месяцев и я сделал выводы, о которых расскажу ниже.
Исследования
На тему выгорания есть немало исследований, и в каждом из них прослеживается такая закономерность – если сотрудник работает на максимуме своих возможностей, он рано или поздно выйдет из строя и даже если ранее он имел последовательный успех в своих проектах, начнет показывать кардинально другие результаты, срывать сроки, упадет качество и как следствие снизится эффективность. (Так было и со мной).
Как частный случай выгорания стоит упомянуть отсутствие в некоторых компаниях нормальных практик DevOPS, если в компании выкатка обновлений вызывает стресс у разработчиков то это также может привести к выгоранию.
Также если стабильность прода завязана на одном инженере, то он может испытывать колоссальную ответственность, и стрессовать по этому поводу.
В конечном счете на личном опыте убедился, что руководитель отдела разработки должен удерживать уровень стресса у сотрудников в минимальных значениях, этому есть и классическое объяснение, давайте посмотрим на пирамиду потребности Маслоу,
Самые фундаментальные потребности находятся в основании пирамиды.
И потребность в безопасности занимает место на второй ступени, а высокий уровень стресса воспринимается организмом сотрудника как потенциальная опасность.
Для начала нужно определиться с тем кто это должен мониторить. В нашей компании StormWall этим на постоянной основе занимается непосредственный руководитель отдела, который также занимается выкаткой фич, и знает не понаслышке как все деплоится, какие бывают проблемы. Он может на «собственной шкуре» ощутить всю боль, и если она есть выработать план по ее устранению. К слову сказать этот руководитель я. Мой жизненный опыт дает мне дополнительное понимание процесса выгорания, т.к. я испытал все его эффекты на себе самом.
Плюс периодический «healthcheck» каждого сотрудника, в т.ч. и руководителя проекта, делает наш супер-позитивный HR, и это очень помогает выявлять все на ранней стадии.
Внешние факторы
По моим наблюдениям если сотрудник теряет установленный уровень дисциплины (дисциплина простая: в 10 утра планерка, вечером около 18 вторая планерка), например, начинает опаздывать, отвечать невпопад забывая то, что он делал вчера, то это признак выгорания. Также не забывайте разговаривать со своими сотрудниками о житейских вещах, рассказывайте как устроен ваш быт, делитесь своими переживаниями, и если у вас есть хороший контакт с коллегами то будьте уверены, он тоже поделиться с вами, и при детальном обдумывании его проблем, попытавшись прочитать «между строк», вы увидите что возможно сотрудник на пути к выгоранию.
У скрам есть очень хорошая серия вопросов которые я задаю каждый день себе и своим сотрудникам: «Что ты делал вчера? Какие возникли проблемы? Что ты будешь делать сегодня?», ответы на эти вопросы наводят порядок в головах, и если систематически задавать их, то можно распознать выгорание в самом зачатке.
Ко всему прочему если вы знаете, что ваши сотрудники работают по 12ч в день, будьте уверены – они работают на пределе и выгорание уже не за горами.
Что с этим делать?
Управляйте ситуацией, обеспечьте комфортные условия работы, помогите решить сотруднику его личные проблемы, возможно будет достаточно мудрого и ненавязчивого совета.
Внедряйте практики DevOPS, делайте частые релизы, канареечный деплой (выкатить релиз на 10% клиентов и если все ок выкатить на остальных) все это должно понизить уровень стресса. Тут нужен системный подход, поэтому я бы посоветовал ознакомиться с книгой Ускоряйся! Наука DevOps
Как создавать и масштабировать высокопроизводительные цифровые организации
Николь Форсгрен, Джез Хамбл, Джин Ким (2020)
В этой книге помимо темы DevOPS, теме выгорания уделяется достаточное внимание, прочитав ее, вы сможете понять все ли хорошо в вашей команде, и если нет то исправить это.
Официальное трудоустройство тоже хорошая вещь, это позволяет значительно снизить уровень стресса у сотрудника, вселяя веру в завтрашний день.
На самом деле все хотят хоть иногда выкинуть работу из головы на несколько дней, подумать о своей семье, уделить время личным делам и проектам. А потом вернуться в работу и со свежей энергией продолжить.
Поэтому каждый вечер перед концом рабочего дня я захожу в наш рабочий тимспик и вижу как мои молодые и целеустремленные бойцы без устали трудиться, как они выкладываются на все 150%. Меня это очень вдохновляет, но вспоминая свой опыт я принудительно разгоняю всех членов команды по домам, в конечном итоге держа норму – 8 часовой рабочий день.
Но у ребят были порывы работать в выходные, и это мы тоже постепенно пресекли. Теперь работаем строго по графику, и переработки уже давно не случались. А соответственно и уровень стресса на минимуме.
Будьте добрыми друзьями со своими коллегами, не оставляйте их в беде, помогайте настолько насколько это возможно, людям очень часто просто не хватает доброго общения на отвлеченные темы, делайте это искренне и ваша команда будет успешной!
Резюме
- Будьте добрыми друзьями с сотрудниками.
- Старайтесь не перегружать сотрудников, выдавайте им новые задачи после того как будут решены старые.
- Выработайте практики ежедневной «косвенной» проверки здоровья вашего персонала.
- Если возможно сделайте официальное трудоустройство/долгосрочные контракты – вселяйте уверенность в завтрашний день.
- Проведите анализ здоровья ваших DevOPS практик например по книге Ускоряйся! Наука DevOps, и если требуется – улучшите их.
- Сделайте график работы и принудительно держите всех сотрудников в нем.
- Сделайте 5 дневную рабочую неделю с двумя полноценными выходными.