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

При составлении impact map мы уже на входе должны иметь правильно сформулированную измеримую цель. Поэтому важно проводить обсуждение в два этапа: на первом мы формулируем цель и подбираем контрольные параметры, а на втором – рисуем саму карту.

 

Подготовительный этап 1: Сформулируйте бизнес-цель

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

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

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

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

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

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

 

Подготовительный этап 2: Выберите эффективные метрики

Отправной точкой при составлении impact maps являются четко сформулированные цели проекта. Мой опыт подсказывает, что даже в тех случаях, когда бизнес-цели определены (например, «рост числа игроков»), крайне полезно обсудить показатели, которыми будет измеряться их достижение. Обычно это позволяет внести дополнительную ясность относительно достижимости этих целей и распределить их в порядке важности. После того как вы ознакомитесь со «списком покупок» (документы, описывающие границы проекта, списки фич, предлагаемые к реализации пользовательские истории и т. д.) и обозначите потенциальные бизнес-цели, следует дополнительно конкретизировать их, выбрав ключевые параметры.

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

• что мы собираемся измерять (Гилб называет это «объект измерений»);

• как мы будем измерять его («параметр»);

• какова ситуация на данный момент («бенчмарк»);

• минимально допустимое значение, точка безубыточности для инвестиций («ограничение»);

• целевой показатель («цель»).

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

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

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

ЭКСПЕРИМЕНТИРУЙТЕ С НАЗВАНИЯМИ

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

 

Подготовительный этап 3: Наметьте первую контрольную точку

После того как у вас возникнет список целей и соответствующих им параметров, проанализируйте его еще раз. Убедитесь, что все цели и параметры действительно относятся к текущему этапу проекта, и если возможно, отложите некоторые из них. Как правило, в «списке покупок» существует только одна доминирующая цель – и очень важно, чтобы люди, отвечающие за бизнес-составляющую проекта, были с ней согласны. Я часто прибегаю к голосованию: в процессе каждый из присутствующих получает несколько стикеров, чтобы прикрепить их к тем целям, которые ему представляются наиболее важными. Если для голосования использовать виртуальные деньги, то иногда удается получить более точные результаты. Создайте условные наличные (например, указав на листочках номинал £100) и раздайте их участникам голосования таким образом, чтобы каждый получил меньше «купюр», чем имеется потенциальных целей. Еще одна опция – раздать участникам голосования деньги для игры в «Монополию» или любые другие деньги, используемые в настольных играх, – их можно купить практически в любом магазине игрушек. Попросите заказчиков «инвестировать» эти средства в бизнес-цели, которые им представляются наиболее ценными. Количество стикеров или выраженный в виртуальных деньгах бюджет, предназначенный для той или иной цели, в итоге дадут вам список приоритетов.

Команды, ведущие итеративную разработку, должны по возможности единовременно трудиться только над одной целью. Лучше выполнить пять последовательных этапов, каждый из которых имеет только одну бизнес-цель, чем один этап, подразумевающий частичное достижение пяти целей сразу. Причина в том, что ландшафт может измениться после того, как вы добьетесь первой цели. Поэтому можно разделить этап с двумя ключевыми целями (скажем, рост числа игроков с 300 000 до 1 миллиона и сокращение затрат на IT на 40 %) на два. Целью первого будет увеличение числа игроков при сохранении затрат на IT на прежнем уровне, а второго – сокращение затрат на IT без негативного влияния на число игроков. Когда цели распределены между этапами, вторая цель становится активной сразу же после того, как первая окажется позади.

Если для достижения первой цели требуется слишком много времени или слишком рискованно ждать, пока число игроков достигнет 700 000, то, прежде чем взяться за сокращение затрат на IT, следует пересмотреть имеющиеся цели. Целью первого этапа могло бы стать увеличение количества пользователей до 100 000, а второго – сокращение расходов на IT. Затем вы можете вернуться к задаче дальнейшего увеличения числа игроков.

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

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

Если ответ «нет», вернитесь к началу: вы выбрали неправильные целевые параметры.

 

Составление impact map: Этап 1 создание «скелета» карты

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

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

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

• Реалистично ли наше ожидание, что данная функциональность будет способствовать оказанию необходимого влияния?

• Правда ли это влияние способно воздействовать на данное лицо?

• Действительно ли данное влияние будет способствовать достижению цели?

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

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

 

Составление Impact map: Этап 2 поиск альтернатив

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

• Что еще эти люди могли бы для нас сделать?

• Кто еще может нам помочь? Каким образом?

• Кто может нам помешать?

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

Если вы хотите по максимуму использовать потенциал команды, можно воспользоваться какой-либо из кооперативных игр, описанных в книгах «Бизнес-игры» [Hohmann, 2006] и «Геймшторминг» [Gray, 2010].

 

