TL;DR

• Проблема: культ «продуктивности разработчиков» (velocity, строки кода, story points) слабо связан с деньгами и ведет к spray-and-pray, раздуванию фич и росту KTLO.

• Идея: сместить фокус с output на outcome/impact через Impact Intelligence и impact-сети: явные связи proximate-метрик (рядом с фичей) с downstream-метриками бизнеса.

• Два рычага:

  1. Robust Demand Management (RDM) — жёсткий отбор инициатив вопросами: проблема, доказательства, ожидаемые proximate/downstream-эффекты, горизонт, уверенность, допущения, как меряем, риски, альтернативы.

  2. Impact Validation — системная проверка «прогноз vs факт» по proximate и последующая атрибуция вклада в downstream через contribution analysis.

• Инфраструктура измерений: погасить measurement debt — инструментировать продукт бизнес-событиями, собрать дашборды, сделать наблюдаемым именно влияние, а не только поставку.

• Метрика для инвестрешений: вместо формального ROI — ROP (Return on Projection): доля реализованных обещанных выгод на портфельном уровне.

• Практика CTO: отделить приоритизацию от планирования, пускать в план только «проверяемые идеи», запускать impact-ретро по расписанию, публиковать отчёты «прогноз vs факт».

• Развенчание возражений: это не «тормоз» и не против Agile; инновации допустимо фиксировать как гипотезы с последующей валидацией; PMO/VMO редко делают пост-фактум проверку.

• Итог: разговор с COO/CFO уходит от «ускорьте девов» к подтвержденному вкладу в выручку, маржу, NPS, CAC/LTV, Time-to-Decision и долю Run/Change; бюджет идет туда, где влияние доказано.

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

Impact Intelligence — так называется моя новая книга. Она про то, как вернуть видимость бизнес-влияния новых инициатив. В условной «классической корпорации» такие траты считаются дискреционными; в продуктовых компаниях их часто относят к НИОКР (R&D). Книга написана в логике инвестиционного управления и адресована тем, кто утверждает бюджет: у них есть полномочия менять правила и самый сильный мотив — ответственность перед инвесторами. Но интерес здесь не только у них: технологические CXO тоже выигрывают, когда продвигают Impact Intelligence.

Представьте: вы — CTO или другой техрук уровня CIO/CDO. Команды берут в работу то, что им ставит продукт или BRM — менеджер по взаимодействию с бизнесом (Business Relationship Manager). И всё чаще к вам приходят с просьбой «покажите рост продуктивности». Иногда это часть бюджетного раунда: COO или CFO спрашивают, правда ли, что без допбюджета никак, и что вы делаете, чтобы ускорить разработчиков. В последнее время сюда же притягивают ИИ: «А используем ли мы его, чтобы поднять продуктивность?» или даже «Как с помощью ИИ снизить стоимость одного story point?» Это порочная юнит-экономика: оптимизация метрики, которая слабо связана с бизнес-влиянием. Предсказуемый результат — проблемы.

Следить, чтобы каждый не филонил, — нормально. Но культ «продуктивности разработчиков» перегрет и бьёт мимо цели. Это давно обсуждалось, и вы, вероятно, согласны: продуктивность — про output. Важнее outcome и impact. Если ИИ ускорил кодинг, но бизнес-результаты не сдвинулись, толку ноль. Там, где связь между output и outcome слабая, риск особенно высок.

Задача, соответственно, в другом: как переориентировать COO/CFO с фетиша продуктивности на общий бизнес-эффект.

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

Влияние важнее продуктивности

В производстве считают штуки в час, в стройке — рубли за квадрат. Там результат осязаем, повторяем и легко сравним. В интеллектуальном труде иначе: неоднозначность, креатив, нерутинные задачи. Продуктивность здесь измерять сложнее, и она часто слабо связана с прямыми бизнес-результатами. Больше часов и больший output (строки кода, темп в спринте, документы, встречи) не гарантируют большую ценность. Исключение — сервисные компании с почасовым биллингом. Как техлидер, это важно проговаривать, иначе легко попасть в вредный цикл.

