Пятница, вечер. Менеджер открывает таск-трекер: спринт закрыт на 94%, задачи двигаются, в чатах порядок. Всё горит идеальным зелёным светом. Через три недели два ключевых разработчика одновременно кладут на стол заявления. Один — молча, второй — с дежурной фразой про «накопившуюся усталость». Менеджер не понимает, где пропустил сигнал. По отчётам команда была в норме.

Эта иллюзия благополучия обходится дорого. По данным S-PRO за 2026 год, 46,1% работающих россиян уже находятся в состоянии выгорания. Половина из них называют главной причиной слишком большой объём работы.

Стандартные отчёты показывают только часы и количество задач. Реальная причина увольнений — скрытая когнитивная нагрузка. Ментальный ресурс сотрудника выгорает в ноль задолго до первых сорванных дедлайнов.

Ниже разбираемся, как измерять этот ресурс, какие поведенческие сигналы пропускают трекеры и как перестроить операционные процессы.

Количественная нагрузка против когнитивной: в чём разница

Разберём классический пример с двумя сотрудниками в одном спринте. У первого в работе пятнадцать понятных, однотипных задач с чёткими критериями приёмки. У второго — всего пять задач, но каждая требует согласования с четырьмя стейкхолдерами, ТЗ размыто, а приоритеты меняются дважды в неделю. Оценка нагрузки по количеству тикетов здесь принципиально не работает, так как она путает количественные показатели с когнитивным давлением. Менеджер видит в трекере свободные часы, но не замечает стоимость постоянных переключений, уровень неопределённости и расход энергии на сложные коммуникации.

Стандартные отчёты не фиксируют когнитивную нагрузку, хотя именно она истощает команду. Ментальный ресурс сотрудника сгорает на преодолении барьеров вокруг задачи, а не на её выполнении. Нагрузка растёт каждый раз, когда человек вынужден переключаться между несвязанными контекстами, часами ждать ответа от заблокировавшего его коллеги, балансировать между противоречивыми требованиями разных руководителей или работать без базового критерия готовности (Definition of Done). В итоге рабочий день уходит на борьбу с организационными тупиками, а к непосредственным обязанностям сотрудник приступает уже уставшим.

Именно поэтому механическое сокращение объёма работы редко решает проблему выгорания. Исследования McKinsey Health Institute подтверждают, что этот кризис напрямую связан с дизайном работы — структурой процессов, распределением зон ответственности и качеством менеджмента. Если система распределения задач сломана, уменьшение их количества просто растянет те же самые операционные тупики на более долгий срок.

По данным Хабра, перегруз чистым объёмом работы составляет меньше половины всех случаев выгорания. Остальное — это несоответствие ролей, потеря смысла и отсутствие автономии. В условиях хаоса и хронической неопределённости сотрудник может выгореть даже при шестичасовом рабочем дне, так как на каждое действие накладывается невидимый «налог» в виде стресса от независящих от него факторов. В то же время его коллега может увлечённо кодить по десять часов в состоянии потока и чувствовать себя отлично, потому что процессы прозрачны, а сам он полностью контролирует свои задачи и понимает их ценность для продукта.

Настоящая перегрузка всегда возникает из-за дисбаланса требований и ресурсов. Требования включают в себя не только физический объём задач, но и их сложность, неопределённость требований и коммуникационные издержки. Ресурсы — это доступное время, энергия, ясность приоритетов и реальный контроль над ситуацией. Если количество задач в трекере ничего не говорит об этом балансе, менеджменту необходим принципиально другой индикатор.

Flow Efficiency: метрика, которая покажет выгорание за недели до кризиса

Flow Efficiency (FE) показывает, сколько времени задача действительно находилась в работе, а не кисла в очередях.

FE = Active Time / Total Cycle Time × 100%

Парадокс в том, что у нормальных Kanban-команд этот показатель редко превышает 15–40% (классика, описанная Клаусом Леопольдом в Rethinking Agile). Звучит дико: получается, большую часть времени задача просто лежит?

Именно так. Она ждет код-ревью, ответов от заказчика, тестирования или релиза. И для большинства процессов это здоровая картина.

Но если FE падает ниже 10% — пора бить тревогу. Это главный симптом когнитивной перегрузки команды.

Механика буксования: почему падает эффективность

