Как управлять развитием продукта при ограниченных ресурсах

Спойлер: серебряной пули нет, но формальный процесс улучшает ситуацию.

Одной из самых сложных и творческих задач в управлении продуктом мне кажется выбор новых функций для реализации. Ресурсов не хватает никогда и никому, и из всех возможных улучшений постоянно приходится отбирать в лучшем случае десятую часть. (Возможно, что этот обязательный дефицит ресурсов даже полезен, поскольку 8 из 10 сервисов, в которых мне приходится работать, и так выглядят как переросший кадавр Франкенштейна.)

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

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

В целом процесс процесс выглядит очень просто.

• Собрать список новых фич.
• Выбрать самые интересные и запланировать их выход.
• Разработать и выложить в продакшн.
• Повторить.

Как обычно, самое главное — в деталях. Пройдемся по пунктам.

У всех нас есть свои идеи по развитию продукта. Они могут быть удачными или идиотскими. Пример ниже — мой персональный список фич, которые я считал перспективными в 2008 году (отправка документов по факсу выглядит очень плохой идеей). Но все инновации в конечном итоге приходят именно отсюда — из головы.

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

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

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

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

Очень важный канал. Многие пользователи могут годами ныть «ваш продукт — дерьмо» и годами продлевать свою подписку. Значит, по сути их все устраивает. Но есть действительно уходящие клиенты. Если они уходят из-за недостатков продукта (а не из-за закрытия своего бизнеса), эти недостатки критичны.

С отвалами у нас в компании общаются специальные люди — аккаунт-менеджеры — перед которыми стоит задача собирать и обобщать причины ухода.

Любой бизнес работает не в вакууме, а среде из конкурентов и партнеров. В этой среде что-то постоянно происходит. Например, в нашей нише в 2018 году стали трендом дешевые простые решения для предпринимателей второй волны внедрения онлайн-касс (мы решили действовать еще более радикально и сделали бесплатную версию продукта). Мониторинг экологической ниши, которую занимает наш продукт, дает непрерывный поток новых идей.

Представление о современном и удобном UI непрерывно меняется. За последние несколько лет мы видели скевоморфизм, интерфейс Metro, Material Design. Макет ниже выглядел хорошо в 2011 году, но сейчас воспринимается как безнадежно устаревший.

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

Одна из причин, по которым я люблю IT: здесь непрерывно появляются принципиально новые технологии. Мобильные приложения, чат-боты, big data, machine learning. Не все из них получается осмысленно использовать в продукте, но иногда они подсказывают отличные направления для развития.

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

Все уже знают про ЕГАИС и онлайн-кассы, но с появлением в нашей стране обязательной маркировки товаров эта история только начинается.

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

В начале роадмапы планировались на год. Это оказалось слишком большим периодом — планы постоянно обновлялись и вторая половина года не выполнялась почти полностью. Со временем мы перешли на 6-месячное планирование, а теперь — на 4-месячное.

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

У каждого роадмапа выбирается общее направление (например: сейчас мы хотим прокачать возможности аналитики). Задача рабочей группы — отобрать из большого списка фич (собранных из всех предыдущих источников) небольшую часть, которую вы возьмем в очередной роадмап.

Мы перепробовали три подхода к расстановке приоритетов.

Некоторое время мы старались сохранять баланс между тремя направлениями:

• Новые фичи.
• Улучшение и переработка UX и UI.
• Бэклог и архитектура.

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

Известная техника, которая делит функции продукта по их влиянию на удовлетворенность пользователей. Функции делятся на:

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

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

Подход работал не очень долго: довольно скоро мы реализовали все must be фичи, а одномерных функций было слишком много.

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

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

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

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

1. Соблюдение формального процесса помогает не делать откровенно бесполезную работу и сокращает количество «я же говорил!» на ретроспективе результатов.
2. Сам процесс планирования не отлит в граните и постоянно меняется. Уже через год процесс в нашей компании будет сильно отличаться от текущего.
3. Наличие понятной логики, по которой развивается продукт, помогает работать и команде, и пользователям.