Software Product Management Russia

Пора учиться: NPDP и CSPO

Bredyuk — Fri, 20 Aug 2010 14:45:23 +0000

New Product Development Professional (NPDP)

Разработчик сертификации – Product Development and Management Association (http://pdma.org)
Тест Multiple Choice (один вариант из четырех) на Английском языке
200 вопросов за 3, 5 часа
Можно сдавать в Москве (http://prometric.com)

Я вчера сдал))
Покупал Study Guide от Product Innovation Educators за $359 (http://productinnovationeducators.com). Круть.
Всего готовился пару месяцев в ненапряженном режиме (по вечерам и в метро книжку читал)
Сложно? Зависит от вашей подготовки. Расскажите про ваши знания и опыт и я расскажу, насколько тяжело будет подготовиться

Certified Scrum Product Owner (CSPO)

Проводит Scrum Alliance (http://scrumalliance.org)
В ближайшее время будет аж 2 возможности пройти: в Питере (9-10 сентбря) и Киеве (6-7 октября)
Я поеду в Питер)) Присоединяйтесь!

Презентация доклада на ЛАФ-2010

Bredyuk — Sun, 11 Jul 2010 16:37:34 +0000

Презентация моего доклада «Специфика управления требованиями в разработке корпоративных коробочных решений» на ЛАФ-2010:

Требования к корпоративным коробкам

View more presentations from Konstantin Bredyuk.

Компетенции менеджера продуктов

Bredyuk — Sun, 23 May 2010 15:20:55 +0000

Gopal Shenoy (Product Management Tips) предлагает простую таблицу для оценки собственных компетенций как менеджера программных продуктов.

В заполненном виде она может выглядеть следующим образом:

Сделал в виде гуглодока для удобства читателей:

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

А вам эта таблица понравилась?

Фреймворк для маркетинга продукта от Rocket Watcher

Bredyuk — Wed, 19 May 2010 13:19:15 +0000

April Dunford (Rocket Watcher) опубликовала свой фреймворк для маркетинга продуктов.

Совсем тепленький: с момента публикации не прошло и получаса

Подробности тут.

Менеджер продукта и продажи

Bredyuk — Wed, 12 May 2010 16:06:33 +0000

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

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

Вопросы:

Каким образом вы взаимодействуете с отделом продаж?
Входят ли в обязанности Product Manager собственно продажи, контроль продаж (на каком уровне)?
Имеет ли смысл разделять продажника и Product Manager-а или есть возможность объединения ролей при небольшом объеме продаж?
Product Manager сам (вы, например) занимается продвижением продукта на рынок? Т.е. какова ваша функция как Product Manager в продвижении продукта?

Мои соображения:

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

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

Мы имеем здесь две крайние точки по функциональной загруженности менеджера продукта: а) полный контроль всех функциональных процессов по созданию продукта б) выполнение специфической функции управления продуктом, и минимальное вмешательство в другие функции (см. lightweighted и heavyweighted product management).

Нет универсального правильного ответа на вопрос о том, что выбрать в конкретном случае. Ответ зависит от размера компании, структуры компании, специфики рынка, роли конкретного менеджера продуктов (Junior, Senior, VP of PM).

Например, в Pragmatic Marketing Framework описываются вот такие функции Product Management, связанные с sales:

Sales Process. Align your organisation’s selling process to the buying process, describing the key personas’ information needs for each step in the process
Sales Tools. Create tools for salespeople focused on a specific step of the selling process
Channel Support. Provide on-going support for the sales channel. Look for opportunities to make support more repeatable

Эти вещи нужны для успеха продукта. Но должен ли этим в вашей компании заниматься именно менеджер продуктов?

Мои ответы:

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

Треугольник управления продуктом

Bredyuk — Thu, 29 Apr 2010 13:09:56 +0000

В процессе подготовки к докладу на Software People 2010 мы с Дмитрием Безуглым придумали треугольник управления продуктом по аналогии с треугольником управления проектом.

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

Мы дополняем треугольник управления проектом тремя внешними силами, которые определяют проект: потребители, конкуренты, технологии.

Предназначается для наглядного описания отличия проекта от продукта.

Комментарии приветствуются.

P.S. English версия для забугровых коллег, которые почитывют этот блог.

Geoffrey Moore о стратегии

Bredyuk — Tue, 27 Apr 2010 20:50:10 +0000

Geoffrey Moore на конференции Business of Software 2009 говорит о стратегии софтверных компаний.

Moor – живой классик, автор Crossing the Chasm.

Очень понятно и интересно рассказывает.

Презентация Дениса Бугрова про управление продуктами

Bredyuk — Mon, 26 Apr 2010 20:48:54 +0000

Презентация Дениса Бугрова (QuattroLab) на RitConf про управление продуктами. Интересный взгляд на процесс, стоит ознакомиться.

Что приятно, была использована наша Горбатая диаграмма с некоторыми доработками.

Хроники окопной войны

View more presentations from guest885f085.

Презентация про управление продуктами

Bredyuk — Sun, 25 Apr 2010 20:21:06 +0000

Отличная презентация про управление продуктами от Максима Яшунина (Spirit DSP):

Стратегия по Портеру

Bredyuk — Sun, 25 Apr 2010 16:50:24 +0000