Вы выпускаете новые цифровые продукты и возможности, но их коммерческое влияние неочевидно: нет петель обратной связи по эффекту. В ответ запускают ещё больше идей «чтобы сдвинуть стрелку». Spray and pray. Появляется фича-фабрика, ИТ-ландшафт раздувается.

Все это новое хозяйство нужно поддерживать в работе. Растут расходы на поддержку (Run, KTLO). Это урезает долю бюджета, доступную для нового развития (Change, R&D, Innovation). Когда вы просите у COO или CFO увеличить бюджет, вам отвечают просьбой улучшить продуктивность разработчиков. Или требуют обосновать запрос через бизнес-влияние. Вам сложно дать такое обоснование из-за общего дефицита impact intelligence в организации.

Если хотите, чтобы вас перестали донимать «продуктивностью разработчиков», нужно перевести разговор в более конструктивное русло. Переориентируйтесь. Уделяйте больше внимания бизнес-влиянию усилий ваших команд. Помогайте наращивать Impact Intelligence. Ниже — вводная.

Impact Intelligence

Impact Intelligence — это постоянное понимание того, как инициативы (технологические, R&D, трансформационные, бизнесовые) бьют по ключевым метрикам. Смотрим не на ближайшие, «низкоуровневые» показатели вокруг фичи, а на вклад в настоящие бизнес-метрики. На рисунке 2 это показано схемой, которую я называю impact-сетью (impact network).

Такая сеть показывает, как факторы напрямую и опосредованно влияют на результат. Похоже на KPI-дерево, но чаще это именно сеть, а не строгая иерархия. Для практики вводим условные обозначения: зелёные/красные/синие/чёрные стрелки — желательные эффекты, нежелательные эффекты, агрегирующие связи (rollup) и ожидаемое влияние функциональности. Сплошные и пунктирные линии обозначают прямые и обратные зависимости. Кроме rollup-связей, отношения не детерминистичны — impact-сеть работает скорее как вероятностная причинно-следственная модель. Остальные соглашения разобраны в книге.

Нижняя полоса с фичами и инициативами — временный слой поверх impact-сети. Сама сеть по сути — KPI-дерево, где каждый узел это метрика или другая измеримая величина. Я говорю «временный», потому что портфель работ (book of work) постоянно меняется, а «дерево» метрик остаётся относительно стабильным.

Обычно новые фичи и возможности напрямую сдвигают продуктовые метрики. До метрик верхнего уровня влияние доезжает опосредованно и не всегда предсказуемо. Непосредственный эффект (proximate) проще заметить и присвоить себе, а последующий (downstream) проявляется позже и зависит от множества факторов. Ниже это разбирается на примерах.

Дальше в статье — компактные, контекстные срезы общей impact-сети для конкретного бизнеса.

Пример №1: чат-бот службы поддержки

Какой вклад ИИ-чат-бота в снижение нагрузки на контакт-центр при сохранении удовлетворённости клиентов?

Сегодня уже недостаточно считать успехом сам факт поставки решения. Даже метрика «virtual assistant capture» (число удачных сессий с ботом) — это лишь непосредственный эффект. На него обычно нацелена мантра Lean Startup «build-measure-learn». Но в этом кейсе важнее последующий эффект — фактическое уменьшение телефонных обращений. В целом proximate-метрики не всегда надёжно предсказывают downstream-результат.

Чат-бот — небольшая инициатива, но на таких как раз удобно «прокачивать» Impact Intelligence.

Пример №2: ИИ-ассистент по регуляторному комплаенсу

Типовой процесс такой: аналитику прилетает кейс, он изучает материалы, релевантные нормы и свежие изменения, применяет экспертизу и формирует рекомендацию. Далее — цепочка ревью и согласований, масштаб которой зависит от важности кейса. Время до решения (Time to Decision) — от часов до недель, и затяжка напрямую бьёт по бизнесу. Если узкое место — именно работа аналитиков, есть смысл сделать ИИ-ассистента («Regu Nerd»), который помогает интерпретировать и применять постоянно меняющиеся требования. Impact-сеть для этой инициативы показана ниже.

