Текст книги "Пользовательские истории. Искусство гибкой разработки ПО"

Глава 2. Планируйте разработать меньше

У вас никогда не будет достаточно людей, времени или денег, чтобы разработать все, что нужно. Никогда.

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

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

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

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

Сотрудникам Globo.com лучше, чем кому-либо на планете, известно, что такое дедлайны, не подлежащие смещению. Например, компания хочет выпустить новую версию Fantasy Football Game – браузерной игры, которая дополняется и обновляется регулярно к чемпионату мира по футболу – самому громкому событию в футбольном мире. Если Globo.com не будет успевать к чемпионату, то перенос даты выхода игры их не спасет. Почему? Да потому что никто не изменит дату начала чемпионата. Globo.com планирует также выпустить разную функциональность и контент к Олимпийским играм, которые пройдут в Бразилии в 2016 году[8]8
  Книга вышла в 2014 году. – Примеч. ред.


[Закрыть], и я могу гарантировать, что это будет сделано вовремя – иначе никак! Кроме того, в компании выпускается масса функциональности и контента к выходу огромного количества телевизионных программ и реалити-шоу. Ничто из этого не может быть перенесено, если Globo.com запаздывает с разработкой. Компания всегда должна закончить работу вовремя. И так как это очень важно для бизнеса, Globo.com отлично справляется. Не потому, что люди там работают быстрее, чем в любом другом месте, – быстро, конечно, но не настолько быстро. Секрет в том, что они умеют делать меньше.

Составление карт помогает достичь единого мнения в больших группах

Посмотрите на рисунок.

Это всего лишь фрагмент огромной карты, созданной в результате совместной работы представителей восьми команд из трех разных групп Globo.com. Команды из «Спорта», «Новостей» и «Развлечений» составили вместе эту карту, чтобы продумать и распланировать работу, которая потребуется для преобразования, модернизации и обновления их основной системы управления контентом. С помощью этой системы компания управляет всеми сайтами новостей, спортивных событий, мыльных опер, публикует рекламу, ищет гостей реалити-шоу и делает еще многое. Такая огромная система должна быть способна обработать огромное количество видеофайлов и фотографий, счетчики и итоги голосования в реальном времени, экстренные новости и т. д. Система должна делать очень многое, и делать это без проблем.

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

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

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

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

Карта историй продукта, с которым работают несколько команд, визуализирует зависимости.

Анатомия большой карты

Карта Globo.com – хороший пример того, на что похожа типичная карта после того, как вы обрисовали, связали и исследовали множество деталей.

Карту организует каркас

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

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

Карта и ее значение для совместного выпуска продукта

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

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

Карта в изложении истории, включающей много пользователей и систем

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

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

Хроника повествования такой большой системы затрагивает множество различных пользователей и системных историй. Мне удобно располагать наклейки или простые ярлычки с обозначением персонажей над каркасом, в результате чего легко понять, о ком конкретно мы говорим на определенном этапе истории. Можно очеловечить в том числе и процессы сервера или какие-либо компоненты, имеющиеся в системе. Например, мои друзья в SAP для элементов системы создают фантастических персонажей и используют изображения R2D2 или C3PO из «Звездных войн».

Карты помогают вам распознать дыры в истории

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

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

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

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

Свои границы расширяет понимание, а не проект.

Всегда слишком много

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

«Задача слишком велика! Нужно сделать так много и это займет так много времени!» – говорили сотрудники Globo.com.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Крис Шинкл, SEP

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

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


[Закрыть] кабинете отдела разработки!

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

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

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

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

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

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

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

Дуг Тру, генеральный директор FORUM, о значении карт историй для запуска проекта сказал так: «Когда мы начали работу по проекту с использованием карт историй и персонажей, я чувствовал некоторый скепсис. Честно говоря, мне казалось нецелесообразным тратить на это время. Но на следующий день польза от потраченного времени стала очевидной. Сейчас я уже не могу представить себе запуск такого большого и сильно затрагивающего интересы пользователей проекта без этого предварительного процесса».