-Поиск по дневнику

Поиск сообщений в product_manager

 -Подписка по e-mail

 

 -Статистика

Статистика LiveInternet.ru: показано количество хитов и посетителей
Создан: 10.11.2010
Записей: 602
Комментариев: 758
Написано: 2090

Не спи на работе!

4 вещи, которые не сделала Amazon и которые привели Amazon Prime к успеху

Среда, 01 Декабря 2010 г. 23:11 + в цитатник


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

Есть несколько вещей, которые Amazon не сделала, но которые, по моему мнению, помогли Amazon Prime добиться успеха:
дальше
Рубрики:  менеджмент

Метки:  

Почему вам следует читать страничку вашей жены на Фейсбуке

Среда, 01 Декабря 2010 г. 11:39 + в цитатник


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

Метки:  

Три практики успешных менеджеров продукта

Среда, 01 Декабря 2010 г. 10:57 + в цитатник
На самом базовом уровне успех продукта измеряется тем, насколько хорошо он продаётся на рынке, и прибылью, которую он приносит компании. Успех компании - это, в конечном счёте, совокупность всех продуктов и услуг, продающихся с прибылью. Это кажется прямолинейным, и всё же по моему опыту, лидеры компании слишком часто теряют эту важную цель. Они сосредоточены на этой рекламной кампании или на той новой технологии, и теряют самое важное. Конечно, иногда они делают слишком большой акцент на прибыль за счёт других важных директив, но это тема для другого поста.
дальше
Рубрики:  менеджмент

Метки:  

Рекламные сообщения стартапа и рыночная система отсчёта

Среда, 01 Декабря 2010 г. 02:11 + в цитатник
 (150x150, 4Kb)
Рекламные сообщения - одна из самых трудных вещей для стартапов, особенно стартапов на развивающихся рынках. Ваши маркетинговые сообщения должны описать, что вы делаете, таким образом, чтобы это было и легко понять, и иллюстрировало уникальную ценность, предоставляемую вашим решением. Зачастую наиболее сложной частью для стартапов является то, что рыночная категория ещё не точно определена. Сообщения поэтому не только должны описать ваш продукт, но и дать причины, почему эта категория продукта должна существовать.
дальше
Рубрики:  маркетинг

Метки:  

Общие интересы: Важность прислушивания к стратегии связей с общественностью B2B (и жизнью)

Среда, 01 Декабря 2010 г. 00:29 + в цитатник
Горы южной Аризоны недавно дали мне тревожный сигнал о важности слушания - питаемое кофеином напоминание от создателей моего нового любимого справедливого кофе, Café Justo (www.justcoffee.org).

Какое отношение имеет лучший в мире бобовый напиток Robusto к стратегии связей с общественностью "бизнес-бизнес"? Во время этого визита в пограничный регион Аризоны и Мексики, мне напомнили, что слушание - наиболее объединяющей общий знаменатель в мире. Даже в общинах, страдающих от таких поляризационных вопросов, как обсуждение иммиграции, с объединяющим призывом к вниманию к сложному вопросу может согласиться каждый.

От Minute Men до адвокатов незаконных иммигрантов, люди по всему спектру иммиграционных дебатов согласились: если только вся общественность уделит проблеме иммиграции внимание, которое она заслуживает, решение бы уже готовилось. Хотя предлагаемые решения сильно отличались, каждый в Южной Аризоне соглашался, что прислушивание может приблизить нас к решению и что получить возможность рассказать свою историю может иметь решающее значение для продвижения вперед.

Как профессиональные коммуникаторы, мы умеем донести аудитории "нашу" (или наших клиентов) сторону множества различных видов деловых и экономических историй. Подумайте: как вы вплели слушание в вашу стратегию коммуникаций?

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

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

Источник: B2B Bliss
Рубрики:  менеджмент

Метки:  

Проведение виртуальной встречи с клиентом.

Вторник, 30 Ноября 2010 г. 22:24 + в цитатник
Одним из основных видов деятельности по управлению продуктами - это выбраться из офиса и получить понимание потребностей клиентов и партнеров из первых рук, и других вопросов рынка. Мало что может заменить хорошие полевые исследования.

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

