Что делает базовый показатель аудита инженерной эффективности справедливым?

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

Справедливый базовый показатель не равен среднему значению всего, что произошло недавно. Это задокументированная картина обычной операционной capacity: сколько полезной работы выполняет конкретная команда, сколько эта работа ждёт, что её прерывает и какой уровень надёжности она поддерживает, когда календарь не горит. Для стартапа это единственный базовый показатель, на который стоит опираться, решая, окупятся ли изменения процессов, AI-инструменты, подрядчики или новый найм.

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

Базовый показатель должен описывать обычную работу, а не недавнюю историю

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

Представьте команду, которая закрыла 80 задач за предыдущие десять недель. Это число почти ничего не говорит. Возможно, за две недели команда выпустила крупную миграцию клиента, неделю восстанавливалась после инцидента с базой данных, месяц работала без одного инженера и попала на корпоративный праздник. В оставшиеся недели она могла стабильно выпускать по шесть клиентских изменений. А могла обрабатывать множество мелких запросов поддержки, отодвигая работу по roadmap. Одно и то же общее число может описывать совершенно разные условия работы.

С самого начала используйте три категории:

• Работа, подходящая для базового периода, выполнена в недели с обычной численностью команды, обычным спросом и обычной практикой релизов.
• Исключительная работа включает запуски, инциденты уровня severity one, миграции, работу в условиях жёсткого дедлайна, задачи после приобретения компании, аудиты и другие концентрированные события, которые меняют работу команды.
• Модификаторы capacity включают государственные праздники, плановые отпуска, вакансии, адаптацию новых сотрудников, длительную болезнь, неполный график и временное переключение на поддержку продаж или найм.

Не выбрасывайте исключительную работу. Она помогает отвечать на важные вопросы. Неделя запуска показывает, выдерживают ли процессы выпуска высокую нагрузку. Инцидент выявляет отсутствие ответственности и слабую наблюдаемость. Нехватка сотрудников показывает, насколько поставка зависит от одного человека. Эти факты должны попасть в повествование аудита и отдельные метрики. Но их нельзя включать в знаменатель обычной недельной capacity.

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

Восьми-двенадцати недель достаточно, если недели сопоставимы

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

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

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

Хороший базовый период должен оставить как минимум шесть подходящих недель. Если из двенадцати недель вы исключили шесть из-за запуска, сбоя, двух праздников и изменения состава команды, это важный результат: бизнес работал недостаточно обычно, чтобы делать уверенный вывод о продуктивности. Не решайте проблему, молча добавляя необычные недели. Зафиксируйте, что данных недостаточно, расширьте период наблюдения и продолжайте отслеживание.

Отчёт DORA за 2024 год разделяет показатели поставки ПО на throughput и нестабильность, а не рассматривает скорость как всю картину. В него входят lead time изменений, частота развёртываний, время восстановления после неудачного развёртывания, доля неудачных изменений и доля повторной работы после развёртывания. Такой подход полезен для аудита: команда, которая работает быстрее, но создаёт больше срочной работы по исправлениям, не стала эффективнее.

DORA измеряет работу на уровне системы и команды. Так и оставляйте. Базовый показатель, построенный на отдельных коммитах или pull request, создаёт другую игру: люди дробят работу на крошечные изменения, избегают ревью и наставничества, выбирают заметные задачи вместо неприятного обслуживания. Вы получите более красивые графики активности и худшее инженерное поведение.

Сначала классифицируйте недели, потом считайте среднее

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

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

week: 2026-W18
eligible_for_baseline: false
exceptions:
  - product_launch
  - extended_release_freeze
capacity:
  planned_engineer_days: 25
  available_engineer_days: 24
  open_role_days: 0
  onboarding_engineer_days: 0
work_mix:
  planned_product: 0.58
  defects: 0.12
  support_and_escalations: 0.10
  platform_and_maintenance: 0.20
notes: "Launch support continued through Thursday. Do not use for normal throughput."

Этот артефакт предотвращает типичную тихую ошибку аудитов: кто-то называет неделю «обычной», потому что люди приходили на работу, хотя они проводили мост запуска, обрабатывали звонки от эскалировавших клиентов или не могли выпускать изменения из-за заморозки релиза. Присутствие на работе не равно доступной capacity поставки.

Заранее задайте правила исключения, до того как изучать итоговые метрики. Например:

