Software Product Management Russia

Дано

• продуктовая компания;
• вы руководите отделом управления продуктами;
• у вас портфель из k продуктов;
• в компанию каждый промежуток времени t поступают n идей реализации новых продуктов, изменения функциональности старых продуктов, выхода на новые рынки, продуктизации кастомных разработок и т.д.

Задача

Как выбирать «правильные» идеи и проекты, чтобы не тратить деньги впустую и развивать портфель продуктов?

Рассуждение

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

Вариант ответа – Stage-Gate process

В далеком 1985 году Robert G. Cooper придумал Stage-Gate process – фреймворк для отбора новых идей и проектов. В дальнейшем этот фреймворк был доработан им совместно с Scott Edgett. Они также создали консалтинговую компанию Stage-Gate International (+ Product Development Institiute) и успешно внедряют свою разработку во многие компании (оцените список клиентов).

Общая схема Stage-Gate process:

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

Решение в каждой точке принимается группой лиц, у которой есть полномочия принять данное решение. Само решение принято называть go-kill decision.

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

Материалы по теме:

• английская Википедия
• «библия» stage-gate process: Winning at New Products
• Stage-Gate International
• Product Development Institiute

Если вам интересна данная тема, я готов подробнее описать каждую из стадий. Дайте знать в комментариях.

Если есть вопросы, которые, на ваш взгляд, требуют коллективного мозгового штурма, их можно задать в форуме в разделе «Стратегия» или «Управление требованиями» на ваше усмотрение. Я также попробую на них ответить там.

Перевод статьи из блога tynerblain.com (Scott Sehlhorst).

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

http://tynerblain.com/blog/2009/02/02/user-stories-and-use-cases/

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

User Stories – один из ключевых Agile артефактов, который позволяет командам разработчиков создавать наиболее важные возможности системы в первую очередь. Они отличаются от Use Cases по ряду значительных причин, но у них есть гораздо больше общего, чем вы можете подумать.

User Stories на практике

Майк Кон написал книгу User Stories Applied: For Agile Software Development. Это книга о том, как писать, оценивать и использовать User Stories. Если вы думаете о том, чтобы попробовать Agile в первый раз и не читали эту книгу, то вам необходимо это сделать. Автор очень подробно и с забавными историями рассказывает о том, как писать, управлять и использовать User Stories.

Что такое User Stories?

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

User Story пишется в формате

• Как [человек в определенной роли] я хочу [выполнить некоторое действие], чтобы [некоторая цель была достигнута] 

Вот и все. Ничего больше. Совершенно атомизированно, очень кратко и недвусмысленно. Откуда эта элегантная идея появилась?

User-Centered Design (UCD, пользовательско-ориентированный дизайн) – это подход к дизайну продуктов, который также может рассматриваться как философия. В колледже у меня была привычка говорить, что индустриальные дизайнеры проектируют вещи «снаружи внутрь» (from the outside in), а инженеры проектируют вещи «изнутри наружу» (from the inside out). Идеальные продукты – это такие продукты, в которых соединены форма (то, что снаружи) и функции (то, что внутри) в виде элегантного решения, в котором размывается разделяющая форму и функцию граница. Первые дизайнеры инженерных продуктов были инженерами, а первыми дизайнерами программного обеспечения были программисты – только они знали, что может быть сделано. Любой, кто использовал приложение с интерфейсом, созданным специалистам по базам данных, помнит, что оно из себя представляло. В итоге, кто-то успешно адаптировал образ мыслей проектирования продукта, основанный на том, что кто-то может использовать его, чтобы что-то сделать вместо того, чтобы смотреть на то, что оно умеет делать и пытаться понять, как его использовать. Это подчеркивает важность UCD, ну вы поняли идею.

Из подхода UCD следует много выводов, которые реально определяют то, как мы создаем продукты сегодня. Kessler и Sweitzer сфокусировались на понимании этих целей пользователей в книге Outside-In Software Development. Цели стейкхолдеров задают требования (возможно, это и есть требования). Но тяжело создавать практические планы из целей. Вам необходимо что-то, чтобы преодолеть этот разрыв.

User Story в Agile процессе преодолевает этот разрыв.  В мире структурированных требований Вигерса, этот разрыв покрывается с помощью Use Cases.

Концептуально User Story преодолевает ту же пропасть, что и Use Case. User Story определяет, что люди должны сделать (например, более быстрое осуществление звонков) для того, чтобы достигнуть целей компании (например, снизить затраты на кол-центр), с определенным подходом к решению (написать программное обеспечение вместо того, чтобы использовать дешевых сотрудников в кол-центре).

Сейчас мы находимся в запутанной ситуации: у нас есть User Srories, Use Case Scenarios и по крайней мере три различных типа Use Cases – формальные и неформальные Use Cases и Use Case Briefs. В чем они отличаются друг от друга и в чем они схожи?