Таким образом, хотим мы этого или нет, нам пришлось решать эти проблемы и всё-таки провести исследование. Вот как мы это сделали.

Продолжение Организация виртуальной встречи с клиентом

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

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

Так что вот, что вы можете сделать, чтобы максимизировать ценность виртуальной встречи.

1. Руководите обсуждением простым набором слайдов

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

* Повестку дня с темами обсуждения и выделенное время
* 1 слайд на каждую обсуждаемую тему
* Ключевые вопросы, на которые нужно ответить, к каждой теме

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

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

Ключевые вопросы происходят от этапа планирования проекта.

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

2. Назначьте ведущего оратора с вашей стороны

Если из вашей компании в совещании участвует несколько человек (в моих совещаниях из нашей компании участвовало до 6 человек), назначьте 1 человека в качестве лидера. Это, вероятно, будет менеджер продукта, но кто бы это ни был, установите основное правило (заранее среди вашей команды), что лидер ведёт обсуждение и поддерживает его движение вперед. Другие, безусловно, могут вмешиваться и задавать клиенту наводящие или уточняющие вопросы по мере необходимости.

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

3. Назначьте хранителя времени

Попросите кого-нибудь (кроме лидера), быть хронометристом. Будет ли совещание коротким или длинным, роль этого человека - следить за часами и напоминать лидеру, когда повестка дня отстаёт от графика. График повестки дня не высечен в камне, но если времени мало, используйте его, чтобы сосредоточиться на важных областях обсуждения.

4. Записывайте разговор/веб-семинар

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

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

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

5. Если делаете заметки, назначьте на эту работу больше 1 человека

Если клиент отказывается от записи, то держите наготове по крайней мере 2 человека для записей. Почему два? Ни один записывающий не сможет охватить 100% совещания. Когда записи делают 2 человека, каждый будет фиксировать моменты, которые другой упустил.

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

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

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

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

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

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

7. Закончите вовремя

Это возвращает нас к пункту 3 выше (Назначьте хранителя времени), но убедитесь, что вы закончите вовремя, или в худшем случае, если вы видите, что не успеваете, спросите заранее, может ли клиент продлить совещание на 5-10 минут. Большинство клиентов, которых я встречал, очень заняты и не имеют много дополнительного времени.

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

И наконец ...

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

Источник: Saeed Khan
Рубрики:  менеджмент

Метки:  

Или слайды, или документы

Вторник, 30 Ноября 2010 г. 11:36 + в цитатник
Очень часто организаторы разных мероприятий требуют подготовки презентаций. Хорошим выходом будет составить набор слайдов, где отразить ключевы моменты, и документ, где описать подробности. На мероприятии раздавать или первое, или второе. Ни в коем случае не оба варианта.

Рубрики:  менеджмент

Метки:  

Каннибализация продукта ...

Вторник, 30 Ноября 2010 г. 01:38 + в цитатник

На прошлой неделе я получил письмо от Netflix о том, что моя абонентская плата выросла на $ 3 в месяц с $ 20/месяц до $ 23/месяц. Они предположили, чтобы я вместо этого перешёл на тариф $ 8/месяц за Internet Streaming. Они отметили, что они быстро расширяют библиотеку фильмов, доступных через мгновенный просмотр. Я сразу переключился на тариф $ 8/месяц - мы всё меньше и меньше получали DVD-диски по почте, а все больше и больше смотрели фильмов через потоковое видео, используя нашу Wii консоль, плюс нас не волновало, если нам нужно было ждать, чтобы посмотреть новейшие фильмы. Так что это было идеальным решением для нас и Netflix.

