惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

B
Blog RSS Feed
V2EX - 技术
V2EX - 技术
P
Privacy & Cybersecurity Law Blog
T
The Exploit Database - CXSecurity.com
美团技术团队
WordPress大学
WordPress大学
博客园 - 司徒正美
S
Securelist
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
博客园 - Franky
Attack and Defense Labs
Attack and Defense Labs
Security Latest
Security Latest
L
LINUX DO - 最新话题
NISL@THU
NISL@THU
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
cs.AI updates on arXiv.org
cs.AI updates on arXiv.org
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
腾讯CDC
Y
Y Combinator Blog
The Hacker News
The Hacker News
Security Archives - TechRepublic
Security Archives - TechRepublic
IT之家
IT之家
T
Threatpost
Hugging Face - Blog
Hugging Face - Blog
Scott Helme
Scott Helme
S
SegmentFault 最新的问题
Cyberwarzone
Cyberwarzone
C
Cisco Blogs
阮一峰的网络日志
阮一峰的网络日志
U
Unit 42
B
Blog
Microsoft Azure Blog
Microsoft Azure Blog
P
Proofpoint News Feed
小众软件
小众软件
V
Vulnerabilities – Threatpost
J
Java Code Geeks
V
Visual Studio Blog
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
A
Arctic Wolf
博客园 - 【当耐特】
Microsoft Security Blog
Microsoft Security Blog
S
Security @ Cisco Blogs
雷峰网
雷峰网
Help Net Security
Help Net Security
The Last Watchdog
The Last Watchdog
Recent Announcements
Recent Announcements
G
Google Developers Blog
C
CERT Recently Published Vulnerability Notes
T
Troy Hunt's Blog
MyScale Blog
MyScale Blog

Все публикации подряд на Хабре

