[Почему CEO не видят, куда уходит R&D-бюджет, и как это исправить]

В тот момент, когда CEO мысленно относит разработку к "центру затрат", наступает особая слепота. Центрами затрат управляют через сдерживание: держать штат на одном уровне, отклонять запросы на бюджет и измерять результат через метрики скорости, которые никто в совете директоров не понимает по-настоящему. Бюджет R&D (исследования и разработки) становится строкой расходов, которую нужно минимизировать, а не портфелем, который нужно оптимизировать.

Проблема в самой модели.

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

Фрейминг "центра затрат" сохраняется не потому что он точен, а потому что альтернатива требует видимости, которой у большинства организаций нет. Когда нельзя сказать CFO, сколько стоит построить конкретную фичу и что она приносит, портфельный фрейминг ощущается как стремление, а не как операционная реальность. Цель этого материала — сделать его операционным. Это наиболее актуально для компаний, где разработка занимает наибольшую долю R&D-расходов — как правило, продуктовых SaaS и программных — но базовый фреймворк применим везде, где затраты на R&D отслеживаются на уровне команд.

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

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

R&D-расходы обычно охватывают разработку, продакт-менеджмент, дизайн и аналитику. Этот фреймворк фокусируется на разработке как на наиболее крупном и наименее прозрачном компоненте затрат, но та же портфельная логика применима ко всем R&D-функциям, когда инфраструктура данных на месте.

На практике видимость портфеля для CEO означает чёткую и актуальную картину по четырем направлениям: стоимость каждой инициативы относительно ее прогресса; проекты, где потребление бюджета опережает результаты поставки; доля емкости, поглощаемой незапланированной работой вместо инвестиций в дорожную карту; и исторические паттерны отдачи по категориям фич, которые должны определять распределение будущего бюджета.

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

Именно в этом разрыве между теоретически известным и реально видимым живет большинство проблем с бюджетированием R&D.

Традиционная R&D-отчётность дает CEO неполную картину, и недостающая часть, как правило, оказывается самой дорогостоящей.

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

Что не попадает в отчётность, хотя должно:

• Налог на обслуживание. В большинстве зрелых кодовых баз значительная доля инженерной емкости уходит на поддержание работоспособности существующих систем: исправление багов, обновление зависимостей, работа с производительностью и реагирование на инциденты. Эта работа реальна, необходима и напрямую конкурирует с разработкой фич за тех же инженеров. Когда она не выделяется отдельно, она невидима в бюджетных разговорах, и обязательства по новым фичам принимаются против емкости, которой фактически нет.
• Технический долг как мультипликатор затрат. Кодовая база с существенным техническим долгом раздувает стоимость каждой последующей фичи. Например, фича, которая должна занять три недели, занимает шесть, потому что базовые модули хрупкие, плохо задокументированные и неустойчивые к изменениям. Этот мультипликатор реален и измерим, но редко фигурирует в каком-либо отчете на уровне совета. Вместо этого он проявляется как "мы отстаём от графика" и "команда перегружена" без финансового фрейминга, который сделал бы первопричину понятной CFO.
• Вариативность эффективности подрядчиков и вендоров. Организации, тратящие на внешнюю инженерную емкость (подрядчиков, офшорные команды, специализированных вендоров) как правило, имеют ограниченную видимость того, насколько эффективны эти расходы. При наличии правильных данных проверка счетов и вариативность затрат по вендорам поддаются отслеживанию. Сравнение продуктивности требует большей осторожности — важно то, соответствует ли результат вендора тому, что он выставляет в счет, измеренный относительно его собственных исторических показателей. Без такого продольного взгляда внешние R&D-расходы в значительной мере вопрос доверия.
• Реальная стоимость незапланированной работы. Производственные инциденты, экстренные фиксы и незапланированные изменения скоупа отвлекают инженеров от запланированной работы, не появляясь нигде в исходном бюджете. Совокупная стоимость этого "налога на прерывания" редко поддается количественной оценке, но в организациях, ведущих несколько параллельных проектов, она регулярно оказывается существенной.
• Накладные расходы продукта и дизайна на отмененную или невостребованную работу. Емкость продукта и дизайна, поглощенная фичами, которые не выходят или срезаются после запуска, — еще одна стоимость, редко всплывающая в R&D-отчетности. Исследовательская работа, итерации дизайна и время PM, потраченное на депriоритизированные пункты дорожной карты, представляют реальный бюджет, потраченный без какой-либо отдачи, но они редко отслеживаются в составе совокупной стоимости фичи.

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

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

1. Уровень первый: фактическая стоимость каждой фичи. Это фундамент. Для каждой фичи: каков был плановый объем инженерных инвестиций и какова фактическая стоимость? Входные данные — ворклоги, привязанные к фичам и переведенные в приблизительную стоимость с использованием полных ставок по ролям — тот вид представления, который призваны создавать такие инструменты, как маржинальность проектов в Enji. Результат — цифра, которую можно сопоставить с исходной оценкой и отслеживать в динамике. Этот уровень отвечает на вопрос: "Строим ли мы то, что сказали, по той стоимости, которую называли?"
2. Уровень второй: состояние поставки по направлениям. В рамках портфеля какие проекты идут хорошо, а какие демонстрируют ранние предупредительные сигналы? Индикаторы здесь — это точность оценок, вариативность времени выполнения, соотношение багов к фичам и частота переработок: метрики, указывающие на то, здорово ли направление или накапливает структурные проблемы. Этот уровень отвечает на вопрос: где мы рискуем выйти за рамки бюджета и что это вызывает?
3. Уровень третий: атрибуция отдачи. Это самый сложный уровень, и именно в его систематическом решении большинство организаций отстают больше всего. Что принесли уже запущенные функции? Данные об использовании, определение доли выручки и сокращение объема обращений в службу поддержки — все это важные показатели, но они, как правило, хранятся в разных системах и требуют целенаправленной настройки инструментария, чтобы соотнести их с первоначальными затратами на разработку. Даже приблизительные ответы на эти вопросы — такие как показатели внедрения функций по сравнению с затратами на разработку и объем обращений в службу поддержки по функциональным областям — гораздо полезнее, чем полное отсутствие ответов.

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

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

