Часть 2. Что ребята из FinOps реально поняли - и как это превратили в продукт
Вчера я рассказывал, как команда собрала UXR Point of View - свою “карту мышления пользователей”. Сегодня - коротко и человеческим языком: что они там накопали и что сделали дальше.
Основные инсайты, которые они вынесли Из их многопрофильного (qual + quant) исследования вышли такие ключевые открытия:
*** Разные сегменты пользователей с совершенно разными потребностями и подходами.** Они не делали банальную сегментацию по роли/организации, а выделили группы по тому, как люди реально управляют облачными расходами: уровень зрелости, подход, активность, страхи, желание автоматизации.
*** Боли и боли - везде, но не все одинаково.** У одних pain-point’ов была тёплая зона: непонятность биллинга, сложность расчётов, неопределённость цены. У других — усталость от ручного контроля, желание автоматизации, страх перед ошибками. То есть «болит» не просто облако, а болит по-разному, в зависимости от поведения и зрелости клиента.
*** Большая часть фидбека - от «громких» клиентов, которые не отражают большинству.** Просто слушать запросы из sales / support — опасно. Это зачастую голос «эксцентричных» пользователей, не репрезентативный.
*** Только смешанный подход** (качественные + количественные методы) даёт надёжную и масштабируемую картинку. Интервью + user journeys + лог-аналитика + опросы/сегментация + сравнительный анализ рынка — всё это вместе позволило увидеть, что реально востребовано, а что - шум.
*** Юзер хочет «инструмент + руководство», а не просто фичи.** Они выяснили, что многие FinOps-практики хотят не просто UI-фичу, а «one-stop shop» - дашборд + рекомендации + контроль + прогноз. Им нужна не просто кнопка, а карта + компас, чтобы ориентироваться в хаосе облачных расходов.
*** Ресурсы ограничены - приоритет должен идти по боли + масштабу + реализуемости.** Не каждая pain-точка стоит миллиардов инженерного ресурса. Нужно выбирать, что реально даст эффект для большинства, что проще реализовать, и что даст конкурентное преимущество.
🛠 Как они применили эти инсайты: от PoV к реальному продукту После того как инсайты собрали - они не просто положили их на полку. Вот как это трансформировалось в рабочий продукт:
1. Выставили чёткие критерии - приоритет + дифференциация Они оценивали каждую потенциальную возможность (pain/fear/feature) по таким параметрам: критичность для пользователя, масштаб проблемы (сколько пользователей затронуто), конкурентная ситуация, реалистичность реализации. Только после этого шли дальше.
2. Сегментировали пользователей и кастомизировали подход Вместо «всем по одной UI-таблице» - сегментный подход: для новичков - понятный UI, минимальный порог входа; для опытных - автоматизация, programmatic access, продвинутая аналитика.
3. Создали UXR PoV - как стратегический фильтр Это стало как внутренняя Конституция: PoV описывал, как разные группы пользователей взаимодействуют с продуктом, какие у них боли, страхи, ожидания. И каждое решение проверялось через него.
4. Разработали “one-stop shop” дашборд + инструменты + рекомендации То, что продуктовая команда называла “дифференцированным предложением” на фоне конкурентов - дашборд с actionable insights, гибкой сегментацией, настройками, вариантами контроля и автоматизации, чтобы дать пользователю контроль и уверенность.
5. Приоритизировали фичи по логике PoV + данных, а не по “кто громче сказал” Фича-бэклог стал структурированным: сначала шли базовые задачки для массовых пользователей, потом - продвинутые, кастомные. Это позволило эффективно распределить ресурсы и избежать ненужного overengineering.
6. Оставили PoV “живым”: итерации, рефлексия, переоценка по мере роста Они выбрали подход «strong opinions, loosely held» - то есть PoV не догма, а рабочая гипотеза: с ростом пользователей, с новыми данными - PoV можно и нужно пересматривать. Это дает гибкость.
