Software Product Management Russia

Перевод статьи из блога requirements.seilevel.com/blog.

Ссылка на статью:

http://requirements.seilevel.com/blog/2009/06/what-does-requirements-sign-off-mean-in.html

——перевод——↓

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

Подождите минутку! Придержите своих лошадей! Требования определены? В Agile?

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

В итоге, мы пришли, на мой взгляд, к достаточно интересному решению. У нас было множество требований в формате user stories и других моделей, таких как «диаграммы процессов», «диаграммы состояний» и т.д. Также мы тесно работали с пользователями для выявления требований. Итак, мы попросили подтвердить, что к данному моменту времени не пропущено никаких серьезных требований, о которых они знают, и нет никаких значительных вопросов, которые не были сформулированы, о которых они знают. Суть в том, что они видели требования, участвуют в процессе и разработка прототипа не отклониться слишком далеко от необходимого. Но по-прежнему они имеют право добавить что-то новое после того, как увидят систему, подумают об этом или что-то в этом роде.

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

Перевод статьи Generating Product Ideas из блога carlknibbs.net.

Ссылка на статью: http://www.carlknibbs.net/blog/2009/5/7/generating-product-ideas.html

——перевод——↓

Непрерывное генерирование идей для продукта и функций очень важно. Как я отмечал ранее, не так важно КТО придумал идею, важно лишь, что менеджер продукта НАШЕЛ лучшие идеи и включил их в продукт.

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

Как провести ваш мозговой штурм: 

• забронируйте комнату и пригласите участников (выбирайте просторную комнату с большим количеством мест для фиксации идей);
• не делайте одно совещание дольше полутора часов (мы все достаточно быстро устаем);
• начинайте совещание с утверждения проблемы, которую вы пытаетесь решить или сценария / результата, к которым вы стремитесь;
• разделите совещание на 3 /4 /5 секций;
• делайте секции достаточно короткими (в идеале 15-20 минут);
• определите человека (или несколько) специально для записи идей (используйте заметки на Whiteboard’е, клейкие заметки (post-it), большие листы бумаги);
• начните совещание с секции общего обсуждения и используйте последующие секции для детального обсуждения наиболее сильных идей;
• постарайтесь завершить первую секцию с небольшим количеством специфичных идей или тем, которые, по мнению группы, являются лучшими кандидатами для развития;
• всегда описывайте результаты совещания и рассылайте участникам;
• не делайте совещание более сложным, чем описано выше.

Перевод статьи из блога Ask Good Product Manager.
Ссылка на статью: http://ask.goodproductmanager.com/2008/11/03/how-can-you-listen-to-the-market-with-limited-resources/

——перевод——↓

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

Как при сокращении бюджетов в трудные времена прислушиваться к клиентам? Какие существуют хорошие практики получения удаленной (remote) обратной связи от пользователей?

Ответ Pail Young (Product Beautiful): Когда бюджеты сокращаются, управление продуктом не является исключением. Будет меньше возможностей путешествовать, что означает меньше возможностей непосредственного общения с клиентами. Внимательно следить за рынком еще более важно во времена экономии, потому что клиенты имеют меньше желания тратиться на ваши решения, и те функции, которые были добавлены в продукт, становятся большим, нежели просто трата ресурсов, они могут быть опасны для вашего продукта и сущестования компании! К счастью, несложно найти очень дешевые способы для поддержания связи с рынком, для этого требуются лишь работа и терпение.

Если вы хотите лишь обратную связь о существующем продукте, существуют дешевые / бесплатные решения, такие как GoToMeeting и WebEx, которые позволяют вам проводить вебинары и демонстрации. Вы можете использовать Google Ads, электронные книги или справочные документы (White Paper) для привлечения заинтересованной аудитории. Вы также можете поработать с существующей клиентской базой. У вас всегда есть 10 любимых пользователей, к которыми мы обращаемся за обратной связью; обращайтесь с ними хорошо и они будут к вам благосклонны. Уделите им дополнительное внимание, показывайте им beta-версии, получайте обратную связь от них и используйте их как раннее оповещение о том, что следует изучить на рынке. Просто помните, что они, как ваши клиенты, склонны давать обратную связь сквозь линзу продукта, который они покупают у вас: «Я хочу кнопку на этом экране» или «Я хочу функцию Х». Если вы будете ориентироваться только на ваших собственных клиентов, вы рискуете потерять тренды на рынке. Вы должны говорить с целевыми клиентами.

В зависимости от типа продукта или услуги, которыми вы управляете, спрсите себя – где я могу найти своих целевых клиентов? Если вы продаете потребительские товары, вы можете спуститься в местную бакалейную лавку и увидеть клиентов собственными глазами. Если вы продаете ИТ руководителям или CIO, задача будет сложнее – не существует бакалейной лавки, где вы можете наблюдать этих людей… или существует? Я недавно написал пост в блоге Product Beautiful о том, как можно использовать социальные сети для связи с вашими клиентами. Существуют миллионы блогов и некоторые ведутся вашими целевыми клиентами. Существует масса людей в LinkedIn, Facebook, Twitter и других социальных сетях, в которых они указывают информацию о себе и своих интересах и вам доступна эта информация. Погуглите по ключевым словам, которые ваши потребители могут использовать, и используйте мою инструкцию о том, как связяться с ними по email, это почти бесплатно: стоит для вас только несколько минут вашего времени и может свести вас со значимыми людьми, которым будет интересно пообщаться.

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

Перевод статьи из блога Ask Good Product manager.
Ссылка на статью:

http://ask.goodproductmanager.com/2008/09/17/what-is-the-best-way-to-manage-feature-requests/

——перевод——↓

Вопрос: Какой лучший способ для менеджера продукта управлять запросами на добавление новых фич и улучшения?

У нас есть тонны советов, как улучшить наш продукт. Некоторые из этих идей разумны, некоторые – не очень. На данный момент, у нас нет способа управления этими идеями. Должны ли мы отбросить те идеи, которые кажутся нам негодными или мы должны их фиксировать и как-либо использовать? И если мы будем фиксировать их, то как предохранить себя от того, чтобы быть заваленными ими? Еще важнее, как мы можем наилучшим образом использовать эту информацию от пользователей и в то же время не тратить все наше время отвечая на запросы на изменения.

Ответ Roger Cauvin (http://cauvin.blogspot.com): существуют два аспекта данного вопроса.

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

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

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

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