сть и контент к Олимпийским играм, которые пройдут в Бразилии в 2016 году[8], и я могу гарантировать, что это будет сделано вовремя – иначе никак! Кроме того, в компании выпускается масса функциональности и контента к выходу огромного количества телевизионных программ и реалити-шоу. Ничто из этого не может быть перенесено, если Globo.com запаздывает с разработкой. Компания всегда должна закончить работу вовремя. И так как это очень важно для бизнеса, Globo.com отлично справляется. Не потому, что люди там работают быстрее, чем в любом другом месте, – быстро, конечно, но не настолько быстро. Секрет в том, что они умеют делать меньше.
Составление карт помогает достичь единого мнения в больших группах
Посмотрите на рисунок.
Это всего лишь фрагмент огромной карты, созданной в результате совместной работы представителей восьми команд из трех разных групп Globo.com. Команды из «Спорта», «Новостей» и «Развлечений» составили вместе эту карту, чтобы продумать и распланировать работу, которая потребуется для преобразования, модернизации и обновления их основной системы управления контентом. С помощью этой системы компания управляет всеми сайтами новостей, спортивных событий, мыльных опер, публикует рекламу, ищет гостей реалити-шоу и делает еще многое. Такая огромная система должна быть способна обработать огромное количество видеофайлов и фотографий, счетчики и итоги голосования в реальном времени, экстренные новости и т. д. Система должна делать очень многое, и делать это без проблем.
В тот день, когда я пришел в офис Globo.com, они как раз составили эту карту и, судя по всему, вот-вот должны были угодить в ловушку плоского бэклога. Отдельные команды разработали собственные бэклоги с элементами, расставленными по степени важности. Было понятно, что предстоит огромный объем работы и что каждая группа зависит от остальных. Например, для хорошего новостного сайта требовалась работа не только группы новостей, но и других, которые создадут основные компоненты, нужные сайту для работы: фотографии, видео, данные, полученные в реальном времени, и еще многое.
Мы сели за стол, и я напомнил всем кое-что уже известное: «Я понимаю, что вы все принадлежите к разным командам, потому что концентрируетесь на разных областях, но тут у вас полноценная переработка одной системы управления контентом. Выпускать продукт вы будете вместе. И не сможете запланировать релиз, пока у вас не будет общего видения. Вам надо визуализировать все эти зависимости».
Они согласились со мной и быстро принялись за работу: нужно было преобразовать в карту все индивидуальные бэклоги. За несколько часов карта была готова и размещена на стене с помощью стикеров, после чего история работы с системой управления контентом стала видна как на ладони.
Я не присутствовал при совместной работе членов команды над созданием карты, но, вернувшись позднее в этот же день, был поражен тем, как быстро им удалось это проделать. Они относились друг к другу доброжелательно и рассматривали мнение каждого. Оказалось, что удобнее всего организовать несколько комплексных бэклогов, которые вместе составляли одну связную историю. Таким образом, каждая команда могла видеть, как их работа встроена в общую картину.
Карта историй продукта, с которым работают несколько команд, визуализирует зависимости.
Карта Globo.com – хороший пример того, на что похожа типичная карта после того, как вы обрисовали, связали и исследовали множество деталей.
Карту организует каркас
Вверху карты историй располагается каркас, который иногда имеет несколько уровней. Вы можете начать с базовой истории одного уровня, но по мере того, как она развивается и удлиняется, целесообразно ввести еще один или несколько уровней, чтобы в дальнейшем было проще подвести итог. Позднее я немного уточню терминологию, относящуюся к тому, что следует помещать на каждый уровень, но один старый друг напомнил мне, что не всегда нужно стремиться изъясняться точно. «Есть важные вещи, а есть мелочи», – сказал он. И это абсолютно верно.
Все это выглядит так, будто вы откопали скелет какого-то неведомого фантастического животного. Наверху вы размещаете этот скелет с множеством позвонков, находящихся на произвольном расстоянии друг от друга, и выпирающими ребрами деталей разной длины.
Карта и ее значение для совместного выпуска продукта
Эта карта была создана различными командами Globo.com. Над ней работали команды, ответственные за видеоматериалы, и команды, создающие ПО для внутреннего пользования, применяемое редакторами для создания контента и управления им. Были команды, ответственные за метаданные и связи между данными – всю эту семантическую разметку, в которую я, честно говоря, никогда не вникал. Были и те, кто занимался внешним представлением и обеспечивал хорошую картинку для конечных пользователей и/или потребителей. И конечно, много людей, выполняющих специфические функции, связанные со спортом, новостями или развлечениями.
Работа нескольких команд над картой была необходима потому, что ни одна команда не могла реализовать свою часть масштабной реорганизации без взаимодействия с остальными. Команды создали одну общую карту, потому что на протяжении этой работы они должны были думать как одно целое.
Карта в изложении истории, включающей много пользователей и систем
Карта началась с того, что слева обозначили названия специалистов, а также их действия по настройке расположения на экране текста, иллюстраций и видео. Затем в дело вступали другие люди, которые из этих материалов формировали страницы сериалов или новостных веб-сайтов. После них – редакторы, которые добавляли на страницы контент. Таким образом, весь каркас повествовал о том, как много людей в Globo.com занято конструированием контента на веб-сайте и управлением этим контентом.
Когда вы читаете каркас слева направо, он рассказывает историю обо всех людях, которые используют систему и производят какие-то действия для того, чтобы создать и настроить страницы и контент. Порядок слева направо я называю хроникой повествования – это такой академический способ обозначить последовательность изложения истории. Разумеется, все упомянутые в ней люди делают свою работу одновременно, иногда процессы и вовсе протекают довольно беспорядочно – это понятно. Мы просто располагаем составляющие в порядке, удобном для формирования истории.
Хроника повествования такой большой системы затрагивает множество различных пользователей и системных историй. Мне удобно располагать наклейки или простые ярлычки с обозначением персонажей над каркасом, в результате чего легко понять, о ком конкретно мы говорим на определенном этапе истории. Можно очеловечить в том числе и процессы сервера или какие-либо компоненты, имеющиеся в системе. Например, мои друзья в SAP для элементов системы создают фантастических персонажей и используют изображения R2D2 или C3PO из «Звездных войн».
Карты помогают вам распознать дыры в истории
Когда я разговариваю с людьми, которые уже составляли карты историй, они всегда признаются: «Каждый раз, составляя истории, мы находим дыры! Мы обнаруживаем, что другая команда должна была что-то сделать, но они, как оказалось, этого не знали. Мы обнаруживаем важные вещи и очень важные функции, которые забыли обсудить!»
После того как вы визуализировали весь продукт или какую-то функциональность, гораздо проще играть в игру «Что, если». Именно в этот момент мы начинаем задумываться: «Что будет, если что-то пойдет не так?» или «А что с этими, другими пользователями?». Играйте во «Что, если» с любыми сомнениями, которые у вас есть, и добавляйте наклейки в основную часть карты, где затем появятся идеи, которые нужно воплотить в программном обеспечении. В главе 1 Гэри играл во «Что, если», рассматривая варианты и альтернативы. Когда вы и другие команды проделаете это, то удивитесь тому, какое огромное количество проблем может обнаружиться при взаимодействии разных команд.
Один из часто приводимых аргументов, которые озвучивают, возражая против составления карт историй, заключается в том, что, когда команды садятся и составляют карты историй, на выходе получается слишком много всего. Но я убежден, что таким образом выявляются проблемы, с которыми так или иначе придется столкнуться позже, и в целом это скорее плюс, чем минус.
При традиционном подходе к разработке программного обеспечения ситуацию, когда что-либо новое обнаруживалось на одном из поздних этапов – уже после того, как было рассчитано время разработки и утверждена дата выхода, – мы называли расширением границ проекта. Я считаю, что в действительности расширяются границы не проекта, а понимания. То же самое происходит при построении карт историй – люди обнаруживают пробелы в своем понимании ситуации.
Свои границы расширяет понимание, а не проект.
Всегда слишком много
Когда я покидал команду реорганизации системы управления контентом в Globo.com, все было прекрасно – все отлично знали, что им делать, и понимали задачу одинаково. Однако, вернувшись через несколько дней проведать ребят, я обнаружил их в растерянности – они поняли, насколько огромная работа им предстоит, а потребуется на нее, скорее всего, больше года. И, как уже догадался проницательный читатель, когда разработчик предполагает сделать что-то за год, на самом деле это означает два. Не потому, что он некомпетентен или не умеет планировать свое время, – просто-напросто оценить временные затраты на то, чего прежде не делал, очень нелегко. Ну и, конечно, все мы склонны смотреть на жизнь с оптимизмом.
«Задача слишком велика! Нужно сделать так много и это займет так много времени!» – говорили сотрудники Globo.com.