У внутреннего сервиса нет выручки, зато есть вечный вопрос от бизнеса: зачем на него тратить команду и бюджет. ROI внутреннего продукта в таком случае считают не через продажи, а через три более приземлённые вещи: сэкономленное время, предотвращённые потери и снятые риски. Для русскоязычных продактов, тимлидов и IT-директоров это полезная рамка: она помогает защищать бэклог без шаманства с «косвенной пользой».
Эту логику разбирает автор материала на Habr / Карьера, который посвящён работе Internal Product Owner. Главная мысль простая: классическая формула ROI, завязанная на выручке, для внутренних продуктов почти бесполезна. Оркестратор, внутренняя платформа, сервис интеграций или модуль документооборота ничего не продают напрямую. Их работа обычно заметна только в двух случаях: когда всё сломалось или когда кто-то снова спрашивает, почему именно эта задача попала в приоритет квартала.
Вместо попытки натянуть на внутренний продукт формулу «доход минус затраты» автор предлагает считать ценность по типу эффекта. Первый и самый удобный вариант — экономия времени. Если сотрудники раньше тратили часы на ручные операции, разбор ошибок или ответы на однотипные вопросы, это можно перевести в деньги почти без допущений. Берётся разница между «было» и «стало», умножается на стоимость единицы работы и на период. В статье для этого приводится кейс со статусом заявки: после небольшой доработки фронт дилерских центров стал видеть причину ошибки от смежной системы, и число обращений в поддержку по теме сократилось с 40 до 20 в день. При стоимости обработки одного обращения в 300 рублей месячная экономия составила 120 тысяч рублей. Тут ценность не в самой доработке, а в снижении реальных затрат. Бизнес обычно понимает именно этот язык, а не рассказ о том, как команда «повысила прозрачность статусов».
Второй тип эффекта — предотвращённые потери. Это уже зона, где математика перестаёт быть стерильной, зато становится ближе к реальности. Внутренний сервис может не падать, а просто работать медленнее: клиент ждёт ответ по заявке лишние пять минут, конверсия проседает, а деньги уходят не в отчёт, а мимо кассы. В примере из статьи берётся 100 заявок в день, падение конверсии с 70% до 65% и средний чек автокредита 1,5 млн рублей. На этой модели потери оцениваются в 7,5 млн рублей в день. Важно, что автор не продаёт это как точный прогноз. Это именно оценка порядка величины, которая нужна, чтобы показать масштаб проблемы руководителю. И здесь есть трезвое предупреждение: если связь между задержкой и падением конверсии не подтверждена аналитикой, её нельзя выдавать за установленный факт. Один раз перепутаешь гипотезу с метрикой — и следующую таблицу с ROI будут смотреть уже с тем выражением лица, которое обычно достаётся презентациям про синергию.
Третий сценарий — снятый риск. Самый неблагодарный для расчётов и при этом самый понятный для крупных компаний, особенно в финтехе, банках и любой зарегулированной среде. В статье разбирается кейс с требованиями 353-ФЗ о раскрытии полной стоимости кредита и графика платежей. Система должна собрать данные из смежного сервиса и передать их во фронтальные каналы для формирования документов. Если интеграцию не сделать или ошибиться в расчётах, у бизнеса появляется риск претензий со стороны регулятора. В условной модели из статьи вероятность выявления нарушения на проверке оценивается в 30%, потенциальный штраф — в 700 тысяч рублей, а снятый риск — в 210 тысяч рублей на одну проверку. Для приоритизации такие задачи часто не нуждаются в особой защите: если это прямое требование закона, делать всё равно придётся. Но числовая оценка полезна для истории, когда через год кто-то спросит, зачем команда потратила спринт на то, что пользователь глазами вообще не заметил.
Практическая ценность этой схемы не только в формулах, но и в дисциплине мышления. Автор предлагает держать для задач простой шаблон: было, стало, метрика, формула, период и итог в деньгах. Такой каркас не обещает точность до рубля и не заменяет нормальную продуктовую аналитику, зато помогает быстро перевести спор о приоритетах из режима «нам кажется это важным» в режим «вот какой эффект это даёт или какой ущерб снимает». Для внутренних команд это особенно актуально, потому что их работа часто страдает от парадокса невидимости: чем надёжнее сервис, тем меньше его замечают. А значит, тем труднее объяснить, почему в бэклоге снова не фича для внешнего клиента, а какая-нибудь скучная интеграция, мониторинг или переработка статусов ошибок.
При этом материал честно признаёт ограничение подхода: не всё нужно и не всё стоит переводить в деньги. Доверие смежных команд, репутация платформенной команды внутри компании, готовность бизнеса идти на компромиссы в спорных местах — это тоже ценность, просто она не помещается в аккуратную ячейку Excel. Попытка монетизировать вообще всё иногда обходится дороже самой пользы. Но как рабочий способ считать ROI внутреннего продукта этот подход выглядит здраво: сначала считать то, что действительно считается, потом явно отделять измеренные данные от гипотез, и только после этого выходить на разговор о приоритетах. Похоже, для многих внутренних продуктов проблема уже не в том, как доказать пользу, а в том, готовы ли команды перестать защищать важные задачи одними только словами.