Тайм-менеджмент для инженера Цели: SMART, OKR, антицели и почему цели часто вредят
0%

Цели: SMART, OKR, антицели и почему цели часто вредят

Цели: SMART, OKR, антицели и почему цели часто вредят

В предыдущей статье — Горизонты планирования — мы построили каркас: день, неделя, квартал, год и обзор, который их связывает. Каркас пустой. Он отвечает на вопрос «когда я думаю о чём», но не на вопрос «к чему я вообще иду».

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

Главный тезис статьи: цель — это не мотивационный инструмент, а инструмент фокусировки внимания, и у него есть побочные эффекты. Как у любого инструмента с побочными эффектами, у него есть показания и противопоказания. Большая часть вреда от целей происходит не потому, что человек «плохо их ставил», а потому, что цель применили к задаче, для которой она не подходит.

Что действительно доказано: теория целеполагания

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

Эдвин Локк в 1968 году опубликовал работу «Toward a Theory of Task Motivation and Incentives», с которой началась goal-setting theory. За следующие тридцать пять лет Локк и Гэри Лэтам собрали, по их подсчёту, более 400 исследований. Итог они подвели в статье «Building a Practically Useful Theory of Goal Setting and Task Motivation: A 35-Year Odyssey» (American Psychologist, 2002, PDF). Основные выводы:

  1. Конкретная и трудная цель даёт результат выше, чем «сделай как можно лучше». Это самый устойчивый эффект во всей области. Расплывчатая установка не задаёт критерия остановки, и человек останавливается на «достаточно».
  2. Зависимость производительности от трудности цели близка к линейной — до предела способностей. Слишком лёгкая цель работает как потолок, а не как пол.
  3. Механизмы четыре: направление внимания на релевантное, мобилизация усилия, настойчивость во времени и — самое интересное — активация уже имеющихся стратегий выполнения.
  4. Обязательные условия: приверженность цели (commitment), обратная связь о прогрессе и наличие нужных способностей и ресурсов. Без обратной связи цель почти не работает.

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

Обратите внимание, чего в списке нет. Там нет SMART, нет OKR, нет квартальных ревью, нет каскадирования целей сверху вниз. Всё это — управленческие практики, надстроенные над теорией позже, и у каждой своя, гораздо более скромная доказательная база.

Короткая история: от MBO до OKR

Здесь важен сюжет, а не даты. Практика (MBO, SMART, OKR) почти всегда опережала доказательства, а критика приходила спустя десятилетия, когда побочные эффекты успевали накопиться в реальных компаниях. Ни одна из популярных методик не была сначала проверена, а потом внедрена.

SMART: что написал Доран и что от этого осталось

Оригинал 1981 года

Джордж Доран, консультант и директор по корпоративному планированию Washington Water Power Company, опубликовал в ноябрьском номере Management Review за 1981 год двухстраничную заметку «There’s a S.M.A.R.T. Way to Write Management’s Goals and Objectives». Оригинальная расшифровка:

  • Specific — конкретная область для улучшения;
  • Measurable — количественный показатель прогресса;
  • Assignable — назначаемая, то есть указано, кто это делает;
  • Realistic — реалистичная при имеющихся ресурсах;
  • Time-related — с указанием срока.

Заметьте: Assignable, а не Achievable, и Realistic, а не Relevant. Знакомая всем расшифровка — результат тридцатилетнего испорченного телефона. Хуже того, Доран прямо писал, что не каждая цель обязана удовлетворять всем пяти критериям и что аббревиатура — мнемоника, а не тест на допуск. Индустрия тренингов превратила мнемонику в обязательный формуляр.

Отдельно стоит знать: у SMART как формулы нет собственной доказательной базы. Работоспособны отдельные компоненты, унаследованные от теории целеполагания (конкретность, измеримость, срок как форма обратной связи). Требование «реалистичности» вообще противоречит выводу Локка и Лэтама о том, что трудная цель эффективнее умеренной. Когда вам говорят «SMART доказан наукой» — это неверно; доказана конкретность, а не аббревиатура.

