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

Большинство основателей могут назвать общий фонд оплаты труда инженеров и сумму в последнем облачном счёте. Гораздо меньше людей могут ответить на более полезный вопрос: какая часть продукта съедает деньги?

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

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

Продуктовой области нужны владелец и границы

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

У полезного модуля есть четыре признака. Клиенты могут понять, какой результат он даёт. Кто-то может принимать по нему компромиссные решения. В большинстве случаев работу можно отнести к этому модулю. Можно перечислить системы и зависимости, которые в него входят.

Для B2B SaaS-продукта карта на старте может выглядеть так:

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

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

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

Опишите границы в коротком реестре. У каждого модуля должны быть ID, название, ответственный владелец, статус жизненного цикла, основной показатель для клиента и список компонентов. Добавьте правило для неоднозначной работы. Например: «Если проблема затрагивает клиентский рабочий процесс и базовую платформу, отнесите исправление к модулю рабочего процесса и зафиксируйте зависимость от платформы». Это не даст расходам платформы исчезнуть и не позволит объявлять каждую сложную проблему «общей».

FinOps Framework говорит о том же языком облачных расходов: для распределения нужны понятные группы, стратегия тегов и иерархии, а также описанный метод работы с общими затратами. Важен не сам тег. Важно заранее договориться, что он означает, до того как придёт счёт.

Сначала распределяйте прямые расходы

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

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

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

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

period           2026-06
source_type      support_ticket
source_id        SUP-1842
module_id        integrations
cost_class        support
amount_usd        96.00
allocation_method direct
allocation_driver null
confidence        high
notes             CSV import fails on duplicate external IDs

Поля дают больше, чем кажется. source_type позволяет проследить итоговую сумму до исходных данных. cost_class отделяет облачные расходы от времени людей. allocation_method показывает читателю, видит ли он факт или правило. confidence помогает команде обозначить неопределённые назначения, а не прятать их внутри аккуратно выглядящего отчёта.

Не используйте «разное» как модуль. Помещайте неопределённые позиции в unassigned с объяснением. Если через два отчётных цикла неназначенные расходы остаются высокими, исправьте данные событий, реестр модулей или и то и другое. Аккуратная корзина «разное» позволяет постоянным потерям закрепиться в компании.

Тикеты поддержки показывают, где продукт создаёт нагрузку для клиентов

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

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

При закрытии тикета фиксируйте как минимум следующие поля:

• Клиентский модуль и любой участвующий модуль.
• Тип запроса: дефект, инструкция, настройка, исправление данных, работа после сбоя или проблема с доступом.
• Минуты, потраченные поддержкой, инженерией и customer success.
• Была ли у проблемы известная первопричина или обходное решение.
• Привёл ли тикет к изменению продукта, документации или автоматизации.

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

Достаточно простой формулы:

support_cost_for_module =
  support_hours × support_rate
  + engineering_hours × engineering_rate
  + customer_success_hours × customer_success_rate

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

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

Учёт инцидентов должен включать исправление и профилактику

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

Представьте сбой в модуле отчётов. Запрос отчёта исчерпал пул соединений общей базы данных. Непосредственная стоимость инцидента относится к отчётам, потому что именно отчёты вызвали последствия для клиентов. Для постоянного исправления могут понадобиться ограничение пула соединений на платформе и переработка запроса отчёта. Зафиксируйте обе профилактические задачи с собственными назначениями модулей и свяжите их с ID инцидента.

Руководство Atlassian по инцидентам стоит прочитать ради правила ответственности, а не ради копирования точного процесса. В нём команда, отвечающая за неисправный сервис, отвечает за разбор инцидента, а работа по устранению последствий попадает в бэклог этой команды. Именно это поведение стоит перенять. Разбор без назначенной последующей работы остаётся документом. Он не снижает стоимость обслуживания.

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

1. Время обнаружения и первичного анализа.
2. Время смягчения последствий и восстановления.
3. Коммуникация с клиентами и ручное восстановление.
4. Последующая инженерная работа, предотвращающая повторение.

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

Рекомендации Google SRE определяют toil как повторяющуюся и предсказуемую операционную работу, необходимую для поддержания сервиса. Это определение даёт основателям практическую границу. Инженер, расследующий новую архитектурную неисправность, может создать долговечные знания. Инженер, который каждое утро перезапускает одну и ту же зависшую задачу, оплачивает постоянный счёт за обслуживание. В первом случае нужны плановые инвестиции в надёжность. Во втором должны появиться автоматизация, изменение продукта или отказ от него.

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

Для инженерного времени нужны категории, а не слежка

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

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

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

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

Расчёт должен отделять время от денег:

maintenance_hours[module, month] =
  linked_issue_hours
  + incident_hours
  + approved_weekly_unplanned_hours

engineering_maintenance_cost[module, month] =
  maintenance_hours[module, month] × blended_engineering_rate

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

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

Для распределения облачных расходов нужны теги ресурсов и обоснованные показатели

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

Начните с прямых облачных расходов: выделенные базы данных, очереди, хранилища, пулы рабочих процессов, внешние API и окружения. Помечайте каждый ресурс полями module_id, environment и owner. Там, где это позволяет облачный провайдер, автоматически проверяйте теги. Тега центра затрат недостаточно, если он указывает только на компанию или инженерный отдел.

Для общих ресурсов нужно письменное правило. Выбирайте самый простой показатель, который причинно связан с потреблением.

• Стоимость общего API-шлюза можно распределять по числу запросов каждого модуля.
• Общие объектные хранилища, по объёму сохранённых и полученных данных.
• Общий аналитический склад, по вычислениям запросов или объёму просканированных данных.
• Счёт за наблюдаемость, по объёму журналов, трассировок или числу отслеживаемых хостов.
• Общий кластер Kubernetes, по запрошенным CPU и памяти, а не по выручке приложения.

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

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

select
  module_id,
  round(shared_cost_usd * module_requests / total_requests, 2) as allocated_usd
from monthly_module_usage
where period = date '2026-06';

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

Общая работа платформы не должна исчезать в накладных расходах

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

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

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

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

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

Отчёт об обслуживании должен помогать принимать продуктовые решения

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

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

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

Вот последовательность проверки, которую я использую с основателями:

1. Отсортируйте модули по общей стоимости обслуживания. Спросите, что создаёт три крупнейшие статьи.
2. Отсортируйте по стоимости обслуживания на активного клиента. Проверьте, не нужны ли нишевому модулю изменение цены, переработка или план закрытия.
3. Отсортируйте по незапланированным инженерным часам. Так можно найти потерю мощностей раньше, чем её заметят финансы.
4. Изучите каждое назначение с низкой уверенностью и каждый неназначенный расход. Именно там часто обнаруживается непринятое решение об ответственности.
5. Выберите одно действие, укажите владельца, ожидаемое сокращение расходов и дату проверки.

Пример показывает суть. Допустим, интеграции приносят $18 000 ежемесячной выручки. На них приходится $2 400 труда поддержки, $1 600 на исправление и профилактику инцидентов, $3 000 инженерного обслуживания, $1 200 прямых облачных расходов и $1 800 распределённых общих расходов. Итого ежемесячное обслуживание стоит $10 000, ещё до продаж, общего управления и разработки новых функций.

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

Точность растёт благодаря проверкам, а не масштабному запуску

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

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

Установите три правила, которые не дадут журналу прийти в негодность:

• Новый модуль нельзя выпускать без владельца, ID и плана распределения затрат.
• Новым облачным ресурсам нужен тег модуля или явная классификация как общего ресурса.
• Шаблоны инцидентов и поддержки должны требовать указания основного модуля до закрытия.

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

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

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