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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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