80% вместо 100% — такой режим работы команды автор публикации называет нормой для устойчивой разработки. Тезис звучит особенно жестко на фоне привычной для многих компаний гонки за полной утилизацией людей, но именно загрузка команды под потолок, по его опыту, сначала дает краткий прирост скорости, а затем бьет по качеству, удержанию сотрудников и деньгам бизнеса.
Об этом сообщает Habr / Карьера со ссылкой на колонку руководителя, который в 2015 году управлял штатом из 100 человек, а в 2024-м отвечал за программу внедрения нового биллинга в федеральном телекоме. За 15 лет работы и более чем 300 интервью он пришел к выводу, который многим руководителям в IT может не понравиться: производительность нельзя честно измерять количеством занятых часов, а стратегия «выжать максимум» на перегретом рынке труда превращается для компании в дорогую управленческую ошибку.
Ключевая мысль материала проста и потому неприятна для любителей тотального контроля. Команда, которая в штатном режиме работает на 100% мощности, не имеет запаса на инциденты, срочные релизы, незапланированные переделки и просто человеческую усталость. Пока все идет по плану, такая модель может выглядеть выигрышно: velocity растет, задачи закрываются быстрее, менеджмент доволен. Но при первом сбое система начинает расплачиваться тем, что обычно не видно в еженедельных отчетах: увеличивается число ошибок, растет внутреннее напряжение, сильные сотрудники уходят, а найм и адаптация замены съедают тот самый выигрыш, ради которого и запускалась гонка.
Автор описывает свой подход как набор из четырех опор. Первая — синхронизация личных целей сотрудника с целями компании. На практике это не про абстрактную «миссию», а про очень прикладные вещи. Если кандидат хочет жить за городом, ему предлагают не просто удаленку как льготу, а культуру асинхронной работы. Если человек нацелен на вертикальный рост, под него заранее готовят лидерский трек. Логика здесь не особенно романтичная, зато понятная бизнесу: когда работа помогает человеку закрывать его собственные цели, растут и вовлеченность, и вероятность, что он не начнет смотреть по сторонам после первого трудного квартала.
Не контроль, а запас прочности
Вторая опора — инженерная культура. Автор выступает за T-shaped-подход, при котором специалист понимает не только свою узкую зону, но и соседние слои системы. В его версии это касается не только инженеров: даже проджект-менеджер должен представлять, как работает интернет и зачем нужна виртуализация. Отсюда и довольно редкий для корпоративной рутины прием — поездки в дата-центры, чтобы менеджеры и аналитики лучше понимали физический уровень инфраструктуры. Идея не в том, чтобы превратить всех в универсальных солдат, а в том, чтобы уменьшить число коммуникационных разрывов между бизнесом и разработкой. Для российских IT-команд, где половина конфликтов начинается с разных представлений о сложности задачи, это звучит куда практичнее, чем очередной курс про «эффективные коммуникации».
Третья опора — управление через доверие, а не через постоянный надзор. В колонке регулярные 1-to-1 описываются как аудит состояния системы: руководитель выявляет, что помогает человеку работать, что мешает, и фиксирует ожидания в формате SMART. Неформальное общение — квизы, BBQ и прочие нерабочие активности — подается не как корпоративный праздник ради фотографий в чате, а как способ снижать «социальный шум» и замечать проблемы до того, как они выльются в серию увольнений. Подход не новый, но здесь важен акцент: мотивация рассматривается не как набор бонусов и приятных мелочей, а как инструмент управления рисками. Для руководителя это, по сути, тот же резерв, только не в бюджете и не в железе, а в людях.
Самая жесткая часть подхода — так называемый «глиссирующий режим»: штатная загрузка команды должна держаться примерно на уровне 80%. Оставшиеся 20% — это не роскошь и не скрытый простой, а управленческий буфер для критических релизов, инцидентов и обучения. Такой тезис идет наперекор культуре, в которой незаполненный календарь воспринимается как недоработка менеджера, а свободное время сотрудника — как потерянный актив. Но именно эта логика, по мнению автора, и ломает длинную дистанцию. Если люди постоянно работают на пределе, компании нечем форсировать в момент, когда форсаж действительно нужен. Получается парадокс: попытка выжать максимум каждый день снижает способность команды выдерживать настоящую нагрузку.
Что это значит для IT-рынка
В качестве примера приводится проект 2021 года по созданию комплекса CRM + ERP для производственной компании. Несколько кварталов подряд команда шла с загрузкой, близкой к 100%. Сначала картина выглядела почти образцово: velocity росла. Затем начались ошибки, усилились конфликты, а после этого уволился главный разработчик. Только после пересмотра планирования и введения буфера загрузки ситуация стабилизировалась, а производительность на длинной дистанции оказалась выше. Это важный момент для бизнеса: в материале нет обещаний чудесного роста после перехода на более щадящий режим. Речь, скорее, о другом — о способности сохранять темп без потери ключевых людей и без превращения каждого сложного релиза в маленькую организационную катастрофу.
Для русскоязычной IT-аудитории здесь есть несколько неприятных, но полезных выводов. Во-первых, дефицит кадров и дорогой найм меняют математику управления: заменить сильного разработчика часто сложнее, чем еще квартал давить команду ради красивого статуса в Jira. Во-вторых, деньги сами по себе работают недолго, особенно если в компании нет внятной среды, карьерного трека и нормального разговора о нагрузке. В-третьих, загрузка команды — это не только вопрос производственного планирования, но и индикатор зрелости руководителя. Если лидер умеет держать резерв, он управляет системой. Если все живет в режиме вечного перегруза, он управляет только пожаром, который пока еще не вышел наружу.
Автор утверждает, что текучесть кадров в его командах не превышала 5%. Даже без дополнительных внешних метрик этот показатель делает колонку интересной не как мотивационный текст, а как управленческую позицию, идущую против старого культа переработок. Для российского IT-бизнеса вопрос теперь звучит предельно приземленно: готовы ли компании считать резерв в людях такой же обязательной частью устойчивости, как резерв в инфраструктуре, или привычка жить на 100% загрузки так и останется дорогой формой самообмана.