Майкл Портер – классик в области стратегии. Пять конкурентных сил Портера – один из базовых инструментов стратегического анализа.

Сергей Котырев из Umisoft сделал на Ritconf 2010 доклад «Конкурентные стратегии проекта или продукта» как раз по Портеру. Ниже презентация. Рекомендуется как введение в стратегию по Портеру.

Kotyrev@Rit

View more presentations from rit2010.

Доклад на Software People 2010

Bredyuk — Fri, 23 Apr 2010 14:33:35 +0000

Презентация нашего с Дмитрием Безуглым доклада на Software People 2010 «Кто такой менеджер продукта и что он может дать компании разработчику?».

Software people. Кто такой менеджер продукта

View more presentations from Konstantin Bredyuk.

Agile PM от Quantum Whisper

Bredyuk — Fri, 23 Apr 2010 04:16:56 +0000

Понравилась картинка, демонстрирующая применение Agile подхода в управлении продуктами:

Взято отсюда: http://blogs.forrester.com/tom_grant/10-04-22-agile_poses_boss_level_pm_challenge

А придумано товарищами из Quantum Whisper – небольшой компании, которая делает тул для Product Manager’ов, работающих по Agile.

Duct и Ject

Bredyuk — Tue, 13 Apr 2010 23:07:30 +0000

Брейнстормим с Дмитрием Безуглым в кафе доклад на Software People 2010 про управление продуктами. Все время возникают сравнения управления продуктами с управлением проектами, менеджера продуктов и менеджера проектов. Проблема в том, что на бумаге они сокращаются одинаково: ПМ, PM или PrMng))

Если начала одинаковые, то надо различать по окончанию. Отныне:

То, что относится к управлению продуктами, – это Duct.

А к управлению проектами – Ject.

Стратегическая роль управления продуктами

Bredyuk — Thu, 11 Mar 2010 15:53:24 +0000

Продолжаем разбираться с базовыми вопросами управления продуктами. Хочу поделиться с вами презентацией (in English) от компании Pragmatic Marketing, разработчика самого известного фреймворка управления продуктами и вообще признанного thought-лидера в области управления продуктами.

Презентация главным образом отвечает на вопрос «Зачем в компании нужен Product Management».

Strategic Role Product Management

View more presentations from Software Product Managemen Russia.

Вторая встреча. Интересные вопросы

Bredyuk — Thu, 11 Mar 2010 15:20:42 +0000

Мы понемногу расширяем off-line деятельности нашего сообщества. Вчера была очередная небольшая встреча. Были Дмитрий, Андрей и я. Обсудили много интересных, основополагающих вопросов, связанных с управлением продуктами:

с какого момента компании целесообразно выделять управление продуктами как отдельный вид деятельности и, соответственно, роль менеджера продуктов
во всех ли отраслях управление продуктами одинаково актуально. Мы заметили, например, что в телекоме почему-то роль менеджера продуктов более распространена, чем в других отраслях. Чем это может быть вызвано? Рассмотрели также маппинг на кино-индустрию: режиссеров, продюсеров)
как разделять сферы ответственности руководителя проектов и менеджера продуктов
в чем value введения управления продуктами для топ-менеджмента компании. Как объяснить, что управление продуктом – это не то же самое, что управление проектом и менеджеры продуктов нужны в компании
почему нельзя назвать создание продукта «специальным видом проекта» и управлять им с помощью методик управления проектами (PmBOK) и т.д.

Брейнсторминг получился достаточно интересный. Надеюсь, из него получатся результаты в виде содержательных постов.

Возможно, сделаем в обозримом будущем более представительную встречу. Для этого нам, наверное, надо будет немного доработать формат: ввести роль докладчика. Брейнстормить в свободном полете при большом количестве участников неэффективно))

Презентация «Введение в управление программными продуктами» v1

Bredyuk — Sun, 07 Mar 2010 02:47:29 +0000

Я подготовил презентацию «Введение в управление программными продуктами» версии 1. Буду ее рассказывать в рамках педагогической практики на отделении программной инженерии ВШЭ.

Введение в управление программными продуктами v1

View more presentations from Konstantin Bredyuk.

Комментарии приветствуются. До самой презентации планирую сделать еще пару версий. Надеюсь на ваши замечания))

Кстати, если есть желание, приходите послушать. Это, наверное, где-то в апреле будет. Пообщаемся.

Горбатая диаграмма 2

Bredyuk — Sat, 06 Mar 2010 16:10:28 +0000

Я немного обновил модель с описанием активности различных процессов по фазам жизненного цикла программного продукта. Так называемая «горабатая диаграмма» (hump diagram).

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

Спасибо Андрею Вербицкому, Дмитрию Безуглому, Анатолию Левенчуку за комментарии к предыдущей версии.

Управление продуктовыми линейками от SEI

Bredyuk — Fri, 05 Mar 2010 00:02:43 +0000

Многие хоть раз слышали про модель CMMI. Ее разработал известнейший центр исследований в области программной инженерии Software Engineering Institute, подразделение Carnegie-Mellon University.

Так вот этот же SEI ведет разработки в области Software Product Lines, т.е. линеек программных продуктов.

В рамках этих работ был создан Framework for Software Product Lines Practice.

Также была издана книга Software Product Lines, которая написана по результатам этой исследовательской программы.