Как менеджер программного продукта, конечно, это заставило меня задуматься. То, что происходит с Netflix, мне кажется каннибализацией продукта, разве что они делали это сами с собой. Они выталкивали своих клиентов из их жирного бизнеса доставок DVD-дисков по почте на другой их продукт, который стоит на треть меньше. Представьте себе. А Netflix - это публичная компания, которая должна оправдывать ожидания Уолл-стрит. Я уважаю Netflix за то, что не многие компании посмеют сделать.
Я могу перечислить следующие преимущества для Netflix от перевода клиентов на потоковое видео:

  1. Масштабируемость - вам не придётся увеличивать закупку DVD-дисков, увеличивать складское пространство, чтобы хранить все DVD-диски и, конечно, увеличивать расходы на доставке, когда растёт ваша клиентская база. Потоковое видео через интернет не имеет физических затрат и расходов на доставку.
  2. Возможная международная экспансия - всё больше и больше людей за рубежом имеют высокоскоростной интернет. В настоящее время они представляют потенциальный рынок - снова мгновенная масштабируемость, без необходимости беспокоиться об огромной инфраструктуре и эксплуатационных расходах, ограничении импорта, боязни не получить DVD-диски назад и т. д.
  3. Реагирование на конкурентные угрозы - технологии для высокоскоростного потокового видео уже существуют. Это большая угроза бизнеса Netflix по доставке DVD-дисков почтой - если они не смогут приспособиться, то они могут последовать за Blockbuster.


Бизнес DVD-дисков по почте, как ожидается, сохранится ещё долгое временя, но Netflix видит надпись на стене и позиционирует себя, чтобы воспользоваться новыми технологиями и сохранить свои лидирующие позиции в отрасли. Я очень впечатлен тем, что они сделали, и останусь лояльным клиентом Netflix. Я уверен, что это весело - быть менеджером программного продукта в такой компании.

Источник: Gopal Shenoy
Рубрики:  менеджмент

Метки:  

Создаёте ли вы творческое напряжение?

Понедельник, 29 Ноября 2010 г. 00:32 + в цитатник
В последнее время я читал о лидерах ... людях, которые находят лучшее в себе и, в свою очередь, вдохновляют, привлекают и мобилизуют других в сложных обстоятельствах.

Три недели назад во время полета на конференцию на западном побережье у меня было 6 часов для чтения. Я недавно начал "Лидерство без легких ответов" Рональда Хейферца. Хейфец, старший преподаватель Школы правительства им. Кеннеди Гарвардского университета и один из основателей Центра общественного лидерства, является экспертом по вопросам лидерства. Коллега предупредил, что книга Хейферца "довольно плотная" и требует дополнительных усилий, чтобы провести параллели с современной бизнес-средой. И поэтому я попросил у стюардессы кофе.

Наполненный кофеином, я устроился для 6 часов тяжёлой работы ... но затем вспомнил, что я взял ноябрьский Harvard Business Review, в котором подчеркивались уроки лидерства среди военных. Я решил пролистать выпуск, прежде чем вернуться к книге Хейферца. Два часа спустя я всё ещё читал HBR.

Хорошо, что я так сделал.

Ноябрьский HBR показал, как конкретные стратегии лидерства могут непосредственно влиять на успех. И статья Роберта Симона "Стресс-тестируйте вашу стратегию" предоставляет 7 ключевых мер, которые должны использовать лидеры для оценки здоровья своей бизнес-стратегии. И одна из этих мер всегда в мешке продукт менеджера.

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

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

Итак, что же я сделал?

Я открыл сумку и достал изношенный инструмент управления продуктом ... Я создал творческое напряжение. Я просто разместил изображение на Твиттере недавно запущенного конкурентом приложения по подписке для iPad / iPhone. Я не говорил слов. Мне не было нужно. Но сообщение было ясным; "мы отстаём в мобильных вычислительных системах."



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

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

Кап, кап, кап.

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

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

Источник: The Product Pipe
Рубрики:  менеджмент

Метки:  

ИТ-директорам и ИТ-отделам нужна "виртуализация", чтобы делать "практически" всё

Воскресенье, 28 Ноября 2010 г. 20:50 + в цитатник
В дополнение к постоянному реагированию на меняющиеся бизнес-требования со стороны всё более требовательных руководителей отделов маркетинга и управления продуктами, ИТ-организации должны сократить время на обслуживание, упростить сети, сократить потребление энергии и снизить затраты. Виртуализация всё более становится ключевой

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

