Пользовательские истории. Искусство гибкой разработки ПО — страница 11 из 47

«И что, все-все это необходимо реализовать?» – спросил я, на что они, конечно, ответили:

«Разумеется! Это же все части одной большой системы управления контентом!»

«Но ведь обычно вы не делаете проекты так долго. Я знаю вашего генерального директора, он наверняка захочет увидеть результаты гораздо раньше, верно?»

«Так и есть, – подтвердили они. – Он хочет видеть что-то рабочее к выборам в Бразилии, то есть через несколько месяцев».

«А нужно ли, чтобы к этим выборам работало все

Ага! Стоило мне задать этот вопрос, как у них в головах словно зажглась лампочка. Конечно же, все им было не нужно. До этого момента они концентрировались на выявлении последовательностей и зависимостей, предполагая, что должны реализовать все задуманное. Это было возможно, вопрос только в сроках. Но теперь наконец фокус сместился на реалистичный результат.

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

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

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

Отделите релиз минимального работоспособного продукта

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



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

Фокусируйтесь на результате – что пользователи увидят и будут способны сделать, когда система выйдет в свет, – и запланируйте выпуск только того, что обеспечит этот результат.

Составьте план релизов

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

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



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

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

Секрет выбора приоритетов при разработке программ – концентрация на конкретных ожидаемых результатах.

Обратное тоже верно: если вы не можете определиться, каких результатов ожидаете, каких конкретных выгод хотите достичь, расставить приоритеты практически невозможно.

Не пытайтесь расставить приоритеты в функциональностях вместо результатов

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

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

Волшебство? Так и есть

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

Много раз и я сам, и команды, с которыми работал, фиксировали в карте мысли, возникшие по поводу замечательного продукта, а потом ужасались тому, какой огромный объем работы нужен, чтобы воплотить все их в жизнь. Критически важным кажется все! Но затем мы немного остываем и задумываемся о конкретных людях, которые пользуются нашим продуктом, а также о том, что им нужно для достижения успеха. Эти мысли мы излагаем в паре предложений. А потом стоит лишь отсечь все лишнее – и все поражены тем, как на самом деле мало нужно, чтобы выпустить жизнеспособное решение! Это волшебство.

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

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

Поиск маленького жизнеспособного релиза

Крис Шинкл, SEP

FORUM Credit Union – один из самых больших и технически развитых кредитных союзов в стране. Хотя культура разработки ПО в компании отличается и креативностью, и компетентностью, ее сотрудники обратились в SEP за помощью в создании новой банковской онлайн-системы, которая должна была конкурировать с типовыми коммерческими решениями. Целью было добавление возможности пользоваться мобильным банкингом, СМС-банкингом, а также лично управлять своими финансами.

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



После того как карта была составлена, SEP обучила сотрудников FORUM составлять простую модель расстановки приоритетов.

• Конкурентное преимущество – преимущество, которое отличает их от конкурентов.

• Спойлер – функциональность, которая стремится перекрыть чужое конкурентное преимущество.

• Фактор снижения затрат – функциональность, введенная для снижения затрат организации.

• Минимальный пакет – минимальный набор функций, необходимый для успешного конкурирования на рынке.

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



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