Где брать идеи для бэклога продукта, если клиент не хочет развиваться

Как устроен бэклог

Бэклог — упорядоченный список всего, что команда может сделать с продуктом. Термин пришёл из Scrum, где за него отвечает владелец продукта.

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

Хороший пункт в списке отвечает на три вопроса: что сделать, зачем и как понять, что сделано. Формулировка «улучшить корзину» не годится. «Добавить повтор прошлого заказа, чтобы постоянные клиенты оформляли его быстрее» — уже задача.

• пользовательские истории и новые функции;
• баги;
• технический долг;
• гипотезы для проверки;
• исследования и аналитика.

Общий бэклог и бэклог спринта

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

Груминг: как держать список в порядке

Раз в одну-две недели команда пересматривает верх списка. Уточняет формулировки, дробит крупные задачи, добавляет оценки и выкидывает то, что потеряло смысл.

Эту встречу называют грумингом или refinement. Без неё список за полгода превращается в архив на сотни пунктов, где никто ничего не может найти.

Тридцати-сорока минут обычно хватает.

Как расставить приоритеты

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

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

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

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

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

Ещё источники задач

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

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

• Вебвизор и карты кликов в Яндекс Метрике: где люди застревают;
• поиск по сайту: что ищут и не находят;
• воронка заказа: на каком шаге уходят;
• обращения в поддержку и записи звонков;
• сайты конкурентов и их обновления.

Опрос сотрудников клиента: как провести

Пять-семь интервью по 30 минут с операторами, менеджерами и кладовщиками дают больше, чем месяц переписки с руководителем. Спрашивайте о повседневной работе: что делают руками, где теряют время, какие вопросы чаще всего задают клиенты.

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

Форма обратной связи на сайте: что спрашивать

Один открытый вопрос «Что можно улучшить?» работает лучше длинной анкеты. Показывайте форму после заказа или на странице, где люди проводят больше времени. Ответы разбирайте раз в неделю и сразу переносите в список задач.

Ошибки, из-за которых бэклог не работает

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

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

Как выбрать проект, у которого есть шанс расти

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

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

Продакт-менеджер на стороне клиента

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