Виртуализация действительно приобретает всё большую популярность, и такие игроки, как Cisco, NEC, Nortel, Microsoft, Avaya и другие сражаются, чтобы завоевать рынок бизнес-коммуникаций. Касается ли это связи или других секторов, не секрет, что ИТ-организациям необходимы сложные архитектуры сетей передачи данных, которые помогают оптимизировать развертывание внутри и между центрами обработки данных, поскольку бизнес-пользователи всё больше жалуются на проблемы, которые препятствуют их способности сотрудничать, используя новые приложения и услуги.

Поскольку около 37% простоя в сети связано с человеческими ошибками (Yankee Group), это решение Avaya является примером того, как виртуализированная архитектура или "частное облако" направлены на сокращение числа реконструкций сети, которые должен делать IT, когда маркетинг или другие бизнес-единицы требуют изменений или новых услуг. Цель - упорядочить задачи предоставления и конфигурации политики, которые часто мешают запуску новых или усовершенствованных приложений и услуг. Корпоративные пользователи телекома, будь то маркетинг, разработка продуктов, финансы или другие, нуждаются в надежных соединениях со своих компьютеров с корпоративными центрами обработки данных, и их ИТ-группы должны защитить основные сети от сбоев. А при "виртуализации" много энергии тратится на создание оптимальных сетевых соединений между серверами приложений и конечными пользователями.

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

Источник: connected planet
Рубрики:  менеджмент

Метки:  

8 опасностей внедрения Agile

Воскресенье, 28 Ноября 2010 г. 19:41 + в цитатник
 (500x335, 53Kb)
Как будто внедрение Agile не было достаточно страшно, Кит Ричардс из KRC на конференции APM в прошлом месяце говорил о 8 опасностях Agile. Вот они:

Она переворачивает всё вверх дном

"Мы на самом деле не хотим, чтобы технари захватили организацию", - говорит Кит. "Этот подход вверх тормашками немного опасен". Он отметил, что Agile - это не что-то, что должно органично вырасти из ИТ-отдела. Убедитесь, что ваше развертывание Agile - это сознательное решение.

Она выглядит простой

"Если бы это было просто, нам не пришлось бы обучаться в PRINCE2", - сказал он. На мой взгляд, всё просто, когда вы знаете, как это работает, но Agile выглядит обманчиво простой со стороны. Будьте осторожны с реализациуй, рекомендует Кит.

Это смешение масла с водой

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

Вы начинаете с упаковывания времени

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

Команды самоуправляются

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

Она растёт вирусно

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

Люди наверху её не понимают

Это очень реальная опасность, но я бы поспорил, что это проблема всех подходов к управлению проектами, а не только agile способа ведения дел. Если у вас нет заинтересованного и понимающегоруководителя, то добиться каких-нибудь изменений процесса или методологии будет очень трудно. Вы можете противостоять этой опасности путём усиления образовательной кампании, чтобы она касалась и этих руководителей, а также людей, которые будут непосредственно с ней работать.

Инструменты руководят переходом

Кит отметили это как опасность для реализации Agile, но опять-таки я считаю, что это угроза для любого изменения в методологии. Не позволяйте инструментам определять переход к новому способу работы. Инструменты должны поддерживать ваши новые процессы, а не наоборот. В случае Agile, не покупайте какое-то программное обеспечение для поддержки разработки и затем не надейтесь, что оно "исправит" всё. Программное обеспечение не развёртывает новые процессы - это делаете вы.

Источник: pm4girls
Рубрики:  менеджмент/agile

Метки:  

Новые идеи

Пятница, 26 Ноября 2010 г. 22:02 + в цитатник
На прошлой неделе наше руководство проснулось от спячки и разразилось длинным письмом о новой концепции продукта и о путях его развития.

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

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

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

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