Как это выглядит у инженера

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

Плохо Почему плохо Лучше
«Улучшить производительность API» Нет критерия остановки, нет базовой линии «Снизить p99 GET /orders с 840 мс до 300 мс к 30 июня, замер — дашборд api-latency, окно 7 дней»
«Разобраться в Kubernetes» Неизвестно, что считать «разобрался» «К 15 мая самостоятельно поднять и задокументировать staging-неймспейс сервиса billing, без помощи SRE»
«Стать сильнее в code review» Не наблюдаемо «В каждом ревью крупнее 200 строк оставлять минимум один комментарий про границы модуля, а не про стиль; проверять по своим ревью на недельном обзоре»
«Закрыть техдолг» Не цель, а настроение «Убрать прямые обращения к БД из billing-api в пользу репозитория: 23 места → 0, к концу квартала»

Три практических правила формулировки, которые дают больше пользы, чем сама аббревиатура:

  1. Всегда пишите базовую линию. «840 мс → 300 мс» несравнимо полезнее, чем «300 мс». Без базовой линии вы не отличите достижение от совпадения.
  2. Указывайте источник замера. Не «стало быстрее», а «дашборд такой-то, окно такое-то». Половина споров о достижении цели — это споры о способе измерения.
  3. Формулируйте результат, а не работу. «Внедрить кеш» — это работа; её можно выполнить полностью и не получить ничего. «p99 ниже 300 мс» — результат; кеш может оказаться ненужным.

Где SMART ломается

На исследовательской работе. «Понять, почему p99 скачет по вторникам» невозможно сделать измеримым заранее: измеримым является только ответ, которого у вас нет. Попытка натянуть SMART на исследование даёт две патологии: либо цель формулируется через объём работы («прочитать 5 статей», «поставить 3 эксперимента»), либо человек подсознательно выбирает ту гипотезу, которую проще подтвердить в срок.

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

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

Ключевая развилка: цель результата или цель обучения

Это самая полезная идея в статье, и она почти не попадает в популярные тексты.

Гэри Лэтам с коллегами обнаружили, что на сложных новых задачах конкретная трудная цель результата ухудшает результат. Механизм: цель мобилизует усилие, но усилие не помогает, когда неизвестна стратегия; человек начинает лихорадочно перебирать подходы, тратит рабочую память на отслеживание разрыва с целью и хуже учится. Решение — цель обучения (learning goal): вместо «достичь X» ставится «найти и описать N способов сделать X» или «разобраться в механизме Y». См. Winters & Latham (1996) и обзор Seijts & Latham «Learning versus performance goals: When should each be used?» (Academy of Management Executive, 2005).

Для инженера это переводится буквально:

Практическое правило: если вы не можете набросать план решения за десять минут — ставьте цель обучения, а не цель результата. «Снизить p99 до 300 мс» превращается в «за две недели построить профиль запроса и назвать три главных источника задержки с цифрами». Вторая формулировка выполнима, проверяема и не толкает вас к преждевременным «оптимизациям» ради цифры.

Таймбокс при этом остаётся жёстким — иначе исследование расползается бесконечно. Ограничиваем время, а не результат.

OKR

Откуда взялись

Энди Гроув в Intel сконструировал то, что называл iMBO — «Intel Management by Objectives», описав систему в «High Output Management» (1983). Его формула проста: «Я хочу [Objective], измеряемое [Key Results]». Джон Дёрр, работавший у Гроува, в 1999 году принёс подход в Google, где тогда было около сорока сотрудников. Дальнейшая популяризация — книга Дёрра «Measure What Matters» (2018) и сайт whatmatters.com.

Механика

Анатомия OKR: объектив, ключевые результаты, антицель и типичные ошибки

