Запомните: результаты, которые мы кладем в основу расстановки приоритетов, – это конкретные изменения в поведении конкретных людей, вовлеченных в конкретные действия и процессы. Сконцентрировавшись на выборах в Бразилии, Globo.com стала ориентироваться лишь на людей, которые следят за новостями – особенно за обновляющимися данными голосования. Но в результате этого за бортом остались зрители мыльных опер, спортивные болельщики и множество других типов пользователей. Этим людям придется довольствоваться старой версией сайта несколько дольше. Помните, что невозможно удовлетворить всех и каждого одновременно.
Волшебство? Так и есть
Конечно, меня немного переполняют эмоции, но разделение действительно одна из самых крутых вещей в организации идей для ПО с помощью карты историй.
Много раз и я сам, и команды, с которыми работал, фиксировали в карте мысли, возникшие по поводу замечательного продукта, а потом ужасались тому, какой огромный объем работы нужен, чтобы воплотить все их в жизнь. Критически важным кажется все! Но затем мы немного остываем и задумываемся о конкретных людях, которые пользуются нашим продуктом, а также о том, что им нужно для достижения успеха. Эти мысли мы излагаем в паре предложений. А потом стоит лишь отсечь все лишнее – и все поражены тем, как на самом деле мало нужно, чтобы выпустить жизнеспособное решение! Это волшебство.
Гэри из главы 1 как раз и проделал нечто подобное. Он изначально сузил область своего внимания до менеджера группы, фанатов, а также администратора Mimi – нужно ведь, чтобы кто-то поддерживал сайт. Владельцев концертных площадок и авторов музыкальных фрагментов ему пришлось оставить на потом. В итоге, остановившись всего на нескольких типах пользователей и основном процессе рекламного продвижения, Гэри создал потрясающую платформу для рассылок по электронной почте. Может быть, вы сами являетесь пользователем Mimi и знаете, как она работает.
Когда мы излагаем свои мысли на большой красивой карте, все эти шаги сделать проще. С ее помощью множество людей могут работать вместе, чтобы прийти к общему решению.
Поиск маленького жизнеспособного релиза
Крис Шинкл, SEP
FORUM Credit Union – один из самых больших и технически развитых кредитных союзов в стране. Хотя культура разработки ПО в компании отличается и креативностью, и компетентностью, ее сотрудники обратились в SEP за помощью в создании новой банковской онлайн-системы, которая должна была конкурировать с типовыми коммерческими решениями. Целью было добавление возможности пользоваться мобильным банкингом, СМС-банкингом, а также лично управлять своими финансами.
SEP начала работу с двухдневной исследовательской сессии составления карты историй, включающей результаты, персонажей и сами истории. В результате хорошо организованного обсуждения удалось получить большой набор предположений по поводу необходимой функциональности, отсортированный по приоритетности, однако для расстановки по приоритетности историй результатов и персонажей оказалось недостаточно. Но к концу второго дня карта историй занимала две стены в 1000-футовом
[9] кабинете отдела разработки!
После того как карта была составлена, SEP обучила сотрудников FORUM составлять простую модель расстановки приоритетов.
• Конкурентное преимущество – преимущество, которое отличает их от конкурентов.
• Спойлер – функциональность, которая стремится перекрыть чужое конкурентное преимущество.
• Фактор снижения затрат – функциональность, введенная для снижения затрат организации.
• Минимальный пакет – минимальный набор функций, необходимый для успешного конкурирования на рынке.
SEP обозначила категорию каждой истории стикерами разных цветов, что вызвало любопытные обсуждения. Как оказалось, то, что одни участники считали конкурентным преимуществом, с точки зрения других являлось минимальным пакетом. Еще интереснее было то, что об этом, очевидно, говорилось впервые! Карта историй с моделью расстановки приоритетов заставила людей обсудить вопросы, которые раньше никогда не возникали! В результате этой работы члены команды наконец пришли к общему мнению относительно приоритетов.
После сортировки историй SEP использовала систему голосования, чтобы помочь участникам свести воедино их замыслы и результаты обсуждений, а затем прийти к четкому набору функций, нацеленному на результат. К удивлению всех присутствующих, оказалось, что некоторые истории можно отложить на неопределенный срок или исключить вовсе. Только по самым общим подсчетам это сэкономило компании несколько сотен тысяч долларов еще до написания первых строк кода.
Дуг Тру, генеральный директор FORUM, о значении карт историй для запуска проекта сказал так: «Когда мы начали работу по проекту с использованием карт историй и персонажей, я чувствовал некоторый скепсис. Честно говоря, мне казалось нецелесообразным тратить на это время. Но на следующий день польза от потраченного времени стала очевидной. Сейчас я уже не могу представить себе запуск такого большого и сильно затрагивающего интересы пользователей проекта без этого предварительного процесса».
Почему никто не любит МЖП
Термин «минимально жизнеспособный продукт» (МЖП) давно используется в индустрии программного обеспечения. Хотя первое его употребление приписывают Фрэнку Робинсону, сейчас более популярны определения Эрика Райса или Стива Бланка. Хотя множество умных людей пытались объяснить, что такое МЖП, многие, включая меня, так и не могут толком разобраться в этом понятии. В каждой организации, где мне доводилось слышать этот термин, под ним подразумевалось что-то свое. Бывало даже, что люди, работавшие в одной организации, в разговорах друг с другом подразумевали под МЖП разные вещи.
Как и большинство слов в словаре, этот термин имеет несколько значений. Я приведу три примера определений: одно плохое и два хороших.
Начнем с плохого.
Минимально жизнеспособный продукт – это не самый ужасный продукт, который вы потенциально способны выпустить.
Но МЖП – это не продукт, с которым могут работать ваши пользователи, – разве что в самых простых обстоятельствах, да и то при условии высокого болевого порога. Тем не менее я регулярно вижу организации, пытающиеся довести до ума ужасные продуктовые решения, чтобы «кто-нибудь мог использовать продукт», хотя каждому участнику этой работы очевидно, что он сам не стал бы с ним мучиться.