Составление Impact map: Этап 3 определение ключевых приоритетов

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

• Какие решающие факторы могут остановить нас еще до начала разработки?

• Есть ли какие-либо влияния, которые мы можем оказать без особых усилий?

• Какие ключевые гипотезы необходимо протестировать?

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

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

Улучшаем структурированность карты

Если вы хотите сделать обсуждение еще более последовательным, ознакомьтесь с моделью Кано и моделями, направленными на синхронизацию проектных целей со стратегическими приоритетами компаний. В модели Кано [Cohn, 2006] используется опросник, помогающий разделить ожидаемую функциональность продукта на несколько категорий: базовая (продукт не может ее не иметь), линейная (чем ее больше, тем лучше) и восхищающая (ее присутствие даже в ограниченной степени может существенным образом повысить удовлетворенность продуктом). В модели синхронизации целей [Pixton, 2009] различные категории функциональности определяются как критически важные для рыночной дифференциации продукта, сравнимые (должны быть не хуже, чем в других аналогичных продуктах), партнерские (некритичные для миссии продукта, их можно приобрести в составе других продуктов) и безразличные для потребителя (допустимо вообще не включать).

 

Составление Impact map: Этап 4 обучение на ошибках

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

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

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

• Как проще всего поддержать данную активность? Что еще мы могли бы сделать?

• Если мы не уверены в своей гипотезе, как ее проще всего протестировать?

• Можем ли мы протестировать ее, не прибегая к созданию кода?

• Можно ли привести данную гипотезу в рабочее состояние, даже если поначалу часть операций будет совершаться вручную?

Если для того, чтобы протестировать ключевые гипотезы, у вас не получается сознательно ограничить масштаб проводимого эксперимента, попробуйте воспользоваться картами пользовательских историй Паттона [Patton, 2008 и Patton, 2009] или «методом гамбургера» [Adzic, 2012], которые помогают разделить итеративную разработку на небольшие фрагменты и быстро получить подтверждение своей гипотезы или как минимум – сделать полезные для дальнейшей разработки выводы.

Задайте вопрос: «Уверены ли мы, что гипотеза, лежащая в основе пункта #1 нашей карты, является верной?»

Если ответ «нет», найдите способ проверить эту гипотезу, не выходя за рамки имеющегося «бюджета на обучение»!

 

Отображение метрик на карте

 

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

 

Добавить показатели в виде отдельных пунктов списка

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

 

Переименование узлов

Когда к конкретному узлу карты относятся всего один или два ключевых показателя, мы можем просто переименовать его, включив в название соответствующие параметры. Так, название узла «рост числа игроков» можно изменить на «рост числа игроков до 800 000–1 млн в течение 6 месяцев». Это одинаково эффективно как для метрик, относящихся к главной цели проекта, так и для ориентированных на измерение влияний. Так структура impact map не изменяется и остается предельно ясной. Его недостаток в том, что текст, размещенный внутри конкретного узла, становится длиннее. Из-за этого данный способ удачен только тогда, когда ключевых показателей, относящихся к данному узлу, не так много. При переименовании узлов часто приходится опускать еще больше информации, чем при использовании маркированных списков.

 

Показатели собраны в отдельной таблице

Если предполагается, что ключевых показателей будет много, и вы хотите отразить всю информацию о них (например, вы работаете над отдельным документом, который необходимо разослать заинтересованным лицам со стороны), то не исключено, что лучше всего свести показатели в отдельную таблицу и целиком разместить ее на impact map. Данный способ позволяет организовать внушительный объем информации, не усложняя при этом саму карту. Его недостаток – для обсуждения хода проекта одной карты теперь недостаточно. При работе с маркерными досками большой площади я часто использую одну половину для отображения ключевых показателей, а вторую половину – для самой карты. В этом случае основная информация видна всем в полном объеме.

 

Добавление дополнительных узлов

В книге «Управление IT-проектами через эффекты» (Effect Managing IT) Балич и Домингес предлагают отражать показатели на карте, вводя в нее дополнительные узлы. Преимущество этого способа состоит в том, что он позволяет отобразить полную информацию о контрольных показателях и даже расставить их в иерархическом порядке. Этот подход работает в любых приложениях для ментальных карт, поскольку для метрик создаются стандартные дополнительные ветви. Недостаток подхода – усложняется структура карты и общая картина порой выглядит несколько запутанной, поскольку разные понятия могут оказаться на одном и том же уровне. В частности, становится сложнее воспринимать показатели, которые относятся к влияниям, а не только к бизнес-целям.

 

Предварительные итоги

