💸 Как оценивать эффективность технических фич

Канал о системном и бизнес-анализе, продуктовом мышлении и архитектуре. Как выявлять реальные проблемы, строить работающие решения и не терять здравый смысл в IT. Все вопросы - @innokentyB

технические фичимикросервисыkyc

Многие компании до сих пор делят фичи на “видимые” и “технические” — мол, первые приносят ценность бизнесу, а вторые просто нужны, «чтобы всё не упало».

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

Возьмём пример на другом полюсе — оптимизацию инфраструктуры. Компания перешла с монолита на микросервисы, и время простоя сократилось с 2 часов до 10 минут в месяц.

При средней стоимости простоя ₽500 000 в час, это экономия почти ₽1 млн в месяц, или ₽11 млн в год.

📈 SLA — это не про стабильность ради стабильности. Это про деньги, которые бизнес не теряет.

Теперь другой тип фичи — автоматизация KYC-проверок.

До внедрения аналитики вручную валидацировали данные клиентов: 25 минут на клиента × 3000 клиентов = 1250 часов в месяц. При ставке ₽1250/час — это ₽1,56 млн расходов.
После автоматизации 90% кейсов проходят без участия аналитиков. Осталось ₽156 000 в месяц, а экономия — ₽1,4 млн.

💡 Фича окупилась за один спринт. И аналитики наконец занялись тем, что требует мышления, а не чек-листа.

🧠 Вывод: Каждое улучшение можно посчитать — будь то архитектурный переход, оптимизация API или автоматизация проверки данных. Всё, что уменьшает время, риски и потери — уже создаёт value.

Главное — не лениться переводить это в цифры.

Подробнее про работу с техническими фичами на интенсиве для технических продактов! Старт 17 ноября! Регистрация тут

Дискуссия