Ближний эффект можно мерить по использованию ассистента, например по числу запросов на одного аналитика в неделю. Но куда важнее смотреть на экономию времени при обработке кейса. Реальное бизнес-влияние проявится в улучшении Time to Decision — это уже последующий эффект. Он появится только если ассистент действительно помогает и если «время до первичной рекомендации» (Time to initial recommendation) и было тем самым узким местом.

Пример №3: SaaS для email-маркетинга

Возьмём SaaS, который продаёт решение для email-маркетинга. Выручка держится на новых подписках и продлениях. Последние зависят от реальной пользы для клиентов и адекватной цены. На рисунке 5 показан соответствующий фрагмент impact-сети.

Самый явный маркер успеха клиента — сколько дополнительной выручки он получает из лидов, сгенерированных через платформу. Поэтому продуктовая команда добавляет функциональность, которая должна повышать вовлечённость. Например, персонализирует время отправки под поведение конкретного получателя: по логам открытий и кликов вычисляются «окна» максимального внимания, и эти данные подаются в планировщик кампаний. Как измерять успех такой фичи? Если смотреть только на открываемость (Open Rate, OR) и кликабельность (Click-Through Rate, CTR), это легко проверяется A/B-тестом. Но это всего лишь ближний эффект.

Научиться мастерски управлять техническим подразделением можно на курсе «CTO / Технический директор»

Рычаги влияния

Impact-сеть — удобная отправная точка. Это общий визуальный язык, как «единый язык» в DDD: все смотрят на одно и то же полотно причинно-следственных связей. Чтобы прокачать Impact Intelligence, нужно починить узкие места в контуре «idea → impact» (см. рис. 6). На схеме он выглядит линейным, но по факту это итеративный цикл.

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

В системном мышлении «точки приложения усилий» — это места, где небольшой сдвиг даёт непропорционально большой эффект для всей системы. В контексте Impact Intelligence их две: отбор идей и измерение эффекта. Формально за них отвечают бизнес-лидеры, BRM и CPO, а давление за «продуктивность» прилетает вам, тех-CXO, из-за слабого бизнес-влияния. Как добавить здесь нужной строгости?

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

Такое обычно случается там, где продукт и разработка выросли как параллельные функции со своими CXO/вице-президентами. Молодые и небольшие компании ещё могут не дорасти до этой дисфункции. Но если ваш поезд оргдизайна уже ушёл, придётся действовать из того, что есть.

Действия по улучшению Impact Intelligence

Следующий ход — прийти к COO, CFO или CEO (ядро C-Suite) с этими рекомендациями. Можно подарить книгу или оформить короткую выжимку для выездной сессии. Именно это ядро утверждает инвестиции, у них и полномочия, и мотивация навести порядок с Impact Intelligence. Они лучше всех позиционированы, чтобы усилить инвестиционное управление. Такой путь подробно разбирается в книге. Но что если сейчас это нереалистично и у них другие приоритеты?

Тогда хотя бы заручитесь их «добром» на локальные реформы. Это окупится: за текущий статус-кво расплачиваетесь в итоге вы. Итак, как действовать CTO-реформатору (читай: «активисту»).

Действие №1: внедрите опросник строгого отбора инициатив (Robust Demand Management, RDM)

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

Опросник для RDM

Идея считается достаточно документированной, если на следующие вопросы даны недвусмысленные ответы.

1. Какую проблему решает эта идея? Или какую возможность она стремится использовать?

2. Какие есть доказательства того, что проблема/возможность действительно существует?

3. Какое решение/подход предлагается? Кто является инициатором/владельцем?
   — Какие альтернативные решения рассматривались и были отклонены? Почему?
   — Какие метрики это решение, вероятно, улучшит (ближние — proximate — и дальнейшие — downstream)?
   - На сколько и в каком временном горизонте?
   - Насколько вы уверены в этих ожиданиях? На каком основании?
   - При каких допущениях и зависимостях они справедливы?
   - Как будет верифицироваться эффект? Есть ли у нас соответствующие возможности измерения?
   — Каковы риски, если этого не делать? Какова вероятность наступления этого риска?