Вот такие дела. Мне нравятся эти новые веяния. Надеюсь, у ВП хватит духу довести их до конца. Я даже питаю честолюбивые планы проявить себя в одном из проектов, чтобы меня запомнили. (может, повысят когда-нибудь до регионального
Рубрики:  личное

У каждого есть своя история - А какая она у вас?

Четверг, 25 Ноября 2010 г. 22:41 + в цитатник


Когда мы задаём кому-то основной вопрос: "Ну, и чем ты занимаешься?", то существует несколько ответов, которые вы ни за что не услышите:

"Мы проводим операцию "и я тоже".
"Я посредственный доктор/юрист/дизайнер."
"Мы делаем ровно столько, чтобы не дать нашим клиентам жаловаться."

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

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

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

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

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

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

Источник: Bliss
Рубрики:  маркетинг

Метки:  

Поле Чудес - это не стратегия продукта

Среда, 24 Ноября 2010 г. 22:23 + в цитатник
"Если вы построите, они придут." Это мудрый совет, если вы подумываете о том, чтобы построить бейсбольный стадион на кукурузном поле, а на дворе 1989 год. Но это ужасный совет для стратегии продукта.

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

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

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

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

Источник: High Start Group
Рубрики:  менеджмент

Метки:  

Ни за что не дам тебе мой номер телефона

Среда, 24 Ноября 2010 г. 22:01 + в цитатник
 (250x167, 8Kb)
Парень в баре подходит к кому-то, кого он находит привлекательным, и первое, что он говорит: "Дай мне свой номер телефона."

Девушка в местной кофейне видит кого-то, кого она находит интересным, и начинает разговор с : "Сколько ты зарабатываешь?"

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

И тем не менее именно так ведут себя многие компании.

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

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

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

Источник: Web Ink Now
Рубрики:  маркетинг

Метки:  

Правило 43: Жизнь коротка

Среда, 24 Ноября 2010 г. 20:31 + в цитатник
Нам прислали столько замесательных правил для книги "42 правила управления продуктом", что мы просто не могли не поделиться не вошедшим в книгу.

Правило 43: Жизнь коротка
Рина Капур

Не кипятите океан!

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

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

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

Основная роль Джобса в Эппл - это отказы. "Он фильтр", - говорит инженер Маков Хертцфельд. Каджый день СЕО предлагаются идеи новых продуктов и новых характеристик уже существующих. Ответ по умолчанию - нет. У каждого инженера, который обсуждал с ним продукт, есть история о том, как быстро Джобс тянется к кнопке УДАЛИТЬ. "Я одинаково горжусь теми продуктами, которые мы не выпустили, как и теми, которые выпустили", - сказал Джобс в интервью в 2004 году.

Один способ сделать это успешно (конечно, подразумевая, что вы не всесильный Стив Джобс) - это установить два условия: 1) вы действительно проделали домашнюю работу и знаете свой рынок и целевых пользователей вдоль и поперёк; будьте готовы говорить о том, что ценят ваши пользователи и почему, и обоснуйте это хорошими данными; имейте в виду, что эти данные не обязательно должны быть цифрами из первичного исследования, а могут быть хорошо продуманными выводами из синтеза отраслевых тенденций, опросов потребителей и т.д. и 2) вы показываете другим настоящие "затраты" отклонения от вашего лазерного прицела. Это нелегко, но это следует сделать, если вы хотите увлечь за собой команду, а не бороться с ними за каждую особенность.

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

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

Поэтому основными стадиями подготовки к разработке будут следующие:

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

2. Честно оцените следующее -

2.1. можете ли вы предложить возможности для хорошего решения основных проблем пользователя (достаточно хорошо для пользователей) так, чтобы это
2.2. было уникальным (больше никто так не делает),
2.3. имело смысл (пользователи считают, что это значительное преимущество),
2.4. было подходящим (они могут довольно часто этим пользоваться) и
2.5. ценным (и они готовы платить за это?)
2.6. Разработайте стратегию, чтобы она давала вам преимущества в будущем, например, встройте ограничения на будущее переключение, будущее резвитие и захват доли рынка.