Impact maps вместе с измерением контрольных показателей позволяют повысить сосредоточенность проектов на целях, синхронизировав их с глобальными стремлениями организации. Но именно поэтому impact maps могут превратиться в очередную ловушку, которая приведет к провалам, сравнимым с провалами в городском строительстве и сельском хозяйстве, от которых предостерегает Джеймс Скотт. Он показывает, каким образом планы, сфокусированные на достижении одного конкретного результата (как правило, коммерческого характера) поначалу имеют все шансы преуспеть («нельзя отрицать чрезвычайную силу подобного подхода для увеличения урожаев»). Однако при этом возникают «слепые пятна» по отношению ко всему, что осталось вне суженного поля зрения проектантов, в частности, долгосрочные результаты и влияние, которое оказывается на третьи стороны. Такие проблемы, как правило, остаются незамеченными до тех пор, пока они не начинают негативно влиять на изначальные цели проекта. Но в этот момент часто уже слишком поздно что-либо менять.

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

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

По мнению Тома Гилба, стоимость каждой итерации в ходе проекта не должна превышать 2 % от общего объема инвестиций. Эрик Рис рекомендует проводить регулярные совещания, в центре внимания которых должен быть вопрос о том, стоит ли придерживаться избранного курса или необходимо коренным образом изменить направление разработки. С самого начала договоритесь с командой, как часто вы собираетесь оценивать, насколько вы продвинулись к цели: например, раз в неделю или раз в месяц. Постарайтесь сразу определить, какого рода события должны указывать на необходимость поддержания или изменения курса и в какие сроки.

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

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

Крупномасштабные карты

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

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

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

 

Типичные организационные ошибки

 

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

 

Задействовано слишком много людей

Работая в одиночку, невозможно воспользоваться «мудростью толпы». В то же время чем больше людей присутствует в совещаниях, тем труднее модератору выполнять свою роль. Оптимальное количество участников особенно важно для подготовительного этапа, цель которого состоит в том, чтобы определиться с бизнес-целями и контрольными параметрами. Каждому из собравшихся захочется высказать свое мнение, а если в комнате собралось 20 человек, то первый раунд может занять несколько часов. Поэтому при проведении первого совещания постарайтесь ограничиться пятью или шестью участниками. Убедитесь, что присутствуют все ключевые технические руководители и лица, принимающие решения со стороны бизнеса. Если вам все же приходится работать с большой группой, разделите ее на несколько подгрупп, которые должны будут провести обсуждение параллельно, а затем представить свои результаты. На втором совещании может присутствовать от 10 до 20 человек – это позволит в полном объеме воспользоваться преимуществами дивергентного мышления с последующим синтезом. Чтобы при такой численности участников обсуждение было эффективным, необходимы услуги модератора. Профессионального модератора нанимать необязательно, но следует убедиться, что есть по крайней мере один человек, который может взять на себя его роль. Его задача состоит в том, чтобы продвигать обсуждение вперед (модератору необязательно самому вносить предложения по заполнению карты). Проводя совещание, модератор обязан контролировать использование времени: ни у кого из участников не должно быть возможности продавливать свои частные интересы и все должны успеть задать правильные вопросы.

 

Неправильный подбор участников

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

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

 

Планировка помещения

Идеальная планировка облегчает взаимодействие, позволяя людям временно объединяться в группы, переходить от группы к группе и обратно. Наихудший вариант планировки – аудитория или класс с немобильными стульями: все просто уснут. Неудобны и варианты планировки, где 90 % полезной площади занимает большой стол. В конце концов, вы же не собираетесь проводить встречу с целью подписания мирного договора, а просто хотите разработать хорошую дорожную карту. Рассадка вокруг большого стола провоцирует людей играть во время выступлений со своими мобильными телефонами, а не участвовать в работе. Меня не раз отчитывали офис-менеджеры за то, что я сдвигал все столы в одну сторону комнаты – но дело того стоило. Предоставьте людям пространство, где им будет легко передвигаться и взаимодействовать, и они ответят вам тем, что начнут активно предлагать более эффективные идеи.

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

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

 

Типичные ошибки модерации

 

 

Слишком ранняя критика

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

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

 

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

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

 

Реверс-инжиниринг

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

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

Хороший прием – разделить группу на небольшие подгруппы, каждая из которых должна заняться какой-либо частью первоначального списка и найти способ отобразить его в базовой версии карты. Через 15–20 минут соберите всех вместе и обсудите результаты. Сотрудничество в отдельных группах должно психологически подготовить участников к следующему шагу. Карты, где скомбинировано несколько вариантов, представленных разными группами, должно быть достаточно, чтобы склонить участников к обсуждению альтернативных действующих лиц и влияний.

 

Погружение в излишние детали на ранних этапах

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

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

 

Типичные ошибки при составлении Impact map

 

 

Прыгун с шестом

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

 

Астронавт

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

 

Сюрреалист

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

 

Любитель шопинга

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

 

Оптимист

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

 

Мечтатель

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

 

Робот

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

 

Осьминог

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