Формально:

  • Objective — качественное, вдохновляющее, без цифр. Отвечает на «куда идём».
  • Key Results — 2–5 штук, каждый численный, с базовой линией и целевым значением. Отвечают на «как мы узнаем, что дошли».
  • Цикл — квартал (иногда год для верхнего уровня), с обязательным промежуточным чек-ином.
  • Разделение на commit и aspirational. Commit-цели должны выполняться на 1.0 — это обязательства. Aspirational («moonshot») ставятся заведомо трудными, и ожидаемое выполнение 0.6–0.7. Это не «недоработали», а калибровка амбиции.
  • Отвязка от компенсации. Дёрр и внутренние материалы Google подчёркивают: как только OKR влияет на премию, люди начинают ставить достижимые цели, и весь смысл aspirational-режима исчезает. Это, пожалуй, самое часто нарушаемое правило метода.

Знаменитая «оценка 0.7» — источник постоянной путаницы. Она относится только к aspirational-целям. Если commit-цель выполнена на 0.7, это не норма, а провал обязательства.

Почему индивидуальные OKR почти всегда ломаются

Личные OKR у отдельного инженера — самая частая и самая вредная форма карго-культа. Причины конкретные:

Инженер редко владеет исходом. KR вида «Снизить количество инцидентов P1 с 9 до 3» зависит от нагрузки, чужих релизов, инфраструктуры и удачи. Владелец такого KR — команда, а не человек. Персональное владение неуправляемым исходом даёт ровно один эффект — тревогу.

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

Гейминг наступает мгновенно. Как только цифра связана с оценкой человека, оптимизируется цифра. Это не про нечестность, это про устройство систем с обратной связью.

Смешение работы и результата. Девять из десяти личных KR, которые я видел, — это замаскированный список задач: «внедрить X», «написать Y», «провести Z». Список задач в формате OKR не становится целью, зато обрастает ритуалом.

Честная позиция: OKR — инструмент организационного выравнивания. Его ценность в том, что двадцать команд публично объявляют, чего они не будут делать. У одного человека нет проблемы выравнивания с самим собой, зато есть все издержки метода. Если ваша компания требует личных OKR, минимально вредная стратегия — брать один Objective, два-три KR, формулировать их как вклад («мой вклад в командный KR — такой-то»), и держать отдельный, честный личный план вне этой системы.

Что известно из исследований

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

Метаанализ стоит знать: Rodgers & Hunter, «Impact of Management by Objectives on Organizational Productivity» (Journal of Applied Psychology, 1991) — 70 исследований, прирост производительности в 68 из них. Но ключевая находка не в этом. Когда высшее руководство было реально вовлечено, средний прирост составлял порядка 56%; при низкой вовлечённости — около 6%. То есть работает не механика метода, а внимание руководства и качество обратной связи. Ровно это объясняет, почему одна и та же система в двух компаниях даёт разные результаты, и почему её невозможно «внедрить» скриптом.

Почему цели часто вредят

В 2009 году вышла статья Ordóñez, Schweitzer, Galinsky и Bazerman «Goals Gone Wild: The Systematic Side Effects of Overprescribing Goal Setting» (Academy of Management Perspectives; рабочая версия HBS, PDF). Авторы предложили относиться к целям как к рецептурному препарату — с вкладышем о побочных эффектах. Локк и Лэтам ответили резко («Has Goal Setting Gone Wild, or Have Its Attackers Abandoned Good Scholarship?», там же), утверждая, что описанные эффекты — следствие плохого применения. Обе стороны частично правы, и полемику полезно прочитать целиком.

Побочные эффекты, переведённые на инженерный язык:

1. Слишком узкий фокус. Цель направляет внимание — и одновременно уводит его со всего остального. Классический пример из статьи: программа Ford Pinto, где жёсткие цели по срокам, весу и цене привели к выпуску автомобиля с известным дефектом топливного бака. Инженерная версия помягче: квартальная цель по latency, ради которой команда полгода не трогает наблюдаемость и накапливает слепые зоны.

2. Гейминг метрики. Закон Гудхарта (1975), в формулировке Мэрилин Стратерн: «Когда мера становится целью, она перестаёт быть хорошей мерой». Родственный закон Кэмпбелла (1979) утверждает то же о социальных показателях.

Дрейф Гудхарта: расхождение метрики и реального результата после того, как метрика стала целью

