От исследования до релиза: как создают и развивают цифровые продукты

Свой сайт или мобильное приложение нужны бизнесу в любой нише. При этом не всегда в компании есть понимание, из каких шагов состоит разработка. Без чёткого плана сложнее найти ресурсы на создание и улучшение цифрового продукта и организовать работу в команде.

Меня зовут Иван Меркурьев, и я занимаюсь развитием Календаря в Яндекс 360 — сервиса, которым пользуются миллионы людей для личных целей и тысячи компаний для бизнес-целей. У Календаря есть несколько версий: десктоп, мобильная внутри приложения Яндекс Почты, а также touch-версия, которая открывается с браузера смартфона. Развивать такой продукт в разы сложнее, потому что нужно учитывать интересы каждого сегмента пользователей и особенности разных платформ. В статье я расскажу, какие этапы мы проходим, чтобы подготовить и грамотно внедрить новые фичи в Календарь.

Этап 1: исследование

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

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

Этап 2: проектирование

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

Чтобы выбрать оптимальное решение, мы обычно проводим:

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

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

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

В ходе проектирования мы выстраиваем понятный пользовательский путь. Он складывается из шагов, которые проходит человек, чтобы достичь своей цели в рамках сервиса. А ещё определяем бизнес-метрики, которые хотим улучшить. Например:

• DAU — дневная аудитория пользователей;
• MAU — месячная аудитория пользователей;
• Retention — возвращаемость пользователей к продукту.

Этап 3: защита решения

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

Мы предлагаем наше решение и прорабатываем его вместе с коллегами из Почты, Диска, Телемоста и других сервисов. Так у нас получается выкатить не изолированное обновление, а новый сценарий — как пользователи могут работать с продуктами Яндекс 360.

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

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

Этап 4: разработка

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

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

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

Отдельно стоит отметить работу со смежными командами: Поддержка, Продажи, Маркетинг и другие. Обычно к завершению этого этапа они все погружены в будущий запуск и понимают, что им нужно сделать.

Этап 5: релиз

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

Мы постепенно раскатываем новый функционал на определённый процент пользователей: от 5 до 100%. Такой подход позволяет внимательно отслеживать, как люди взаимодействуют с обновлениями.

Параллельно с релизом команда собирает обратную связь: анализирует отзывы в App Store и Google Play, из которых скачивают мобильное приложение Яндекс Почты (внутри него живёт Календарь), и изучает обращения в техподдержку по всем каналам. А для бизнес-клиентов выделены менеджеры, которые общаются с ними напрямую. Календарём пользуются разные группы пользователей — что хорошо и удобно для одних, может оказаться неочевидным и сложным для других.

Этап 6: оптимизация и дальнейшее развитие

Специалисты на этом этапе продолжают обрабатывать обратную связь от пользователей и фиксируют, что можно улучшить в продукте. Но самое важное после релиза — понять, стоит ли дальше вкладываться в эту фичу или лучше направить силы на развитие новой, которая решит больше проблем.

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

Краткий алгоритм: как улучшить цифровой продукт за 6 шагов

Если чётко следовать плану и не пропускать этапы, выше шанс, что ваш сайт, приложение или другой цифровой продукт будет востребован. Что важно сделать:

1. На этапе исследования нужно проанализировать запросы целевой аудитории и определить направление развития.
2. Этап проектирования позволит разработать оптимальное решение, которое закроет потребности пользователей.
3. Если ваш цифровой продукт связан с другими сервисами, обсудите идею обновления с коллегами из смежных команд.
4. На этапе разработки подключается целый пул специалистов: разработчики, дизайнер, тестировщик. Менеджер проекта курирует работу над новой функцией.
5. В момент запуска собирайте обратную связь, чтобы понять, насколько нововведения удобны для пользователей.
6. После релиза стоит вернуться к целевым метрикам: если они достигнуты, можно думать о разработке новых функций, если нет — нужно искать другие пути для решения поставленной задачи.