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

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

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

Меня зовут Денис Соловьев, и так получилось, что я работал и продолжаю работать как раз на таких внутренних ИТ-продуктах. Я хочу сравнить, какие из инструментов и подходов работают для них.

Для внешних продуктов понятен путь развития и ориентиры на нём: доля рынка; прибыль компании; время, проведённое пользователями в приложении. Такие метрики помогают принимать решения и оценивать динамику продвижения продукта к цели.

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

Немного о своём опыте: я работал в команде, которая создавала внутреннее облако банка, там же руководил командой, которая создала продукт по планированию мощностей для этого облака, а потом интегрировала эту систему в бюджетирование компании. Участвовал в создании системы внутреннего биллинга и каталога ИТ-продуктов. А сейчас я работаю в команде, которая автоматизирует ИТ-процессы в Ozon.

Существующие инструменты для продуктов

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

Product market fit

Этот подход описывался, например, вот в этой статье. Основная идея Product market fit (PMF) — обеспечить соответствие продукта ожиданиям рынка, то есть насколько ваш продукт «попал» в потребителя и какова длина очереди из покупателей. То есть основное, что важно для продукта на этой стадии, это наличие рынка потребителей, по которому, как по компасу, мы можем сверять путь развития и стараться, чтобы он не отклонялся далеко от рынка.

MVP

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

Продуктовые метрики

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

Для целей этой статьи, разделим метрики на три группы:

• про деньги;

• про динамику пользователей;

• специфичные для продукта метрики.

Про деньги:

• GMV — Gross merchandise volume, общий объём оборота товаров или услуг.

• LTV — Lifetime value, доход от одного пользователя за время использования сервиса. Обычно эту метрику измеряют за год (LTV360), но не обязательно: сервисы, связанные с обучением, могут рассматривать только учебный год или даже полугодие.

• Средний чек — сколько в среднем тратит пользователь в рамках одного заказа. Здесь могут использоваться медианные значения, а не средние.

• CAC — Customer Acquisition Cost, стоимость привлечения одного пользователя в сервис. Это те деньги, которая компания тратит на рекламу, проведение акций и другие маркетинговые активности.

Про динамику пользователей:

• Retention — сколько пользователей вернулось в сервис к определённому дню, то есть сколько пользователей, которые пришли к вам в первый день, вернулись во второй, третий и так далее. Такую метрику рассматривают обычно по когортам, это даёт понять, как изменяется ваш поток пользователей с течением времени, из кого этот поток состоит в конкретную дату. Может так оказаться, что в некотором интервале дат количество пользователей приблизительно одинаковое или даже немного растёт, но, на самом деле, имеется отток новичков, а текущие показатели обеспечиваются «старыми» пользователями.

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

• MAU\DAU — Monthly Active User\Daily Active Users, количество уникальных пользователей в день и месяц без учёта повторных сессий. Эта метрика важна для сервисов, которые борются за время пользователей: социальных сетей, сервисов стриминга музыки и фильмов, игровых сервисов и т. п.

Специфичные для продукта метрики могут быть самыми разнообразными, например:

• количество прослушиваний;

• количество поездок;

• длина поездки;

• количество скачиваний;

• количество просмотров;

• количество заказов и т. д.

Фреймворки приоритизации

Не буду очень подробно останавливаться на каждом из способов в отдельности, по этому поводу написано много статей, в том числе и на Хабре. Отмечу только те моменты, которые важны для нас.

Количественные

• WSJF (Weighted Shortest Job First, «сначала — более важная и короткая работа») — метод, используемый в Scaled Agile Framework (SAFe). И основная сложность в нём, это его громоздкость. Если вы сможете собрать все необходимые параметры, то получите очень хороший результат.

• RICE (Reach — охват, Impact — влияние, Confidence — достоверность, Effort — усилия) — по сути, оценка каждой задачи с точки зрения её ценности в противовес уверенности в ней и приложенным усилиям.

• ICE (Impact — влияние, Confidence — уверенность, Ease — легкость реализации) - очень похож на RICE, но в этом методе не учитывается параметр «охват», в остальном всё то же самое.