Каталог инженерного гейминга, который встречается повсеместно:

Метрика как цель Как её ломают Что теряется
Покрытие тестами ≥ 90% Тесты на геттеры, тесты без ассертов Тесты перестают ловить регрессии
Velocity / story points Инфляция оценок, дробление задач Оценки перестают быть оценками
Количество PR или коммитов Микро-PR, косметические правки Ревью-ёмкость команды тратится впустую
Deployment frequency (DORA) Пустые деплои, дробление релиза Показатель растёт, поток не меняется
Число инцидентов Инцидент переклассифицируется в «обращение» Пропадает статистика надёжности
Время закрытия тикета Тикет закрывается и переоткрывается новым История проблемы теряется
Строки кода Копипаста, отказ от удаления кода Кодовая база растёт быстрее пользы

Показательно, что авторы самих DORA-метрик и авторы фреймворка SPACE (Forsgren, Storey, Maddila, Zimmermann, Houck, Butler, «The SPACE of Developer Productivity», ACM Queue, 2021, текст) прямо предупреждают: нельзя оптимизировать одну метрику, метрики должны быть в наборе и из разных измерений. Это ровно защита от Гудхарта.

3. Неэтичное поведение. Wells Fargo: в 2016 году Бюро по финансовой защите потребителей США оштрафовало банк на 185 млн долларов; сотрудники открыли около 1,5 млн депозитных счетов и 565 тысяч заявок на кредитные карты без согласия клиентов (пресс-релиз CFPB). В основе — цель «восемь продуктов на домохозяйство». В Goals Gone Wild приводится и более старый пример: Sears в 1992 году поставила механикам цель по выручке 147 долларов в час, и это привело к массовым ненужным ремонтам. Инженерный аналог менее драматичен, но узнаваем: скрытые от отчётности инциденты, «зелёный» статус проекта до последней недели.

4. Вытеснение внутренней мотивации. Когда деятельность, которой человек занимался ради интереса, обвешивается целями и внешним контролем, интерес обычно падает. Это область эффекта сверхоправдания и теории самодетерминации (Deci, Koestner & Ryan, метаанализ 1999). Многие разработчики наблюдали это лично: хобби-проект, превращённый в план с дедлайнами, перестаёт быть отдыхом.

5. Рост склонности к риску и упорство не в том направлении. Цель, до которой немного не хватает, толкает к рискованным решениям в конце периода: выкатить в пятницу, срезать тесты, «потом починим». Разрыв с целью субъективно ощущается как потеря, а под потерей люди рискуют охотнее.

6. Цена невыполнения. Недостигнутая цель — сигнал, а не приговор, но переживается она телесно. Когда таких сигналов много кварталов подряд, они складываются в общее ощущение неуспешности, которое цепляется к другим факторам нагрузки. Про это осторожно и подробно — в статье про выгорание; здесь достаточно сказать, что систематическое невыполнение — это чаще информация о нереалистичности планирования или об условиях работы, чем о человеке.

Резюме раздела: цели работают, когда они направляют внимание на то, что вы контролируете, и вредят, когда становятся мерой вашей ценности или единственной оптимизируемой цифрой.

Антицели

Идея

Термин anti-goals популяризовал предприниматель Эндрю Уилкинсон, описавший, как вместо «чего я хочу достичь» они с партнёром выписали «чего в моём дне не должно быть никогда» — и построили работу вокруг этого списка. Интеллектуально приём старше: это инверсия Карла Якоби («invert, always invert»), которую Чарли Мангер сделал элементом инвестиционного мышления, и «stop doing list» Джима Коллинза из «Good to Great» (2001).

Механика проста. Вместо того чтобы описывать желаемое состояние (что трудно и требует предвидения), вы описываете состояния, которые считаете неприемлемыми (что легко, потому что вы их уже переживали). Затем формулируете условие, которое их предотвращает.

Почему это работает лучше обычных целей в ряде случаев:

  • Отрицательный опыт вспоминается точнее и конкретнее положительного воображаемого.
  • Антицель не подвержена геймингу так, как метрика: её нельзя «выполнить на 0.7».
  • Она не требует предсказывать будущее — только помнить прошлое.
  • Она задаёт границу, а не направление, и потому не сужает внимание.

