Очень много статей и книг о работе менеджера продукта, рассматривают вопросы стратегического и инноваций. Безусловно, это базис. Мне же нравится обращать внимание на ежедневные рутинные задачи. Одна из таких работа с запросами пользователей и требованиями к продукту.
Аксиомой является то, что запросы на функциональность от пользователей не являются требованиями к продукту. Запрос может быть легко разделён на несколько требований, и наоборот, одно требование состоять из нескольких запросов от пользователей.
Давайте рассмотрим простой пример — приложение Калькулятор. Вы получили запрос: добавить поддержку двоичной системы счисления. Он может породить несколько требований к продукту.
- Поддержка арифметических операций.
- Поддержка конвертации. Это, кстати, затронет и существующую десятичную систему. Нужно будет, как минимум, сделать кнопки в интерфейсе.
- Поддержка логических операций.
Как можно увидеть, изначально пользователь не просил поддержать, например, только логические операции. Запрос о системе счисления в целом, но он содержит под собой несколько требований.
Возможно, это все очевидно. Но процесс работы с запросами, в случае если ему не придать значения, может добавить проблем. Первый подводный камень — ведение записей в трекере.
Очевидно, что иметь единую систему для запросов пользователей и требований к продукту лучше, чем две. Ну, как минимум, у вас будет всего одно окно открыто. Важно при этом иметь разные типы объектов для записей. Пример из моего опыта. Я получаю где-то в среднем от двух до четырех запросов пользователей каждый рабочий день. Вы можете представить объем. Список в бэклоге продукта просто огромен. Имея два типа записей “требование” и “запрос на функциональность” позволяет настраивать фильтры, собирать бэклог конкретной версии и делать ссылки между требованиями и запросами для отслеживания истории. Более того, после рассмотрения запроса его можно закрыть с пометками “планируется к релизу” или “не будет реализовано”.
Второй аспект работы — непосредственно сбор требований. Одним из способов является получение их через техническую поддержку. Это хороший процесс, в результате которого вы получаете отфильтрованный запрос, содержащий суть. С другой стороны, это непрозрачно для ваших пользователей. Многие могут не видеть, что подобный запрос был, и обращаются повторно.
Поэтому вендоры, в особенности делающие облачные решения, могут использовать порталы для получения обратной связи.
Zendesk форум обратной связи
Этот способ улучшает видимость. Отделяет запросы от требований, так как системы разные. Однако теперь ваша работа удвоилась. Вам нужно быстро просматривать новые записи, комментировать, отвечать на вопросы. Тишина, в особенности в публичной коммуникации, недопустима.
Но самое трудное, что теперь придется отслеживать и маркировать запросы каким-либо образом, чтобы отметить те, которые планируются к реализации, или наоборот. Возвращаясь к примеру с калькулятором. Как на портале нужно помечать запрос на поддержку двоичной системы, если вы планируете реализовать только арифметические операции и конвертацию, без логических операций.
Каждый менеджер продукта выбирает собственное решение. Здесь нет универсального подхода. Однако, всегда нужно помнить, что даже такой небольшой процесс как сбор и обработка запросов от пользователей может содержать много скрытых тем, и легко удвоить работу.
Автор: MikhailZakharov
