Базовая линия: зачем она нужна и как её посчитать

Когда дашборд показывает “68% глубокой работы сегодня” или “5.8 переключений в час на этой неделе”, первый вопрос, который стоит задать — не “это хорошо или плохо”, а “по сравнению с чем”. Без ответа на этот вопрос любое число висит в воздухе: 68% может быть заметным достижением, а может быть обычным вторником, в зависимости от того, что для конкретного пользователя типично. Эта точка отсчёта и называется базовой линией — и то, как именно её посчитать и на что при этом опираться, для многих остаётся менее очевидным, чем сам факт, что сравнивать нужно с собой.

Что такое базовая линия: определение
Зачем база, а не готовый норматив
Сколько данных нужно для устойчивой базы
Таблица: окно данных и когда его использовать
Как база обновляется со временем
Типичная ошибка: короткая база выдаёт случайность за сдвиг
Как база используется на практике: эксперименты и цели
Частые вопросы
Читайте также

Что такое базовая линия: определение

Базовая линия (baseline) метрики — это типичное значение показателя за предыдущий период, рассчитанное по собственной истории пользователя, которое служит точкой отсчёта для сравнения с новыми данными. Не среднее по рынку, не рекомендация из статьи и не число, придуманное заранее — а то, что для этого конкретного пользователя при этой конкретной работе является обычным. Новое значение метрики приобретает смысл только тогда, когда его есть с чем сопоставить, и база — это именно то “с чем”.

Важно отличать базу от единичного вчерашнего значения. База — это не “сколько было вчера”, а обобщённая картина по достаточному числу дней: диапазон, в котором обычно колеблется показатель, и, как правило, среднее значение внутри этого диапазона. Вчерашний день может быть типичным или нет — это как раз и проверяется сравнением с базой, а не наоборот.

Зачем база, а не готовый норматив

Соблазн простой: найти готовое число — “нормальный” процент глубокой работы, эталонное количество переключений в час — и сверяться с ним, не считая ничего самому. Проблема в том, что такого универсального норматива не существует по объективной причине: структура рабочего дня слишком сильно различается между ролями. У разработчика, который большую часть дня пишет код в одиночку, и у менеджера, чей день состоит из вереницы созвонов, принципиально разная “нормальная” доля непрерывной работы — не потому что один работает лучше другого, а потому что это структурно разные виды работы.

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

Сколько данных нужно для устойчивой базы

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

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

Таблица: окно данных и когда его использовать

Окно данных	Когда использовать	Основной риск
3–5 дней	Только как черновая прикидка, никогда как финальная база	Случайные обстоятельства одного-двух дней воспринимаются как норма
1 неделя	Первое приближение, если данных пока больше нет	Один нетипичный день недели (отпуск, аврал) искажает всё среднее
2–3 недели	Минимально устойчивая база для повседневного сравнения	Разумный баланс между свежестью и стабильностью — рекомендуемый минимум
4–6 недель	Метрики с высокой изменчивостью день ото дня, редкие события (например, число коммитов)	База более гладкая, но медленнее подхватывает реальные изменения условий работы
3+ месяцев без обновления	Не рекомендуется как фиксированная точка отсчёта	Устаревает при смене роли, проекта или состава задач

Таблица — не про то, что длиннее всегда лучше. Она про соответствие окна задаче: для повседневного “похоже это на мой обычный день или нет” двух-трёх недель обычно достаточно, а вот держать базу фиксированной полгода без обновления — уже отдельная ошибка, о которой дальше.

Как база обновляется со временем

База — это не число, посчитанное один раз и записанное навсегда, а скользящее окно, которое сдвигается вперёд вместе с текущим днём. Практически это означает, что база пересчитывается по данным за последние N недель (например, три), и с каждым новым днём в этот расчёт добавляется вчера, а самый старый день из окна выпадает. База сегодня и база через месяц — это, как правило, разные числа, даже если ничего особенного за это время не произошло: она просто становится немного точнее и актуальнее по мере накопления данных.

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

Типичная ошибка: короткая база выдаёт случайность за сдвиг

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

Гипотетический пример, все числа условные и придуманы только для иллюстрации логики, а не как факт о реальных пользователях. Допустим, пользователь решает посчитать базу по переключениям контекста всего за четыре дня: понедельник — 9 переключений в час, вторник — 6, среда (день с несколькими встречами подряд) — 14, четверг — 7. Среднее по этим четырём дням — 9. Пользователь фиксирует “моя обычная база — 9 переключений в час” и на этом останавливается.

В пятницу показатель — 6 переключений в час. Формально это заметно ниже “базы” в 9, и пользователь делает вывод: “сегодня я собраннее, чем обычно”. На самом деле пятничные 6 почти не отличаются от вторничных 6 — просто во вторник этот день случайно оказался частью базы, а в пятницу воспринимается как отклонение от неё. Реальная проблема не в пятнице, а в том, что “необычная” среда с несколькими встречами задала завышенную планку для всего четырёхдневного среднего — один структурно нетипичный день перекосил базу, которая должна была описывать обычный уровень.

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

Как база используется на практике: эксперименты и цели

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

В экспериментах база — это период до изменения, с которым сравнивается период самого эксперимента: если гипотеза звучит “если отключить уведомления с 10 до 11, переключений в этот час станет меньше”, то итог оценивается не против абстрактного “правильного” числа переключений, а против собственной базы за недели до начала эксперимента. Подробно о том, как именно считается результат такого сравнения — в статье про эксперименты и гипотезы.

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

Строка «День 1 из 5 · база: 6.9/ч» — это и есть базовая линия, посчитанная по собственной истории до начала эксперимента, с которой дальше сравнивается каждый день эксперимента.

В целях база работает иначе, но на той же логике: DevPace не подставляет целевое значение по умолчанию и не предлагает “рекомендуем 4 часа глубокой работы” — число выбирает сам пользователь. Но разумный способ его выбрать — не придумать число из головы, а оттолкнуться от собственной базы за последние недели и поставить цель немного выше или ниже неё, а не ориентироваться на чужой норматив, который может не подходить под конкретную работу и график. И эксперименты, и цели в этом смысле устроены одинаково: точкой отсчёта в них всегда служит собственная история, а не абстрактная цифра.

Частые вопросы

Что делать, если данных пока меньше 2–3 недель?

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

Нужно ли сбрасывать базу при смене работы или проекта?

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

Как часто база пересчитывается — вручную или сама?

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