Три года назад я впервые столкнулся с выгоранием в масштабе целой команды. Не у одного человека — у всей команды из восьми разработчиков одновременно. Проект был критичным, дедлайны жёсткими, а влетающих задач становилось всё больше. На второй месяц работы в таком режиме люди начали писать заявления на увольнение. Первый звонок прозвенел, когда сеньор с пятилетним опытом сказал: “Я больше не могу так работать”.
С тех пор я управляю пятью командами на 30 человек и постоянно думаю о том, как не повторить ту историю. За это время я выработал набор инструментов, которые помогают держать нагрузку под контролем — не для галочки, а потому что команда, работающая на износ, теряет эффективность быстрее, чем вы успеваете нанять замену.
Признаки перегруза — когда уже поздно и когда ещё можно
Выгорание команды не происходит за один день. Оно копится месяцами, и если вовремя не заметить ранние признаки, вы получите кадровую катастрофу.
Ранняя стадия (ещё можно исправить):
- Люди начинают задерживаться на работе, хотя раньше уходили вовремя
- На стендапах всё чаще звучит “почти сделал, но появилась ещё одна срочная задача”
- Код-ревью занимает больше времени — люди устают, внимание рассеивается
- На встречах появляется раздражение по мелочам
Когда я вижу эти сигналы у двух-трёх человек одновременно — это не совпадение. Это признак системной проблемы с нагрузкой.
Средняя стадия (нужны срочные меры):
- Люди перестают предлагать идеи на митингах, становятся пассивными
- Растёт количество багов в коде — признак усталости и потери фокуса
- Появляются конфликты в команде, которых раньше не было
- Сотрудники начинают “забывать” про задачи, хотя раньше такого не случалось
На этом этапе я останавливаю всё и провожу серию one-on-one, чтобы понять масштаб проблемы. Как вести такие разговоры — я разбирал в статье про обратную связь. Обычно выясняется, что люди не жалуются, потому что боятся выглядеть слабыми или думают, что “все так работают”.
Критическая стадия (люди уже выгорели):
- Заявления на увольнение
- Больничные без видимых причин (люди физически не могут заставить себя прийти)
- Полное отсутствие инициативы — делают только то, что явно сказано
- Саркастические комментарии про работу в общих чатах
На этой стадии восстановление занимает месяцы, и часть людей вы уже потеряли безвозвратно. Ваша задача как руководителя — не доводить до этого.
Приоритизация — это не про todo-лист, а про выживание команды
Когда задач больше, чем команда может выполнить, единственный способ не сгореть — научиться говорить “нет” или “не сейчас”. Но для этого нужна система, которую понимают все: и команда, и продуктовые менеджеры, и топ-менеджмент.
Я вложил 2 квартала на то, чтобы выработать, выровнять с коллегами и внедрить единый стандарт приоритизации для команд в моём управлении. Основная идея проста: не все задачи одинаково важны, и не все срочные задачи действительно критичны.
Четыре уровня приоритета
Я использую четыре уровня, и у каждого свой срок реакции:
🔴 Критически — немедленно
Это задачи, которые блокируют ключевую бизнес-функцию или представляют критическую угрозу. Например: кнопка “купить” не работает; сервис недоступен для всех пользователей, утечка платёжных данных.
Когда приходит критическая задача, команда останавливает текущий спринт и переключается. Без вопросов. Но — и это важно — такое должно случаться редко. Если у вас каждую неделю появляется Критическая-задача, проблема не в задачах, а в процессах — стоит покопать глубже методом «5 почему».
В моей практике за последний квартал было 2 настоящих “крита”. Два за три месяца на пять команд. Если у вас больше, то потенциально вы неправильно оцениваете приоритеты или у вас есть скрытые проблемы с качеством кода и инфраструктурой.
🟠 Высокий — ближайший спринт
Серьёзные проблемы, но есть обходной путь. Важные регуляторные требования с близким дедлайном. Медленная работа системы, на которую жалуются пользователи.
Эти задачи планируются в следующий спринт, но не выдергивают команду из текущей работы. Оценочно это около 20-30% бэклога в любой момент времени.
🟡 Средний — очередные спринты
Улучшения, которые важны, но не срочны. Технический долг, который замедляет разработку (иногда это следствие неоправданно сложной архитектуры). Регуляторные требования с дедлайном через полгода-год.
Это основная масса работы — 50-60% бэклога. Здесь планирование идёт по дорожной карте, с учётом стратегических целей.
🟢 Низкий — по остаточному принципу
Опечатки, косметические дефекты, теоретические уязвимости без доказанного вектора атаки. Эти задачи делаются, когда есть свободное время или когда разработчик хочет сделать что-то простое для переключения.
Главное правило: приоритет = ответственность
Окончательный приоритет для продуктовых задач ставит продуктовый менеджер. Для технических задач — тимлид. Но если продакт и техлид не согласны, то решение примает юнитлид.
Это звучит жёстко, но это единственный способ избежать ситуации, когда все задачи становятся критами, потому что “это важно для бизнеса”. Важно — не значит срочно.
Влетающие задачи и директивные запросы — как не превратить спринт в хаос
Самая частая причина перегруза — не плохое планирование, а постоянные влеты. Задачи, которые прилетают в середине спринта с пометкой “срочно” или “от ТОПов”.
Моё правило: любая влетающая задача оценивается по тем же критериям, что и запланированные. Даже если запрос пришёл от топ-менеджера.
Как работать с директивными запросами
Когда CEO, CPO или CTO говорит “нужно сделать это срочно”, у вас два варианта:
- Сказать “да” и сломать спринт
- Задать вопросы и договориться
Я всегда выбираю второй вариант. Вот что я спрашиваю:
“Что произойдёт, если мы не сделаем это прямо сейчас?”
Этот вопрос помогает понять реальную критичность. Если ответ “потеряем ключевого клиента” или “получим штраф от регулятора” — это действительно критически важно. Если ответ “хотелось бы показать на встрече через неделю” — это высокий приоритет, и мы планируем в ближайший спринт.
“Что можем отложить взамен?”
Спринт — это не резиновая лента. Если добавляем новую задачу, что-то другое нужно убрать. Я всегда предлагаю список текущих задач и прошу выбрать, что менее важно.
Важный момент: я не спорю с приоритетами. Я прошу явно выбрать, что важнее. Это превращает эмоциональное “срочно!” в рациональное обсуждение размена более важного на менее важное.
“Есть ли обходной путь на первое время?”
Часто срочную задачу можно разбить на минимальное решение, который закрывает острую боль. Параллельно разрабатывая полную реализацию, которая делается по выстроенному процессу и дорожной карте. Временный фикс за два часа лучше, чем сломанный спринт и выгоревшая команда.
Правило 20% на влеты
Я стараюсь закладывать 20% ресурса на непредвиденные задачи. Не грузить команды “по самое ни хочу”, а под 80%. Оставшиеся 20% — буфер на влеты, баги, больничные, помощь коллегам.
Когда я впервые предложил это продуктовым менеджерам, они возмутились: “Как это — 20% простоя?”. Я объяснил: это не простой, это страховка. Без неё мы либо срываем дедлайны каждый спринт, либо работаем на износ.
Через три месяца работы с буфером мы начали стабильно закрывать спринты вовремя. Без переработок. Продакт-менеджеры перестали жаловаться.
Защита времени команды — как тимлиду стать щитом, а не воронкой
Руководитель должен защищать время команды. Не перепоручать все запросы вниз, а фильтровать их на своём уровне.
Митинги — пожиратели времени
Я видел команды, где разработчики проводили по 3-4 часа в день на встречах. Дейлик, груминг, планниг, синк с продуктом, демо, ретро, 1-1 … По итогу у человека остаётся два часа на доставку артефактов (код, тесты, дизайн), а потом он сидит до вечера, потому что “не успел ничего сделать”.
У разработчика не должно быть больше 10 часов митингов в неделю! Это примерно 2 часа в день, с учётом того, что не каждый день одинаково загружен.
Да, есть необходимость созвонов для обмена опытом, ревью, парного программирования, архитектурных проработок. Но это часть доставки и реализации в счёт времени “встреч” это не идёт.
Как этого добиться:
- Не все встречи обязательны для всех. Если на синхронизации команд нужно обсудить интеграцию API — пусть придут те, кто этим занимается, а не вся команда.
- Таймбоксинг жёстко. Ежедневный дейли — до 30 минут, не час. Если не укладываетесь — у вас не стендап, а статус-митинг.
- Асинхронная коммуникация вместо лишних встреч. Иногда достаточно текста в чате или документа с комментариями.
Я слежу за календарями команды. Если вижу, что у человека 15+ часов встреч в неделю — выясняю причину и убираю лишнее. Иногда это значит, что мне нужно пойти на митинг вместо него.
Коммуникация вверх — как объяснить менеджменту, что команда перегружена
Самое сложное в управлении нагрузкой — это донести до топ-менеджмента, что команда работает на пределе, и нужно что-то менять. Особенно если менеджмент не технический и не понимает, почему “просто добавить кнопку” — это не два часа работы. Как правило, вышестоящие руководители отлично понимают понятие нагрузки и приоритетов. Имея полную картину они быстро смогут вам сказать от чего стоит отказаться, где пере-договорится по срокам, а где они могут вам помочь.
Говорить на языке бизнеса
Я никогда не говорю: “Команда устала” или “У нас слишком много задач”. Это пустая жалоба. Вместо этого я говорю:
“При текущей загрузке мы рискуем сорвать дедлайн по проекту X, который приносит Y% выручки”
или
“Два сеньора за последний месяц рассматривали покинуть компания. Замена каждого обойдётся в 3-4 месяца найма не считая онбординга. Это отложит релиз проекта Z на 2 квартала минимум”
Риски и деньги — это язык, который понимает менеджмент. Не эмоции, а последствия для бизнеса.
Показывать trade-offs явно
Когда приходит запрос на новую функцию или проект, я всегда отвечаю не “нет”, а “да, но…”:
“Да, мы можем это сделать. Но тогда проект X сдвинется на два спринта. Что для вас важнее?”
Это не моё решение. Это решение бизнеса. Моя задача — показать цену каждого выбора.
Если менеджмент говорит “нужно и то, и то”, я говорю: “Хорошо, тогда нам нужно либо увеличить команду, либо снизить планку качества, либо сдвинуть дедлайны. Что выбираем?”
Что делать прямо сейчас
Если вы узнали признаки перегруза в своей команде — начните с малого.
Проведите индивидуальные встречи с каждым. Спросите напрямую: “Как ты себя чувствуешь с точки зрения нагрузки? По шкале от 1 до 10, где 10 — я на грани выгорания?” Не принимайте “нормально” за ответ. Копайте глубже.
Посчитайте, сколько встреч у каждого разработчика в неделю. Если больше 10 часов — уберите лишнее. Если не можете убрать поставьте их подряд, для экономии когнитивной энергии на переключения.
И введите явную систему приоритизации. Не обязательно мою — любую. Главное, чтобы все в команде и за её пределами понимали: не все задачи одинаково важны, и не все срочные задачи требуют немедленной реакции.
Итог
Управление нагрузкой команды — это не про то, чтобы все постоянно были счастливы и расслаблены. Это про то, чтобы команда работала стабильно и долго. Без авралов каждую неделю и без текучки кадров каждые полгода.
За три года управления несколькими командами разработки я, к сожалению, потерял 3 человек за 3 года из совокупно 30 человек. Это меньше 4% текучки. При этом мы выпускаем релизы стабильно, закрываем 85-90% запланированных задач в квартал и не работаем по выходным (ну кроме инцидентов).
Приоритеты, защита времени, честный разговор с менеджментом — ничего революционного. Задача руководителя — не загрузить команду по максимуму, а выстроить темп, в котором люди могут работать годами.
Теги: