Один квартальный отчёт выглядел безупречно. Время цикла сократилось, код-ревью летели, тикетов закрыли больше, чем в прошлом квартале. Дашборд сиял зелёными индикаторами. Руководитель разработки чувствовал заслуженную гордость. Ровно до того момента, пока продакт-лид не спросил: «А что изменилось для клиентов?»
Ответ оказался неловко коротким. Пара исправлений. Пара фич в частичном развёртывании. Косметический ремонт админки, который никто за пределами компании не заметил. Команда разогналась, но энергия ушла в свисток. С тех пор я с подозрением отношусь к скорости. Она слишком заметна, чтобы быть честным мерилом.
Российский бизнес в 2025 году потратил на корпоративное обучение и развитие персонала около 100 млрд рублей. 84% компаний инвестируют в прокачку сотрудников. Но если после тренингов и спринтов клиентский опыт не меняется, а выручка стоит на месте — значит, мы научились быстро делать бесполезную работу.
Цифры не врут. Они просто не договаривают
Самое неприятное в плохих метриках продуктивности — их фактическая точность. Команда действительно смержила больше пул-реквестов. Тикеты действительно двигались быстрее. Очередь на ревью схлопнулась. Паплайн деплоя отлажен. Отрицать эти факты глупо.
Проблема в том, что они не закрывают вопрос. Если после ускорения тормозит оформление заказа, растёт нагрузка на саппорт, кодовая база превращается в минное поле, а инженеры тратят следующие два месяца на разгребание решений, которых никто не помнит, — скорость была лишь частью истории. Возможно, осознанной сделкой. Возможно, оправданным риском. Но называть это продуктивностью только потому, что середина конвейера ускорилась, — самообман.
SPACE-фреймворк потому и живуч, что отказывается сводить продуктивность разработчика к одной цифре. Он ставит активность рядом с результативностью, удовлетворённостью, коллаборацией и потоком. Но люди берут самую удобную для измерений колонку и назначают её истиной в последней инстанции. Активность комфортна — она похожа на доказательство. Но доказывает она только то, что активность была.
Ловушка локальных побед
Большинство улучшений скорости — локальны. Генерация кода ускорилась. Ревью ускорилось. Билды ускорились. Деплой ускорился. Каждое звено по отдельности — молодцы. Я сам потратил уйму времени, выжимая миллисекунды из этих этапов.
Беда в том, что локальная скорость обожает перекладывать работу на соседа. Команда сократила время реализации — и обнаружила, что узким горлышком стало ревью. Сократили ревью — тестирование захлебнулось. Автоматизировали QA — выяснилось, что никто не знает, решает ли фича исходную проблему. Каждый слой празднует свой личный рекорд, пока работа тихо гниёт на стыке.
Первый раз я это осознал, наблюдая за командой, где все были заняты, но ни один значимый дедлайн не был соблюдён. Дизайн ждал продукт. Бэкенд ждал архитектуру. Фронтенд ждал контракты API. Тестирование ждало хоть что-то стабильное. Никто не бездельничал. Ничто не двигалось.
Большинство руководителей ищут незагруженных людей. Это ошибка. Искать надо работу, которая застряла. Где она ждёт? Кто должен взять её следующим? Найдите недостающее решение, переоткрытый тикет, заблокированную передачу, разрыв между «формально готово» и «фактически полезно». Эти проверки куда неприятнее вопроса «как быстро мы едем?». Но их сложнее накрутить.
Искусственный интеллект сделал старую ошибку дешевле
AI не изменил суть проблемы. Мы и до него путали выпуск артефактов с прогрессом. Просто теперь производство артефактов стоит копейки. Если ваша организация верит, что продуктивность — это «больше реализованного функционала за меньшее время», AI выглядит как манна небесная. Я сам пользуюсь этими инструментами и назад не хочу. Они хороши для каркасов, разведки, черновиков тестов, скучных трансформаций и прочей мелочи, которая раньше съедала внимание, не заслуживая его.
Но я не доверяю ни одному заявлению о продуктивности, которое останавливается на скорости генерации. Отчёт DORA за 2025 год фиксирует это напряжение. Внедрение AI массовое. Большинство респондентов говорят, что их продуктивность выросла. При этом DORA подчёркивает: выгода сильно зависит от ясности рабочих процессов, качества внутренних платформ, быстрой обратной связи и сыгранности команды. И одновременно фиксирует негативную корреляцию со стабильностью поставки.
Это звучит правдиво. AI помогает сильнее, когда окружающая система уже хороша. Если система разболтана, AI просто генерирует больше материала для переработки этой разболтанной системой. Ранние исследования вроде METR (начало 2025) я не читаю как «AI делает разработчиков медленнее». Это было бы слишком просто и, вероятно, перестанет быть правдой по мере развития инструментов. Я выношу более узкий урок: опытные разработчики в знакомых, зрелых репозиториях теряли время на формулирование промптов, ожидание, ревью и вычистку сгенерированного кода.
Если AI экономит три часа печати, но создаёт пять часов ревью, отладки и сомнений, — цифра про три часа всё ещё правдива. И всё ещё бесполезна сама по себе.
Куда на самом деле уходит время
Когда команда говорит мне, что она быстрая, но вымотанная, я смотрю на края работы. Видимая часть — написанный код, проверенные PR, прокачанные через CI релизы — редко бывает всей проблемой. Дорогое время живёт тише.
Оно прячется в двух днях до старта реализации, когда никто не продавил продуктовый вопрос. Оно живёт в рабочем чате, где три старших специалиста почти согласились, но решение так и осталось подвешенным. После релиза оно всплывает, когда саппорт узнаёт о новом поведении системы раньше, чем команда разработки. А месяцы спустя оно материализуется в рефакторинге, который случился потому, что исходная работа была корректна относительно тикета и ошибочна относительно пользователя.
Я сам наступал на эти грабли как руководитель. Не раз. Я подгонял команду ускорить видимую часть, потому что именно там чувствовал контроль. Реальная задержка сидела выше по течению — в качестве решений. Мы подавали неясную работу в улучшенную машину и удивлялись, что машина производит более чёткие версии неправильного.
Именно поэтому метрики DORA связывают пропускную способность с нестабильностью. Частота деплоев и время доставки изменений полезны только в паре с отказами, переделками и восстановлением. Скорость без противовеса льстит. Этого не должно быть.
Дашборд, который я хочу видеть
Мне не нужны новые метрики. Мне нужно меньше самообмана. Исследования в области Developer Experience полезны именно здесь: они говорят о петлях обратной связи, когнитивной нагрузке и состоянии потока. Эти слова звучат мягко, пока вы не увидите, как команда теряет неделю на тестовый набор, которому никто не доверяет, или на сервисную границу, которую никто не понимает. Тогда они перестают звучать мягко.
Хороший дашборд должен делать реальные задержки труднее для сокрытия. Покажите мне, сколько работа лежит после статуса «готово», но до того, как ей можно пользоваться. Покажите, сколько переделок возникло из-за нечёткого замысла. Скажите, у каких активных проектов нет названного принимающего решение. Как часто отгруженная фича меняется после получения реальных данных. Какие передачи задач раз за разом стопорят один и тот же тип работы.
Ни одна из этих цифр не идеальна. Некоторые — едва ли цифры. Это нормально. Смысл в том, чтобы начать более честный разговор. После завершения проекта я люблю спрашивать: «Что стало легче?» Если ничего не стало легче — будьте осторожны. Возможно, работа была необходимой: комплаенс часто выглядит именно так, некоторые миграции — чистая оборона, часть работы по надёжности предотвращает боль, а не создаёт восторг. Отлично. Скажите это прямо. Будьте честны о типе созданной ценности.
Но если каждый проект отгружается, и ничего не становится легче — ни пользователям, ни операторам, ни поддержке, ни будущим инженерам, ни будущим решениям, — вы смотрите не на продуктивность. Вы смотрите на организационное пищеварение. Команда потребляет работу и производит артефакты. Это не равно прогрессу.
Что я изменил бы на месте лидера
Я бы начал с меньшего, чем стартует большинство программ по продуктивности. Я бы перестал спрашивать команды, почему они не быстрее, пока у меня нет внятного ответа, зачем вообще нужна текущая работа. Одно это оздоровило бы многие организации. Половина давления «ускориться» — это дискомфорт от неясных приоритетов, наряженный в костюм доставки.
Я бы сделал активную работу болезненно видимой. Не красивый портфельный дашборд. Простой список, который директор может прочитать и слегка устыдиться. Слишком много команд тащат работу только потому, что никто не хочет нести социальные издержки её остановки. Грамотно выстроенные стратегические сессии помогают вскрыть именно такие залежи фиктивной занятости.
Я бы требовал реального обзора результатов после поставки. Без церемоний, без слайдов. Люди, которые спонсировали, строили, поддерживали и эксплуатировали продукт, смотрят на то, что произошло на самом деле. Помогло ли? Что сломалось? Пользователям было не всё равно? Что бы вы прекратили делать, если бы поверили фактам?
Я бы приравнял удаление к поставке. Убрать запутывающую фичу, прибить тухлый проект, упростить рабочий процесс, выпилить код, который никто не понимает. Это всё акты продуктивности. Они редко выглядят как скорость, потому что артефакт становится меньше. И это требует качественной оценки персонала, чтобы понять, кто способен не только создавать, но и принимать сложные решения об отказе от лишнего.
Я бы следил за старшими инженерами на предмет признаков того, что скорость покупается ценой их внимания. Сейчас это одна из самых распространённых скрытых издержек. Команда выглядит быстрее, потому что сильнейшие инженеры молча поглощают больше ревью, больше чисток, больше архитектурных правок, больше прерываний в формате «слушай, быстрый вопрос». Дашборд говорит, что пропускная способность выросла. Календарь старшего инженера говорит об обратном. Так можно управлять какое-то время. Счёт в итоге выставляется оттоком, хрупкой архитектурой или старшим инженером, у которого внезапно кончилось терпение.
Что стоит произносить вслух
Есть фраза, которую я хотел бы слышать от лидеров чаще: «Мы движемся быстрее. Я пока не знаю, стали ли мы продуктивнее». Эта фраза создаёт правильный дискомфорт. Она уважает проделанную работу, удерживая стандарт честности. Команда не оскорблена. Руководитель отказывается путать движение с ценностью.
Большинство инженерных команд не полны людей, которые избегают работы. Они полны людей, которые тратят слишком много усилий на работу, вошедшую в систему слишком небрежно, ожидавшую в неправильных местах или так и не проверенную реальностью после отгрузки. Говорить такой команде «быстрее» — ленивый менеджмент. Задача сложнее: сделать так, чтобы большая часть усилий считалась. Более ясный замысел до старта. Меньше незавершённой работы. Более быстрая обратная связь. Чуть больше готовности остановить работу, которая больше не заслуживает внимания команды.
Ничего из этого не ново. Отчасти поэтому это и раздражает. Продуктивность — это не скорость. Это то, что остаётся после того, как движение проверили чем-то настоящим.
Практические рекомендации
- Проведите «вскрытие» последнего спринта. Соберите команду и честно ответьте на вопрос: «Что из сделанного нами за последние две недели уже принесло измеримую пользу пользователю или бизнесу?» Если ответов меньше трёх — вы работали на внутренний контур, а не на результат.
- Найдите «работу-призрак». Поднимите все задачи, которые висят в статусе «Готово» дольше трёх дней, но ещё не попали к пользователю. Скорее всего, вы обнаружите бутылочное горлышко на стыке команд, о котором все молчат.
- Введите метрику «Время до осознания». Замеряйте, сколько проходит от момента, когда фича попала в прод, до момента, когда команда получила первые реальные данные о её использовании. Если этот цикл длиннее недели — вы теряете деньги на доработках вслепую.
- Легализуйте удаление. Раз в квартал проводите «день расхламления»: пусть команда предложит функции, микросервисы или участки кода, которые можно безболезненно выпилить. Прогресс — это не только новые строки, но и исчезнувшие старые.
- Защитите старших инженеров. Проверьте календари ваших техлидов. Если больше 30% времени уходит на незапланированные прерывания и ревью чужих «сырых» задач, скорость команды — фикция, купленная ценой выгорания ключевых людей.
Заключение
Скорость опьяняет, потому что её видно. Руководители получают график для отчёта. Команда — облегчение от ощущения, что система работает. Но иногда система просто движется. Настоящая продуктивность не живёт в дашборде спринта. Она живёт в том, что стало легче, понятнее и быстрее для пользователя после того, как схлынула рабочая пыль. Всё остальное — просто шум.
Специалисты группы компаний «Алмаз» помогают руководителям выстроить систему, в которой скорость не противоречит смыслу. Фасилитационные сессии и программы развития лидерских компетенций позволяют навести порядок в приоритетах и перестать гнать команду быстрее в стену.
Часто задаваемые вопросы
Как отличить реальную продуктивность от имитации бурной деятельности?
Задайте два вопроса после каждого спринта или проекта: «Что изменилось для клиента?» и «Что стало легче делать команде?». Если ответы абстрактны или их нет — вы имеете дело с имитацией. Реальная продуктивность всегда оставляет след в виде упрощения чьей-то работы или улучшения пользовательского опыта.
Какие метрики действительно важны, кроме скорости?
Время, которое задача проводит в состоянии «готово» до реального использования. Количество переделок, вызванных нечёткой постановкой. Частота, с которой отгруженные фичи меняются после получения обратной связи. И главное — субъективное ощущение команды: стало ли работать легче, чем полгода назад.
AI ускоряет разработку или создаёт иллюзию скорости?
AI кратно ускоряет написание кода, но одновременно увеличивает объём работы на ревью, отладку и интеграцию. Если ваши процессы ревью и тестирования не были отлажены до внедрения AI, вы рискуете получить не рост продуктивности, а рост технологического долга. AI помогает сильным командам и топит разболтанные.
Как убедить руководство, что «медленнее» иногда значит «лучше»?
Перестаньте оперировать скоростными метриками в вакууме. Привяжите их к бизнес-показателям: «Когда мы сократили время на ревью вдвое, количество багов в проде выросло на 40%, и мы потратили две недели на хотфиксы». Цифры, связывающие скорость с издержками, действуют на руководство отрезвляюще.
Что делать, если команда перегружена, но останавливать проекты страшно?
Составьте список всех активных задач и проектов. Напротив каждого напишите, что случится, если его заморозить на месяц. В 70% случаев ответ будет «ничего страшного». Начните с заморозки самого бесполезного. Освободившиеся ресурсы направьте на то, что действительно влияет на бизнес. Страх остановки — главный враг продуктивности.
Как измерить продуктивность команды, если мы не пишем код (HR, маркетинг, продажи)?
Принцип тот же: ищите не активность, а результат. Для HR — не количество проведённых собеседований, а время закрытия вакансии и приживаемость новичков. Для маркетинга — не количество публикаций, а лиды, дошедшие до отдела продаж. Для продаж — не количество звонков, а реально заключённые сделки и их маржинальность.
