Давайте снова вернемся к MadMimi. Гэри нужно было придумать продукт, который быстро завоевал бы определенный рынок, прежде чем закончатся деньги. Жизнеспособность, с точки зрения Гэри, означала, что у него были бы клиенты, полюбившие продукт и готовые за него платить. Затем он начал бы увеличивать аудиторию продукта и, как следствие, свою прибыль.
Данная бизнес-цель в сочетании с финансовыми ограничениями заставила Гэри сконцентрироваться на конкретных пользователях и их задачах, которых он решил поддерживать. Гэри не оставлял надежду создать «маркетинговый интерфейс музыкальной индустрии», давший Mimi название, но для начала решил сфокусироваться на задачах менеджера, рекламирующего свою музыкальную группу с помощью прямой электронной рассылки фанатам. Как только Гэри принял это решение, конкретные функциональности, над которыми следовало работать, стали яснее ясного.
Если вы сейчас читали внимательно, то, конечно, уже поняли, в чем секрет расстановки приоритетов.
Конкретные результаты, необходимые бизнесу, устанавливают фокус на конкретных пользователях, их целях, а также действиях, которые они проделывают в нашем продукте. Фокус же на действиях, в свою очередь, привлекает наше внимание к каким-то конкретным функциям и инструментам, которые нужны пользователям для достижения своих целей.
Работая над MadMimi, Гэри принял взвешенное решение сконцентрироваться на достижении целей менеджеров, рекламирующих свои ансамбли.
Ошибка большинства людей в том, что они пытаются сперва расставить приоритеты функциональностей.
В следующий раз, услышав, как кто-то интересуется, у какой функциональности самый высокий приоритет, без обсуждения бизнес-целей, целевых пользователей и ценности для них, сочтите это хорошей возможностью начать задавать вопросы. Постарайтесь не быть слишком высокомерным: все-таки не все знают этот секрет.
Действия, обсуждения и артефакты в исследовании
Существует очень много действий, которые вы и ваша команда можете проделать, и артефактов, которые вы можете создать, проводя исследование. Эта простая таблица даст вам некоторое представление о том, что вы можете использовать. Не стоит пытаться выполнить сразу все – это излишне, но и не ограничивайтесь лишь тем, что перечислено здесь, ведь наверняка существуют и другие методы, которые больше подойдут в вашей ситуации с учетом имеющихся у вас возможностей и навыков. Главное – не просто сидеть в комнате и писать бесконечное количество историй. Это глупо.
Цель исследования – выработка одинакового понимания
Приходилось ли вам когда-нибудь работать над проектом программного продукта, где никто как следует не представлял себе картину в целом? Приходилось ли вам сталкиваться с ситуацией, когда в разгар разработки команда обнаруживала, что необходимо сделать большой незапланированный кусок работы? Когда такое случалось со мной, нередко оказывалось, что среди членов нашей команды и людей со стороны, которые сотрудничали с нами, хоть кто-нибудь да имел необходимые сведения. Чтобы избежать проблем, нам нужно было всего лишь иметь полное взаимопонимание.
Отчасти история Гэри из главы 1 как раз об отсутствии общей картины у него самого и его команды разработки. Даже сам Гэри, в голове которого родился продукт, не осознавал до конца сложности и размера этого проекта. Визуализация продукта в виде ряда простых моделей помогла ему и всем, кто ему помогал, нарисовать одну и ту же цельную картину в своем сознании.
Для некоторых создаваемых вами вещей может быть вполне достаточно достичь взаимопонимания относительно заказчиков и пользователей, а также формулировки найденного решения. Но хочу предостеречь: ваши гипотезы о том, что вы создаете, вполне могут быть неверными. Не беспокойтесь, как раз в следующей главе я собираюсь рассказать о нескольких стратегиях, которые помогут вашим исследованиям стать максимально эффективными.
Глава 15. Эмпирическое обучение через исследование
Вообще-то частично я ввел вас в заблуждение.
Многие из вас, наверное, читали предыдущую главу и другие главы перед ней, медленно закипая, так как я, очевидно, упускаю самое интересное. Сожалею об этом.