Безжально приоритизируйте строительство возможностей (СКАЖИТЕ НЕТ), принимая во внимание всё вышеизложенное и требования по времени и ресурсам.

Источник: 280 group
Рубрики:  менеджмент

Метки:  

Нужно сообщество, чтобы построить сообщество

Среда, 24 Ноября 2010 г. 02:52 + в цитатник
 (500x367, 61Kb)
Недавно я работал от имени клиентов фирмы Forrester, чтобы ответить на вопрос: "Как организовать сообщество?" Обычно ответ следующий: "Сообщества не организовывают. Их расширяют." Редкие сообщества возникают с нуля за счёт стараний технологической фирмы. Чаще сайты успешных сообществ определяют существующее собрание людей с одинаковыми интересами, а затем привязывают их к сайту чем-то ценным для них.

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

Более мелкие вендоры, конечно, испытывают трудности. Если вы продаёте, например, системы автоматизации торговли (САТ), то существует большое кличество людей, заинтересованных в эффективности торговли, но гораздо меньшее количество заинтересованы в вашей программе. Поскольку у разработчиков нет прямого интереса в управлении торговлей, то вы не можете на них рассчитывать, что они заинтересуются вами так же, как ВП по продажам. Таким образом, сложно понять, почему разработчики захотят принять участие в форумах САТ, разве что у них есть вопрос, на который они хотят получить мгновенный ответ. (Обычно в виде "Почему это не работает?")

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

(Приготовьтесь к небольшому количеству академического языка. Я собираюсь использовать мудрёные немецкие термины, потому что, честно говоря, они передают что-то, чего английский язык не может передать. Так что, пожалуйста, простите меня за этот временный переход на профессорский жаргон.)

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

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

Связи Gemeinschaft длительные, часто нерушимые. (Фраза "культурный католик" отражает одну такую постоянную связь.) Связи Gesellschaft часто меняются и исчезают. Gemeinschaft больше взывает к сердцу, Gesellschaft - больше к голове. Оба могут переводиться как общество, даже если они не могли бы более отличаться друг от друга.

Итак, какое это имеет значение для сайта сообщества разработчиков вендора? Вообще-то, большое.

Обычно вендоры за сайтом сообщества взывают к мышлению типа Gesellschaft. Приходите на наш сайт, говорят они, потому что вы как-то связаны с нами. К сожалению, эти связи чрезвычайно слабые и ни в коем случае не определяющие. Если я работаю в компании, которая внедряет RightNow, у меня будет время от времени желание посетить сайт RightNow. Но я не буду там зависать ни по практическим, ни по эмоциональным причинам. Я пришёл, я ушёл, и любые усилия сделать сайт "притягательным" мне просто мешает.

Тем временем веб-сайты, которые не помогают мне в моей каждодневной работе, часто получают больше моего внимания. Какими бы ни были мои интересы - трэш метал, сериал Glee, рыбалка, епископалианизм - сайты сообществ, где люди обсуждают подобные вещи, делятся опытом и советами, высказывают мнения о вещах, которые им небезразличны, часто забирают больше моего времени, чем, скажем, Oracle Technology Network.

Есть исключения из этого правила. Сайты открытого кода, например, похоже, привлекают довольно высокий уровень участия. Хотя финансовое вознаграждение за участие в открытом коде может быть низким, чувство коллективной цели (и коллективной идентичности) может быть довольно высоким. Таким образом, сайты открытого кода возникают из-за уже существующего сообщества людей, которые, по причинам, коренящимся как в Gemeinschaft, так и в Gesellschaft, нуждаются в форуме, на котором они могли бы общаться. После участия в проектах открытого кода разработчики часто чувствуют себя, как будто они члены общего сообщества открытого кода, связь, которую время, потраченное в Microsoft Developer Network или форумах Netweaver, не создаёт.

