Style_Julia
New member
Помню проект, который мы с командой тянули почти год, и помню день, когда наш тимлид просто не вышел на созвон. Не заболел, не уволился — просто выключил ноутбук и две недели не отвечал на сообщения. Тогда я впервые по-настоящему понял, что выгорание — это не красивое слово из статей про продуктивность, а реальная угроза срокам, бюджету и людям. Расскажу, как это выглядело со стороны и что я вынес из этой истории.
Первые звоночки я, честно говоря, проигнорировал. Тимлид стал отвечать в чате позже обычного, потом начал закрывать задачи молча, без привычных шуток и обсуждений. На ретро он впервые сказал, что всё нормально, просто устал. Я кивнул и пошёл дальше — у нас же были дедлайны. Вот это и есть главная ошибка: усталость в IT почти всегда маскируется под профессионализм и спокойствие.
Дальше посыпалось всё сразу. Код-ревью стали формальными, на проде участились мелкие инциденты, а двое джунов начали копировать стиль своего выгоревшего наставника — то есть тихо ненавидеть работу. Мы сожгли три недели на переделку того, что раньше делали за пару дней. Проект не умер, но нервы и доверие заказчика — вполне.
Самое ценное, что я вынес: смотреть надо не на графики, а на людей. Я ввёл короткие личные созвоны раз в неделю — без повестки, без отчётов, просто поговорить. Спрашивал не что ты сделал, а как ты себя чувствуешь и что тебя бесит в текущей задаче. Половина проблем всплывала именно там, за пять минут до того, как превратиться в пожар.
Ещё я начал отслеживать косвенные сигналы. Резкое падение активности в чатах, рост времени на простые задачи, отказ от отпуска, фразы вроде давайте потом, мне некогда — всё это красные флажки. Не надо быть психологом, чтобы заметить, что человек перестал спорить на обсуждениях. Здоровый разработчик всегда имеет мнение и готов его отстаивать.
Что я рекомендую как руководитель и коллега? Во-первых, честно пересматривать сроки: нереальный дедлайн выжигает команду быстрее любого овертайма. Во-вторых, ротация задач — если человек полгода чинит одно и то же легаси, он сломается. В-третьих, право на отдых без чувства вины: отпуск, который приходится выпрашивать, не восстанавливает силы. И последнее — самим руководителям стоит признавать свою усталость. Когда я впервые сказал команде, что тоже выгорел, люди выдохнули и начали говорить правду.
Выгорание не отменяется силой воли, зато отлично лечится вниманием, нормальными сроками и человеческим разговором. Проект мы в итоге спасли, а один из тех джунов теперь сам ведёт команду — и первым делом спрашивает у новичков, как у них дела. Такие истории дают надежду, что мы всё-таки учимся.
А теперь вопрос к вам, форумчане: какой самый ранний и неочевидный признак выгорания вы замечали у себя или у коллег — тот, который потом оказался абсолютно точным?
Первые звоночки я, честно говоря, проигнорировал. Тимлид стал отвечать в чате позже обычного, потом начал закрывать задачи молча, без привычных шуток и обсуждений. На ретро он впервые сказал, что всё нормально, просто устал. Я кивнул и пошёл дальше — у нас же были дедлайны. Вот это и есть главная ошибка: усталость в IT почти всегда маскируется под профессионализм и спокойствие.
Дальше посыпалось всё сразу. Код-ревью стали формальными, на проде участились мелкие инциденты, а двое джунов начали копировать стиль своего выгоревшего наставника — то есть тихо ненавидеть работу. Мы сожгли три недели на переделку того, что раньше делали за пару дней. Проект не умер, но нервы и доверие заказчика — вполне.
Самое ценное, что я вынес: смотреть надо не на графики, а на людей. Я ввёл короткие личные созвоны раз в неделю — без повестки, без отчётов, просто поговорить. Спрашивал не что ты сделал, а как ты себя чувствуешь и что тебя бесит в текущей задаче. Половина проблем всплывала именно там, за пять минут до того, как превратиться в пожар.
Ещё я начал отслеживать косвенные сигналы. Резкое падение активности в чатах, рост времени на простые задачи, отказ от отпуска, фразы вроде давайте потом, мне некогда — всё это красные флажки. Не надо быть психологом, чтобы заметить, что человек перестал спорить на обсуждениях. Здоровый разработчик всегда имеет мнение и готов его отстаивать.
Что я рекомендую как руководитель и коллега? Во-первых, честно пересматривать сроки: нереальный дедлайн выжигает команду быстрее любого овертайма. Во-вторых, ротация задач — если человек полгода чинит одно и то же легаси, он сломается. В-третьих, право на отдых без чувства вины: отпуск, который приходится выпрашивать, не восстанавливает силы. И последнее — самим руководителям стоит признавать свою усталость. Когда я впервые сказал команде, что тоже выгорел, люди выдохнули и начали говорить правду.
Выгорание не отменяется силой воли, зато отлично лечится вниманием, нормальными сроками и человеческим разговором. Проект мы в итоге спасли, а один из тех джунов теперь сам ведёт команду — и первым делом спрашивает у новичков, как у них дела. Такие истории дают надежду, что мы всё-таки учимся.
А теперь вопрос к вам, форумчане: какой самый ранний и неочевидный признак выгорания вы замечали у себя или у коллег — тот, который потом оказался абсолютно точным?