Когда на команду наваливают слишком много, люди не начинают лениться — они начинают переключаться.

  • Как надо: взять задачу и сделать её за 2 сфокусированных подхода.
  • Как происходит при перегрузке: у сотрудника нет ментальной емкости держать сложный контекст. Он берет задачу, продвигает на миллиметр, откладывает. Берет вторую, дергается на созвон, возвращается к первой, полчаса вспоминает, на чем остановился.

В итоге вместо двух нормальных сессий задача проходит через десять «микро-подходов». На бумаге человек занят 24/7, по факту — процесс стоит.

Два скрытых маркера, которые не покажет Velocity

Обычно менеджеры смотрят на Velocity (скорость команды в спринте). Но Velocity — коварная метрика, она до последнего маскирует проблемы. Смотреть нужно на другие маркеры:

  1. Падение Flow Efficiency (задачи дольше стоят, чем делаются).
  2. Рост Cycle Time при стабильном Throughput (каждая отдельная задача идет до продакшена дольше, хотя суммарно штук в неделю сдается столько же).
Аналогия с пульсом: представьте бегуна. Он может бежать с той же скоростью, но его пульс вырос со 130 до 170 ударов. Если тренер смотрит только на секундомер (Velocity), он решит, что всё в порядке. Но бегун уже на пределе и скоро сойдет с дистанции.

Как выглядит выгорание на практике: типичный сценарий

У команды разработки FE за пару спринтов падает с 25% до 12%. Задачи закрываются в срок, графики красивые. Менеджер доволен. А через месяц двое ведущих инженеров берут больничный из-за выгорания, и проект встает.

Если бы нагрузку скорректировали в момент падения FE, команду бы не штормило. Потоковые метрики — это ваш радар раннего обнаружения, который показывает проблему до того, как она превратится в катастрофу.

7 поведенческих маркеров перегрузки, которые проявляются раньше, чем падает производительность

Снижение производительности — поздний симптом. К тому моменту, когда оно становится заметным, человек уже несколько недель работает на износ. Ранние маркеры лежат в поведении: в том, как человек общается, принимает решения и реагирует на неопределённость.

  1. Снижение толерантности к неопределённости. Сотрудник, который раньше спокойно работал с размытыми ТЗ и сам уточнял детали по ходу, начинает требовать детализации каждого шага до старта. Когнитивных резервов на «додумывание» больше нет. По данным Бизнес-секретов, именно снижение толерантности к неопределённости и рост раздражительности — первые поведенческие маркеры выгорания, которые появляются до падения KPI.
  2. Рост раздражительности в рабочих коммуникациях. Короткие резкие ответы в чатах, нежелание обсуждать, сворачивание дискуссий, которые раньше шли нормально.
  3. Маскировка перегрузки под лояльность. Сотрудник берёт задачи на себя, говорит «справлюсь», не сигнализирует о проблемах. Снаружи — ответственный человек. Внутри — накапливающийся долг, который однажды обнуляется больничным или заявлением. Этот паттерн практики в профессиональных сообществах называют одним из самых опасных: перегрузка маскируется под ответственность до тех пор, пока человек не выходит из строя. Менеджер принимает за «сильного игрока» сотрудника, который просто боится или не умеет просить о помощи. Проблема в том, что внешняя автономность маскирует скорый упадок сил.
  4. Сужение инициативы. Перестаёт предлагать улучшения, задавать вопросы «а почему мы делаем именно так?», участвовать в ретроспективах содержательно. Работает строго «по заданию».
  5. Рост числа мелких нетипичных ошибок. Опечатки в документах, пропущенные детали, которые раньше он замечал сам. Нехарактерные для этого человека, не критичные — но нетипичные. Когнитивный контроль ослабевает первым.
  6. Избегание синхронных коммуникаций. Отменяет 1-on-1, переносит встречи, предпочитает асинхронные каналы там, где раньше охотно созванивался. Видеозвонок забирает гораздо больше когнитивных ресурсов, чем текстовое сообщение. Когда мозг перегружен, любая встреча голосом становится для него тяжелым испытанием.
  7. Изменение паттерна рабочего времени. Начинает работать поздно вечером или в выходные, при этом дневная активность падает. Попытки найти время без переключений начинаются там, где весь день превращается в сплошной поток фонового шума и уведомлений.

