Развиваем продукт «без проблем»

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

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

Как с помощью Jobs To be Done принимать продуктовые решения, и почему сейчас мы используем этот подход для работы над нашими внутренними продуктами.

О каком продукте пойдёт речь

REpublic — это релизный портал в Ozon, который помогает разработчикам и тестировщикам с процессом установки релизов в production. Его основная цель — это уйти от понятий коммит, ветка, пайплайн, тег и оперировать понятием релиз. Этот сервис предоставляет удобный интерфейс для простого и понятного процесса установки и отката релизов.

В общем, это такой центр управления полётами.

С его интерфейсом и тем, как мы над ним работали, вы можете ознакомиться в статье моей коллеги.

С чего начинался продукт

Этот продукт начинался как data mining-сервис. На первом этапе нашей задачей было научиться собирать данные об устанавливаемых релизах. REpublic собирал данные о том, что происходит в Gitlab и Jira, и отображал это в своём интерфейсе. 

Было важно на практике подтвердить, что будет достаточно данных, чтобы выстроить цепочку событий и собрать наш «синтетический» релиз. 

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

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

А что же делать дальше?

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

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

К нам приходили пользователи с запросами на доработки, и самыми «показательными» стали два:

1. от команды мобильной разработки — дать возможность добавлять к релизу описание, чтобы иметь единое место, где можно составлять, исправлять и автоматически публиковать в магазины приложений описания для релизов;

2. от команд логистики — добавить возможность создавать и «проходить» по чек-листу при установке релиза.

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