Запросы от пользователей и требования к продукту

Очень много статей и книг о работе менеджера продукта, рассматривают вопросы стратегического мышления ^[1] и инноваций. Безусловно, это базис. Мне же нравится обращать внимание на ежедневные рутинные задачи. Одна из таких работа с запросами пользователей и требованиями к продукту.

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

Давайте рассмотрим простой пример — приложение Калькулятор. Вы получили запрос: добавить поддержку двоичной системы счисления. Он может породить несколько требований к продукту.

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

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

Возможно, это все очевидно. Но процесс работы с запросами, в случае если ему не придать значения, может добавить проблем. Первый подводный камень — ведение записей в трекере.
Очевидно, что иметь единую систему для запросов пользователей и требований к продукту лучше, чем две. Ну, как минимум, у вас будет всего одно окно открыто. Важно при этом иметь разные типы объектов для записей. Пример из моего опыта. Я получаю где-то в среднем от двух до четырех запросов пользователей каждый рабочий день. Вы можете представить объем. Список в бэклоге продукта просто огромен. Имея два типа записей “требование” и “запрос на функциональность” позволяет настраивать фильтры, собирать бэклог конкретной версии и делать ссылки между требованиями и запросами для отслеживания истории. Более того, после рассмотрения запроса его можно закрыть с пометками “планируется к релизу” или “не будет реализовано”.

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

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

^{Zendesk форум обратной связи}

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

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

Каждый менеджер продукта выбирает собственное решение. Здесь нет универсального подхода. Однако, всегда нужно помнить, что даже такой небольшой процесс как сбор и обработка запросов от пользователей может содержать много скрытых тем, и легко удвоить работу.

Автор: MikhailZakharov

Источник ^[2]