Описание использования системы

Use Cases, Use Case Scenarios и User Stories представляют собой документированное описание того, как продукт будет использован. Они могут быть отображены на одной прямой в зависимости от затрат, необходимых для их создания.

• Формальные Use Cases требуют максимальных усилий. Их написание сопровождается соблюдением определенных «церемоний», но они описывают все варианты того, как какой-либо человек будет выполнять некоторые действия (или их вариации);
• Неформальные Use Cases - по сути то же самое, только они менее формальны. Задача состоит в том, чтобы предоставить правильный уровень детализации и не прийти к формальным Use Cases;
• У Use Case Briefs нет практически никаких дополнительных затрат, но здесь также присутствует проблема «какой уровень детализации необходим», как и в случае неформальных Uses Cases, только она в этом случае более актуальна;
• User Stories имеют минимальные затраты и предоставляют минимальный контекст.

Use Case Scenarios несколько из другого рода. Как и User Story, Use Case Scenario описывает один путь в Use Case с несколькими путями. Но вы не можете (по крайней мере, я никогда не видел, чтобы кто-то делал это) создавать Use Case Scenario без предварительного создания формальных Use Cases. Этот артефакт сочетает слабость формальных Use Cases (высокая документированность) со слабостью User Stories (ограниченный контекст). Они могут быть очень удобны для разработки Test Cases, если ваша команда тестирования не очень хороша в написании Test Cases. Мы не будем рассматривать Use Case Scenarios в дальнейшей дискуссии.

Высокая документированность с соответствующими издержками несет определенное преимущество – возросшую детализированность.

Т.к. User Story описывает один путь в Use Case, при меньшей затратности она включает также и меньше деталей. Это нормально, т.к. Agile ставит коммуникацию выше исчерпывающей документации. Вы попадете в ситуацию неэффективности, когда объем обсуждений (особенно повторяющихся) станет обременительным. Необходимый объем обсуждений задается как функция от количества знаний о предметной области или контекстов, которые уже были выявлены командой разработчиков.

Мне стоит использовать User Stories или Use Cases?

Это зависит от вашей аудитории. Формальные и неформальные Use Cases помимо того, что более затратны в реализации, также предоставляют больше контекста и позволяют вам описать более сложные варианты использования вашего продукта. Некоторые пользователи настолько сложны, что вам необходимо использовать Use Cases для их описания. Некоторые настолько просты, что что-либо сложнее User Story является бесполезной тратой усилий. Интерпретация того, что является сложным, а что простым, тем не менее, не является просто оценкой того, что пользователи хотят делать, она также зависит от уровня владения предметной областью вашей командой разработчиков.

Некоторые команды просто не готовы к восприятию User Stories и Use Case Briefs. Вы должны писать ваши требования для читателей, поэтому вы должны знать, когда у людей возникают проблемы с реализацией решений, основанных на User Stories или Use Case Briefs и предоставить им больше структуры и формализованности. Вы должны адаптироваться к реалиям вашей текущей ситуации и опыта вашей команды.

Вы можете заменить слова «компетентность читателя в предметной области» (Reader Domain Expertise) на слова «уровень доверия к команде», если хотите, и диаграмма будет выглядеть примерно так же. Это другая концепция, которая критична для того, чтобы команда работала эффективно: уровень доверия приравнивается к уровню делегирования.

Если вы доверяете своей команде создать решение, которое будет соответствовать User Story, делегируйте этот «следующий уровень детализации» им. Если вы не доверяете им, тогда не стоит этого делать. Но вы должны. Одно из преимуществ Agile состоит в том, что ваша команда быстро предоставит вам решение и вы сможете дать им обратную связь. Если они не предоставят вам решение, которое было бы отражением потребностей пользователей, предоставьте им обратную связь и они изменят его. Agile процесс фактически основан на этой возможности сохранять эффектинвость «немногословных» артефактов. Кто-то из команды в общих чертах опишет, как будет выглядеть решение и получит обратную связь до начала реализации. Чем больше будет такого взаимодействия, тем более эффективной будет легковесная документация.

Заключение 

Не надейтесь на банальное описание User Stories и Use Cases. Понимайте природу различных артефактов. Думайте об их сильных и слабых сторонах. Рассмотрите, как вы взаимодействуете со своей командой. Должны ли вы доверять вашей команде? Доверяете ли вы вашей команде? Определите, что им нужно и дайте им это.

Перевод статьи из блога http://www.accompa.com/product-management-blog (Michael Shrivathsan).

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

http://www.accompa.com/product-management-blog/2009/07/13/features-vs-requirements-requirements-management-basics/

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

Вопрос, который чаще других возникает в последнее время в моих дискуссиях:

В чем разница между требованиями и функциями (features)?

Позвольте попробовать объяснить эту разницу в данном коротком посте.