Общепринятая impact-сеть действительно помогает ответить на часть вопросов. Но для Robust Demand Management важнее не сама схема, а наличие ответов. Они превращают идеи в SMART. Без этого идеи оказываются VAPID. Проверить бизнес-влияние VAPID-идей после поставки невозможно — привет негативным эффектам с рисунка 1.

Чтобы не попадать в эту ловушку, важно отстоять право распределять ёмкость команд — дорогой ресурс — только на достаточно задокументированные инициативы. Речь про существенные усилия, не про каждую user story или баг. Задайте порог сами, например две человеко-недели.

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

Если ответы уже даны на этапе триажа, у разработки к ним должен быть прямой доступ. RDM означает, что инженеры берут в работу только те задачи, которые оформлены по этой схеме, плюс к вашим обычным требованиям к документации (например, PRD). Это про то, чтобы «что, как и зачем» в контексте Impact Intelligence понимали не только вы, но и команды. Подробности дальше.

Важно: «достаточно документировано» ≠ «качественно обосновано». RDM не про вердикт разработки «делать/не делать». Смысл в другом: ожидаемые выгоды и сроки должны быть зафиксированы так, чтобы их можно было потом проверить. Право продакта расставлять приоритеты сохраняется. Чтобы задача попала в план, на часть вопросов можно честно ответить «не знаем». По крайней мере будет видно, какая доля ёмкости инженерных команд уходит на хорошо информированную приоритизацию, а какая — на слабо информированную.

У подхода будут противники, особенно у тех, кого эта дисциплина касается напрямую. Это легко окрестят «гейткипингом». Придётся взять на себя роль главного объясняющего, зачем это нужно. В одной из следующих частей — рекомендации, как именно это делать. Ниже — типичные возражения.

1. Это нас замедлит. Мы не можем себе это позволить.

2. Самоцензура: «сначала наведем порядок у себя».

3. Это не по-agile — слишком много анализа заранее.

4. Инновации непредсказуемы.

5. У нас есть PMO/VMO, они уже этим занимаются.

6. Это не про сотрудничество.

7. У нас нет данных.

Последнее — больше, чем просто возражение, если это правда. Это может полностью заблокировать развитие Impact Intelligence и требует немедленного внимания.

У нас нет данных

Данные нужны, чтобы отвечать на вопросы из опросника RDM. Инициаторы спроса могут возразить: «у нас нет нужных данных для ответа на часть вопросов». Что делать CTO? Для начала — зафиксировать статус-кво. В одном проекте мы ввели шкалу качества ответов: заявки, прошедшие первичный отбор, оценивались от «недостаточно» до «отлично» по полноте ответов на вопросы RDM. Дальше — ежемесячные отчёты о «степени информированности» входящих запросов. Такие отчёты наглядно показывают COO и CFO, какая доля ёмкости инженерных команд уходит на работу «по чуйке». Создать видимость через отчёты — первый шаг.

Как только пробелы становятся видны, всплывает главный вопрос: почему у нас нет данных? Частая причина — дырявая измерительная инфраструктура. Оформите это как долг по измерениям (measurement debt), чтобы он получал не меньше внимания и финансирования, чем техдолг.

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

Действие №2: погасите долг по измерениям

Лучше всего закрывать этот долг через программу улучшения измерений: выделенная команда устраняет «слепые зоны» в метриках и интеграциях. Потребуется отдельное финансирование, значит тех-CXO, скорее всего, придётся убеждать COO/CFO. Если это сейчас нереалистично — стартуйте своими силами.

