Пользовательские истории. Искусство гибкой разработки ПО - [72]

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

Если вы сейчас читали внимательно, то, конечно, уже поняли, в чем секрет расстановки приоритетов.

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

Работая над MadMimi, Гэри принял взвешенное решение сконцентрироваться на достижении целей менеджеров, рекламирующих свои ансамбли. Это и была конкретная ценность, которую он поставил своей основной целью. Он не использовал абстрактное понятие «ценность для бизнеса», а совершенно конкретно определил то, что будет иметь ценность для него.

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

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

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

Действия, обсуждения и артефакты в исследовании

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

Цель исследования – выработка одинакового понимания

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

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

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

Глава 15. Эмпирическое обучение через исследование

Вообще-то частично я ввел вас в заблуждение.

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

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

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

Большую часть времени мы ошибаемся

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