Маркеры 4 и 5 легко списать на «плохую неделю». Именно поэтому важна динамика: один эпизод ничего не значит, повторяющийся паттерн на протяжении двух-трёх недель уже сигнал.

Кейс: как контроль нагрузки сэкономил 35 часов рабочего времени в сутки

По данным Kaiten, производственная компания из Киргизии до внедрения контроля нагрузки работала по классической схеме, когда задачи распределяли по принципу «кто свободен» или «кто сам возьмет». Реальной картины занятости сотрудников не видел никто. Точный размер команды в кейсе не раскрывается, но итоговый результат зафиксирован четко: система помогла высвободить 35 часов рабочего времени в сутки. Этого результата добились за счёт устранения скрытых потерь (простоев, дублирования функций и зависания задач у перегруженных специалистов, пока у остальных оставались свободные слоты), а вовсе не из-за ускорения темпов работы.

Похожая история произошла в iFellow. Компания сделала загрузку прозрачной и внедрила систему планирования ресурсов, что за первый год сократило срывы сроков на 40%. Команда не начала работать сверхурочно. Перегрузка стала видна заранее, поэтому задачи успевали перераспределить до того, как дедлайн начинал гореть.

В основе обоих кейсов лежит одна и та же механика: единая и понятная картина занятости людей, перехват задач на этапе ранней перегрузки и регулярный мониторинг вместо разовых аудитов после случившегося кризиса.

Для понимания масштаба можно взглянуть на контекст. Производительность труда назвали приоритетом №1 на 2026–2027 годы 64% компаний, при этом число активных вакансий на рынке сократилось на треть. Это значит, что нагрузка неизбежно перераспределяется внутри текущего штата, ведь нанять замену сейчас гораздо сложнее. В таких условиях управление емкостью команды становится чисто операционной задачей, а не просто HR-инициативой.

Что должен видеть менеджер за две недели до кризиса

Почему именно две недели? Если средний цикл задачи в вашей команде — 5–7 дней, то два спринта — это горизонт, на котором деградация потоковых метрик уже заметна, а до видимого кризиса (срывы сроков, увольнения) ещё есть время среагировать.

Профилактика выгорания работает, когда она встроена в операционный ритм, а не запускается по факту. Система раннего обнаружения строится на двух уровнях: регулярные разговоры с людьми и объективные данные по задачам.

Уровень 1 — регулярные check-in'ы по ёмкости. Gartner рекомендует регулярные проверки реальной ёмкости команды как системный подход к профилактике. Ключевое слово — «реальной». Вопрос «как дела?» не работает. Работает структурированный разговор: «Какие задачи сейчас вызывают наибольшее напряжение? Есть ли что-то, что ты откладываешь больше двух дней?» И отдельно, самый важный вопрос: «Чувствуешь ли, что можешь отказаться от задачи, если не справляешься?» Он проверяет, есть ли у человека психологическая безопасность сигнализировать о перегрузке.

Уровень 2 — визуализация загрузки и потоковые метрики. «Невидимая» перегрузка — главный враг менеджера. Когда нагрузка распределена по чатам, таблицам и головам, никто не видит полной картины. Нужен единый экран: кто чем занят, сколько задач в работе одновременно, где скопились «зависшие» карточки. Поверх этой картины динамика метрик — Cycle Time, Throughput, Flow Efficiency. Эти метрики работают как тренды, поэтому отслеживать их нужно исключительно в динамике. Рост Cycle Time на 20% и более за два спринта при стабильном объёме задач — красный флаг. Такой маркер сигнализирует о необходимости перераспределить задачи и спокойно обсудить ситуацию с командой.

Два уровня работают вместе. Check-in'ы дают субъективную картину от людей. Визуализация и метрики — объективную картину по задачам в динамике. Когда оба сигнализируют одновременно, у менеджера нет шансов пропустить момент.

Нагрузка должна быть видимой: как это устроено в инструменте

Инструмент управления проектами должен делать нагрузку прозрачной. Важно видеть движение задач и точки их торможения, ведь простое количество задач в колонке ни о чём не говорит.

В Shtab для этого есть несколько механик.

Активность пользователя — временная шкала показывает не только рабочее время, но и простои. Менеджер видит количество перерывов и отвлечений в течение дня. Согласно документации Shtab, эти данные помогают скорректировать нагрузку и пересмотреть план — среагировать до того, как человек дойдёт до точки невозврата, а не после.