Возглавьте сокращение долга. Попросите команды инструментировать приложение так, чтобы в ключевых точках оно публиковало структурированные события про бизнес-влияние. Эти данные сохраняем и используем для аналитических дашбордов, которые подтверждают proximate- и downstream-эффекты. Дашборды должны появляться вместе с новой функциональностью. Закрывайте именно пробелы в измерениях и интеграциях, не дублируйте то, что уже умеют сторонние инструменты, которыми пользуется продукт. Если в компании есть Product Operations, подключайте их — вместе с разработчиками они быстрее найдут и устранят дыры.

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

Подробнее о долге по измерениям — здесь.

Действие №3: внедрите валидацию влияния (Impact Validation)

Когда измерение влияния становится нормальной практикой, можно вести отчёт вроде таблицы ниже: он сводит «прогноз vs факт» по обсуждаемым инициативам. Обычно этим занимается продакт, и в таком случае разработке стоит подключиться. Если продакт этого не делает, берите флаг в руки и запускайте процесс сами — иначе снова скатитесь в spray and pray и у вас не будет альтернативной повестки на разговоры про «продуктивность разработчиков».

Дальше появляется простор для impact-ретро. Ответ на вопрос «на сколько и в каком горизонте» из опросника RDM позволяет заранее назначить дату сессии по ближнему эффекту (proximate impact). На встрече разбираем расхождение между прогнозом и фактом. Если есть недобор, цель одна — научиться, а не искать виноватых. Итоги корректируют будущие прогнозы и замыкают цикл обратно в RDM.

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

С измерением последующего (downstream) влияния всё сложнее: меряем так же, а вот валидация другая. В отличие от ближнего (proximate) эффекта, downstream формируется множеством факторов. Поэтому любое улучшение по downstream-метрике нельзя автоматически записывать на счёт одной инициативы. Пример: звонков стало больше всего на 2,4% за квартал при росте клиентской базы на 4%. Значит, нагрузка растёт медленнее базы — но целиком ли за это отвечает чат-бот поддержки? Нужна дополнительная атрибуция и разбор.

Ретроспективы по последующему (downstream) эффекту нужны, чтобы атрибутировать наблюдаемые улучшения конкретным инициативам и прочим факторам. Это и есть анализ вклада (contribution analysis). Руководить таким процессом со стороны инженерии сложнее: в нём должны участвовать все инициативы, влияющие на метрику, в том числе вне разработки. Оптимальный ритм — раз в месяц или квартал, созывает сессию бизнес-руководитель, заинтересованный в метрике. Для реформаторского CTO это может быть слишком тяжёлой ношей, но вы можете заранее обеспечить нужные измерения, чтобы ретро состоялось по инициативе бизнеса.

Для полноты: на рисунке 7 показан возможный результат такой ретроспективы на примере чат-бота поддержки.

Там видно, что объём звонков вырос всего на 2,4% квартал к кварталу при росте клиентской базы на 4%. Базовая модель предполагает: при прочих равных динамика звонков должна совпадать с динамикой базы. Разница — 1,6 п.п., то есть 160 б.п. Как это объяснить? Аналитики данных могут снять 60 б.п. на сезонность. Оставшиеся 100 б.п. — на счёт каналов самообслуживания; дальше просим владельцев инициатив предъявить свой вклад. После раунда contribution analysis получаем итоговые цифры (см. нижнюю часть схемы). Дойти до них можно эвристиками и простой обработкой данных. Этот подход я называю «простой атрибуцией влияния» — в отличие от более строгих методов вроде контролируемых экспериментов, которые понравятся дата-сайентистам, но доступны не всегда.

Действие №4: предложите CFO/COO альтернативу ROI

Честно: ROI по инициативам часто не знает никто. Прогнозы делают ради одобрения и нередко вообще не в терминах ROI: «после запуска метрика X вырастет на 5%». По такой заявке ROI не посчитаешь. Зато при наличии валидации влияния можно считать следующую полезную метрику — Return on Projection (ROP). Если метрика выросла на 4% при обещанных 5%, ROP, он же коэффициент реализации выгод (benefits realization ratio), составит 80%. Это лучше, чем ничего, и точно лучше, чем вера в то, что «инициатива сработала, раз мы её выкатывали в прод».

