Источник: http://habrahabr.ru/company/sqalab/blog/213993/
Доклад с прошлогодней конференции специалистов системного и бизнеса анализа — Analyst Days 2013 года от старшего аналитика питерского офиса компании DELL — Петрашева Дмитрия
На странице доклада можно найти презентацию и видео, а здесь текст…
Introduction
Всем добрый день. Меня зовут Петрашев Дмитрий. Я старший аналитик в питерском офисе компании Делл. Сегодня хотелось бы рассказать о таком подходе к стратегическому планированию как Impact Mapping:
Сразу сделаю ремарку, что компания у нас продуктовая и в моем рассказе, возможно, будет много нашей специфики. Но стоит пояснить, что сам подход достаточно универсален, чтобы быть примененным и в заказной разработке, и в каких либо специфичных сценариях.
Итак, почему я считаю что не всегда команда разработки в нашем случае делает то, что нужно и причем здесь Импакт Маппинг.
Взаимодействие бизнеса и R&D
В нашей компании «что именно нужно» определяет специально обученный человек, отвечающий за стратегию продукта —менеджер по продукту.
В двенадцати часовых поясах от него живет команда разработки, которая реализует необходимые фичи и в основном ни сном, ни духом почему изменения требуются именно такие. Бэклог для них это просто список покупок, за которыми отправили в магазин. Что именно будут готовить они, как правило, не знают.
Итак, какие общеизвестные проблемы растут из-за этого пробела в коммуникациях.
Проблемы
1. Так как решение о том, какие изменения нужны в продукте для достижения поставленной бизнес цели, принимается единолично менеджером продукта, не всегда эти решения эффективны и обоснованы.
2. Команда, которая не понимает куда стремится продукт, не мотивирована на то чтобы делать его лучше. Они просто закрывают фичи, не более.
3. Пояснять команде как именно должна быть реализована фича и почему именно в таком порядке, не зная исходной цели крайне сложно.
4. Развиваем профессиональное заболевание любого менеджера по продукту. Они просто обожают ближе к дате релиза расширять требования различными бесплатными на их взгляд мелочами. Все эти «небольшие правки» с большим трудом вырезаются из бэклога просто потому что мы не знаем действительно ли они не важны.
Мы уже пытались ранее решить эти проблемы различными способами.
1. У нас был документ с маркетинговыми требованиями — MRD. Постепенно отмер. Возможно, как дань переходу на agile, где принято больше говорить, нежели писать.
2. Были «темы»=themes, которые должны были описывать релиз и задавать общий тренд всех изменений одним абзацем. Тоже не пошло.
Импакт мапинг стал для нас очередной попыткой внести ясность в то, куда продукт движется и как мы, как команда разработки, этому способствуем.
Импакт маппинг
Импакт маппинг – это подход к стратегическому планированию, позволяющий построить логическую цепочку от бизнес-целей в голове у продакт-менеджера до изменений в продукте, необходимых для достижения поставленных целей.
Название подхода (импакт — воздействие) обуславливается тем, что мы пытаемся понять: кто и какое именно воздействие на нашу цель может оказать, и только потом принимаем решение, что нужно изменить в продукте для этого.
На выходе мы получаем карту mind map, которую в процессе обсуждения рисуют совместно бизнес и представители дев-команды. Никаких многостраничных документов, только одна хорошо структурированная схема.
Для подготовки карты требуется ответить на четыре простых вопроса.
Шаг 1. Why — зачем
Сначала требуется ответить на вопрос why – зачем
1. Зачем мы выпускаем данную версию продукта,
2. Почему мы считаем, что в продукте требуется что-то поменять
На данном шаге мы определяем цель. Цель естественно должна быть смартовой (SMART):
1. Конкретной,
2. Измеряемой,
3. Ориентированной на действие,
4. Достижимой в разумный промежуток времени.
Ответ на вопрос “Why” есть (должен быть) у нашего менеджера продукта, но навряд ли его цель соответствует критериям. Над этой целью придется еще поработать.
Хорошая цель представляет собой проблему, которую нужно решить, а не готовое решение.
Шаг 2. Who – Кто
Следом отвечаем на вопрос Who? — кто? Основная задача – определить круг заинтересованных (или не очень) лиц.
1. Кто нам может помочь с достижением цели?
2. Кто может помешать?
На этом шаге важно рассмотреть всех задействованных лиц, а не только юзеров. Все кто может повлиять на результат, должны попасть на нашу карту. Продукты не работают в вакууме, и использование продукта влияет не только на конечных пользователей.
В нашем случае это оказались и другие команды, с которыми интегрируемся, и маркетинг, и даже топ менеджеры компании.
Шаг 3. How – Как?
1. Отвечаем на вопрос по каждому задействованному лицу — как мы должны изменить (воздействовать на) поведение этого действующего лица, чтобы он посодействовал нам в достижении цели?
2. Определяем воздействие на юзеров и других действующих лиц
Это, пожалуй, единственный «вопрос» из всего подхода impact mapping’а, требующий пояснения на примере.
У нас был проект, перед которым была поставлена цель — «увеличить количество пользователей желающих продолжить разбираться с продуктом после триального периода»:
Был сформулирован impact — «shorten time to value», т.е. сократить промежуток времени, который требуется пользователю, чтобы понять какие возможности ему предоставляет продукт, какие его проблемы решаем (начиная с момента, когда пользователь открывает авторан).
Идеально сформулированное воздействие — простое и напрямую влияющее на цель.
По факту было сделано огромное количество изменений в документации, сетапе, GUI и так далее.
Шаг 4. What – Что?
Последний вопрос для построения карты — что?.. Именно на этом этапе появляются фичи.
Нужно понимать, что не всегда для оказания нужного нам воздействия требуется вносить изменения в продукт и что-то девелопить. Порой достаточно изменить документацию, например. Или другой пример — для привлечения пользователей не всегда нужны фичи, альтернативным решением может стать маркетинговая активность и проведение рекламных компаний.
Этапы построения карты
1. Определяем цель, не забывая о требованиях SMART,
2. Выбираем метрику, по которой будем смотреть насколько мы приблизились к цели,
3. Определяем промежуточные этапы для достижения цели (milestones),
4. Рисуем костяк карты, отвечая на четыре ключевые вопроса – why+who+how+what,
5. Ищем возможные альтернативы, причем желательно сфокусироваться не на фичах, а на ролях (who?) и на том, как на них воздействовать,
6. Определяем приоритетные направления на карте,
7. По мере продвижения не забываем удостоверяться, что мы действительно продвигаемся к цели максимально эффективным образом.
Пример карты
Пример честно позаимствован из книги, о которой будет упомянуто ближе к концу доклада.
1. Онлайн игра, преследующая цель расшириться до 1млн игроков (промежуточный этап вырасти в 2раза от 400 до 800к игроков),
2. Выделены несколько ролей, явно видно с достижением цели нам могут помочь не только игроки, но и рекламщики, например,
3. На каждой из веток выделено по несколько воздействий,
4. Фичи в явном виде соответствуют цели. Помните наши проблемы? Здесь мы явно видим что делаем, почему и более того видим несколько альтернативных вариантов движения к цели.
5. Звездочками на ветках карты отмечены приоритетные направления,
6. Ветви карты легко ложатся на пользовательские истории истории (As a… I want to… So that …).
Внедрение Impact Mapping в Dell
Я выступал в роли инициатора, поэтому в первую очередь все внедрение было поделено на этапы.
Время для этапа 1 определилось по звездам, но как выяснилось, конец текущего релиза, время, когда требуется начать выяснять задачи на следующую версию это и есть лучший момент для начала перехода на новые рельсы.
Начал я с того, что продал идею импакт маппинга менеджеру продукта и объяснил ему почему нам нужно жить по новому. Мы обсудили — с какими проблемами мы, как дев команда, обычно сталкиваемся, почему мы ощущаем недостаток понимания — куда движется продукт и почему это плохо.
Для нашего ПМа данный диалог оказался сюрпризом. Впрочем, отрицать очевидное он не стал.
Итак, я представил идею импакт маппинга и настоятельно разжевал, что результат достигается совместными усилиями и что мы не предлагаем ему опять начать единолично писать многостраничные MRD.
После этого я начал потихоньку тянуть из ПМа цель на грядущий релиз, по которому у нас уже был список фичей на обсуждение
1. самым сложным здесь было заставить менеджера поставить конкретную цель, которая была бы измерима и достигалась в ограниченный промежуток времени,
2. из собрания длиной в час, мы только сорок минут бодались вокруг цели, пока не выбрали что-то похожее на правду,
3. лишний раз убедился, что наличие мысли в голове у менеджера продукта не обязательно означает, что он может ее внятно сформулировать.
По окончанию первой встречи мы поделились впечатлениями и договорились
1. еще раз подумать о целях (в том числе и в более долгосрочной перспективе)
2. через неделю собраться снова уже для того чтобы попробовать нарисовать карту
За ту неделю пока менеджер продукта наш естественно НЕ думал о целях, я подготовился к следующему собранию. У меня была драфтовая цель, было понимание, что навряд ли наш менеджер согласится под ноль переработать все то, что у нас уже было ранее занесено в бэклог. Поэтому пришлось произвести некоторый реверс-инжиниринг бэклога и подготовить первый вариант карты на грядущий релиз самому:
1. роли были выявлены достаточно быстро
2. необходимые воздействия тоже
3. но далеко не все фичи удалось связать с поставленной целью. Забегая вперед скажу, что в результате большая часть «нелогичных фичей» была вырезана,
Получившийся черновик был представлен продакт менеджеру.
1. Мы обсудили то, что не вписывалось в цель и зарезали эти фичи/истории,
2. Обсудили чем еще можно сделать в рамках тех ролей, которые уже были выявлены,
3. Появилось несколько новых ролей, для которых не нужно было делать ничего на стороне продукта, кроме как предоставить необходимые материалы (маркетинг, пресейлзы),
На удивление наш продакт менеджер принял крайне активное участие в доработке карты, которая дорисовывалась у него на глазах. Именно благодаря ему на карте появилось большое количество ответвлений, не относящихся к изменениям в продукте.
К заключительной стадии внедрения импакт маппинга на наших продуктах мы начнем через релиз, когда планирование состава фичей на версию будет изначально обрисовываться с помощью импакт маппинга.
Пока что мы просто прощупали насколько успешными окажутся первые попытки.
Отзывы внутри компании
1. Продукт менеджер высказался, что его уже много раз пичкали различными около-скрамовскими методологиями, но именно этот подход его не напрягает и очень ему нравится (естественно ведь карта в зоне ответственности аналитиков и рисуется ими же).
2. Команда проявила хороший интерес к тому, что получилось. Особо им понравилось, что к их мнению прислушиваются, и что они могут предложить обоснованную с точки зрения бизнес-цели фичу.
3. Команда получила компас, с помощью которого проще проводить планирование спринтов и минимизировать споры вокруг очередности историй и деталей их реализации.
4. Наши менеджеры оказались счастливы от того, что теперь для понимания результатов релиз планинга не требуется проводить общую планерку, а достаточно посмотреть на карту. Обсуждение при этом достаточно легко переносится в офлайн.
5. Всем понравилось, что на карту проросла не только деятельность команды, но и в том числе активность которая ранее была теневой (работа маркетинга, проталкивание продукта на уровне бизнеса).
6. Аналитик использует карту на каждом созвоне по текущему состоянию дел (current state call), который проходит каждую неделю и проходится по ключевым веткам карты. Теперь в фокусе получается удерживать большее количество вопросов.
Для того чтобы получить больше информации о данном подходе, крайне рекомендуется одноименная книжка Гойко Аджича.
Источник: http://habrahabr.ru/company/sqalab/blog/213993/
Доклад с прошлогодней конференции специалистов системного и бизнеса анализа — Analyst Days 2013 года от старшего аналитика питерского офиса компании DELL — Петрашева Дмитрия
На странице доклада можно найти презентацию и видео, а здесь текст…
Introduction
Всем добрый день. Меня зовут Петрашев Дмитрий. Я старший аналитик в питерском офисе компании Делл. Сегодня хотелось бы рассказать о таком подходе к стратегическому планированию как Impact Mapping:
- Расскажу, что он из себя представляет,
- Поясню почему мы им заинтересовались и решили внедрить в нашей компании,
- Поделюсь опытом внедрения и что из этого получилось.
Сразу сделаю ремарку, что компания у нас продуктовая и в моем рассказе, возможно, будет много нашей специфики. Но стоит пояснить, что сам подход достаточно универсален, чтобы быть примененным и в заказной разработке, и в каких либо специфичных сценариях.
Итак, почему я считаю что не всегда команда разработки в нашем случае делает то, что нужно и причем здесь Импакт Маппинг.
Взаимодействие бизнеса и R&D
В нашей компании «что именно нужно» определяет специально обученный человек, отвечающий за стратегию продукта —менеджер по продукту.
- Он определяет какие стратегические бизнес цели стоят перед продуктом, сопоставляет их с тем куда движется вся компания, общается с ключевыми и показательными заказчиками и так далее.
- Зная бизнес цели, менеджер продукта формирует список необходимых изменений на следующий релиз и через аналитика передает их дев команде.
В двенадцати часовых поясах от него живет команда разработки, которая реализует необходимые фичи и в основном ни сном, ни духом почему изменения требуются именно такие. Бэклог для них это просто список покупок, за которыми отправили в магазин. Что именно будут готовить они, как правило, не знают.
Итак, какие общеизвестные проблемы растут из-за этого пробела в коммуникациях.
Проблемы
1. Так как решение о том, какие изменения нужны в продукте для достижения поставленной бизнес цели, принимается единолично менеджером продукта, не всегда эти решения эффективны и обоснованы.
2. Команда, которая не понимает куда стремится продукт, не мотивирована на то чтобы делать его лучше. Они просто закрывают фичи, не более.
3. Пояснять команде как именно должна быть реализована фича и почему именно в таком порядке, не зная исходной цели крайне сложно.
4. Развиваем профессиональное заболевание любого менеджера по продукту. Они просто обожают ближе к дате релиза расширять требования различными бесплатными на их взгляд мелочами. Все эти «небольшие правки» с большим трудом вырезаются из бэклога просто потому что мы не знаем действительно ли они не важны.
Мы уже пытались ранее решить эти проблемы различными способами.
1. У нас был документ с маркетинговыми требованиями — MRD. Постепенно отмер. Возможно, как дань переходу на agile, где принято больше говорить, нежели писать.
2. Были «темы»=themes, которые должны были описывать релиз и задавать общий тренд всех изменений одним абзацем. Тоже не пошло.
Импакт мапинг стал для нас очередной попыткой внести ясность в то, куда продукт движется и как мы, как команда разработки, этому способствуем.
Импакт маппинг
Импакт маппинг – это подход к стратегическому планированию, позволяющий построить логическую цепочку от бизнес-целей в голове у продакт-менеджера до изменений в продукте, необходимых для достижения поставленных целей.
Название подхода (импакт — воздействие) обуславливается тем, что мы пытаемся понять: кто и какое именно воздействие на нашу цель может оказать, и только потом принимаем решение, что нужно изменить в продукте для этого.
На выходе мы получаем карту mind map, которую в процессе обсуждения рисуют совместно бизнес и представители дев-команды. Никаких многостраничных документов, только одна хорошо структурированная схема.
Для подготовки карты требуется ответить на четыре простых вопроса.
Шаг 1. Why — зачем
Сначала требуется ответить на вопрос why – зачем
1. Зачем мы выпускаем данную версию продукта,
2. Почему мы считаем, что в продукте требуется что-то поменять
На данном шаге мы определяем цель. Цель естественно должна быть смартовой (SMART):
1. Конкретной,
2. Измеряемой,
3. Ориентированной на действие,
4. Достижимой в разумный промежуток времени.
Ответ на вопрос “Why” есть (должен быть) у нашего менеджера продукта, но навряд ли его цель соответствует критериям. Над этой целью придется еще поработать.
Хорошая цель представляет собой проблему, которую нужно решить, а не готовое решение.
Шаг 2. Who – Кто
Следом отвечаем на вопрос Who? — кто? Основная задача – определить круг заинтересованных (или не очень) лиц.
1. Кто нам может помочь с достижением цели?
2. Кто может помешать?
На этом шаге важно рассмотреть всех задействованных лиц, а не только юзеров. Все кто может повлиять на результат, должны попасть на нашу карту. Продукты не работают в вакууме, и использование продукта влияет не только на конечных пользователей.
В нашем случае это оказались и другие команды, с которыми интегрируемся, и маркетинг, и даже топ менеджеры компании.
Шаг 3. How – Как?
1. Отвечаем на вопрос по каждому задействованному лицу — как мы должны изменить (воздействовать на) поведение этого действующего лица, чтобы он посодействовал нам в достижении цели?
2. Определяем воздействие на юзеров и других действующих лиц
Это, пожалуй, единственный «вопрос» из всего подхода impact mapping’а, требующий пояснения на примере.
У нас был проект, перед которым была поставлена цель — «увеличить количество пользователей желающих продолжить разбираться с продуктом после триального периода»:
Был сформулирован impact — «shorten time to value», т.е. сократить промежуток времени, который требуется пользователю, чтобы понять какие возможности ему предоставляет продукт, какие его проблемы решаем (начиная с момента, когда пользователь открывает авторан).
Идеально сформулированное воздействие — простое и напрямую влияющее на цель.
По факту было сделано огромное количество изменений в документации, сетапе, GUI и так далее.
Шаг 4. What – Что?
Последний вопрос для построения карты — что?.. Именно на этом этапе появляются фичи.
Нужно понимать, что не всегда для оказания нужного нам воздействия требуется вносить изменения в продукт и что-то девелопить. Порой достаточно изменить документацию, например. Или другой пример — для привлечения пользователей не всегда нужны фичи, альтернативным решением может стать маркетинговая активность и проведение рекламных компаний.
Этапы построения карты
1. Определяем цель, не забывая о требованиях SMART,
2. Выбираем метрику, по которой будем смотреть насколько мы приблизились к цели,
3. Определяем промежуточные этапы для достижения цели (milestones),
4. Рисуем костяк карты, отвечая на четыре ключевые вопроса – why+who+how+what,
5. Ищем возможные альтернативы, причем желательно сфокусироваться не на фичах, а на ролях (who?) и на том, как на них воздействовать,
6. Определяем приоритетные направления на карте,
7. По мере продвижения не забываем удостоверяться, что мы действительно продвигаемся к цели максимально эффективным образом.
Пример карты
Пример честно позаимствован из книги, о которой будет упомянуто ближе к концу доклада.
1. Онлайн игра, преследующая цель расшириться до 1млн игроков (промежуточный этап вырасти в 2раза от 400 до 800к игроков),
2. Выделены несколько ролей, явно видно с достижением цели нам могут помочь не только игроки, но и рекламщики, например,
3. На каждой из веток выделено по несколько воздействий,
4. Фичи в явном виде соответствуют цели. Помните наши проблемы? Здесь мы явно видим что делаем, почему и более того видим несколько альтернативных вариантов движения к цели.
5. Звездочками на ветках карты отмечены приоритетные направления,
6. Ветви карты легко ложатся на пользовательские истории истории (As a… I want to… So that …).
Внедрение Impact Mapping в Dell
Я выступал в роли инициатора, поэтому в первую очередь все внедрение было поделено на этапы.
Время для этапа 1 определилось по звездам, но как выяснилось, конец текущего релиза, время, когда требуется начать выяснять задачи на следующую версию это и есть лучший момент для начала перехода на новые рельсы.
Начал я с того, что продал идею импакт маппинга менеджеру продукта и объяснил ему почему нам нужно жить по новому. Мы обсудили — с какими проблемами мы, как дев команда, обычно сталкиваемся, почему мы ощущаем недостаток понимания — куда движется продукт и почему это плохо.
Для нашего ПМа данный диалог оказался сюрпризом. Впрочем, отрицать очевидное он не стал.
Итак, я представил идею импакт маппинга и настоятельно разжевал, что результат достигается совместными усилиями и что мы не предлагаем ему опять начать единолично писать многостраничные MRD.
После этого я начал потихоньку тянуть из ПМа цель на грядущий релиз, по которому у нас уже был список фичей на обсуждение
1. самым сложным здесь было заставить менеджера поставить конкретную цель, которая была бы измерима и достигалась в ограниченный промежуток времени,
2. из собрания длиной в час, мы только сорок минут бодались вокруг цели, пока не выбрали что-то похожее на правду,
3. лишний раз убедился, что наличие мысли в голове у менеджера продукта не обязательно означает, что он может ее внятно сформулировать.
По окончанию первой встречи мы поделились впечатлениями и договорились
1. еще раз подумать о целях (в том числе и в более долгосрочной перспективе)
2. через неделю собраться снова уже для того чтобы попробовать нарисовать карту
За ту неделю пока менеджер продукта наш естественно НЕ думал о целях, я подготовился к следующему собранию. У меня была драфтовая цель, было понимание, что навряд ли наш менеджер согласится под ноль переработать все то, что у нас уже было ранее занесено в бэклог. Поэтому пришлось произвести некоторый реверс-инжиниринг бэклога и подготовить первый вариант карты на грядущий релиз самому:
1. роли были выявлены достаточно быстро
2. необходимые воздействия тоже
3. но далеко не все фичи удалось связать с поставленной целью. Забегая вперед скажу, что в результате большая часть «нелогичных фичей» была вырезана,
Получившийся черновик был представлен продакт менеджеру.
1. Мы обсудили то, что не вписывалось в цель и зарезали эти фичи/истории,
2. Обсудили чем еще можно сделать в рамках тех ролей, которые уже были выявлены,
3. Появилось несколько новых ролей, для которых не нужно было делать ничего на стороне продукта, кроме как предоставить необходимые материалы (маркетинг, пресейлзы),
На удивление наш продакт менеджер принял крайне активное участие в доработке карты, которая дорисовывалась у него на глазах. Именно благодаря ему на карте появилось большое количество ответвлений, не относящихся к изменениям в продукте.
К заключительной стадии внедрения импакт маппинга на наших продуктах мы начнем через релиз, когда планирование состава фичей на версию будет изначально обрисовываться с помощью импакт маппинга.
Пока что мы просто прощупали насколько успешными окажутся первые попытки.
Отзывы внутри компании
1. Продукт менеджер высказался, что его уже много раз пичкали различными около-скрамовскими методологиями, но именно этот подход его не напрягает и очень ему нравится (естественно ведь карта в зоне ответственности аналитиков и рисуется ими же).
2. Команда проявила хороший интерес к тому, что получилось. Особо им понравилось, что к их мнению прислушиваются, и что они могут предложить обоснованную с точки зрения бизнес-цели фичу.
3. Команда получила компас, с помощью которого проще проводить планирование спринтов и минимизировать споры вокруг очередности историй и деталей их реализации.
4. Наши менеджеры оказались счастливы от того, что теперь для понимания результатов релиз планинга не требуется проводить общую планерку, а достаточно посмотреть на карту. Обсуждение при этом достаточно легко переносится в офлайн.
5. Всем понравилось, что на карту проросла не только деятельность команды, но и в том числе активность которая ранее была теневой (работа маркетинга, проталкивание продукта на уровне бизнеса).
6. Аналитик использует карту на каждом созвоне по текущему состоянию дел (current state call), который проходит каждую неделю и проходится по ключевым веткам карты. Теперь в фокусе получается удерживать большее количество вопросов.
Для того чтобы получить больше информации о данном подходе, крайне рекомендуется одноименная книжка Гойко Аджича.
Источник: http://habrahabr.ru/company/sqalab/blog/213993/
Комментариев нет:
Отправить комментарий