Вот как описывают линейки программных продуктов в SEI:

A software product line (SPL) is a set of software-intensive systems that share a common, managed set of features satisfying the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way.

Software product lines are emerging as a viable and important development paradigm allowing companies to realize order-of-magnitude improvements in time to market, cost, productivity, quality, and other business drivers. Software product line engineering can also enable rapid market entry and flexible response, and provide a capability for mass customization.

А вот как выглядит процесс разработки продуктов:

Я начал читать основной текст их фреймворка, достаточно интересно.

Пример простой финансовой модели: vmestedeshevle.ru

Bredyuk — Thu, 04 Mar 2010 23:17:50 +0000

Я попробовал рассчитать, сколько теоретически может приносить http://vmestedeshevle.ru, когда выйдет на «проектную мощность». Делюсь результатами. Хочу сразу оговорить предположения, при которых строилась модель:

Задача модели – оценить чистую прибыль в момент, когда проект выйдет на «проектную мощность» и займет свою долю рынка
Не учитываем динамику развития, не будем считать окупаемость
Данные о количестве продаж брались «из воздуха», т.к. других данных у меня нет
Учитывались всего два типа затрат (оба постоянные): аренда и заработная плата. Предполагается, что доработка системы, продвижение, реклама и т.п. включаются в з.п.
Все товары разбиты на 5 ценовых категорий, которым соответствуют такие параметры как «количество экземпляров в лоте», «доход с экземпляра», «количество проданных лотов»
Предполагается, что нет доставки
И другие предположения

Можете поиграться параметрами в гуглодоке (зеленое можно редактировать, синее пересчитается само, красным – главный результат).

Вывод: модель, конечно, достаточно груба, но результаты говорят о том, что можно продолжить исследование))

Российские продуктовые компании – вендоры ПО

Bredyuk — Thu, 04 Mar 2010 12:54:25 +0000

Давно меня (и не только меня) интересует вопрос: а много ли в России более-менее крупных продуктовых софтверных компаний, т.е. вендоров ПО. Ответ на этот вопрос позволяет понять, в том числе, насколько актуальна в РФ дисциплина «Управление программными продуктами».

Сделаем следующее допущение: под российскими вендорами будем понимать те компании, управление продуктами которых осуществляется в РФ. То есть компания, зарегистрированная где-то в оффшоре, но продуктовая команда которой по факту работает в РФ, будет считаться российским вендором. Размер компании: более 50 человек.

Я начну список:

Дополняйте список в комментариях! Я внесу в основной.

UPD. Вынес Интернет-компании в отдельный список

UPD. У нас много вендоров, оказывается))

Product Management vs. Project Management

Bredyuk — Wed, 03 Mar 2010 15:05:15 +0000

Подборка наиболее интересных англоязычных статей по теме «Product Management vs. Projects Management«:

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

Управление проектом – это про то, как сделать какую-то работу в срок и в пределах бюджета. Постановка задачи примерно такая: «сделайте систему X за M дней и D денег».

Управление продуктом – это про то, как сделать работающий продукт «от и до», включая маркетинговые исследования, рекламу, продажи и т.д. Постановка задачи примерно такая: «хочу заниматься продажей софта. Сделайте что-нибудь такое, что клиенты будут покупать».

Некоторые тезисы из различных статей:

Жизненный цикл проекта и жизненный цикл продукта различны
Продукты создаются в рамках проектов
Как каждый продукт требует менеджера продуктов, также и каждый проект требует менеджера проектов
Если в компании нет менеджеров продуктов, то его работу выполняют другие отделы
Требуемые навыки менеджера продуктов и менеджера проектов различны
Управление продуктом – о том, что делать; управление проектом – о том, как делать

А вы что думаете по этому поводу?

О чем вы хотите прочитать в этом блоге?

Bredyuk — Sat, 27 Feb 2010 16:32:34 +0000

Хотите, чтобы в этом блоге появился пост на интересующую вас тему? Оставляйте свои пожелания в этой форме:

Loading…

Все пожелания будут рассмотрены! В будущем форма будет жить здесь: http://swpm.ru/backlog/

Курс по Software Product Management

Bredyuk — Thu, 25 Feb 2010 14:27:19 +0000

Suhas Kelkar разработал и читает курс по Software Product Management для идийского Symbiosys Center for Information Technology. У курса есть страничка в интернете, на которой есть презентации 4-ех лекций (PowerPoint -> PDF). Очень даже интересный курс.

И еще один Product Management Framework

Bredyuk — Fri, 19 Feb 2010 15:04:42 +0000

+1 к нашей коллекции фреймворков управления продуктами.

Нашел здесь: http://grandview.rymatech.com/index.php

Кстати, у них огромная коллекция вебинаров по управлению продуктами и смежным темам:

http://grandview.rymatech.com/pmv/webinars/

Видео про процесс создания новых продуктов

Bredyuk — Fri, 19 Feb 2010 14:55:33 +0000

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

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

Что вам показалось интересным в этих роликах?

Запуск нового продукта / нового релиза

Bredyuk — Fri, 05 Feb 2010 12:08:45 +0000

David Daniels из Pragmatic Marketing специализируется на такой интересной теме как Запуск продуктов (Product Launch). Что же может быть интересного в этой теме, можете спросить вы, если продукт уже готов и нужно лишь «просто начать его продавать»?

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