ROP измеряет соотношение «прогноз vs факт». Тех-CXO может предложить CFO/COO опираться на ROP при следующих инвестиционных решениях. Запрашивать обоснования до выделения денег правильно, но это всегда допущение. Когда решения принимают только по прогнозам, участников стимулируют завышать ожидания: «перебить ставку», чтобы получить бюджет или командную ёмкость. Потом это редко проверяется — если только у вас нет рамки Impact Intelligence.

В книге разбирается, как агрегировать и использовать ROP на уровне портфеля. Важно: цель не «идеальные прогнозы». Мы понимаем, что продуктовая разработка недетерминирована. Цель — лучше управлять входящим спросом, отсекая нереалистичные или сырые ожидания. Меньше spray and pray.

Действие №5: обеспечьте команды всем необходимым

Бывает, что вы — единственный топ-менеджер, кто тянет тему Impact Intelligence, и это выматывает. Но это не обязано быть «одиночным забегом». Подтяните delivery-команды: покажите им общую картину и зачем она бизнесу. Важно проговорить простую вещь: сам факт поставки софта ещё не равен бизнес-влиянию. Даже принятие фич пользователями — тоже не гарантия.

Начните с того, чтобы зафиксировать, что именно считать «бизнес-влиянием» в разных контекстах. Удобно объяснять это через иерархию результатов (см. рис. 8): верхние уровни ближе к бизнес-итогу, нижние — поддерживают и обеспечивают их, но принимать связь «на веру» нельзя. Собственно, Impact Intelligence и про то, чтобы отслеживать, работает ли эта связка так, как задумано.

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

Возражения

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

Возражение №1: «Мы не можем замедляться»

Классика жанра: «Нет времени отвечать на вопросы, давайте уже выкатывать». Это обмен точности на скорость. Под «точностью» здесь — нормальная подготовка, чтобы получить нужный эффект. Игнорировать её ради темпа — и есть та самая spray and pray с рис. 1: стрельба по площадям, надежда на удачу вместо навыка и стратегии. Любую сложную деятельность сначала осваивают ради точности, а уже потом ради скорости. Если точности не хватает, небольшое замедление на старте работает на бизнес-влияние. Думайте об этом как о шахматной партии.

Важно: ни одно из предложенных действий не требует сворачивать текущие инициативы по повышению продуктивности или улучшению потока. Реформистский CTO не забивает на эффективность. Он балансирует эффективность и результативность. Перекос классических компаний в том, что, зациклившись на «гибкости поставки софта» (процесс и output), они забывают про «гибкость бизнеса» (влияние).

Возражение №2: «Сначала наведём порядок у себя»

Чрезмерно щепетильный CTO может колебаться с внедрением robust demand management, пока, скажем, все метрики DORA не выйдут на элитный уровень. Кажется, что так «сначала навести порядок у себя». Это ошибочная искренность. Какой смысл в множественных деплоях в день, если нет Impact Intelligence? Это всего лишь очередная вариация подмены точности скоростью.