Что такое требование?

В одной из моих любимых книг по требованиям, «Разработка требований к программному обеспечению» Карла Вигерса, требование определено следующим образом:

Формулировка потребности или цели, или условия или возможности, которым продукт должен соответствовать для удовлетворения этой потребности или цели.

В другой любимой мной книге, “Mastering the Requirements Process” Suzanne & James Robertson, требование определено следующим образом:

Требование – это то, что продукт должен делать или качество, которым он должен обладать.

Оба определения прекрасны. Принимая их во внимание, я бы определил требование следующим образом:

Требование – это возможность, которой должен обладать продукт или что-то, что продукт должен делать для удовлетворения потребностей потребителя.

Требования, как правило, достаточно подробные и обычно пишутся имея в виду реализацию. Те, кто «потребляет» требования обычно являются разработчиками или техническими специалистами.

Что же тогда есть функция?

Обращаясь опять же к указанным выше книгам, я бы определил функцию следующим образом:

Функция – это набор взаимосвязанных требований, которые позволяют пользователю достичь бизнес-цели или удовлетворить бизнес-потребность.

Функция является объектом более высокоуровневым, нежели требование и чаще сфокусировано на бизнес потребности нежели чем на реализации.

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

Пример

Вы находите эти определения несколько туманными? Рассмотрим пример, который даст вам более реальное представление. Представим, что вы проектируете онлайн-магазин книг, чтобы конкурировать с Amazon.

Для данного проекта вот пример функции:

• заказ за один шаг

Вот несколько требований, связанных с этой функцией:

• пользователь должен иметь возможность включить функцию заказа за один шаг в своем аккаунте;
• пользователь должен иметь возможность выключить функцию заказа за один шаг в своем аккаунте;
• пользователь должен иметь возможность заказать книги всего за один шаг;
• …
• пользователь должен иметь возможность отменить заказ в течение 30 минут после осуществления заказа.

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

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

Перевод статьи из блога 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 и других моделей, таких как «диаграммы процессов», «диаграммы состояний» и т.д. Также мы тесно работали с пользователями для выявления требований. Итак, мы попросили подтвердить, что к данному моменту времени не пропущено никаких серьезных требований, о которых они знают, и нет никаких значительных вопросов, которые не были сформулированы, о которых они знают. Суть в том, что они видели требования, участвуют в процессе и разработка прототипа не отклониться слишком далеко от необходимого. Но по-прежнему они имеют право добавить что-то новое после того, как увидят систему, подумают об этом или что-то в этом роде.

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

Посмотрел короткое видео по приоритизации требований на основе оценки соотношения ценности и сложности:

и подумал, что можно прикрутить к теме приоритизации требований теорию оптимального портфеля Марковица (это из финансов).

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

Если же отобразить, как и показано на видео, требования в осях «ценность» и «затраты» (использую вместо «сложность»), то можно не ограничиваться разделением на 4 квадранта, а также построить эффективную границу.

Для начала, просто отобразим требования в осях «ценность» и «затраты»:

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

Идея в том, что мы можем «вычеркнуть» заведомо невыгодные требования, такие как B. Отметим их красным цветом. Оставшиеся требования и составляют эффективную границу. Они лучше, чем красные и «не хуже», чем другие белые.

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

Для продукта с приоритетом требований на затратами необходимо начать с требования C (зеленая кривая), для продукта с приоритетом затрат над требованиями необходимо начать с сами-видите-какого требования (оранжевая кривая).

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

Перевод статьи 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), большие листы бумаги);
• начните совещание с секции общего обсуждения и используйте последующие секции для детального обсуждения наиболее сильных идей;
• постарайтесь завершить первую секцию с небольшим количеством специфичных идей или тем, которые, по мнению группы, являются лучшими кандидатами для развития;
• всегда описывайте результаты совещания и рассылайте участникам;
• не делайте совещание более сложным, чем описано выше.

Метод приоритизации требований от Joel Spolsky (joelonsoftware.com) в редакции английской Википедии (http://en.wikipedia.org/wiki/Software_product_management).

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

• определите, чье мнение вы будете выяснять;
• создайте список всех требований;
• рассчитайте необходимые затраты (в днях или деньгах) для каждого требования. Оценка может быть очень приблизительной;
• подсчитайте общие затраты E;
• предоставьте участникам опроса бюджет в размере 0,5E каждому. Пусть они распределят его между требованиями таким образом, как им хочется, включая возможность определения всего бюджета на одно требование. Не показывайте им свои оценки отдельных требований, это может повлиять на их решение;
• проранжируйте все требования по соотношению голосов к оценкам затрат;
• реализуйте столько требований, сколько вам позволит бюджет, соблюдая последовательность.

Перевод статьи из блога 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): существуют два аспекта данного вопроса.

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

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

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

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