Современная корпоративная модель управления результатом страдает не от недостатка процессов, процессов как раз слишком много. OKR, KPI, performance review, quarterly planning, комитеты, roadmaps, status reports, health metrics, инициативы, стратегические приоритеты, alignment‑сессии — весь этот зоопарк существует не потому, что компаниям нечем заняться, а потому что они пытаются решить реальную проблему.

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

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

Значит, проблема не только в человеке, проблема в устройстве среды.

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

• плохо сделал — сам страдаешь;

• хорошо сделал — сам выигрываешь;

• потратил лишние деньги — сам без денег остался;

• сэкономил на ерунде — сам потом переделываешь;

• вложился по уму — сам живёшь лучше.

В компании эта связь почти всегда разорвана.

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

После этого удивляться цинизму исполнителей откровенно странно, а чего вы ожидали?

Проблема действующей модели

Обычная корпоративная модель делает вид, что она управляет результатом. На деле она как правило управляет преимущественно отчётностью о результате.

KPI превращаются в приборную панель, к которой зачем‑то привязывают деньги. OKR превращаются в ритуал согласования желаемого будущего. Комитеты превращаются в механизм торможения, где главная задача — не обеспечить результат, а размазать ответственность за принятое решение.

Формально всё выглядит прилично. У компании есть цели. У департаментов есть цели. У команд есть цели. У людей есть цели. Всё каскадировано, синхронизировано, выровнено и красиво разложено по кварталам.

Но в системе нет главного: контракта за результат.

Команде говорят — вы отвечаете за конечный результат.

Но при этом:

• цель сформулирована наверху;

• полномочия остаются наверху;

• зависимости живут где‑то сбоку;

• бюджет контролируется не командой;

• приоритеты могут поменяться без компенсации;

• метрики спорные;

• вознаграждение символическое;

• зато кары вполне реальны;

• оценка результата политизирована.

Это не ответственность, это управленческое шоу.

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

Так и рождается корпоративное болото: сверху спускают спорные цели, посередине их обеззараживают до состояния молочного супчика, внизу их натягивают на глобус, а потом все делают вид, что система работает.

Она не работает. Она просто взрывается не каждый день.

Идея альтернативы

Альтернатива начинается с очень простой мысли:

если бизнес хочет результат, он должен его купить.

Не задачу. Не занятость. Не «инициативу». Не красивую квартальную цель. А именно результат — с ценой, риском, полномочиями, зависимостями и правилами валидации.

Назвать это можно как угодно. OKR 2.0, outcome contract, gainsharing, внутренний рынок, метод волнового горшка, терминология вторична.

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

В контракте должны быть зафиксированы:

• какой бизнес‑результат нужен;

• какая часть результата реально контролируется командой (и только это может быть предметом контракта);

• что считается успехом;

• какие есть guardrails, чтобы не улучшить одно ценой разрушения другого;

• какие зависимости находятся вне зоны контроля команды;

• какие полномочия команда получает;

• при каких условиях контракт пересматривается;

• какое вознаграждение получает команда при достижении результата;

• кто и как разбирает спорные случаи.

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

Команда может сказать:

• это важная цель, но риск очень высок;

• это не в нашей зоне влияния;

• это можно сделать, но нужно право изменить процесс;

• это можно сделать, но премия должна быть выше;

• это можно сделать дешевле, если убрать часть scope;

• это нельзя честно обещать без участия соседней команды.

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

Да, это означает необходимость «продать» проект/задачу команде. Но в этом на самом деле нет ничего нового, «продавать» их приходилось и раньше, просто раньше «продать» идею нужно было руководству/инвесторам, а временами — исполнителю‑субподрядчику. А тут предполагается, что нужно убеждать ещё и команду — вместо того, чтобы просто «отдать распоряжение».

Ужас какой, зачем такие сложности?

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

Затем, что продавить по срокам и рискам команду легко, а объясняться с заказчиком/инвестором по поводу сорванных сроков и необходимости пересмотра уже согласованной функциональности — сложно и финансово больно. У вас есть возможность провести технический аудит своей идеи — зачем от неё отказываться?

Примеры и тонкости

Пример 1. Баланс и скрытые зависимости

Бизнес говорит — мы теряем деньги на неуспешных платежах. Нужно снизить failed payment rate.

Поставлена цель — «снизить failed payment rate с 3.2% до 1.1%». Результат достигнут, но ценой увеличения пропущенного fraud‑а и нагрузки на support. Что делать?

Задействуется внутренний арбитраж, который выносит вердикт:

• проделано много полезной работы;

• failed payment rate был снижен до 2.5%, что подтверждалось тестами;

• уже после этого был принят ряд сомнительных решений;

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

• арбитраж счёл это сознательной попыткой манипулировать метриками для получения премии;

• команда депремируется, технический лид получает выговор;

• компании необходим внутренний тренинг для повышения качества постановки задачи, посредством учёта связанных параметров.