Управление простоем в трекере позволяет фиксировать и анализировать время, когда задачи не двигаются. Это прямой операционный эквивалент Flow Efficiency. Система подсвечивает потраченные часы вместе со временем, в течение которого задача стояла на паузе.

Группировка задач выручает при высокой загрузке, так как позволяет мгновенно оценить общую картину. С ее помощью легко контролировать статус текущих задач, отслеживать срывы сроков и видеть исполнителей. Менеджер получает ту самую единую картину, без которой управление нагрузкой невозможно.

Дайджест уведомлений. Каждое утро система отправляет информацию о просроченных задачах и задачах с приближающимся дедлайном. Это позволяет заметить накопление «хвостов» у конкретного сотрудника до того, как они создадут кризис.

Дизайн работы важнее йоги: что реально снижает выгорание

Корпоративный психолог, фрукты в офисе, онлайн-курс по медитации. Всё это хорошо само по себе. Ни одна из этих инициатив не снижает выгорание, если не меняется дизайн работы.

Gartner прямо рекомендует снижать риск выгорания через перераспределение нагрузки, а не через wellness-программы. Сотрудник, который выгорает в токсично устроенном процессе, не станет устойчивее от занятий йогой.

Аналогия грубая, но точная: wellness-программа при неработающем дизайне работы — это обезболивающее при переломе. Симптом снимает. Причину не лечит.

Что работает на практике и как это подтверждают кейсы

Редизайн процессов: убрать лишние согласования, сократить число переключений контекста, дать людям более длинные «тихие» блоки для глубокой работы. В кейсе iFellow именно устранение операционных зависимостей между командами дало 40% сокращения срывов.

Право сказать «нет» без последствий: если культура команды такова, что признание перегрузки воспринимается как слабость, никакие check-in'ы не помогут. Люди будут говорить «справлюсь» до последнего. Менеджер, который хочет получать честные сигналы, должен сначала доказать, что за честность не наказывают. Причём конкретными действиями, а не декларациями.

Прозрачность приоритетов: когда сотрудник не понимает, что важнее — задача А или задача Б, он тратит когнитивный ресурс на само это решение, но не на работу. Каждый неразрешённый конфликт приоритетов — это скрытый налог на ёмкость команды.

Об этом сдвиге говорят и свежие отраслевые данные. Согласно исследованию Gallup «State of the Global Workplace», выгорание всё чаще рассматривается как результат организационных условий. Это меняет и то, кто несёт ответственность за его профилактику.

Capacity Planning в условиях дефицита: как рассчитать реальную нагрузку, когда людей не хватает

Среднее число активных вакансий сократилось на треть к прошлому году. При этом задач меньше не стало. Нагрузка перераспределяется внутри существующих команд. Из-за этого планирование емкости штата перешло в разряд критически важных задач.

На российском рынке ситуация особенно острая. Дефицит IT-специалистов, который нарастает с 2022 года, означает, что быстро нанять замену выгоревшему разработчику или аналитику — задача на месяцы. Каждый уход из команды создаёт цепную реакцию: нагрузка перераспределяется на оставшихся, их ёмкость падает, риск следующего увольнения растёт. Capacity Planning в данном контексте работает как страховка от каскадных потерь. Обычная оптимизация здесь вторична.

Проблема стандартного подхода к capacity заключается в том, что он считает «часы × люди» и при этом игнорирует когнитивную стоимость работы. 8 рабочих часов разработчика, который весь день пишет код в потоке, и 8 часов того же разработчика на встречах и согласованиях — это не одинаковая ёмкость.

Более честная формула выглядит так:

Доступная ёмкость = рабочие часы − встречи − рутина − буфер на непредвиденное

Буфер в 20% — стандартная рекомендация PMI и Scrum Alliance для команд, работающих в условиях неопределённости. Если после всех вычитаний на целевые задачи остаётся меньше 60% рабочего времени — команда в зоне риска.

Конкретный расчёт. Разработчик, 8 ч/день: минус 1,5 ч на встречи, минус 0,5 ч на рутину (почта, статусы, административные задачи). Остаётся 6 ч. Буфер 20% считаем от полного рабочего дня: 20% × 8 ч = 1,6 ч. Итого: 8 − 1,5 − 0,5 − 1,6 = 4,4 ч на целевые задачи. Если план спринта строится из расчёта 7–8 часов в день — команда перегружена ещё до старта.