Инженерные антицели

Антицель Проверяемое условие
Не хочу больше пятничных релизов в 20:00 Деплой-окно закрывается в 16:00 в четверг; исключение — только инцидент
Не хочу быть единственным, кто понимает сервис расчётов Ни один компонент не имеет одного владельца в CODEOWNERS; за квартал минимум два чужих PR в него
Не хочу день без единого блока в 90 минут Календарь: два защищённых блока в день, встречи по умолчанию отклоняются в эти часы (см. календарь)
Не хочу тянуть недоделанное между спринтами WIP-лимит 2, новая задача берётся только после закрытия (см. личный канбан)
Не хочу оправдываться за скорость метриками Ни одна личная цифра (PR, points, коммиты) не попадает в мой квартальный документ
Не хочу быть узким местом ревью Ни один PR, где я ревьюер, не ждёт меня дольше 24 рабочих часов
Не хочу проснуться в понедельник, не помня, зачем всё это Раз в квартал — 60 минут на вопрос «что здесь мне всё ещё интересно»

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

Как антицели соединяются с целями

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

Цель:     p99 GET /orders: 840 мс → 300 мс к 30 июня
Антицель: не за счёт удаления валидации и не за счёт кеша,
          который отдаёт устаревшие данные дольше 5 секунд
Цель:     доля алертов с раннбуком 40% → 100%
Антицель: ни один алерт не удалён и ни один порог не поднят
          ради улучшения доли

Что реально работает: намерения реализации

Если из статьи нужно унести одну технику с сильной доказательной базой, то это не SMART и не OKR, а implementation intentions Петера Гольвитцера: план в форме «Если наступит ситуация X, я сделаю Y».

Метаанализ Gollwitzer & Sheeran (2006) охватил 94 независимых исследования и дал средний размер эффекта d ≈ 0.65 поверх эффекта от простой постановки цели. Это большой и хорошо воспроизводимый результат для поведенческой области. Механизм: заранее связанный триггер снимает необходимость принимать решение в момент, когда ресурсов на решение уже нет.

Инженерная разница выглядит так:

  • Цель: «буду писать тесты до кода». Намерение: «Если я открываю новый файл в internal/billing, то первым делом создаю _test.go рядом».
  • Цель: «меньше отвлекаться». Намерение: «Если приходит уведомление в Slack во время блока фокуса, то я не открываю его, а записываю в инбокс одной строкой» (см. сбор задач).
  • Цель: «делать ревью вовремя». Намерение: «Если сейчас 11:30 и я закончил утренний блок, то первые 25 минут — очередь ревью, до почты».
  • Цель: «не залипать в дебаге». Намерение: «Если прошло 45 минут без нового факта о баге, то я пишу в канал команды, что застрял, и описываю, что уже проверил».

Родственная техника — mental contrasting Габриэле Эттинген, объединённая с намерениями в протокол WOOP: Wish, Outcome, Obstacle, Plan (woopmylife.org). Ключевой элемент — шаг Obstacle: вы обязаны назвать конкретное внутреннее препятствие («после стендапа у меня падает энергия и я иду в ленту»), а не внешнее. Позитивные фантазии о результате без этого шага, по данным Эттинген, скорее снижают вероятность действия, чем повышают: мозг частично «засчитывает» воображаемое достижение.

Это, пожалуй, главный практический вывод статьи: связка «одна цель обучения на квартал + набор если-то на неделю» на практике сильнее, чем красиво оформленный документ из пяти OKR.

Сборка: рабочая система целей для инженера

Ниже — конкретная конфигурация, которую можно завести завтра.

Уровень квартала: один документ

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

# Q3 2026 — личное

## Контекст
Дежурю 4 недели из 13. Отпуск 10–24 августа.
Реальная ёмкость: ~7 рабочих недель под собственные цели.

