Цели: 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). Основные выводы:
- Конкретная и трудная цель даёт результат выше, чем «сделай как можно лучше». Это самый устойчивый эффект во всей области. Расплывчатая установка не задаёт критерия остановки, и человек останавливается на «достаточно».
- Зависимость производительности от трудности цели близка к линейной — до предела способностей. Слишком лёгкая цель работает как потолок, а не как пол.
- Механизмы четыре: направление внимания на релевантное, мобилизация усилия, настойчивость во времени и — самое интересное — активация уже имеющихся стратегий выполнения.
- Обязательные условия: приверженность цели (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, к концу квартала» |
Три практических правила формулировки, которые дают больше пользы, чем сама аббревиатура:
- Всегда пишите базовую линию. «840 мс → 300 мс» несравнимо полезнее, чем «300 мс». Без базовой линии вы не отличите достижение от совпадения.
- Указывайте источник замера. Не «стало быстрее», а «дашборд такой-то, окно такое-то». Половина споров о достижении цели — это споры о способе измерения.
- Формулируйте результат, а не работу. «Внедрить кеш» — это работа; её можно выполнить полностью и не получить ничего. «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.
Механика
Формально:
- 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 недели подряд -> она снимается, не переносится.
Раздел «Явно НЕ делаю» — самая ценная часть документа. Цель без явного отказа не является решением: вы просто добавили пункт к списку желаний.
Уровень недели: связь с обзором
На недельном обзоре (см. горизонты планирования) по целям задаются ровно три вопроса, не больше:
- Что изменилось в цифре или в понимании за неделю? (Если ничего — это факт, а не повод для самокритики.)
- Какой один блок в календаре на следующей неделе двигает цель? Если такого блока нет — цель на этой неделе не существует.
- Не нарушена ли антицель?
Жизненный цикл цели
Два перехода здесь нетипичны для стандартных методик и потому особенно полезны.
«Под риском → Переформулирована». Если цель результата три недели не двигается, чаще всего проблема не в дисциплине, а в том, что стратегия неизвестна. Правильная реакция — понизить её до цели обучения, а не удваивать усилие.
«Под риском → Снята». Снятая цель с записанной причиной — нормальный, здоровый исход. Молчаливый перенос в следующий квартал — нет: так накапливается список, который вы уже не читаете, потому что читать его неприятно.
Ритм квартала
Обратите внимание: дежурство и отпуск нарисованы явно и вычитаются из ёмкости. План, где 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:
- "переписывание слоя нотификаций"
- "комитет по архитектуре"
Типичные ошибки
- Цели без вычета ёмкости. Тринадцать недель квартала — это в реальности семь-восемь недель работы под собственные цели. Всё остальное — дежурства, отпуска, чужие срочности, ревью.
- Больше трёх целей. Три цели — это отсутствие приоритета в замаскированном виде. Одна главная плюс одна фоновая — рабочий максимум для человека, у которого есть основная работа.
- Цель как список задач. Если пункт можно «закрыть», это задача. Цель нельзя закрыть — её можно достичь или не достичь.
- Отсутствие базовой линии. Без «было» нет «стало».
- Личные метрики производительности как цели. Points, PR, коммиты, строки — это диагностические сигналы для команды, а не персональные цели. Превращение их в цель гарантированно даёт гейминг (см. предупреждение авторов SPACE).
- Цель результата на исследовательской задаче. Основная причина, по которой квартал «не двигался». Лечится понижением до цели обучения.
- Молчаливый перенос. Невыполненная цель, тихо скопированная в следующий квартал, отравляет систему: документ становится списком упрёков, и вы перестаёте его открывать.
- Цель без отказа. Если ради цели ничто не убрано из плана, цель не поставлена.
- Смешение commit и aspirational. Одинаковое отношение к обязательству и к ставке приводит либо к профанации обязательств, либо к отказу от амбициозных ставок.
- Годовые цели без пересмотра. Годовой горизонт полезен как направление, но конкретные годовые KR к марту обычно уже неверны. Направление — на год, числа — на квартал.
Когда цели надо снять, а не дожать
Отдельно и без бодрости. Бывает состояние, в котором любые методики целеполагания не помогают и делают хуже: цели не двигаются, каждое их упоминание вызывает тяжесть, работа, которая раньше нравилась, ощущается пустой. Здесь важно различать две вещи.
Первое: систематическое невыполнение целей — это чаще диагностика условий, чем диагностика человека. Нереалистичная ёмкость, постоянные внешние срочности, отсутствие влияния на исход — организационные факторы. Их не чинят силой воли, их чинят разговором с руководителем о нагрузке, о числе параллельных обязательств и о том, кто владеет результатом.
Второе: истощение, цинизм по отношению к работе и ощущение снижения профессиональной эффективности — это описанный ВОЗ в МКБ-11 профессиональный феномен «выгорание» (код QD85, icd.who.int), а не проблема дисциплины и не то, что чинится более правильным шаблоном целей. Если это про вас — самая полезная вещь, которую может сделать система целей, это освободить место: снять квартальные обязательства, не переносить их, и обратиться к специалисту (врач, психотерапевт, корпоративная программа поддержки). Статья про выгорание разбирает тему подробнее, но она тоже не заменяет консультацию.
Практическое правило, которое стоит записать заранее, в спокойном состоянии: снятие цели — легальная операция, не требующая оправданий. Если это правило зафиксировано в вашем квартальном документе до начала квартала, воспользоваться им в нужный момент существенно легче.
Мини-итог
- Доказана не аббревиатура, а механизм: конкретная трудная цель + обратная связь + приверженность + наличие ресурсов. Всё остальное — надстройка разной степени обоснованности.
- SMART — мнемоника 1981 года, у которой потерялась половина букв и не было собственной доказательной базы. Полезное из неё: базовая линия, источник замера, формулировка через результат, а не через работу.
- Главная развилка для инженера — цель результата или цель обучения. Не можете набросать план за десять минут — ставьте цель обучения с жёстким таймбоксом.
- OKR — инструмент выравнивания организации, а не личной продуктивности. У метода нет собственной исследовательской базы; ближайший метаанализ (MBO) показывает, что решает вовлечённость руководства, а не механика.
- Цели имеют побочные эффекты: узкий фокус, гейминг метрик, риск, вытеснение внутренней мотивации. Инженерный каталог гейминга (покрытие, velocity, deploy frequency, число инцидентов) — не исключение, а норма систем с обратной связью.
- Антицели дешевле и устойчивее к геймингу: одна антицель на каждую цель закрывает большую часть дыр Гудхарта.
- Самая сильная по доказательствам техника здесь — намерения реализации «если X, то Y» (d ≈ 0.65 поверх обычной цели). Она стоит дороже любого красивого документа с OKR.
- Снятая цель с записанной причиной лучше молча перенесённой. Систематическое невыполнение — сигнал об условиях и нагрузке, а не о характере.
Источники
- Locke E. A., Latham G. P. «Building a Practically Useful Theory of Goal Setting and Task Motivation: A 35-Year Odyssey». American Psychologist, 2002. https://doi.org/10.1037/0003-066X.57.9.705
- Locke E. A. «Toward a Theory of Task Motivation and Incentives». Organizational Behavior and Human Performance, 1968.
- Doran G. T. «There’s a S.M.A.R.T. Way to Write Management’s Goals and Objectives». Management Review, 70(11), 1981.
- Seijts G., Latham G. «Learning versus performance goals: When should each be used?». Academy of Management Executive, 2005. https://doi.org/10.5465/ame.2005.15841964
- Winters D., Latham G. «The effect of learning versus outcome goals on a simple versus a complex task». Group & Organization Management, 1996.
- Ordóñez L., Schweitzer M., Galinsky A., Bazerman M. «Goals Gone Wild: The Systematic Side Effects of Overprescribing Goal Setting». Academy of Management Perspectives, 2009. https://www.hbs.edu/ris/Publication%20Files/09-083.pdf
- Locke E. A., Latham G. P. «Has Goal Setting Gone Wild, or Have Its Attackers Abandoned Good Scholarship?». Academy of Management Perspectives, 2009.
- Rodgers R., Hunter J. E. «Impact of Management by Objectives on Organizational Productivity». Journal of Applied Psychology, 1991. https://doi.org/10.1037/0021-9010.76.2.322
- Gollwitzer P. M. «Implementation Intentions: Strong Effects of Simple Plans». American Psychologist, 1999. https://doi.org/10.1037/0003-066X.54.7.493
- Gollwitzer P. M., Sheeran P. «Implementation Intentions and Goal Achievement: A Meta-analysis of Effects and Processes». Advances in Experimental Social Psychology, 2006. https://doi.org/10.1016/S0065-2601(06)38002-1
- Oettingen G. WOOP — протокол мысленного контрастирования. https://woopmylife.org/
- Deci E., Koestner R., Ryan R. «A meta-analytic review of experiments examining the effects of extrinsic rewards on intrinsic motivation». Psychological Bulletin, 1999. https://doi.org/10.1037/0033-2909.125.6.627
- Grove A. «High Output Management», 1983 — глава про iMBO.
- Doerr J. «Measure What Matters», 2018. https://www.whatmatters.com/
- Google re:Work. Guide: Set goals with OKRs. https://rework.withgoogle.com/guides/set-goals-with-okrs/
- Forsgren N. et al. «The SPACE of Developer Productivity». ACM Queue, 2021. https://queue.acm.org/detail.cfm?id=3454124
- DORA. Метрики и исследование State of DevOps. https://dora.dev/
- Strathern M. «“Improving ratings”: audit in the British University system». European Review, 1997 — формулировка закона Гудхарта.
- Consumer Financial Protection Bureau. Пресс-релиз о штрафе Wells Fargo, 2016. https://www.consumerfinance.gov/about-us/newsroom/consumer-financial-protection-bureau-fines-wells-fargo-100-million-widespread-illegal-practice-secret-opening-unauthorized-accounts/
- Collins J. «Good to Great», 2001 — идея stop doing list.
- ВОЗ, МКБ-11: выгорание (QD85) как профессиональный феномен. https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281
Что дальше
Мы разобрали, как ставить цели так, чтобы они помогали, и как понять, что конкретная цель уже вредит. Но есть отдельный, крайне неприятный класс ситуаций: цель поставлена правильно, ёмкость посчитана, блок в календаре стоит — и человек всё равно не начинает. Это не лень и не дефект характера, у этого есть вполне изученные механизмы.
Прокрастинация: настоящие причины и что действительно помогает