О работе менеджера по продукту написано множество статей и книг, посвященных вопросам стратегического мышления и инноваций.
Конечно, это основа.
Мне нравится уделять внимание повседневным рутинным задачам.
Один из них — работа с запросами пользователей и требованиями к продукту.
То, что запросы пользователей на функции не являются требованиями к продукту, является аксиомой.
Запрос легко можно разделить на несколько требований, и наоборот, одно требование может состоять из нескольких запросов от пользователей.
Давайте рассмотрим простой пример — приложение «Калькулятор».
К вам поступил запрос: добавьте поддержку двоичной системы счисления.
Это может породить несколько требований к продукту.
- Поддержка арифметических операций.
- Поддержка конверсий.
Это, кстати, коснется и существующей десятичной системы.
Как минимум, вам нужно будет сделать кнопки в интерфейсе.
- Поддержка логических операций.
Запрос касается системы счисления в целом, но содержит ряд требований.
Возможно, это все очевидно.
А вот процесс работы с запросами, если ему не уделять внимания, может добавить проблем.
Первый подводный камень — ведение записей в трекере.
Очевидно, что иметь одну систему для запросов пользователей и требований к продукту лучше, чем две.
Ну, по крайней мере, у вас будет открыто только одно окно.
Важно иметь разные типы объектов для записей.
Пример из моего опыта.
Я получаю в среднем от двух до четырех запросов пользователей каждый будний день.
Вы можете себе представить объем.
Список в бэклоге продуктов просто огромен.
Наличие двух типов записей «требование» и «запрос на функцию» позволяет настраивать фильтры, собирать бэклог конкретной версии и устанавливать связи между требованиями и запросами для отслеживания истории.
Более того, после рассмотрения заявки ее можно закрыть с отметками «планируется к выпуску» или «не будет реализовано».
Второй аспект работы — непосредственно сбор требований.
Один из способов — получить их через техническую поддержку.
Это хороший процесс, в результате которого получается отфильтрованный запрос, содержащий суть.
С другой стороны, это не прозрачно для ваших пользователей.
Многие могут не увидеть, что был сделан такой запрос, и подать заявку повторно.
Поэтому поставщики, особенно те, которые создают облачные решения, могут использовать порталы для получения обратной связи.
Форум обратной связи Zendesk
Этот метод улучшает видимость.
Отделяет запросы от требований, поскольку системы разные.
Однако теперь ваша работа увеличилась вдвое.
Вам нужно быстро просматривать новые публикации, комментировать, отвечать на вопросы.
Молчание, особенно в публичном общении, недопустимо.
Но самое сложное в том, что теперь вам придется каким-то образом отслеживать и помечать запросы, чтобы отмечать те, которые запланированы к реализации, или наоборот. Возвращаясь к примеру с калькулятором.
Как отметить на портале заявку на поддержку двоичной системы, если вы планируете реализовать только арифметические операции и преобразования, без логических операций.
Каждый продакт-менеджер выбирает свое решение.
Здесь не существует универсального подхода.
Однако всегда следует помнить, что даже такой небольшой процесс, как сбор и обработка запросов пользователей, может содержать множество скрытых тем, и работу легко удвоить.
Теги: #Управление продуктом #требования #Управление продуктом
-
Плюсы И Минусы Ноутбука
19 Oct, 24 -
Животные В Экспериментах
19 Oct, 24 -
Гуа
19 Oct, 24 -
Гинкго Двулопастный
19 Oct, 24 -
Google Начал Продавать Google Apps
19 Oct, 24
