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