1. Исключайте неделю из обычного throughput, если определённый запуск потребовал заморозки релиза, расширенной поддержки или работы вне обычного цикла планирования команды.
2. Исключайте неделю, если инцидент уровня severity one или severity two занял значительную часть запланированной capacity команды. Сам инцидент фиксируйте в отдельном представлении надёжности.
3. Помечайте неделю как скорректированную по capacity, а не исключённую, если из-за запланированных праздников или отпуска у команды было меньше рабочих дней, но сама практика поставки оставалась обычной.
4. Отмечайте переходный период в составе команды, если открытая позиция, увольнение или адаптация изменили эффективную capacity команды. Заранее решите, делает ли это неделю непригодной для базового периода или требует только нормализации.
5. Не исключайте неделю только потому, что в ней была сложная функция, дефект или плохой результат. Если сложная работа обычна, она должна входить в базовый показатель.

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

Реестр должен быть достаточно компактным, чтобы его можно было поддерживать. Если для каждой недели нужны сорок меток, никто не будет обновлять его, и метки превратятся в выдумку. Обычно достаточно пяти-семи понятных полей.

Запускам нужен отдельный срез, а не скрытая корректировка

Крупный запуск может создать впечатление, что команда работает необычно быстро или необычно медленно. Оба вывода могут быть неверными.

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

Создайте отдельное представление запуска с четырьмя вопросами:

• Какой объём запланированной работы вышел в продакшен к согласованной дате?
• Сколько незапланированной работы по исправлениям или поддержке последовало за релизом?
• Изменились ли правила выпуска, например появились заморозка кода, дополнительные согласования или ручное развёртывание?
• Какую работу команда отложила, чтобы освободить место для запуска?

Последний вопрос предотвращает распространённую управленческую иллюзию. Успешный запуск может выглядеть доказательством роста capacity команды, хотя на самом деле команда заняла capacity у работы по надёжности, технического долга, клиентских запросов и следующего спринта. Команда могла отлично исполнить план. Но это ещё не означает, что она создала дополнительный устойчивый результат.

Рассматривайте недели запусков как стресс-тест. Если у продукта повторяемый ритм релизов, сравнивайте их с другими запусками. Не сравнивайте их с обычными неделями и не используйте количество задач в них как цель для нового AI-процесса.

Есть одно исключение: если каждая неделя фактически является неделей запуска, потому что компания использует continuous delivery, а продуктовая работа идёт без отдельной церемонии релиза, это обычная работа. Метка должна соответствовать операционной модели, а не эмоциональному напряжению вокруг выпуска.

Праздники и отсутствие сотрудников сначала меняют capacity, а потом результат

Четырёхдневная неделя не становится обычной пятидневной только потому, что в Jira нет поля для праздников. То же относится к ситуации, когда половина команды в плановом отпуске, senior-инженер три дня проводит собеседования или новый инженер нуждается в постоянной поддержке.

Считайте capacity в инженерных днях и объясняйте, что именно означает результат. Если пять штатных инженеров должны были работать по пять дней, плановая capacity составляет 25 инженерных дней. Если один человек взял два дня отпуска, а другой потратил день на встречу с клиентом, доступная capacity равна 22 инженерным дням. Это не значит, что команда располагает 88% обычного результата. Издержки координации и распределение ответственности могут усилить эффект. Но raw-количество за неделю нельзя сравнивать с неделей на 25 дней, будто состав команды не изменился.

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

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

Ключевое различие проходит между capacity и результатом. Capacity это усилия, которые организация могла применить. Результат это то, что дошло до клиента или продакшена. У команды может быть полная capacity и низкий результат, если работа ждёт ревью, тестирования, согласования или продуктового решения. У команды может быть сниженная capacity и высокий результат, если она завершила работу, подготовленную заранее. Когда аудит смешивает эти понятия, он начинает обвинять инженеров в очередях, которые находятся в других частях компании.

Нехватку сотрудников нужно измерять как потерю возможностей, а не как пустые места

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

Зафиксируйте даты освобождения позиции, выхода нового сотрудника и момента, когда он начал самостоятельно отвечать за работу. Не делайте вид, что новый сотрудник приносит такой же вклад с первого дня. Сначала команда несёт стоимость адаптации и только потом получает отдачу, особенно если документация слабая или большая часть знаний о развёртывании сосредоточена у одного человека.

Для базового периода аудита классифицируйте пробелы в найме одним из двух способов:

• Если команда весь базовый период работала с одинаково сниженной численностью, эта численность и есть текущая норма. Используйте её, но пометьте базовый показатель фактической capacity.
• Если увольнение или задержка найма произошли внутри периода, разделите наблюдение на части. Не усредняйте результат до и после ухода в одно якобы обычное состояние.

Основатель может возразить, что команда должна была «закрыть» отсутствующую роль. Иногда это возможно на короткий срок. Но замещение имеет стоимость. Senior-сотрудники берут на себя ревью и работу в продакшене. Продуктовые задачи ждут. Специалисты избегают отпуска, потому что больше никто не знает систему. Аудит должен показать эту стоимость в составе работ и времени ожидания, а не предполагать, что оставшиеся люди внезапно стали менее способными.

Именно здесь raw velocity особенно вводит в заблуждение. Если после потери инженера команда закрывает примерно столько же задач, сначала изучите причины, а не объявляйте это победой. Возможно, backlog раздробили на более мелкие задачи. Возможно, обслуживание отложили. Возможно, люди работают дольше. Важна устойчивая capacity, а не один график, который не изменился.

Измеряйте поток, надёжность и состав работы вместе

Полезный аудит использует небольшой набор взаимосвязанных метрик. Одна метрика всегда провоцирует неправильную историю.

Начните с потока. Для выбранного типа работы измеряйте время от начала активной разработки до продакшена, а также время ожидания в отдельных состояниях: ревью, QA, согласование продукта, проверка безопасности и очередь релиза. Если возможно, не объединяйте это ожидание в один показатель «cycle time». Смысл аудита в том, чтобы найти ограничение.

Затем добавьте надёжность поставки. DORA определяет lead time изменений как время от коммита кода до успешного развёртывания в продакшене и отделяет сбои, вызванные изменениями, от внешних аварий при измерении восстановления. Это не просто терминологическая разница. Авария у облачного провайдера может навредить клиентам, но не показывает, создаёт ли процесс релизов команды дефектные изменения.

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

• плановая продуктовая работа
• дефекты и исправления в продакшене
• эскалации клиентов и поддержка
• платформа, безопасность и обслуживание
• внутренние запросы, встречи и неклассифицированная работа

Не заставляйте инженеров классифицировать каждую пятнадцатиминутную задачу. Нужной точности достаточно, чтобы понять, финансирует ли компания roadmap или тратит неделю на исправления и прерывания. Если неклассифицированная работа несколько недель подряд превышает небольшой согласованный порог, изучите её. В ней часто скрываются операционная нагрузка, помощь продажам, ручные исправления данных или продуктовые решения, которые пришли слишком поздно.

Фреймворк SPACE делает близкий вывод: у продуктивности разработчиков несколько измерений, включая удовлетворённость и благополучие, результативность, активность, коммуникацию и сотрудничество, эффективность и поток. Он предостерегает от того, чтобы принимать одну метрику активности за продуктивность.

Это не значит, что аудиту нужен большой опрос сотрудников. Но стоит провести короткий структурированный разговор с людьми, которые выполняют работу. Спросите, где работа ждёт, какие прерывания повторяются, какие системы требуют ручной обработки и что люди перестали делать, чтобы сохранить поставку. Если их ответы противоречат дашбордам, сначала проверьте конвейер данных, а не отбрасывайте слова сотрудников.

Медианы показывают ожидание, которое скрывают средние значения

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

Представьте, что восемь подходящих для анализа задач дошли до продакшена за 2, 3, 3, 4, 4, 5, 6 и 45 дней. Среднее равно 9 дням. Основатель, который прочитает это как «команда поставляет за девять дней», будет введён в заблуждение. Медиана равна 4 дням и описывает типичную задачу. Задача на 45 дней требует отдельного изучения: возможно, она показывает проблему с зависимостью, очередью согласований, окружением или неясным продуктовым решением.

Для временных метрик показывайте три числа:

1. Медиану, которая описывает типичную задачу.
2. Центральный диапазон 50%, который показывает стабильность или разброс результатов.
3. Несколько самых медленных задач с причинами ожидания, чтобы выявить ограничения, которые ощущают клиенты.

Для количественных показателей, таких как развёртывания или принятый объём работы, показывайте значения по неделям, а не только сумму. Всего 40 развёртываний за десять недель может означать четыре стабильных развёртывания в неделю. А может означать ноль девять недель и 40 во время запуска. Это разные операционные системы.

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

Пример базового периода показывает, почему исключения меняют ответ