«разогнать» продажи (create sales velocity)
повысить информированность и заинтересованность, что станет началом диалога
создать инструменты для потенциальных клиентов, которые помогут им пройти «цикл покупки»
предоставить sales команде правильную информацию в правильное время, чтобы, чтобы помочь потребителям сконфигурировать решение под их нужды

Смотрите подробности в презентации:

Product Launch Doomed

View more presentations from swpm.

Вот, например, checklist для запуска продукта из этой презентации:

А как вы запускаете новые продукты / релизы?

Что должен знать менеджер продуктов?

Bredyuk — Fri, 29 Jan 2010 13:17:45 +0000

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

Ранее в этом блоге мы уже частично затрагивали эту тему:

Вот ответ на этот вопрос от Michael в примечательной статье «Семь навыков успешного менеджера продуктов» (в моем переводе): http://swpm.ru/2009/06/seven-traits-of-successful-product-managers/
В предыдущем посте есть интересная диаграмма, отражающая активности действующих менеджеров продуктов по определенным областям / дисциплинам: http://swpm.ru/2010/01/product-management-survey-2009-2010/ Можно сказать, что для того, чтобы быть успешным менеджером продуктов, нужно хорошо разбираться в этих областях

Сегодня я хочу с вами поделиться взглядом Product Development and Management Association (PDMA) на этот вопрос. Эта ассоциация (членом которой я являюсь) проводит сертификацию на статус New Product Development Professional (которую я буду проходить в мае). Для того, чтобы сертифицироваться, нужно сдать экзамен. Состав экзамена нас и интересует. Вот он:

Ваше мнение? Какими знаниями / навыками должен обладать менеджер продуктов?

Сообщество менеджеров программных продуктов

Bredyuk — Thu, 28 Jan 2010 15:30:56 +0000

В прошлый четверг состоялась встреча, которую, как мы надеемся, можно будет считать первой встречей «Сообщества менеджеров программных продуктов». Есть несколько вещей, на которые я хотел бы обратить ваше внимание:

мы планируем проводить off-line встречи на более-менее регулярной основе. На встречах возможны доклады / презентации, с, конечно же, последующим обсуждением. Готовы рассмотреть ваши предложения по темам обсуждения;
теперь swpm.ru – это не мой профессиональный блог, а коллективный блог сообщества менеджеров программных продуктов;
LinkedIn группа «Software Product Management Russia» ассоциирована с данным сообществом и предназначена для установления профессиональных контактов между членами сообщества (вступить может любой);
устав сообщества находится в процессе разработки.

Присоединяйтесь!

Результаты исследования «Product Management and Marketing Survey»

Bredyuk — Thu, 28 Jan 2010 14:10:02 +0000

Компания Pragmatic Marketing опубликовала результаты ежегодного исследования «Product Management and Marketing Survey 2009 – 2010″: http://www.pragmaticmarketing.com/publications/survey/2009

Некоторые интересные моменты:

Профиль менеджера продуктов

средний возраст – 37 лет
отвечает за три продукта и работает в отделе из 6 человек
87% частично или полностью «технари»
32% женщин и 68% мужчин
95% закончили college (не уверен в РФ аналоге, скорее всего – ВО), 41% – магистерские программы

… подробности в исследовании

Очень интересная диаграмма, отражающая активность менеджеров продуктов по отдельным областям / дисциплинам (основана на Pragmatic Marketing Framework):

——

Раннее я переводил частично исследование 2008 года: http://swpm.ru/2009/07/survey-product-management-marketing/

Еще один Product Management Framework

Bredyuk — Wed, 13 Jan 2010 17:44:14 +0000

Натолкнулся на очередной Product Management Framework. Их уже вполне можно коллекционировать см. категорию Фреймворки в этом блоге.

http://www.stsc.hill.af.mil/CrossTalk/2009/01/0901Ebert.html

Оргвопросы: LinkedIn, встреча, ваши посты

Bredyuk — Tue, 12 Jan 2010 17:45:47 +0000

Есть три важных сообщения / предложения:

в LinkedIn есть группа Software Product Management Russia. Там мы собираем всех заинтересованных в предмете людей: практикующих менеджеров продуктов, тех, кто хотят ими стать, академических исследователей и т.д. Там же планируются различные интересные дискуссии по теме. Всех приглашаю присоединиться!
Помимо on-line общения есть идея встретиться offline. Обсудить product management – related вопросы, обменяться контактами и т.д. Принимаются предложения по темам обсуждения, формату проведения.
Я готов поделиться площадкой и предоставить вам возможность писать посты по темам, связанным с управлением программными продуктами в этом блоге. То есть я хочу попробовать сделать из swpm.ru коллективный блог.

Ответы / вопросы / предложения принимаются в виде комментов к этому посту и по почте: bredyuk@gmail.com

Спасибо!

Семинар «Разработка концепции ПО» от UML2

Bredyuk — Thu, 19 Nov 2009 21:37:57 +0000

Концепция – один из важнейших документов при создании программных продуктов. 26 ноября Векленко Ирина и Сурова Ирина проводят семинар на тему «Разработка концепции ПО»:

26 Ноя	Разработка Концепции ПО CustIS Чт, 26 Ноября 2009 в 19:00

SPEM модель управления программными продуктами

Bredyuk — Fri, 13 Nov 2009 14:21:08 +0000

Мы разрабатываем SPEM (Wiki, Specification) модель управления программными продуктами. Планируем описать все активности, роли, артефакты.

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

По горизонтали отображены дисциплины, которые присутствуют в процессе разработки программного продукта:

Стратегия. Стратегический анализ, выработка направления развития
Управление требованиями. Сбор, анализ, генерация, приоритезация требований
Разработка. Кодирование, тестирование, документирование
Маркетинг продукта. Общение с рынком, подготовка материалов, презентаций, проведение конференций и т.п.
Финансовый анализ. Оценка рынка, прогноз будущих продаж, анализ успешности продуктов
Поддержка. Техническая поддержка

По вертикали отображены фазы жизненного цикла программного продукта:

Идея
Формирование границ
Прототип
Релизы – n
Выход с рынка

Спасибо Дмитрию Безуглому (http://system-approach.ru) за замечания и предложения, высказанные при подготовке модели.

Прокомментируйте, пожалуйста, нашу модель, в частности, – набор фаз жизненного цикла и дисциплин. Спасибо!

Схема планирования продуктов от Linda Gorchels

Bredyuk — Fri, 13 Nov 2009 13:06:12 +0000

Linda Gorchels в книге Product Manager’s Handbook приводит Product Planning Framework:

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

Product Management Life Cycle Model от Steven Haines

Bredyuk — Wed, 11 Nov 2009 00:10:14 +0000

Steven Haines в книге Product Manager’s Desk Reference предлагает «Product Management Life Cycle Model».

Haines работает в консалтинговой компании Sequent Learning Networks.

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

Что можно отметить:

присутствует система stage-gate (см. http://swpm.ru/2009/09/stage-gate-process-introduction/)
определена цикличность (в отличие, например, от Pragmatic Marketing Framework)
выделены три крупные области деятельности
никак не обозначено распределение ролей

Сам Haines пишет: «Эта модель (в силу необходимости) является линейным, последовательным, статичным отражением того, что на самом деле является трехмерным, рекурсивным и динамическим, но для большинства целей это полезное приближение».

Product Management Framework от Zigzag Marketing

Bredyuk — Sun, 08 Nov 2009 14:43:12 +0000

У консалтинговой компании Zigzag Marketing есть свой фреймворк управления продуктами:

Zigzag Marketing Product Management Framework

View more documents from swpm.

На странице фреймворка можно также скачать интерактивную версию для PC и для MAC.

Как и другие консалтинговые компании на этом рынке, Zigzag Marketing проводит обучение и осуществляет консалтинговые проекты на основе своей разработки.

Это не первая попытка определенным образом структурировать Product Management процессы. У нас в блоге даже есть специальная категория - Фрейморвки. Напомню, что самый известный фреймворк управления продуктами разработала компания Pragmatic Marketing. (http://swpm.ru/2009/07/pragmatic-marketing-framework-update/).

Отличия Zigzag Marketing Framework от Pragmatic Marketing Framework:

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

Хотя между фреймворками есть отличия, общего между ними достаточно много. Так что Product Management движется, в целом, в одном направлении.

К концу следующей недели планирую опубликовать нашу разработку: модель процессов управления программными продуктами в привязке к жизненному циклу продукта. Можно будет подискутировать.

Введение в Stage-Gate process

Bredyuk — Sat, 19 Sep 2009 20:40:33 +0000

Дано

продуктовая компания;
вы руководите отделом управления продуктами;
у вас портфель из 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.

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

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

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

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

Обновления: форум и ЖЖ

Bredyuk — Fri, 18 Sep 2009 15:32:04 +0000

Уважаемые читатели!

Есть два объявления:

запущен форум http://forum.swpm.ru
сделана трансляция всех постов в LiveJournal swpm

Трансляция постов в ЖЖ – это вещь, конечно же, полезная, но все же техническая.

А вот относительно форума у меня есть глобальные планы В рунете сейчас нет форума, посвященного управлению программными продуктами. Да и off-line сообществ, насколько я знаю, тоже нет. У этого блога уже есть постоянная читательская аудитория. Поэтому я подумал, что можно сделать попытку организовать первое сообщество, посвященное управлению программными продуктами, в виде форума на основе этого блога.

Приглашаю всех зарегистрироваться на форуме и принять участие в дискуссии!

Основной формат общения предполагается «Вопрос-Ответ». Т.е. интересующийся задает вопрос в соответствующей ветке, а другие участники коллективным разумом пытаются на поставленный вопрос ответить. Возможен также формат «Объявление-Обсуждение».

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

Исследование от 280group

Bredyuk — Tue, 15 Sep 2009 20:54:38 +0000

Консалтинговая компания 280Group совместно с производителем программного обеспечения для управления продуктами Quantum Whisper провела интересное исследование «Product Management Survey – 2009″. В исследовании приняло участие 789 человек. Вот итоговый документ:

Product Management Survey 2009

View more documents from swpm.

Product Management Survey 2009.pdf

Ключевые выводы смотрите на странице 4. Что мне показалось интересным:

в 90% компаний есть выделенный менеджер продуктов
78% менеджеров продуктов работают по выходным
среднестатистический менеджер продукта ведет 3,3 продукта
38% работают по Agile
40% не нужен специализированный софт для управления продуктами
продавцы и маркетологи генерируют больше всего требований к продуктам, однако визиты клиентов больше всего влияют на управление продуктом

Еще есть интересная диаграмма на странице 12. 30% опрошенных не знают, по какой методологии разработки они работают.

Самые популярные инструменты управления требованиями – Excel и Word.

Обзор книги Expert Product Management

Bredyuk — Tue, 15 Sep 2009 20:16:35 +0000

Дочитал одну из книг, которые заказывал летом в Amazon, - Expert Product Management, написанную руководителем консалтинговой компании 280group Brian’ом Lawley. В остальных пока прочитал только самое интересное. Обзоры будут позднее.

Информация о книге:

На Amazon.com

На сайте 280group

На Google Books

Содержание:

Глава 1. Введение

Глава 2. Roadmap продуктов

Глава 3. Проведение программ Beta-тестирования

Глава4. Запуск продукта

Глава 5. Проведение Review-программ

Что понравилось

Дано очень понятное и «с картинками» описание того, какие бывают Roadmap и какой тип Roadmap для каких случаев стоит применять. В обзорную версию на Google Books влезла значительная часть главы, можно почитать. Картинки с типами Roadmap можно посмотреть в разделе «продукты» на сайте 280 group (они продают весь набор шаблонов за $99). Эта классификация Roadmap, похоже, явлется гордостью компании и даже изображена на обложке книги. Также просто и понятно описаны процессы Beta-тестироввания, запуска продуктов и проведения Review-программ.

Итого

Это не учебник по управлению программными продуктами. Это лишь брошюра (92 стр.) с описанием опыта автора в указанных в содержании направлениях. Главной ценность книги является классификация Roadmap вместе с шаблонами и описанием. В целом – полезное чтение.

Шаблон SWOT анализа

Bredyuk — Wed, 05 Aug 2009 19:26:00 +0000

Шаблон для SWOT анализа от Adam Bullied.

http://writethatdown.com/archives/2009/07/competitive-analysis-series-swots

Swot Sample Slide

View more presentations from swpm.

Финансовый анализ новых продуктов

Bredyuk — Fri, 31 Jul 2009 23:13:39 +0000

В Blog Backlog была предложена тема «Как оценивать ROI на новый продукт» и за нее проголосовало больше всего читателей, поэтому данный пост будет посвящен теме финансового анализа и показателю ROI в частности.

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

Постановка задачи

Задача финансового анализа продукта – определить финансовую эффективность продукта для компании. В самом простом случае вопрос сводится к следующему: принесет ли данный продукт нам денег больше, чем мы затратим на его создание. Эта формулировка работает лишь в редких случаях по ряду причин:

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

Во-вторых, формулировка «принесет нам денег больше, чем затратили на его создание» не учитывает такой немаловажный момент как временная стоимость денег (см. далее модели финансового анализа). Если разработка продукта нам обойдется условно в $500.000, а оценка доходов составляет $505.000 через 3 года, это не означает, что продукт нужно разрабатывать. Гораздо выгоднее будет положить эти деньги в банк или вложить в другой проект. Итого: оценка продукта должна осуществляться с учетом временных характеристик возврата вложений.

Три составляющие финансового анализа нового продукта

Финансовый анализ продукта состоит из трех процедур: оценка доходов от реализации продукта, оценка затрат на создание продукта, агрегация полученных данных с помощью моделей в финансовые показатели.

Оценка спроса – задача маркетингового анализа, которую выполняют маркетологи. В маркетинговых исследованиях есть отдельное направление Demand Estimation (оценка спроса), которое и занимается данным вопросом. Оценка спроса связана с анализом целевых потребителей, конкурентным анализом, оценкой объема рынка т.д. Также к оценке спроса имеет отношение непростая тема прогнозирования (forecasting).

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

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

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

Обзор показателей финансового анализа

У меня нет цели описать подробно указанные показатели. Здесь дается только перечень некоторых показателей с кратким описанием. Подробности см. в русской Википедии: ROI, NPV, IRR, точка безубыточности. И в английской: Real options.

И теперь мы подошли к понятию ROI. Для начала, ROI - один из простых показателей финансовой эффективности продукта и в самой простой формулировке рассчитывается как отношение прибыли к инвестициям. Это далеко не единственный способ оценки эффективности продукта. Есть и более «продвинутые» показатели, такие как NPV. Но именно ROI почему-то стал синонимом финансовой эффективности чего-либо в области разработки ПО (IMHO). Наверное, потому что он самый простой, понятный и универсальный

NPV (Net Present Value, Чистый дисконтированный доход) позволяет учесть временную стоимость денег, которая, как мы уже отмечали выше, имеет важное значение при оценке финансовой эффективности продукта. В модели NPV денежные потоки, которые генерируется продажами продукта, «дисконтируется», т.е. приводятся к единому периоду времени, а потом складываются. С NPV тесным образом связан показатель IRR.

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

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

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

Заключение

Термин ROI часто употребляется в сфере разработки ПО как собирающее понятие для финансовой эффективности продукта. Хотя на самом деле ROI – не единственный и не самый эффективный показатель.

Как видите, расчет ROI тривиален. Более важен вопрос сбора данных, которые мы подставим в эту формулу, а также механизм их агрегации, т.е. финансовая модель.

Итого: указывайте в Blog Backlog те аспекты финансового анализа продуктов, которые вам интересны, и лидирующие по количеству голосов темы будут освещены в следующих постах.

Blog Backlog. Принимайте участие

Bredyuk — Wed, 29 Jul 2009 23:40:03 +0000

Когда я выбираю тему для нового поста, я ориентируюсь на две вещи:

насколько данная тема интересна для меня;
насколько данная тема может быть интересна моим читателям.

Для того, чтобы определиться с последним пунктом, я смотрю в основном на две вещи:

какие статьи больше всего читают;
по каким поисковым запросам пользователи попадают на сайт.

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

Для этого заходите на страницу http://swpm.ru/backlog. Там можно как голосовать за уже указанные темы, так и предлагать свои.

P.S. Плагин в версии 0.1. Возможны небольшие сбои в работе.

Roadmap в Agile

Bredyuk — Tue, 28 Jul 2009 12:01:25 +0000

Перевод статьи из блога http://onproductmanagement.net (Saeed Khan).

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

http://onproductmanagement.net/2008/10/28/agilescrum-and-product-roadmaps/

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

При обсуждении Agile / Scrum часто возникает вопрос о создании и поддержке Roadmap в Agile среде. Замешательство возникает из-за того, что Scrum основан на коротких циклах разработки и постоянной приоритизации и реприоритизации функциональности в Product Backlog.

Итак, есть ли здесь противоречие, которое помешает созданию и поддержке Product Roadmap в Agile среде?

Ответ – абсолютно нет. Вкратце: Scrum – это методология разработки, а Roadmap – это инструмент бизнес-планирования и общения. Эти две вещи не зависимы друг от друга, и внедрение Scrum должно оказывать слабое влияние на поддержку Roadmap.

Не удовлетворены? Тогда предоставлю вам более развернутый ответ.

Прежде всего, определимся чем НЕ является Roadmap.

Это НЕ на 100% гарантированное и непоколебимое описание того, что мы безусловно будем делать в ближайших релизах нашего продукта.

Нет, Roadmap этим не является. Даже несмотря на то, что многие продавцы хотят, чтобы так было.

Кстати (небольшое отступление), есть небольшой трюк, позволяющий справиться с продавцами, которые хотят абсолютно фиксированную, определенную Roadmap на будущее.

Скажите им, что менеджмент продукта сделает такую Roadmap, когда команда продавцов подготовит абсолютно фиксированный и определенный объем продаж на 4 квартала. Посмотрите на их реакцию. Я сомневаюсь, что будут желающие.

Итак, что такое Product Roadmap?

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

Для стартапов или компаний, работающих на быстро меняющихся или растущих рынках, эти 2-3 релиза могут покрывать только ближайшие 12 месяцев. Для более зрелых компаний, работающих на менее динамичных рынках, эти релизы могут покрывать несколько лет.

Я выделил слово «планируемый» выше. Планы – это просто планы. Это только наши представления о будущем, основанные на том, что мы знаем и во что верим сегодня. Это не обязательства. Большинство презентаций Roadmap, которые я видел, и практически все презентации, которые делали публичные компании, начинались с оговорки о том, что компания снимает с себя всякие обязательства относительно того, что указано в Roadmap.

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

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

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

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

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

Вот несколько РЕАЛЬНЫХ Roadmap, которые я нашел в Интернете. Какая из этих компаний использует Agile в разработке? Вы можете сказать? Это имеет значение?

User Stories и Use Cases

Bredyuk — Mon, 27 Jul 2009 18:20:48 +0000

Перевод статьи из блога 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. Понимайте природу различных артефактов. Думайте об их сильных и слабых сторонах. Рассмотрите, как вы взаимодействуете со своей командой. Должны ли вы доверять вашей команде? Доверяете ли вы вашей команде? Определите, что им нужно и дайте им это.

Основы SWOT анализа от Ethan Henry

Bredyuk — Mon, 27 Jul 2009 09:35:29 +0000

Перевод статьи из блога onproductmanagement.net (Ethan Henry).

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

http://onproductmanagement.net/2007/08/17/swot-analysis/

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

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

SWOT=

Strengths (Сильные стороны)
Weaknesses (Слабые стороны)
Opportunities (Возможности)
Threats (Угрозы)

Прежде всего, по элементам SWOT: «сильные стороны» и «слабые стороны» отражают внутренние характеристики. Возможности и угрозы относятся ко внешнему окружению.

Так, например, недостаток клиентов – не слабая сторона, пока нет клиентов у продуктов, аналогичных вашему. «Неразвитость рынка» – это угроза, «Недостаточное проникновение на рынок» – слабая сторона. Постарайтесь сфокусироваться на вопросах, которые можно определенно отнести к внешним или внутренним по источнику происхождения. Если выбирать вопросы типа «это ничье», то хороший SWOT анализ не получится.

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

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

	Сильные стороны	Слабые стороны
Возможности	Лучшие возможности	Области улучшения для использования возможностей
Угрозы	Использование сильных сторон для борьбы с угрозами	Области, которые нужно избегать и /или смягчать угрозы

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

Это второй уровень анализа, в результате которого можно получить действительно полезные рекомендации и план действий из SWOT анализа.

——конец перевода——

см. также по SWOT:

http://ru.wikipedia.org/wiki/SWOT (Русский)
http://en.wikipedia.org/wiki/SWOT_analysis (English)
http://quickmba.com/strategy/swot/ (English)

3 полезных совета для успешного маркетинга при запуске новых продуктов (1 часть)

Bredyuk — Sun, 26 Jul 2009 12:40:45 +0000

Перевод статьи из блога Launch Clinic (David Daniels).

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

http://pragmaticmarketing.typepad.com/launchclinic/2009/07/3-tips-for-product-launch-marketing-success-part-1.html

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

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

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

Слушатели семинара по запуску новых продуктов, который я веду, часто спрашивают мое мнение насчет использования тактики A или тактики B. Хотя я не рассматриваю маркетинговые тактики в моем курсе, в этом посте, который будет состоять из трех частей, я поделюсь с вами тремя полезными советами, которые помогут вам выбрать наиболее эффективную маркетинговую тактику запуска новых продуктов.

Почему проваливается маркетинг при запуске новых продуктов?

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

Знайте ваших потребителей

Команды разработчиков используют инструмент user persona, который помогает им в создании удобных в использовании продуктов. User persona – это типичный пользователь. Для более сложных продуктов может быть несколько user persona для представления различных типов пользователей. User persona позволяет преодолеть индивидуальную предубежденность в том, кто является пользователем системы, и создать общее видение пользователей, что ведет к созданию лучших продуктов.

Эта модель может быть расширена на покупателей, которые будут представлены в виде buyer personas. Также как и user personas, buyer personas является архетипом (репрезентативная модель) людей, которые будут покупать или влиять на принятие решение о покупке вашего продукта. Buyer personas представляют типичных покупателей, не исключительные случаи и не единственных в своем роде покупателей. Это те люди, на которых вы хотите нацелить свои маркетинговые программы.

Создание buyer personas

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

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

В ходе процесса создания buyer personas вы получите глубокое представление ваших покупателей и того, что движет ими. С развитием и усложнением buyer persona ваша способность находить их, устанавливать с ними связь будет более интуитивной.

Следующий шаг: знайте, как покупатели покупают

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

Вы используете buyer personas сейчас?

Как они помогают вам в ваших маркетинговых мероприятиях?

Осуществляйте поддержку продаж систематически

Bredyuk — Sat, 25 Jul 2009 18:10:47 +0000

Перевод статьи из блога pragmaticmarketing.typepad.com (Steve Johnson).

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

http://pragmaticmarketing.typepad.com/productmarketing/2009/07/provide-sales-support-systematically.html

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

Какой лучший способ осуществлять поддержку продаж? Легко просто отвечать на их постоянные запросы: «Мне нужна новая презентация», «Мне нужна новая брошюра», «Мне нужны новые инструменты продаж».

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

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

whitepapers для объяснения технической составляющей продукта;
электронные книги для того, чтобы объяснить последствия изменений в индустрии;
стандартные презентации и демонстрации для того, чтобы показать ключевые проблемы, с которыми сталкиваются сегодня потребители;
и многое другое.

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

Как вы можете помочь вашим продавцам с новой информацией, которая им нужна?

——конец перевода——

Интересный, на мой взгляд, комментарий от Saeed Khan:

Абсолютно верно, что поддержка должна осуществляться систематически. Но я думаю, что она должна выходить за рамки wiki, блогов, whitepapaer и т.д.

Маркетологи и Менеджеры продуктов должны анализировать процесс продаж, понимать, какая ключевая информация необходима на различных этапах цикла продаж (т.е. что нужно и когда) и тогда СИСТЕМАТИЧЕСКИ создавать документы и артефакты, которые будут удовлетворять эти потребности.

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

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

Понимайте вашу роль

Bredyuk — Sat, 25 Jul 2009 17:33:06 +0000

Перевод статьи из блога leadonpurposeblog.com (Michael Ray Hopkin).

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

http://leadonpurposeblog.com/2009/07/24/understand-your-role/

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

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

Что вы, как лидер, можете сделать в организации, чтобы помочь людям понять их роли и действовать эффективно? Bob Seelert, председатель Saatchi & Saatchi, запустил внутреннюю программу «Завтрак с Бобом», в рамках которой он совместно позавтракал почти с каждым из сотрудников компании (400 человек), с семерыми за один раз. Он делал это дважды в неделю и встретился почти с каждым в течение 29 недель.

Боб разделял следующую идею, приобретенную в ходе этого мероприятия: «Каждый человек в вашей организации важен для успеха. Если вы лидер, уделяйте много времени на то, чтобы поддерживать связь между людьми». Лидер должен знать его или её роль и помогать другим людям понимать их роли.

—

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

Литература по управлению программными продуктами

Bredyuk — Wed, 22 Jul 2009 18:47:26 +0000

Я закупил интересные книжки в Амазоне. Буду делать обзоры по мере прочтения.

Первая на очереди – Software Product Management Essentials. Она одна из самых тонких Еще раз убедился в том, что на сайте Амазона брошюра и увесистый талмуд выглядят одинаково.