Как поставить цель по продуктивности, которую реально можно измерить

“Хочу быть продуктивнее” — не цель, а пожелание. Чтобы превратить его в цель, обычно советуют SMART или OKR: сформулировать конкретно, измеримо, ограничить сроком. Совет правильный, но у него есть слабое место, которое редко проговаривают — сама формулировка остаётся словесной. “Уменьшить количество отвлечений” звучит вполне по-SMART-ому, но чем именно это будет проверяться каждый день? Обычно — субъективным ощущением в конце недели или квартальной самооценкой по шкале от 1 до 5. Для цели по личной продуктивности этого мало: если метрика не привязана к тому, что реально считается изо дня в день, цель легко подвинуть постфактум под любой результат.

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

Чем абстрактная цель отличается от цели по метрике

SMART и OKR — хорошие рамки для формулировки, но обе исторически придуманы для целей компании или команды, а не для личной продуктивности одного человека за компьютером. Objective в OKR — это обычно направление (“повысить фокус на приоритетных задачах”), а Key Result — куда более общее число, чем то, что можно проверить автоматом: “снизить количество отвлечений”, “увеличить глубокую работу”. Дальше это число всё равно нужно откуда-то взять, и чаще всего его берут из ручного отчёта, дневника или просто ощущения в конце месяца.

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

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

Как это устроено в DevPace

При создании цели выбираются три вещи. Во-первых, метрика — любая из уже отслеживаемых: активное время, доля глубокой работы, количество переключений контекста, число коммитов в git или средняя оценка дневного чек-ина. Во-вторых, режим сравнения — “не менее” (для показателей, где больше обычно лучше — активное время, доля глубокой работы) или “не более” (для показателей, где цель — сократить дробление, например переключения контекста). В-третьих, целевое значение — конкретное число: проценты, часы и минуты, штуки.

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

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

Четыре примера измеримых целей

Формулировка “измеримая цель” звучит абстрактно, пока не привязана к конкретным числам. Вот четыре примера того, как это выглядит на практике для разных метрик.

Доля глубокой работы: “не менее 40% каждый день”. Подходит для роли, где основная ценность — непрерывная сосредоточенная работа над задачей: разработка, аналитика, написание текстов. Если сейчас показатель держится около 30–33%, цель в 40% — небольшой, но реальный шаг вперёд, а не абстрактный ориентир “стремиться к максимуму”.

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

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

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

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

Типичные ошибки при выборе порога

Две ошибки встречаются чаще всего, и обе не про метрику, а про то, какое число за ней поставили. Первая — порог, взятый не от своей нормы, а из общих рекомендаций: “80% глубокой работы, потому что так написано в статье про продуктивность разработчиков”. Если реальный уровень последних недель — 30%, разрыв в 50 пунктов не мотивирует, а почти сразу превращается в ежедневное “опять не выполнено” и цель забрасывают. Разумный шаг — 5–10 пунктов от текущей нормы, не больше.

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

Откуда брать целевое значение

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

Поэтому единственная разумная отправная точка — собственная недавняя статистика, которая и так видна в «Трендах». Если доля глубокой работы последние недели держится около 33%, логичная цель — попробовать 40%, а не абстрактный максимум. Небольшой шаг от своей нормы проверяем и достижим; произвольное число “с потолка” — нет.

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

Разовая цель или повторяющаяся

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

Пауза вместо удаления

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

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

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

Смотрите также

• Как поставить свою цель по продуктивности в DevPace — подробно о режимах, повторе и паузе
• Глубокая работа: что это, как измерить и сколько её реально в дне
• Эксперименты в DevPace: как проверять свои идеи о работе

Опубликовано: 1 июня 2026 г. · обновлено: 26 июля 2026 г.