• Value vs Effort («ценность против усилия») — ещё один уровень упрощения, здесь «схлопнута» ещё и «уверенность», этот параметр как бы включён внутрь «ценности».

• Weighted scoring («взвешенная оценка») — по сути, это количественный метод, такой как RICE или ICE, но только правила вы придумываете сами. И одна из основных сложностей тут — это смочь выработать и договориться со всеми об этих правилах.

Качественные

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

• Story mapping («карта историй») — хороший метод для этапа MVP и определения, что в него должно входить. Он позволяет не терять фокус внимания и не отвлекаться от основных функций на красивые бантики. Но в каждом из столбцов задач необходимо как-то ещё расставлять приоритеты между задачами.

• MoSCoW — как и модель Кано, это, скорее, кластеризация задач на группы, чем именно приоритизация. Но это хороший способ посмотреть на продукт глазами заинтересованных лиц  или клиентов, это иногда приводит к неочевидным выводам. Дальше эти параметры можно использовать как одну из метрик в других методах приоритизации.

• Cost of delay («стоимость задержки») — оценка каждой из задач в деньгах, сколько мы теряем, не имея этой функциональности. Если бы была магическая палочка, которая могла точно считать такие потери, то другие способы приоритизации были бы не нужны. Но увы.

Другие

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

• Opportunity scoring («оценка возможностей»);

• Product tree («дерево продукта»);

• Buy a feature («купи функцию»).

A/B-тестирование

А/В-тестирование — это огромная тема, которую в двух словах не раскрыть. Недавно мои коллеги писали несколько статей про это тут и тут. Если совсем коротко, то А/В-тесты — это способ проверки гипотез с помощью экспериментов. Пользователи разбиваются на две группы, которым показываются разные версии продукта, а затем сравниваются результаты работы этих групп. 

Хорошие эксперименты должны быть измеримыми, опираться на метрики и показывать статистически значимые результаты.

Возможность использовать A/B-тесты — «логически» непростая задача, ведь вы же не захотите проводить только один эксперимент за раз, а значит возможно взаимное влияние одних экспериментов на другие, да и учёт текущих экспериментов непрост. Это сказывается и на технической сложности проведения таких тестов, обычно для этого используют целые платформы.

В общем — это довольно дорого, трудно и очень круто :)

В чём особенность внутренних продуктов

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

Давайте посмотрим, в чём же их особенности.

У пользователей нет выбора

Как бы странно это ни звучало, но если мы говорим о внутренних продуктах, у пользователей чаще всего нет выбора, какими инструментами пользоваться, да и вообще, пользоваться ими или нет. Есть какой-то внутренний процесс и для него в кампании есть инструмент — пользуйся на здоровье. 

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

Автоматизируем имеющиеся процессы как есть

Ещё один интересный момент: внутренние продукты часто создаются и используются для автоматизации какого-то уже существующего в компании процесса. И поэтому, по крайней мере в начале, вопрос об оптимизации этого процесса не стоит. Мы просто автоматизируем то, что и так работает, но на ручном приводе или в каких-то не предназначенных для этого системах. Или в самой мощной системе "АС Excel" — сколько всего можно успеть наплодить в табличках… Вспомните сервисы по заказу канцелярии или ремонта мебели, оформление командировок, заказа пропусков и т. п. Но это могут быть и более сложные сервисы, например планирования закупки ИТ-оборудования или его установки и настройки.

«С корабля на бал»

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

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

Нельзя посчитать экономику

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

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

Иногда так действительно можно оценить эффективность внедрения целого сервиса, но просто попробуйте посчитать, сколько человеко-часов сэкономлено от автоматизации заказа канцелярии, и теперь это происходит не за день, а за…. барабанная дробь — 8 рабочих часов :), потому что мы, конечно, молниеносно заказали это на портале, но оффлайн-процессы сборки, доставки и приёмки остались такими же.

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

Не подключить аналитику к продукту

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

Заказчик — руководитель, а не пользователь

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

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

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

Реклама и маркетинг

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

У команд внутренних продуктов не только нет бюджета на это, так ещё и нужных умений. А это очень важно, необходимо тратить на это силы и время. Я видел очень крутые внутренние продукты, о которых сложилось «мнение», и изменить его и работать в таких условиях гораздо сложнее. Проведение внутренних митапов, открытых демо, хакатонов и тому подобного — необходимая часть внутреннего продвижения, которой нельзя пренебрегать. 

