Geoffrey Moore о стратегии
Geoffrey Moore на конференции Business of Software 2009 говорит о стратегии софтверных компаний.
Moor – живой классик, автор Crossing the Chasm.
Очень понятно и интересно рассказывает.
Блог российского сообщества менеджеров программных продуктов
Archive for the ‘Стратегия’ Category.
Geoffrey Moore на конференции Business of Software 2009 говорит о стратегии софтверных компаний.
Moor – живой классик, автор Crossing the Chasm.
Очень понятно и интересно рассказывает.
Отличная презентация про управление продуктами от Максима Яшунина (Spirit DSP):
Майкл Портер – классик в области стратегии. Пять конкурентных сил Портера – один из базовых инструментов стратегического анализа.
Сергей Котырев из Umisoft сделал на Ritconf 2010 доклад «Конкурентные стратегии проекта или продукта» как раз по Портеру. Ниже презентация. Рекомендуется как введение в стратегию по Портеру.
Многие хоть раз слышали про модель 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.
А вот как выглядит процесс разработки продуктов:
Я начал читать основной текст их фреймворка, достаточно интересно.
Linda Gorchels в книге Product Manager’s Handbook приводит Product Planning Framework:
Интересна схема формирования целей продуктового портфеля из трех источников. Дальше по книге – подробное описание процесса. Если будет интересно, поделюсь.
Дано
Задача
Как выбирать «правильные» идеи и проекты, чтобы не тратить деньги впустую и развивать портфель продуктов?
Рассуждение
С этой задачей сталкиваются в том или ином виде все продуктовые компании. Идеи поступают отовсюду: от разработчиков, от продавцов, от менеджеров продуктов, от конкурентов, из научно-популярных передач на 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.
Данная схема помогает нам отбросить как можно раньше те проекты, которые не должны реализовывать в силу различных причин: как технических, так и рыночных или организационных.
Материалы по теме:
Если вам интересна данная тема, я готов подробнее описать каждую из стадий. Дайте знать в комментариях.
Если есть вопросы, которые, на ваш взгляд, требуют коллективного мозгового штурма, их можно задать в форуме в разделе «Стратегия» или «Управление требованиями» на ваше усмотрение. Я также попробую на них ответить там.
Шаблон для SWOT анализа от Adam Bullied.
http://writethatdown.com/archives/2009/07/competitive-analysis-series-swots
Перевод статьи из блога 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:
Перевод статьи из блога Cauvin.
Ссылка на статью:
http://cauvin.blogspot.com/2008/10/solution-management.html
——перевод——↓
Продажа решений – подход в области продаж, в рамках которого продавец определяет «болевые точки» клиента и собирает пакет предложений для него. Вместо того, чтобы делать отдельное предложение, продавец комбинирует несколько предложений под определенного потребителя (для всестороннего погружения в технологию продажи решений я рекомендую книгу SPIN Selling).
Точно также как продавцы должны принимать во внимание продажу решений, менеджеры продуктов должны принимать во внимание управление решениями.
Посмотрите, как некоторые компании осуществляют управление продуктами. Один мой друг работает в компании, которая продает железо, софт и услуги. Каждое железо, софт и услуга – отдельный продукт в терминологии компании. И менеджеры продуктов управляют по-отдельности этими продуктами. Они определяют roadmap для каждого из продуктов, сообщают требования разработчикам и осуществляют маркетинг для каждого из продуктов.
Клиенты этой компании, однако, почти никогда не покупают отдельные продукты. Комбинация железа, софта и услуг необходима для решения их проблем. Так как менеджеры продуктов работают на уровне отдельных частей решения, они отделены от потребителя.
Продавцы в компании озадачены тем, как и что продавать. Менеджеры продуктов подготовили сопутствующие документы и стратегию маркетинга и продаж отдельных товаров, но не дали руководства относительно того, как собрать их в единое решение, которое полностью удовлетворит потребности клиента.
К счастью, команды развития бизнеса и поддержки продаж помогли восполнить этот пробел. Они работали над тем, чтобы понять ключевые высокоуровневые проблемы, с которыми встречаются потребители и подготовили материалы, которые позволяют определить эти проблемы и подобрать подходящую комбинацию предложений. Эти команды развития бизнеса и поддержки продаж выполняют управление решениями, хотя и неформально.
Вы когда-нибудь задумывались над тем, что такое «продукт» в вашей компании? Ваша компания продает решения или части решений? Возможно ли комбинировать эти части в единое решение? Рассмотрите переход от управления продуктами к управлению решениями или хотя бы формализуйте роль управления решениями в каком-нибудь виде.