## Цель обучения (главная)
Разобраться в модели консистентности нашего шардированного Postgres
настолько, чтобы самостоятельно проектировать миграции без ревью DBA.
  Признак: спроектирована и проведена миграция orders_v3, DBA
  подтверждает отсутствие замечаний по блокировкам.
  Антицель: не читаю ещё одну книгу вместо практики.

## Цель результата
p99 GET /orders: 840 мс -> 300 мс (дашборд api-latency, окно 7 дней).
  Антицель: не ценой отключения валидации и не кешем со stale > 5 c.

## Явно НЕ делаю в этом квартале
- Не берусь за переписывание слоя нотификаций.
- Не иду в комитет по архитектуре.
- Не веду вторую менторскую пару.

## Если-то на квартал
- Если понедельник и 10:00 -> 30 минут ревизии этого файла.
- Если цель не двигалась 3 недели подряд -> она снимается, не переносится.

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

Уровень недели: связь с обзором

На недельном обзоре (см. горизонты планирования) по целям задаются ровно три вопроса, не больше:

  1. Что изменилось в цифре или в понимании за неделю? (Если ничего — это факт, а не повод для самокритики.)
  2. Какой один блок в календаре на следующей неделе двигает цель? Если такого блока нет — цель на этой неделе не существует.
  3. Не нарушена ли антицель?

Жизненный цикл цели

Два перехода здесь нетипичны для стандартных методик и потому особенно полезны.

«Под риском → Переформулирована». Если цель результата три недели не двигается, чаще всего проблема не в дисциплине, а в том, что стратегия неизвестна. Правильная реакция — понизить её до цели обучения, а не удваивать усилие.

«Под риском → Снята». Снятая цель с записанной причиной — нормальный, здоровый исход. Молчаливый перенос в следующий квартал — нет: так накапливается список, который вы уже не читаете, потому что читать его неприятно.

Ритм квартала

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

Мини-скрипт: проверка темпа

Полезный вопрос на середине квартала — не «сколько сделано», а «успеваю ли я в текущем темпе». Считается тривиально; ценность не в математике, а в том, что цифра появляется без самоуговоров.

from dataclasses import dataclass
from datetime import date


@dataclass
class KeyResult:
    name: str
    baseline: float   # значение на старте
    target: float     # целевое значение
    current: float    # текущее значение


def progress(kr: KeyResult) -> float:
    """Доля пройденного пути, 0.0..1.0+. Работает и на убывающих метриках."""
    span = kr.target - kr.baseline
    if span == 0:
        raise ValueError(f"{kr.name}: цель совпадает с базовой линией")
    return (kr.current - kr.baseline) / span


def pace(kr: KeyResult, start: date, end: date, today: date) -> str:
    """Сравнивает фактический прогресс с равномерным темпом."""
    elapsed = (today - start).days / (end - start).days
    done = progress(kr)
    delta = done - elapsed
    if delta >= 0.05:
        verdict = "опережение"
    elif delta >= -0.10:
        verdict = "в графике"
    else:
        verdict = "отставание — обсудить снятие или переформулировку"
    return f"{kr.name}: сделано {done:.0%}, прошло {elapsed:.0%} времени → {verdict}"


krs = [
    KeyResult("p99 GET /orders, мс", baseline=840, target=300, current=610),
    KeyResult("Алерты с раннбуком, %", baseline=40, target=100, current=52),
]

for kr in krs:
    print(pace(kr, date(2026, 7, 1), date(2026, 9, 30), date(2026, 8, 12)))

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

Хранить цели удобно рядом с кодом — тогда они версионируются и не теряются:

# ~/notes/goals/2026-q3.yaml
quarter: 2026-Q3
capacity_weeks: 7          # 13 недель минус дежурства и отпуск
learning_goal:
  statement: "Проектировать миграции шардированного Postgres без ревью DBA"
  evidence: "orders_v3 проведена, замечаний по блокировкам нет"
  anti_goal: "не заменять практику чтением"
outcome_goal:
  metric: "p99 GET /orders (мс)"
  baseline: 840
  target: 300
  source: "grafana/api-latency, окно 7d"
  anti_goal: "без отключения валидации; stale в кеше <= 5s"