Ещё один слой — тип задач. Три часа на сложную аналитику когнитивно тяжелее, чем шесть часов на понятную рутину. Capacity Planning, который это игнорирует, даёт красивые цифры в таблице и сюрпризы в конце спринта.

В Shtab можно настроить SLA и график работы для каждого сотрудника. Система будет считать время с учётом рабочих дней и часов конкретного человека. Это даёт более честную картину доступной ёмкости при планировании, особенно в распределённых командах с разными графиками и часовыми поясами. Подробнее о том, как выстроить графики и предотвратить перегрузку на уровне планирования, рассказали в статье про управление человеческими ресурсами и графиками работ.

Чек-лист: что внедрить на этой неделе

Если нужно выбрать одно первое действие, лучше начать с чек-инов. Без живого разговора остальные инструменты теряют смысл. Метрики подсвечивают проблему, но умалчивают о причинах, а визуализация нагрузки бесполезна, когда сотрудники молчат о перегрузке.

Четыре шага, которые не требуют реорганизации процессов. Их можно начать применять уже с понедельника.

  1. Запустить еженедельный check-in по ёмкости. Встречу важно посвятить именно ощущению нагрузки, оставив разбор статусов по задачам для других созвонов. Два вопроса: «Что откладываешь дольше двух дней?» и «Есть ли задача, от которой хочешь отказаться?» Формат — 15 минут, один на один. Не нужно ждать ретроспективы.
  2. Сделать нагрузку видимой. Вывести загрузку по людям на единый экран. Если используете Shtab, это легко увидеть через группировку задач по исполнителям и мониторинг активности. Любой другой инструмент обязан собирать данные о задачах в одном месте. Разрозненная информация в пяти чатах полностью лишает процесс прозрачности. Данный шаг необходим для того, чтобы убрать слепые пятна.
  3. Начать отслеживать Cycle Time в динамике. Важно сфокусироваться на тренде от спринта к спринту, поскольку отдельное абсолютное число здесь мало о чём говорит. Рост на 20% и более за две недели при стабильном объёме — повод для разговора с командой, но не для подведения выводов. Разговор покажет, где реальная причина.
  4. Установить WIP-лимиты. Договориться с командой о максимальном числе задач в работе одновременно на человека. Даже неформальное правило «не больше трёх активных задач» снижает когнитивную нагрузку от переключений и делает перегрузку видимой раньше, чем она станет хронической.

FAQ

Как диагностировать выгорание у команды?

Работает комбинация поведенческих маркеров (раздражительность, избегание коммуникаций, рост нетипичных ошибок) и потоковых метрик (падение Flow Efficiency, рост Cycle Time), подкреплённая регулярными структурированными check-in'ами. Поведенческие маркеры дают ранний сигнал, метрики подтверждают его цифрами, check-in'ы помогают понять причину. При этом одного инструмента недостаточно, нужна система из всех трёх.

Что такое чувство перегруженности?

Состояние, при котором внутренних ресурсов не хватает для обработки входящих задач и стресса. Согласно исследованию HBR, его испытывали 9 из 10 опрошенных сотрудников. Отличается от простой «занятости» тем, что сопровождается ощущением потери контроля и невозможности расставить приоритеты. Человек не просто много работает, он не понимает, за что браться в первую очередь.

Что такое перегорание на работе?

ВОЗ классифицирует выгорание как синдром, возникающий в результате хронического рабочего стресса, с которым не удалось справиться. Три компонента: эмоциональное истощение, деперсонализация — цинизм по отношению к работе и коллегам, снижение профессиональной эффективности. ВОЗ официально признает выгорание фактором профессиональной среды. Поскольку это не медицинский диагноз, ответственность за его предотвращение полностью ложится на компанию.

Как отличить временную усталость от начала выгорания?

Усталость проходит после выходных или отпуска. Выгорание — нет. Если сотрудник вернулся из отпуска и через два-три дня снова демонстрирует маркеры из списка выше (раздражительность, избегание коммуникаций, сужение инициативы), дело не в количестве отдыха. Дело в дизайне работы, к которой он вернулся.