Таким образом, для вендоров важно при строительстве "сайта сообщества" понимать сообщество, которое может уже существовать, и соответственно может рассматривать форум вендора как продолжение этого сообщества. Силы, которые удерживают сообщество вместе (скажем, личность-Gemeinschaft, практичность-Gesellschaft или некая комбинация обоих) могут привязать его членов к вашему сайту, если вы мудро предоставите нужные стимулы. И если бы у нас был шанс пересмотреть язык социальных медиа, то мы могли бы использовать слово на С более осмотрительно, поскольку настоящее сообщество нельзя просто создать из цельного куска материи.

Источник: Tom Grant
Рубрики:  маркетинг

Метки:  

полезности

Среда, 24 Ноября 2010 г. 00:09 + в цитатник
Это цитата сообщения Kailash [Прочитать целиком + В свой цитатник или сообщество!]

Все электронные библиотеки в одной строке

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


7 ошибок в ценообразовании продукта, которые делают менеджеры продукта

Вторник, 23 Ноября 2010 г. 11:46 + в цитатник
 (150x150, 8Kb)
Если вы спросите менеджера продукта, какая самая страшная часть его работы, я думаю, многие из них назовут вам "ценообразование". Это как чёрная дыра - вы строите догадки, перекрещиваете пальцы и надеетесь, что достаточно покупателей купят ваш продукт по данной цене, и что вы не выбрасываете деньги на ветер. Плюс ко всему получается, что есть ещё 7 часто встречающихся ошибок ценообразования, которые делают менеджеры продукта - а вы считате себя виновным в каких-либо из них?

Ошибка №1: Мой продукт недостоин

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

Ошибка №2: Средняя цена - это всегда выигрыш, так?

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

Как-то в UPS годами использовалась стратегия одна цена для всех. Затем пришёл FedEx и потеснил UPS, предложив своим клиентам различные цены, что позволило некоторым платить выше среднего, а некоторым ниже. Оказалось, что клиенты хотели именно этого.

Ошибка №3: С ценой, основанной на затратах, не ошибёшься

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

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

Ошибка №4: Но другие парни так делают

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

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

Ошибка №5: Неверное мотивирование службы продаж

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

Большинство служб продаж мотивируются объёмом продаж. Это создаёт проблему, потому что хорошим способом поднять объём будет снизить цену (и прибыль). Если бы вместо этого вы мотивировали службу продаж ценностью, которую они приносят, тогда вы бы поступали верно по отношению к компании.

Ошибка №6: Не выходить из загона

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

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

Ошибка №7: Но клиент сказал, что это правильная цена ...

Когда-нибудь клиент приходил к вам и говорил: "Я хотел бы платить больше за ваш продукт?" Спорю, что никогда.

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

Что всё это значит для вас

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

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

В конце концов мы все должны помнить, что существует разница между ценой вашего продукта и актом ценообразования. Цена вашего продукта - это то, что ваши покупатели согласны за него платить, а ценообразование - это то, что делает менеджер продукта, чтобы убедиться, что покупатели захотят купить его. Удачи!

Д-р Джим Андерсон
Рубрики:  менеджмент

Метки:  

Документация Agile

Вторник, 23 Ноября 2010 г. 11:10 + в цитатник
Agile больше ценит работающий софт, а не обширную документацию - это четвёртая часть первичного манифеста. Это не означает "не пишите документацию"! Это ознначает "не пишите больше, чем необходимо для документирования". У документации есть ценность, но сама практика документирования стала излишней - вот почему реакция на плохие примеры привлекла к себе внимание как один из краеугольных камней Agile. Как же избежать чрезмерного сокращения документации при изменении культуры излишнего документирования?

Необходимость документирования

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

С философской точки зрения Agile уделяет особое внимание сотрудничеству. Обычно оно происходит через (1) людей, которые предпринимают действия и работают сообща для принятия наилучших решений и (2) людей, являющихся частью команды, которые сотрудничают с людьми, для которых они создают продукт. Обычно проекты, в разработке которых принимают участие заказчики, успешны, а те, в которых не принимают, - нет, поэтому лучше считать заказчиков частью команды.



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

Коммуникация во времени

Коммуникация между группами людей происходит во времени.



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