Что остаётся для внутренних продуктов

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

MVP

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

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

Не метрики, а статистика

Как я уже описывал, далеко не всегда получается собирать какие-то метрики по продукту. Тут, я бы даже сказал, есть две проблемы.

Первая: бывает довольно сложно определить какую-либо не субъективную метрику для внутреннего продукта. Вот, например, попробуйте сходу предложить основную метрику для внутреннего трекера задач, аналога Jira. Всем пользоваться — обязательно, количество задач — не показатель, количество переходов между статусами — возможно, но это может быть отражение внутренних процессов. В общем, это возможно, но не просто.

Вторая: собирать метрики — задача, может быть, тоже нетривиальная, потому что инструментов, которые можно использовать без доступа в интернет, прямо скажем, не много. Есть Matomo, но он использует MySQL, а это может не вписываться в ваш стек.

А что же делать? Метрики нужно искать, как бы банально это ни звучало. Они могут быть очень нестандартными и совершенно неочевидными, но я уверен, что они точно есть. На одном из своих продуктов я понял, что является основной метрикой по нему — через год :) 

А пока продолжайте использовать статистику по продукту, которая помогает принимать решения при разработке. Что я имею в виду? Возьмём, например, продукт «трекер, аналог Jira»; думаю, такой пример будет многим понятен. По этому продукту можно собрать следующие данные:

• количество проектов;

• количество пользователей;

• количество пользователей в одном проекте;

• длина спринтов;

• количество задач в спринте (только не среднее значение :) ), нам нужен какой-нибудь перцентиль);

• длина названий: команд, задач, спринтов, описаний задач и т. п.

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

Но это всё-таки данные, в которые стоит смотреть, и иногда они преподносят сюрпризы.

Приоритеты без упора на экономику и прирост метрик

Приоритизация — самая спорная часть работы, но от неё никуда не деться даже во внутренних продуктах. И кроме стандартного метода приоритизации «по грейду заказчика» всё-таки нужно использовать и другие :)

Из тех способов, которые я описывал, для нас предпочтительнее те, в которых нет упора на экономику в любом её проявлении, и на охват в части «любви пользователей».

Я предпочитаю использовать ICE или «Value vs Effort», они по-прежнему имеют «субъективную» часть, и, возможно, это хорошо, мы можем быть гибче в расчёте итоговой оценки.

С другой стороны, они всё-таки дают некий формальный признак задачам, по которым их можно сравнивать между собой. Надо стараться выстроить диалог с заинтересованными лицами, так, чтобы уйти от спора о конечных приоритетах задач к определению самих параметров (Impact, Confidencial или Value), и если с ними все согласны, то оценка становится лишь фиксацией реальности.

Тесты на макетах

Да, полноценное A\B-тестирование и дорого, и часто технически недоступно для внутренних продуктов, но ведь никто не отменял другие способы донести свои идеи до заказчиков и пользователей. Начиная от банальных коридорок на картинках, форм опросов, голосования в чатах, кликабельных прототипов и чего-то подобного до использования инструментов usability-тестирования. Мне удавалось их использовать в своих проектах.

В общем — тут как и с метриками: полномасштабно что-то собрать и проверить или невозможно, или очень сложно, но получить обратную связь и выбрать из нескольких вариантов вполне возможно.

Сбор аналитики «как можем»

Тут тоже основной посыл в том, что если нет полноценных инструментов, то можно собирать «как можем». В одном из проектов мы часть метрик писали в логи и строили дашборды в Kibana. Сейчас в Ozon есть внутренний инструмент, который позволяет собирать метрики с фронтенда, а визуализировать данные в Grafana.

Я уже упоминал Matomo — это вполне достойный инструмент для внутреннего использования, и если вы можете его себе установить, то это очень даже хороший вариант.

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

Итог

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

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

Надеюсь, что эта статья поможет кому-то в работе над продуктами. Я для себя кое-что нашёл и освежил в памяти, пока её писал. :)

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

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

Но, кажется, это тема для другой статьи.