not_doing:
  - "переписывание слоя нотификаций"
  - "комитет по архитектуре"

Типичные ошибки

  1. Цели без вычета ёмкости. Тринадцать недель квартала — это в реальности семь-восемь недель работы под собственные цели. Всё остальное — дежурства, отпуска, чужие срочности, ревью.
  2. Больше трёх целей. Три цели — это отсутствие приоритета в замаскированном виде. Одна главная плюс одна фоновая — рабочий максимум для человека, у которого есть основная работа.
  3. Цель как список задач. Если пункт можно «закрыть», это задача. Цель нельзя закрыть — её можно достичь или не достичь.
  4. Отсутствие базовой линии. Без «было» нет «стало».
  5. Личные метрики производительности как цели. Points, PR, коммиты, строки — это диагностические сигналы для команды, а не персональные цели. Превращение их в цель гарантированно даёт гейминг (см. предупреждение авторов SPACE).
  6. Цель результата на исследовательской задаче. Основная причина, по которой квартал «не двигался». Лечится понижением до цели обучения.
  7. Молчаливый перенос. Невыполненная цель, тихо скопированная в следующий квартал, отравляет систему: документ становится списком упрёков, и вы перестаёте его открывать.
  8. Цель без отказа. Если ради цели ничто не убрано из плана, цель не поставлена.
  9. Смешение commit и aspirational. Одинаковое отношение к обязательству и к ставке приводит либо к профанации обязательств, либо к отказу от амбициозных ставок.
  10. Годовые цели без пересмотра. Годовой горизонт полезен как направление, но конкретные годовые KR к марту обычно уже неверны. Направление — на год, числа — на квартал.

Когда цели надо снять, а не дожать

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

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

Второе: истощение, цинизм по отношению к работе и ощущение снижения профессиональной эффективности — это описанный ВОЗ в МКБ-11 профессиональный феномен «выгорание» (код QD85, icd.who.int), а не проблема дисциплины и не то, что чинится более правильным шаблоном целей. Если это про вас — самая полезная вещь, которую может сделать система целей, это освободить место: снять квартальные обязательства, не переносить их, и обратиться к специалисту (врач, психотерапевт, корпоративная программа поддержки). Статья про выгорание разбирает тему подробнее, но она тоже не заменяет консультацию.

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

Мини-итог

  • Доказана не аббревиатура, а механизм: конкретная трудная цель + обратная связь + приверженность + наличие ресурсов. Всё остальное — надстройка разной степени обоснованности.
  • SMART — мнемоника 1981 года, у которой потерялась половина букв и не было собственной доказательной базы. Полезное из неё: базовая линия, источник замера, формулировка через результат, а не через работу.
  • Главная развилка для инженера — цель результата или цель обучения. Не можете набросать план за десять минут — ставьте цель обучения с жёстким таймбоксом.
  • OKR — инструмент выравнивания организации, а не личной продуктивности. У метода нет собственной исследовательской базы; ближайший метаанализ (MBO) показывает, что решает вовлечённость руководства, а не механика.
  • Цели имеют побочные эффекты: узкий фокус, гейминг метрик, риск, вытеснение внутренней мотивации. Инженерный каталог гейминга (покрытие, velocity, deploy frequency, число инцидентов) — не исключение, а норма систем с обратной связью.
  • Антицели дешевле и устойчивее к геймингу: одна антицель на каждую цель закрывает большую часть дыр Гудхарта.
  • Самая сильная по доказательствам техника здесь — намерения реализации «если X, то Y» (d ≈ 0.65 поверх обычной цели). Она стоит дороже любого красивого документа с OKR.
  • Снятая цель с записанной причиной лучше молча перенесённой. Систематическое невыполнение — сигнал об условиях и нагрузке, а не о характере.

Источники

Что дальше

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

Прокрастинация: настоящие причины и что действительно помогает

Нашли неточность? Выделите фрагмент текста — рядом появится жучок.

Нужен разбор именно вашей ситуации?

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

Доска запросов