- есть коммуникации для сейчас
- есть коммуникации для потом.

Оба вида важны.

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



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

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



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

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

Мгновенные документы для будущего

Картинка сверху со встречи по определению недоработок в продукте и начального толчка дляя нового проекта. Команда определила наиболее важные стороны (истории) для первого этапа, критерий их принятия и размер, в баллах, каждой истории. Как часть scrum, истории написаны в пользовательском формате, а критерий принятия каждой истории определён и записан на дополнительных карточках (прикреплённых к карточкам соответствующих историй). Замечательный быстрый способ зафиксировать истории "должны сделать" и "улучшит", о которых думает владелец продукта.

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



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

Мы также разработали набор из 8 прото-персон (прототипов, первый черновой вариант, очень грубое приближение персон - почти стереотипы), которых весь продукт / проект должен был поддерживать. У каждой персоны была звёздочка своего цвета.



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

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

Список тем менялся в процессе - мы перешли с 4 до 5 тем, поскольку поняли, что нам лучше разделить одну тему на две. Группа прото-персон выросла из первоначальных 3 до 8, поскольку мы быстро поняли, что команда пыталась "построить что-то для каждого", а мы хотели избежать проблемы эластичного пользователя и вместо этого разработать возможности, которые бы удовлетворяли ценные группы пользователей с похожими целями и перспективами.

Изменение культуры для заказчиков

Как и следовало ожидать, наличие кучи карточек, прилепленных к стене, даёт команде замечательные, быстрые, "сейчас" коммуникации - как во внедрении, так и при общении. Однако, карточки на стене - явление краткосрочное. Также это не лучший способ общения с заказчиками старой школы (представьте себе руководителя, который заставляет своих админов распечатывать е-мейлы, чтобы их читать и аннотировать - такие люди до сих пор существуют!).

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

В книге "Применение пользовательских историй" Майк Кон делает ударение на том, что краткость пользовательских историй специально призвана побуждать (и я бы добавил "зависеть от") разговор. Я считаю это как сильной, так и слабой стороной пользовательских историй. Сильной, потому что можно быстро охватить широкий круг тем (широта) и высветить несколько историй, как приведённый выше список. Слабой, потому что документация требований не существует сама по себе - она требует разговора для заполнения деталей. Иногда помогает использование тестов принятия "Проверь, что ..." в качестве метода документирования этих деталей (глубина) в сочетании с краткими, легко усваиваемыми историями.

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

Постоянные документы в настоящем

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

Почему бы не применить тот же принцип интерктивной разработки к постоянным документам?

Рассмотрим пример, приведённый выше, с использованием цветных наклеек в виде звёздочек, которые определяли людей, к которым применялась каждая история на каждом этапе. Большая часть времени, потораченная на этот анализ, пришлась на понимание того, какие люди важны (для успеха продукта) и для каких людей возможность осуществления этой пользовательской истории важна (для персоны). Комбинация этих двух важностей - начало приоритизации. Минимальное количество времени было потрачено на прилепление стикеров к карточкам и на создание нескольких карточек для одной и той же истории (каждая с разной наклейкой для разных персон и потенциально разных критериев принятия).

Добавьте немного наглядных пособий и создайте такую таблицу (или как вам удобнее).



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

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

Также очень просто составить таблицу, которая показывает, как каждая тема "представлена" на каждом этапе. Такой вид стимулирует хорошую дискуссию относительно того, стоит ли делать ударение сначала на одной теме, а затем на другой или нужно сначала сделать наиболее важные элементы в каждой теме - и постопенно добиваться прогресса в каждой теме. Создание такого вида и использование его для коммуникаций помогло мне разрешить проблему, когда "внешние" заказчики считали, что команда выглядит "хаотичной и случайной" при её подходе к приоритизации и внедрении.

Множество моделей

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



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

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

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

Заключение

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

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

Источник: Tyner Blain
Рубрики:  менеджмент/agile

Метки:  

Поиск сообщений в product_manager
Страницы: 30 ..
.. 4 3 [2] 1 Календарь