PRO анализ в ИТ
Константин Альбертович Китаев
Да даже дело не в сопротивлении. Просто никто не считает, нет понимания как считать, что учитывать.
И это тоже, но в том и работа продакта, чтобы посчитать
Илья Марчук
Сам посыл - действительно правильный, но в реальности всё работает часто совсем по-другому...
PRO анализ в ИТ
Илья Марчук
Сам посыл - действительно правильный, но в реальности всё работает часто совсем по-другому...
Привет. Поделитесь,как работает на самом деле?
Илья Марчук
PRO анализ в ИТ
Привет. Поделитесь,как работает на самом деле?
В идеальном мире мы можем и должны рассчитывать бизнесовую ценность технических фичей, но это в реальности достаточно редко применимо на практике. Когда есть прямая одноцепочная связка технической фичи и бизнесовой ценности - это действительно не очень сложно, хотя даже этим часто пренебрегают. Но что если у вас не одно звено (Падение прода из-за неправильной конфигурации балансировщика == прямые денежные/репутационные убытки), а несколько, как это бывает намного чаще в реальности? Даже в случае одного звена цепи - мы уже играем с допущениями, рассчитываем ценность и можем смириться с полученной погрешностью. Но если их больше - мы уже получаем расчёт, который : а - очень недостоверный и с огромной погрешностью, б - дорогой при декомпозиции для отдельных фич. Либо другие факторы, которые влияют на возникновение такой непрямой связи. Про какие случаи я говорю, например: 1. Платформенная разработка 2. Проектная/заказная разработка 3. Любые работы, где нет бизнесовых/«видимых» фич - технические работы/devops-аутсорсинг/работы по поддержке Итого, любые работы, где нет прямой связки реализация технической фичи -> оптимизация затрат для клиента, которые можно измерить деньгами на масштабе фичей, как это делается с «видимыми» фичами. Ну и очень часто даже в разрезе продуктовой разработки тебе вообще не имеет смысла заниматься оценкой технических фичей на старте/подъёме продукта. Оптимизация начинает активно играть роль, когда есть уже что оптимизировать и других проблем особо нет, а при этом при управлении рисков вы выявляете, что откладывание технических фичей может приводить уже к массивным экономическим потерям.
PRO анализ в ИТ
Илья Марчук
В идеальном мире мы можем и должны рассчитывать бизнесовую ценность технических фичей, но это в реальности достаточно редко применимо на практике. Когда есть прямая одноцепочная связка технической фичи и бизнесовой ценности - это действительно не очень сложно…
Насчет последнего совсем спорно - как раз на старте и надо заниматься этим - пара неприбыльных фич и все, продукт умер. Приведите пример для платформенной разработки и фичи, я размеру, как ее можно оценить. Насчет заказной разработки - соглашусь, там вообще редко про ценность, там про освоить бюджет обычно.
Илья Марчук
PRO анализ в ИТ
Насчет последнего совсем спорно - как раз на старте и надо заниматься этим - пара неприбыльных фич и все, продукт умер. Приведите пример для платформенной разработки и фичи, я размеру, как ее можно оценить. Насчет заказной разработки - соглашусь, там вообще…
Если на старте продукта у команды есть время на оптимизацию - это значит, что бюджет продукты просто огромный и вам очень повезло. Такие варианты - это прям близко к идеалу, как я сказал. Например, продукт делает два разработчика и им нужно как можно быстрее выкатить продукт в прод - то между тем, чтобы выбрать функциональные фичи, которые принесут деньги в моменте, и технические фичи, которые помогут сооптимизировать затраты - 100 управляющих бизнесом из 100 выберут функциональные фичи. И правильно сделают в условиях ограниченных ресурсов. Насчёт платформенной разработки - да в целом любая фича подойдёт. Например, внедрение какого-то шаблонизатора для упрощения написания инфраструктурного кода или генератора манифестов кубернетеса. В целом - как я и сказал, её можно оценить, типа ускорили команды разработки на 20%, а те в свою очередь приносят фичей в год на 50 млн рублей, вот и выгода в 10 млн рублей. Но это всё погрешности на уровне средней температуры по больнице. ЛИБО, у вас есть действительно огромный внутренний отдел, который занимается внедрением методологий и долго имплементирует различные метрики, которые потом можно связывать друг с другом. Тоже есть погрешности, но поменьше. Ну и это доступно 1% компаний, так как очень дорого для внедрения.
PRO анализ в ИТ
Илья Марчук
Если на старте продукта у команды есть время на оптимизацию - это значит, что бюджет продукты просто огромный и вам очень повезло. Такие варианты - это прям близко к идеалу, как я сказал. Например, продукт делает два разработчика и им нужно как можно быстрее…
Насчет первого я все равно не понимаю (ко второму это тоже относится), а как вы тогда решаете, какие фичи делать, а какие подождать? Guts feeling? Вам нужно ведь как то принимать решение
Илья Марчук
PRO анализ в ИТ
Насчет первого я все равно не понимаю (ко второму это тоже относится), а как вы тогда решаете, какие фичи делать, а какие подождать? Guts feeling? Вам нужно ведь как то принимать решение
Ну как - обычно есть сформированный беклог. Туда добавляются задачи, исходя из бизнесовой потребности, поэтому они на 85% состоят из бизнесовых фичей. Также туда по потребности докидываются технические фичи техлидами/аналитиками/продуктами/кем у вас принято. А дальше вопрос приоритетности, который в 99% случаев отдаётся бизнесовым фичам. Зачем тратить ресурсы на оценку+сравнение решений, если приоритет и так очевиден. И тут вопрос даже не к оценке и не к фичам, а в целом к оптимизации. Она никак не влияет на доходность продукта/компании. Дополню ещё, что большая часть технических фичей связана с рисками, которые бизнес часто готов на себя принимать до какого-то момента/пока не стало слишком поздно.
Илья Марчук
PRO анализ в ИТ
Вот тут и зарыта собака то. Как продакт я как раз и отвечаю за то, чтобы в том числе и риски нивелировать и учитывать возможные потери
Это какой-то очень обособленный продакт в какой-то отдельной команде продуктовой вне больших компаний. Где по сути ПО отвечает полностью за бизнесовую успешность продукта, рассчитывает весь бюджет продукта, определяет приоритетность и так далее. Как я уже сказал - таким ситуаций - достаточно немного в мире (от общей массы, конечно же). Ну и дополню, что продакт просто не обладает достаточной экспертностью в вопросах технических рисков. И это нормально. Пока ему о них не подсветят - он не будет в курсе, поэтому как он может оценить риски, если про них не знает.
Присоединиться к обсуждению →

Читайте так же