Пример 2. Надёжность это «критически важно», пока бесплатно

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

Команда платформы:

— Отлично. Тогда контракт такой: мы снижаем downtime exposure на X, вводим blocking release criteria, получаем бюджет на observability, право останавливать релизы при нарушении SLO и премию за снижение финансового риска от простоев.

Бизнес:

— Ну, может, надёжность это не настолько важно.

И это прекрасно. Потому что в этот момент выясняется реальная цена фразы «критически важно». Если reliability важна только до тех пор, пока она бесплатна, значит, она не критически важна. Она декоративно важна, просто о ней принято говорить, как о критически важной, это красиво смотрится в составе презентации.

В обычной модели это всплывёт позже: через аварию, потерю клиента, выгорание команды, экстренный проект на полгода и героическое латание дыр. В контрактной модели счёт выставляется заранее.

• хотите надёжность — заплатите за неё;

• хотите скорость — принимайте риск;

• хотите и то и другое — платите больше и режьте scope где‑то ещё.

Это не цинизм, это честность.

Пример 3. Соседние команды и зависимости

Команда берёт контракт, но результат зависит от соседней платформенной команды.

В обычной модели это превращается в бесконечный статусный ад с перепихиванием ответственности:

• мы ждём их;

• они не успели;

• приоритеты поменялись;

• dependency не закрыта;

• цель частично выполнена.

В контрактной модели зависимость должна быть куплена или вынесена за пределы ответственности.

Варианты:

1. соседняя команда входит в общий контракт;

2. бизнес отдельно покупает у неё нужный результат;

3. зависимость признаётся внешним фактором;

4. цель пересматривается;

5. команда получает полномочия обойти зависимость.

Это неприятно, зато честно. Плохая декомпозиция цели становится проблемой сразу — а не потом.

Пример 4. А если пореалистичнее? Как в жизни.

Ну, давайте как в жизни. Подробно, по шагам.

Product owner приходит к команде с презентацией (да‑да), описывающей, что именно планируется делать в продукте в следующем квартале.

Шаг 1 — Презентация

Презентация начинается с краткого повторения планов компании на этот квартал (увеличение выручки на 30% за счёт привлечения новых клиентов). Конкретно этот проект должен привлечь 10k новых клиентов — это его вклад в цели компании. Привлекать новых пользователей предлагается за счёт реализации прорывной функции — добавления на каждую страницу приложения анимированного розового жирафа в шляпе.

Обоснование того, почему среднеожидаемое количество пользователей, привлечённых жирафом, составляет именно 10k, находится в приложении MИ2, а подтверждение реалистичности этого обоснования со стороны продуктового коммитета можно найти в приложении ПК4.

Средний доход от одного пользователя приложения составляет 15 мумриков в год (открытая информация, вот ссылка), соответственно, ожидаемый рост доходности составляет 150k мумриков в год, риски реализации укладываются в стандартные (ссылка) 30%, политика компании (ссылка) по поводу премирования — выделять команде 20% от ожидаемой прибыли за первый год в качестве вознаграждения.

Финальный слайд, где все очень‑очень счастливы, с котиком.

Шаг 2 — Review презентации

Через 3–4 дня команда отправляет product owner‑у документ с отзывом на его предложение.

В документе сказано, что в презентации и приложенном к нему PRD не учтены следующие дополнительные риски:...

Также в PRD не учтены объёмы работ, которые понадобятся для того, чтобы:...

Резюме — с учётом вышесказанного, риски явно превышают 50%, а согласно политике компании (ссылка) повышающий коэффициент вознаграждения в таких случаях составляет x1,31.

Также предлагается:

• сменить анимированного жирафа на котика;

• заменить шляпу сапогами;

• переформулировать пункт 3.1 следующим образом:...

В этом случае риски падают до 30% и это становится возможно реализовать по нормальной ставке.

Шаг 3 — Переговоры

Product owner назначает встречу, где объясняет, что он не согласен с возражениями.

• котики всем давно надоели (вот и вот исследования, где это доказывается)

• целевая аудитория хочет именно жирафа (см. приложение МИ1, где это написано прямым текстом и жирным шрифтом, но кто это читает вообще?)

• по поводу пункта 3.1 — согласен, но, кстати, нужно ещё дописать пункты 3.7 и 4.3

• в любом случае, риски, если уж честно, не составляют и 15%, product owner готов поклясться собственной матерью, что его интуиция и опыт говорят именно так

Команда не согласна на предложенные условия и наша дружная компания отправляется на арбитраж.

Шаг 4 — Арбитраж

Внутренний арбитраж это что‑то вроде микса из продуктового и архитектурного комитета. Довольно дорогое удовольствие, кстати. Расходы на него всегда идут за счёт общего бюджета продукта, чтобы был стимул решать вопросы конструктивно и полюбовно.

Арбитраж выслушивает всех (предварительно ознакомившись с документами) и выносит решение. Какое? Да какое угодно, вариантов — море.