Рассмотрим продуктовую команду из шести человек с данными за десять завершённых недель. Руководство хочет понять, сможет ли разработка с поддержкой AI уменьшить потребность в двух запланированных наймах. Сырые результаты показывают 96 завершённых продуктовых задач и медианное время от активной разработки до продакшена 11 дней.

Звучит как подходящая отправная точка. Но это не так.

Еженедельный реестр показывает следующее:

Сырое среднее смешивает все десять недель. Запуск завышает число завершённых задач, потому что подготовленная ранее работа одновременно пересекла финишную линию. Инцидент увеличивает время выполнения, потому что работа над функциями остановилась. Уход сотрудника меняет capacity. Если сравнить период после внедрения AI с этим сырым показателем, любой результат может выглядеть улучшением или ухудшением в зависимости от того, какие события попали в окно.

Справедливый аудит формирует два базовых показателя:

• Базовый показатель нормальной работы полной команды: недели 1, 2, 3, 6 и 7, при этом неделя 3 скорректирована по capacity. Он описывает поставку при составе команды из шести человек и обычных условиях.
• Базовый показатель нормальной работы сокращённой команды: неделя 10 и ещё несколько недель наблюдения. Он описывает текущий состав, но пока недостаточно надёжен для крупного вывода.

Затем аудит изучает, почему медиана полной команды составляет 11 дней. Допустим, данные показывают два дня активной разработки, четыре дня ожидания согласования продукта, три дня ревью, потому что изменения одобряют только два senior-инженера, и два дня ожидания ручного QA-окружения. AI может сократить часть активной разработки. Сам по себе он не устранит очередь продуктовых решений или общее QA-окружение.

Такой вывод защищает компанию от неудачной покупки. Если работа в основном ждёт вне разработки, увеличение мощности написания кода повысит затраты, но оставит главную задержку нетронутой.

После изменений используйте те же правила, иначе сравнение не имеет смысла

После создания базового показателя зафиксируйте определения. Используйте те же типы работы, события начала и окончания, классификации недель, поля capacity и метрики надёжности после внедрения изменения.

Это относится к AI-инструментам, новому staff engineer, подрядчику, переписанному CI-конвейеру или процессу управления продуктом. Если вы одновременно меняете определение метрики и операционную модель, вы теряете возможность сказать, что именно изменилось.

Разумный анализ до и после должен ответить на пять вопросов:

• Изменился ли состав работы существенно?
• Изменилась ли доступная численность команды?
• Изменились ли политика релизов, политика согласований или частота развёртываний?
• Надёжность ухудшилась, улучшилась или осталась стабильной?
• Где именно сократилось время выполнения?

Последний вопрос помогает сохранить честность обсуждения. Если медианное время сократилось с 11 до 7 дней, определите, уменьшилось ли время написания кода, сократились ли очереди ревью, стало ли меньше тестовых сбоев или продуктовые решения стали приходить раньше. Если никто не может объяснить механизм, соберите больше данных, прежде чем объявлять результат улучшением.

Не требуйте математической определённости от небольшого набора данных стартапа. Обычно наблюдений для этого недостаточно. Требуйте проверяемого объяснения. Справедливое сравнение звучит так: «При одинаковой классификации работы и сопоставимой численности команды обычная поставка функций ускорилась, а сокращение времени произошло благодаря меньшему числу итераций ревью и автоматической настройке тестов. Повторная работа не увеличилась». Это намного сильнее, чем заявление: «AI повысил продуктивность команды на 40%».

Аудит Team & AI должен начинаться с этой работы по созданию базового показателя, потому что любая оценка экономии на смешанных неделях превращается в театр. Сначала нужно найти ограничение, а уже потом тратить деньги на его перемещение в другое место.

Первое действие: пометьте последние двенадцать недель

Не начинайте с опроса разработчиков или демонстрации инструмента. Возьмите последние восемь-двенадцать завершённых недель, добавьте в реестр по одной строке на неделю и пометьте запуски, инциденты, праздники, отсутствие сотрудников, вакансии и изменения практики релизов.

Затем считайте обычную поставку только по неделям, которые получили соответствующую метку. Исключённые недели оставляйте рядом, чтобы они были видны. Если обычный базовый показатель слаб из-за того, что осталось слишком мало недель, это полезный результат: организация работает в режиме исключений и нуждается в более длинном периоде наблюдения, прежде чем заявлять о проблеме или успехе в эффективности.

Основатели обычно хотят одно число, потому что им кажется, что им легко управлять. Сначала создайте объяснение. Тогда у числа появится шанс что-то значить.