Цель — последовательная модель, обновляемая достаточно часто, чтобы быть актуальной, достаточно детальная, чтобы быть действенной, и достаточно понятная, чтобы CFO мог работать с ней напрямую.

Наиболее значимое изменение — качество разговора о распределении ресурсов. Без данных о поставке обсуждения бюджета R&D в основном позиционные: руководство разработки отстаивает ёмкость, финансы давит на стоимость, а результат определяется интуицией, а не доказательствами. С данными о поставке разговор переходит к существу: какие направления генерируют отдачу, где портфель сконцентрирован и какое перераспределение улучшит общую эффективность.

Несколько конкретных изменений:

• Решения "разработать или купить" улучшаются. Когда вы знаете, во сколько реально обходится внутренняя разработка на уровне фичи, сравнение со сторонним решением становится выполнимым. Таким образом, дилемма "разработать или купить" перестает быть оценочным суждением и становится расчетом.
• Расходы на подрядчиков либо оправдывают себя, либо нет. Видимость портфеля делает внешние расходы на разработку видимыми на уровне результата, а не только счета. Когда стоимость единицы результата вендора измерима и сопоставима с внутренними показателями, разговор о том, стоит ли расширять, сохранять или пересматривать это сотрудничество, имеет фактическую основу.
• Инвестиции в технический долг получают надлежащий приоритет. Один из наиболее распространенных сбоев в R&D-бюджетировании — невозможность обеспечить инвестиции в снижение долга из-за невидимости его стоимости. Когда коэффициент затрат выражается в цифрах и руководство видит, что 60 % перерасхода средств приходится на три модуля, обоснование необходимости инвестиций в исправление ситуации становится очевидным.
• Прогнозирование улучшается. Исторические данные о стоимости по типам фич дают более точные форвардные оценки. Организации, знающие, какие категории фич стабильно выходят за рамки и насколько, могут закладывать это в плановые допущения; те, кто этого не знает, продолжают брать на себя обязательства по срокам, которые не могут выдержать.

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

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

Что мы потратили на R&D в прошлом квартале и что это произвело?
Не в совокупных терминах штата и общего бюджета, а на уровне направлений: какие фичи вышли, по какой стоимости, относительно какой оценки и каков их ранний профиль отдачи? Если ответ "Мы выпустили X фич и потратили Y рублей" без связи между конкретными инвестициями и конкретными результатами — портфель лишь фигурирует в отчетности, а не управляется.

Куда идет емкость R&D за пределами дорожной карты?
Незапланированная работа — инциденты, устранение технического долга, срочные фиксы — конкурирует с инвестициями в дорожную карту за тех же инженеров. В большинстве организаций эта конкуренция невидима на уровне руководства: дорожная карта показывает, что запланировано, но не то, что это вытесняет. CEO, не способный ответить на этот вопрос, не может принимать обоснованные решения о емкости.

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

Если CEO может ответить на все три с актуальными данными — R&D управляется как портфель. Если нет — инфраструктуры видимости пока нет, но ее можно выстроить.

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

Практический план действий состоит из четырех этапов:

1. Установить таксономию фич. Общий список тегов фич, последовательно используемых в Jira и записях ворклогов — это фундамент. Без него часы нельзя надежно атрибутировать к фичам, а стоимость фич нельзя рассчитать. Это разовый разговор о согласовании между продуктом и разработкой, а не постоянное изменение процесса.
2. Добавлять контекст к ворклогам, а не только время. Разница между ворклогом "4 часа" и между ворклогом "4 часа реализации" или "4 часа переработки после неудачного ревью" существенна для аналитики. Дополнительные затраты времени минимальны, а аналитическая ценность — значительна. Лучше всего это работает, если рассматривать это не как контроль за временем инженеров, а как его экономию: данные позволяют выявить расширение объема работ и незапланированные задачи, что способствует разработке реалистичного плана.
3. Связать время со стоимостью с помощью ставок по ролям. Не индивидуальные оклады, а именно ставки, рассчитанные с учетом должности и согласованные с финансовым отделом. Это преобразование делает данные ворклогов понятными на исполнительном уровне. Час инженерного времени становится денежной суммой, фичи становятся инвестициями, а перерасходы — бюджетными разговорами, а не обсуждениями скорости. То же преобразование на основе ставок применимо к продакт-менеджерам, дизайнерам и аналитикам, вносящим вклад в фичу — методология не меняется, только категории ролей.
4. Используйте инструменты аналитики процессов разработки для выявления закономерностей. Уровень агрегации, объединяющий данные из Jira, GitHub и журналов рабочего времени в единую картину затрат на разработку функций и состояния процессов, — это именно та область, где специализированные инструменты приносят наибольшую пользу. Сделать это с помощью таблиц возможно, но такой подход не масштабируется. Платформы, предназначенные для аналитики процессов разработки, такие как Enji, берут на себя агрегацию данных, проактивно выявляют аномалии и предоставляют данные в формате, удобном как для технических руководителей, так и для руководства высшего звена.

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

"Черный ящик" R&D по сути является проблемой инфраструктуры данных, и ее становится все более реально решить.