Такой подход часто признак «силосной» организации. Негласно считается, что разработка должна думать только о скорости и качестве поставки (build it right, build it fast), а продукт (или BRM позаботится о точности выбора (build the right thing для достижения бизнес-эффекта). Но без Impact Intelligence «точность» неизвестна. Это вопрос веры. Веры в процесс триажа идей или в то, что «у других сработало, значит и нам надо». Если вы видите, что это состояние породило «фича-фабрику» в стиле spray-and-pray (что весьма вероятно), вам же лучше не зацикливаться на «сначала у себя порядок».

Возражение №3: «Это не по-Agile»

Иногда продакты или BRM, глядя на вопросы из опросника RDM, говорят: «Слишком много подготовки. Это не agile». Но мы не копаем решение, мы аккуратно фиксируем гипотезу. Agile — это не «прыгнуть из самолёта, а уж в воздухе решить, где приземляться». Нормально сначала спланировать, а потом итеративно уточнять.

Идей обычно много, а инженерная ёмкость ограничена и дорогая. Размер бэклога — индикатор спроса, значит нужен тщательный шортлист, особенно если первичный отбор (продакт или BRM) был нестрогим.

Инструменты на базе ИИ обещают ослабить дефицит ёмкости. Но если просто штамповать фичи без Impact Intelligence, вы лишь усиливаете порочный круг с рис. 1.

Да, Манифест Agile ставит «работающее ПО» выше «исчерпывающей документации», но речь не о документах ради обоснования, зачем вообще делать это ПО. Рабочий релиз ещё не равен бизнес-эффекту. И принципу «реагирование на изменения важнее следования плану» мы не противоречим: опросник RDM — это не план.

Возражение №4: «Инновации непредсказуемы»

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

Речь не о том, чтобы исключить неудачи. Провалы — часть инноваций. Важно другое: классические компании часто даже не замечают, что инициатива не дала ощутимого бизнес-эффекта. Заметь они это, давно бы вывели такую функциональность из эксплуатации и не раздували ИТ-ландшафт вместе с расходами на поддержку (Run/KTLO).

Возражение №5: «Наши PMO/VMO уже этим занимаются»

Обычно — нет. У них может быть шаблон обоснования, но ни инструментов, ни мандата проверять эффект после релиза. Часто и сам шаблон без острых вопросов, поэтому мирятся с расплывчатыми ответами. Периодически «выгоды» рисуют через объём сделанной работы или потраченные деньги: раз выкатили или освоили бюджет, значит, эффект достигнут. Нет.

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

Возражение №6: «Это не про сотрудничество»

Менять процессы больно. CTO-реформатору легко навесить ярлык «неколлаборативного» или «самозваного гейткипера», особенно тем, чьи хотелки раньше безусловно попадали в приоритет и план. Поэтому прежде чем катить изменения, заручитесь одобрением COO/CFO — это снизит трение.

И ещё нюанс: в разговоре не обязательно называть инициативу как «RDM» («Устойчивое управление спросом»). Мягче и понятнее сработают названия вроде «Проверяемые идеи» (Verifiable Ideas) и «Идеи с полным раскрытием» (Ideas with Full Disclosure). Суть та же, сопротивления меньше.

Действуйте

Если партнёры и руководители вне технологии не тянут тему Impact Intelligence, выгодно взять её на себя. Внедрите RDM. Гасите долг по измерениям. Запускайте валидацию влияния и публикуйте отчёты «прогноз vs факт». Оснастите команды всем, что нужно, чтобы они работали на бизнес-эффект. Так вы не только снимете навязчивую повестку про «продуктивность разработчиков», но и возглавите рост бизнес-отдачи от дискреционных расходов.

Шаги непростые. Иногда кажется легче дальше мериться «продуктивностью», чем становиться реформатором. Но тогда про реальное бизнес-влияние говорить не получится: будете крутиться в порочном круге с рис. 1, а ядро C-Suite по-прежнему увидит в вас прежде всего исполнителя — доставка, инфраструктура, операции. Это вполне ок, если вам этого достаточно. Если нет — вы знаете, что делать.

---

Если тема прозрачности влияния и портфельного управления вам близка, у OTUS есть курс «CTO / Технический директор»: оргдизайн, технологическая стратегия и управление подразделением 100+ человек без лишней теории. Практикующие CTO помогут собрать матрицу компетенций, выстроить контур RDM/метрик и оформить собственный план стратегического развития подразделения. Приглашаем на бесплатные уроки курса:

• 7 октября, 20:00 — CTO и AI-революция: решения, которые надо принимать уже сегодня
  Кейсы, где AI дал эффект; типовые провалы и почему; краткая карта шагов CTO на ближайшее время.

• 15 октября, 20:00 — Как выбрать модель разработки: не методология, а стратегия под бизнес-цели
  Жизненный цикл, критерии выбора, сопоставление моделей под контекст продукта и ограничения бизнеса.

• 20 октября, 20:00 — Всё о курсе «CTO / Технический директор»
  Что внутри программы, какие задачи помогает решать, кому зайдет и как это ложится на вашу роль.