Ловим музу за клавиатуру: как айтишнику стать автором Что умеет Midjourney в 2026? Мой немного грустный разбор этого шикарного инструмента Никто не любит писать тесты, но ИИ может исправить это IPv8 выглядит как мечта. Поэтому почти наверняка не взлетит Производители вернули в продажу материнки с DDR3. Что происходит? Управление агентом с телефона через Telegram теперь в KodaCode От координации к лидерству: как меняется роль руководителя разработки Я сделала родителям бизнес вместо пенсии: зарабатываем 70 тысяч, мама не даёт продать В три раза быстрее приемка товара и оптимизация трудозатрат на 73%: как «РСТ-Инвент» помог Gulliver Group ИИ-шечный мир победил? О влиянии искусственного интеллекта на игропром Кремль снижает давление на Телеграмм пока Европа строит интернет по паспорту Как CEO, CTO и CIO за 8 часов собрали ИИ-директора, который умеет держать позицию под давлением Как (не) потерять домен за выходные Вместо 8 разных VPS: как я организовал практику студентам на одном сервере Почему твой Open Source проект не замечают? R&D: искусство управления неопределенностью в разработке AI-дефляция: вакансий для разработчиков больше, а рост зарплат — худший за 15 лет Мы отдали управление роботами OpenClaw. Что из этого вышло Галактический ID: система идентификации для всех форм разумной жизни Шесть основ бизнес-анализа: начинаем с вопроса «Кто в игре?» Код-ревью, в котором дело не в коде Данные переехали. Команда — нет Системной подход к сдаче OSWE в 2025 Почему комната управления реактором покрашена в цвет морской пены 4 YAML-файла вместо PySpark: как аналитикам строить пайплайны без разработчиков LLM-агент для поиска свободных доменов: автоматизируем подбор Когда, зачем и как правильно начинать новую сессию в Claude Code? Как я заставил нейросеть писать макросы для FreeCAD Анатомия ИИ‑агента для подбора персонала. От тысячи резюме к топ‑10 за минуты Опыт разработчика как экономика внимания Автономность как точка невозврата: кто будет субъектом в цифровом будущем Обучение ИИ в «диких» условиях: как рутинные действия превращаются в датасеты Как измерить LLM для задач кибербеза: обзор открытых бенчмарков Где хранить код? Сравнение GitHub, GitLab и Bitbucket Математика объясняет, почему нормальное распределение встречается повсюду Почему ваш FinOps не работает: 12 тезисов от практиков Как подписать проектную документацию УКЭП с использованием бесплатных лицензий Pilot Адаптивное администрирование Sigla Vision Я грузил уран в бочки, а потом 20 лет строил ИТ в атомной отрасли Чем позвонить с Эвереста? История и обзор спутниковой связи. Часть 2 Как языковая модель помогает контролировать качество инструктажей по охране труда в металлургии Как не передать на desktop свой IP в РКН Анатомия SAP Privileges: как устроено управление правами в macOS MoneyDev: Сказка про три главных слова Обновлённый токенизатор видео K-VAE 2.0 от Сбера Как сделать диспетчеризацию дома на 1284 квартиры почти бесплатно Как мы разогнали железную дорогу Мы дали агентам рутину. Теперь надо решить — что делать с освободившимся временем Токсичный контент, промпт-хакинг и защита ИИ — всё о Guardrails для LLM Умный город начинается с точного взгляда: как «Фалькон Тех» меняет пространство к лучшему Навайбкодил приложение для анализа графов Почему Дюну так интересно читать? Упрощаем работу с рутиной или как стать Гендальфом Белым Деконструкция Go: CPU, RAM и что там происходит. Go Assembler база. Часть 1.1 Какие профессии исчезнут из-за ИИ, а какие появятся? И что с этим делать Как мы построили IT-отдел, где хочется расти: архитектурные встречи, прозрачные метрики и книжные подарки Rufler: Делаем из Claude Code автономный рой через один YAML-конфиг Sing-box и белый список приложений Как построить надёжный обмен сообщениями в микросервисах: лучшие практики для enterprise OpenAI строит MLM-пирамиду, а McKinsey и Accenture помогают ей в этом Дом, который не построил Фишер (Часть 2) «Сверхзвуковой математик» против «Вдумчивого логиста»: битва алгоритмов 3D-упаковки Мультимодальные модели – грубый и дорогой инструмент Разговоры ничего не стоят. Код тоже Проверки физических лиц: с кого начнет ФНС Топ-10 бесплатных нейросетей для создания видео в 2026 году Первые слои кода: как наши решения сегодня определяют архитектуру ИИ на десятилетия Разработка нового статического анализатора: PVS-Studio JavaScript Поиск уязвимостей ПО: базовый минимум или роскошный максимум Почему оценка персонала не работает как инструмент управления Как мы разработали ИИ-ассистента и сократили рутину продуктовой команды на 50% Как я ушел из найма, нажарил косточек и продал на маркетплейсах на 168 млн в год Когда 1С:ERP уже внедрена, а нормального производственного плана всё ещё нет Как я сделал Claude мультимодальным, подключив к нему Qwen Omni Как приглашение на вакансию мечты превращается в атаку Infrastructure as Code: философия и лучшие практики IaC Тестируем Yandex Code Assistant на задаче, в которой нужно хранить секреты nxs-universal-chart v3.0: новое поколение универсального Helm-чарта Callback Injection: Техника, которая отправила Microsoft Defender в глухой нокаут «Все идеи на стол»: митап как способ вывести проект из тупика Сегодня я узнал нечто новое о GPU благодаря багу в своей игре Как заставить LLM ̶ ̶г̶а̶л̶л̶ю̶ ̶ эволюционировать Карта событий как фундамент аналитики: практический кейс для E-commerce Что выбрать для AI: x86, ARM или RISC-V? Дайджест железа за март Роль соматических мутаций в развитии аутоиммунных заболеваний: путь к избирательной терапии Mythos от Anthropic — тревожный сигнал для всех, а не только для банков Guardrails для LLM на Java: как приручить промпт‑инъекции и токсичные ответы Green-VLA: как мы собрали VLA-модель для реального антропоморфного робота и не потеряли обобщение Финансовая гонка вооружений: почему умные люди добровольно в ней участвуют Эра ИИ-агентов наступила: выбираем лучшего цифрового сотрудника # Практический опыт внедрения WinCC Redundancy на производственном предприятии Сделал MVP за 3 дня, а потом неделю прикручивал оплату. Оно того стоило? Физика против Маска: почему Starship V3 может оказаться ещё одной катастрофой Нефть Венесуэлы: крупнейшие запасы в мире, но не крупнейшая нефтяная держава JPA 4. Переосмысление Hibernate Почему зеркальная фотокамера Nikon D5 десятилетней давности идеально подошла для миссии «Артемида-2» Проект «Уровень-Спутник» или как мы сделали платформу для гидрологов «Замедлиться, чтобы ускориться»: почему ИИ повышает цену ошибок в требованиях и архитектуре Как с нуля поднять трафик IT-компании на 1657% при бюджете 55 тыс. и выжить Pixel-perfect Downsampling — идеальная отрисовка 50 миллионов точек без потерь
Почему в корпоративном супе не положено мясо
mrozov · 2026-05-14 · via Все публикации подряд на Хабре

Почему в корпоративном супе не положено мясо

Уровень сложностиСредний

Время на прочтение12 мин

Охват и читатели1.2K

Аналитика

Современная корпоративная модель управления результатом страдает не от недостатка процессов, процессов как раз слишком много. 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 и арбитражем. Если команда берёт на себя кусок реальности — она должна получить возможность этот кусок менять и получить заметную часть выигрыша, если ставка сработает.

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