Гойко Аджич - Impact mapping: Как повысить эффективность программных продуктов и проектов по их разработке

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

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

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

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

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

3. Закулисные действующие лица, которые имеют заинтересованность в проекте, но непосредственно не извлекают из него выгоду и не предоставляют услуги. Пример – государственные агентства, регулирующие данный вид деятельности, лица, принимающие решения на самых высоких уровнях в соответствующих компаниях.

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

• Майк Смит из отдела маркетинга.

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

• Сотрудники Apple, утверждающие приложения, прежде чем разместить их в iTunes.

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

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

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

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

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

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

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

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

• Возможность пригласить друзей принять участие в онлайн-игре.

• Возможность приобрести билеты без звонка в колл-центр.

• Более быстрая продажа билетов.

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

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