Например:

• тут не учтена ещё куча проблем и рисков;

• оценка риска не успеть — больше 70%;

• согласно политике компании (ссылки настолько солидные люди не дают), такие проекты вообще не запускаются;

• от product owner‑а теперь срочно ожидается новое предложение, как именно привлечь новых пользователей;

• с учётом того, что сроки горят, к нему присылается десант (aka enabling team) для проработки новой концепции (угадайте, кто остался без премии?).

Другой например:

• компания давно сотрудничает с подрядчиком «Мамкин Художник Инкорпорейтед», который этого жирафа вам нарисует за неделю, за вполне разумные деньги;

• подрядчику придётся заплатить (за счёт бюджета продукта, разумеется);

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

• к команде на помощь отправляется десант (aka enabling team) для обучения best practices (угадайте — кто останется без премии на этот раз?);

• product owner‑у порекомендовано заменить жирафу шляпу на сапоги, он согласился (тихо пробурчав что‑то неразборчивое);

• product owner‑у порекомендовано придумать ещё какое‑то улучшение для продукта, потому что делать жирафа целый квартал явно не оптимально.

Почему это выгодно собственникам

Потому что собственник всё равно платит за плохие решения. Вопрос только в том, когда.

Сейчас счета приходят поздно:

• продукт проиграл рынок;

• команда выгорела, сильные люди ушли;

• технический долг стал неподъёмным;

• стратегическая инициатива провалилась;

А отчёты всё это время были зелёные.

Контрактная модель выставляет счета раньше:

• эта цель дороже, чем вы думаете;

• этот риск не был предусмотрен;

• эта зависимость неуправляема;

• эта экономия фиктивна;

• этот приоритет не выдерживает рыночной цены.

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

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

Почему это выгодно «хорошим» работникам

Потому что работник получает не мотивационный плакат, а сделку.

Не:

Будь вовлечённым, проявляй ownership, верь в миссию.

А:

• вот результат;

• вот твоя зона влияния;

• вот полномочия;

• вот правила игры;

• вот цена риска;

• вот выигрыш, если получилось;

• вот защита от произвола, если условия изменились.

Это принципиально другой психологический контракт.

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

• за эти деньги — нет;

• без этих полномочий — нет;

• с этой зависимостью — нет;

• под такую оценку результата — нет.

И если компания всё же хочет результат, она должна изменить условия.

Это и есть взрослая ответственность. Не ответственность как «если не вышло, виноваты вы», а ответственность как контракт между дееспособными сторонами.

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

Почему это не мир розовых пони

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

ФОТ в этой схеме совершенно не обязан увеличиться (хотя и может). Он, скорее, перераспределяется — к самым эффективным (в широком смысле) работникам ото всех остальных.

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

Будет множество злоупотреблений — с обеих сторон — особенно поначалу, пока не будет найден новый баланс, как в бизнес‑процессах, так и в защите труда.

Общий уровень стресса, вероятно, только вырастет. Финансовая стабильность пострадает. Это неудивительно, ведь по сути мы таким образом сдвигаем баланс ответственности наёмных работников в сторону бизнесменов/фрилансеров.

Почему это будет невероятно трудно внедрить

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

Обычная компания любит говорить:

• это стратегически важно;

• это нужно сделать;

• денег нет, но вы держитесь;

• давайте найдём способ;

• не надо мыслить силосами.

Контрактная система отвечает:

• сколько вы готовы заплатить?

• какие полномочия даёте?

• кто несёт риск?

• какие guardrails важнее результата?

• кто будет арбитром?

• что будет, если стратегия поменяется?

И корпоративная магия заканчивается.

Внедрить это как HR‑процесс невозможно. HR немедленно превратит это в форму. Менеджмент превратит это в согласование. Legal превратит это в отказ. Комитеты превратят это обратно в «как бы чего не вышло».

Чтобы такая система заработала, её должен защищать уровень, которому действительно интересна экономика: собственник, board, CEO, CFO, сильный COO. И даже тогда получится не везде и не у всех.

Потому что нужны:

• прозрачная экономика;

• качественные данные;

• зрелый арбитраж;

• сильные команды;

• право команд торговаться;

• готовность делиться выигрышем;

• готовность признавать плохие управленческие решения;

• готовность увольнять не только плохих исполнителей, но и плохих организаторов.

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

А потому что это слишком честно. Слишком конкурентно. Слишком небезопасно.

Почему будущее всё равно за этим подходом

Потому что он обещает эффективность. И неизбежно обеспечит эффективность — пусть и не сразу. А эффективность это конкурентоспособность. А неэффективность в условиях конкуренции это необходимость уступить своё место под солнцем более приспособленным.

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

Лучшие сотрудники будут искать именно такие места и все прочие будут терять в эффективности вследствие их ухода. Процесс станет самоподдерживающимся.

Итого

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

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

Всё остальное — суп без мяса. Не потому что мясо забыли положить. Просто мясо не положено.