Глава 14
ЗАДАЧИ КАК ИСТОРИИ НА ПУТИ ПОКУПАТЕЛЯ
Мы уже говорили о задачах как единицах работы, передвигающихся по канбан-доске в течение agile-спринта. Однако мы определили их как «части работы, которые могут быть завершены за один спринт». Для начала это приемлемо. Просто подробно описывайте задачи на листочках или их электронных эквивалентах. Определите приоритеты, возьмите несколько наиболее важных задач на спринт и по мере выполнения перемещайте карточки по канбан-доске.
Впрочем, мы можем вывести поток задач в более мощный фреймворк. Добавив задаче еще несколько характеристик и организуя их в значимые группы, мы вырабатываем клиентоориентированный подход, чтобы крепко связать свои тактические усилия с крупными стратегическими целями.
ДУМАЙТЕ ИСТОРИЯМИ, А НЕ ЗАДАЧАМИ
В ходе гибкой разработки программного обеспечения возникло такое новшество, как пользовательские истории. Вместо того чтобы задавать себе вопрос о том, что можно добавить в программу (как часто делает разработчик, который будет реализовывать новую функцию), члены команды пишут краткую историю, которая объясняет, почему пользователь хотел бы применять эту функцию.
Такие повествования, состоящие из одного-двух предложений, называются пользовательскими историями. Шаблон для их написания выглядит примерно так: «Играя роль пользователя, я хочу получить нужные функции, чтобы извлечь из них пользу». Например, пользовательская история сотрудника HR-отдела звучит так: «Как руководитель я хочу видеть запросы на отпуск на одном экране календаря, чтобы избежать в графике накладок, когда слишком много сотрудников отдыхали бы одновременно».
Казалось бы, написание пользовательских историй вместо запроса функций — мелочь. Но эта мелочь способна сильно повлиять на отношение разработчика к задаче. Если команда представляет не абстрактного пользователя, а человека, который хочет получить определенную функцию, она способна спроектировать и реализовать максимально полезное для клиентов решение. Пользовательская история, словно компас, указывает разработчикам правильное решение из десятков возможных вариантов.
Маркетинг тоже может применить эту концепцию. Поскольку термин «пользователь» больше относится к программному обеспечению, мы можем назвать свою историей на пути покупателя. Надоело штамповать маркетинговые материалы и выполнять задания вроде «Срочно опубликовать справочник цен!». Давайте создавать контент и опыт, которые действительно обращаются к потенциальным и существующим клиентам, по мере того как те принимают решение о покупке и строят отношения с компанией.
Мы хотим думать об истории покупателя. Значит, ее сюжет будет примерно таким: в роли покупателя я хотел бы получить контент или опыт, поскольку получу от этого пользу (причина). Пример такой истории: «Как потенциальный клиент я хотел бы получить справочник цен или интерактивный калькулятор, чтобы определить, впишется ли ваше решение в наш бюджет».
Маркетинг — это умение рассказывать истории. Поэтому маркетологам нужно ясно видеть главных действующих лиц (клиентов) и понимать их мотивы. В самом деле, каждое взаимодействие маркетинга с потенциальным или реальным потребителем вносит вклад в повествование, ведущееся от имени бренда. Поэтому все, что влияет на опыт взаимоотношений людей с компанией — от функций сайта до сборника историй для социальных сетей, — может оказаться полезным с точки зрения создания историй на пути покупателя. Чтобы встроить такие истории почти во все свои работы, придется потренироваться.
Как и у пользовательских историй, наиболее ценная часть истории покупателя — это ответы на вопросы «кто?» и «для чего?». В такой истории покупатель выглядит реалистичным, если он описан очень конкретно. Вспомним провозглашаемую agile-маркетингом ценность: «узкие группы клиентов вместо обезличенного массового маркетинга». В нашей истории это может быть определенный сегмент аудитории или, как в нашем примере, этап на пути потребителя. Если вы разработали индивидуализированные профили покупателей, то их можно успешно использовать для обыгрывания роли в ваших историях. Необходимо как можно точнее представить себе аудиторию, для которой мы работаем.
Часть истории покупателя, рассказывающая о преимуществах — причинах, по которым потенциальный либо реальный клиент хочет получить определенный вид контента или опыта, — должна ответить на вопрос: какую работу нужно проделать, чтобы потребитель захотел взять этот контент или опыт как созданный именно для него? Слова «работа» и «взять» выделены курсивом, потому что это не буквальное описание действий, а метафоры для подспудных желаний (работа), которые покупатель должен превратить («взять») в контент или опыт.
Подход «работа, которую надо сделать» (jobs-to-be-done) придумал Клейтон Кристенсен, профессор Гарвардского университета, известная фигура в области бизнес-инноваций, для того чтобы помочь компаниям понять, почему люди покупают их продукты. Он поделился опытом одного ресторана, работники которого выяснили, что утром посетители приобретают молочные коктейли, чтобы было чем полакомиться в пробках, а днем родители покупают их, чтобы успокоить детей. По утрам клиенты предпочитали густые коктейли, с которыми удобнее коротать время в автомобилях, а родители предпочитали напитки пожиже, чтобы дети выпивали их быстрее. Это знание повлияло на то, как компании фастфуда стали предлагать свои продукты. А придуманный Кристенсеном подход «работа, которую надо сделать» прозвали «маркетингом молочных коктейлей».
Какие задачи необходимо решить клиентам, и как маркетинг может им помочь? Если для каждой части контента и каждого опыта взаимодействия с покупателем маркетологи будут создавать историю покупателя, то получится огромная книга рассказов. Подходите к делу прагматично, не рассматривайте каждую историю как крупный исследовательский проект. Опирайтесь на свое понимание аудитории, чтобы написать текст в считаные минуты. Пусть истории будут неидеальными, подойдут даже гипотетические. Главное условие — подлинность.
В идеале необходимо приложить ответы на вопросы «кто?» и «для чего?» к максимальному количеству результатов маркетинга, чтобы составить представление о покупателях и их приоритетах и реализовать его по всей маркетинговой цепочке.
Вспомним пример со справочником или интерактивным калькулятором цен. Исходя из того, что мы планируем выпустить промежуточное решение, давайте сделаем предположение. Допустим, клиенты в общих чертах знают о наших категориях продуктов, но, вероятно, не знакомы с характеристиками нового предложения. Мы хотим поговорить с ними об этом. Признавая, что клиент собирается выполнить работу в рамках выделенного бюджета, мы можем точнее сформулировать свое предложение — например, обсудить бюджетирование; предложить гибкие варианты дополнительных возможностей, таких как ежегодные или ежемесячные выплаты; дать ссылку на дополнительный контент, который поможет составить запрос на выделение бюджета на эти инвестиции.
Конечно, не все в работе маркетологов непосредственно предназначено для покупателей. Рутинные операции, маркетинговые технологии и исследования, аналитика и другие вспомогательные функции — от отчета до разработки инфраструктуры программного обеспечения — в первую очередь востребованы в самой компании. Работа для внутренних проектов и сервисов тоже приносит пользу, если управлять ею с помощью историй. В историях указывается, кто заинтересованная сторона в компании и почему она желает лучшего принятия решений или расширенных маркетинговых возможностей. Ясное понимание целевой аудитории и ее реальных мотивов полезно и в этих случаях, поскольку упрощает оценку относительного приоритета и реализацию этих работ.
В этом случае мы можем говорить об историях сотрудников, и их сюжет будет таким: «Играя (в компании) роль, я хотел бы иметь возможность (данные и прочее), потому что получу пользу (причина)» — например, «Будучи менеджером по маркетингу, я хотел бы иметь А/B-тестирование на нашем сайте, чтобы мне можно было экспериментировать с различными акциями на главной странице».
ИСТОРИИ В БЭКЛОГЕ, ЗАДАЧИ В СПРИНТЕ
Истории покупателей и сотрудников могут служить основной расчетной единицей приоритизированной маркетинговой работы, как показано на рис. 14.1. В предыдущей главе мы говорили, что циклы agile-спринтов начинаются с обновления бэклога. Во время планирования спринта команда вытягивает из журнала наиболее приоритетные элементы, добавляет их в колонку «Сделать» на канбан-доске и выполняет в соответствии с рабочим процессом маркетинга.
РИС. 14.1. ПРИ ПЛАНИРОВАНИИ СПРИНТА ИСТОРИИ ИЗ БЭКЛОГА ПРЕВРАЩАЮТСЯ В РАБОЧИЕ ЗАДАНИЯ
Теперь можно обрисовать эту картину точнее, опираясь на истории. Маркетинговый бэклог должен состоять из историй покупателей и сотрудников. Если отдел большой, целесообразно иметь несколько бэклогов для разных групп. Тогда удастся избежать чрезмерного разрастания одного бэклога. Детализация историй (кто, что, для чего и почему) должна быть достаточно подробной, чтобы обеспечить быстрый темп гибкого управления (см. рис. 14.1). Но она не может диктовать, какие шаги надо предпринять для выполнения задач, соответствующих этим историям.
Когда история вытягивается в спринт из бэклога, при планировании команда делит ее на несколько задач. По общему правилу, задача должна быть такого размера, чтобы ее можно было завершить в течение одного спринта. Ее выполняет один либо несколько членов команды поочередно.
Некоторые истории и так довольно малы, и их не нужно разбивать на задачи. Например, история покупателя, созданная с целью написания поста в блоге или простой кампании имейл-рассылки, может вполне двигаться по канбан-доске как одна задача. Однако масштабную историю, такую как большой массив маркетингового контента, желательно разделить на задачи: написание текста, разработка графического дизайна, целевой страницы, уведомлений по электронной почте, размещение сообщений в соцсетях, продвижение и прочее.
При делении истории на задачи следует учитывать, какие из них можно выполнять параллельно (несколько человек одновременно трудятся над связанными заданиями), а какие — только последовательно. В этом случае второй участник начинает выполнять свою часть задания только после того, как первый завершит предыдущий этап. Параллельная работа делится на столько частей, сколько членов команды могут работать над ней одновременно. При последовательном подходе желательно разграфить отдельные столбцы на канбан-доске, чтобы содействовать скоординированной передаче задач от одного человека к другому.
Вы можете сами решить, как поделить истории на задачи. Если деление слишком дробное, то канбан-доска будет «замусорена» мелочами. А вот при чересчур крупных задачах теряется прозрачность рабочего процесса и уменьшается гибкость. Между этими полюсами находится широкий спектр возможностей. Постарайтесь отрегулировать степень детализации задач для команды в соответствии с обстоятельствами.
Выбор степени детализации задач, параллельности или последовательности в рабочем процессе — отличные темы для ретроспективы спринта.
И еще, при дроблении полезно убедиться, что в задачах есть указание на историю, для воплощения которой они реализуются. Тогда тот, кто будет выполнять задачу, сможет глубже понять, кому, зачем и почему нужна его работа.
БЭКЛОГ КАК ИНСТРУМЕНТ ГИБКОГО УПРАВЛЕНИЯ
Самое главное правило: задачи в бэклоге должны быть приоритизированы. Из-за сложности компромиссов иногда появляется искушение утверждать, будто все рабочие задания одинаково ценны. Тем не менее, учитывая ограниченность ресурсов, особенно времени, мы не в силах сделать все сразу. Приходится выбирать, что должно выполняться в первую очередь, а что — во вторую, третью и далее по порядку. Тут уместно вспомнить поговорку: если вы ничего не выбрали, вы все же сделали свой выбор. Если придумывать слишком много историй с равным приоритетом, то порядок завершения задач окажется случайным. Члены команды начнут принимать различные решения, влияющие на результат, не осознавая, какие цели важнее других.
Обязательная расстановка приоритетов в бэклоге устраняет эту двусмысленность. Все члены команды и заинтересованные лица видят, что находится в верхней части списка в следующем спринте, а до чего очередь дойдет позже и в какой последовательности.
Чтобы определить приоритеты в бэклоге, возьмите карточки с историями и разместите их в том порядке, в каком они должны быть сделаны. Приоритеты можно изменить в любое время. Благодаря этому способу управление маркетингом обретает гибкость. Обстоятельства меняются, а вместе с ними и значимость записанных в журнале историй покупателей и сотрудников. Появляется необходимость добавить новые истории и переопределить приоритеты.
Как гласит одна из универсальных ценностей Agile, реагирование на изменения важнее строгого следования плану. Конечно, не всегда решения о пересмотре приоритетов в бэклоге даются легко. Иногда приходится делать трудный выбор. Но поскольку все истории можно прочитать, так как они собраны в одном месте и ясно описывают «кто, для чего и почему», маркетологи готовы принимать максимально обоснованные решения об относительных приоритетах. При этом эффект от повышения приоритета одних историй за счет других становится заметен сразу.
Сортировка приоритетов в списке задач, конечно, не волшебная палочка, решающая проблему немедленно, зато этот способ обеспечивает прозрачность. И это ценный инструмент для того, чтобы сознательно идти на компромисс в управленческих решениях.
Постепенно бэклог будет расти. Новые истории покупателей и сотрудников добавляются очень быстро, гораздо быстрее, чем их можно включить в спринт и завершение. У нас рождается намного больше идей, чем можно реализовать. И это прекрасно.
Мы стремимся поощрять творческие предложения в маркетинге и добавлять их в журнал работ. Поскольку в нем можно в любое время поменять приоритеты, все наши истории постоянно конкурируют друг с другом. Блестящая и актуальная идея способна мгновенно попасть в начало очереди. Несомненно, это процесс развития, однако именно это и нужно маркетингу, чтобы быстро адаптироваться к меняющейся обстановке.
Бэклог постоянно развивается. Впрочем, для предотвращения бесконтрольного разрастания необходимо регулярно его «причесывать», как утверждают некоторые agile-практики. При «причесывании» следует убедиться, что определены все приоритеты. Особенно важно это для историй в верхних строках списка — кандидатов на место в следующем спринте. Полезно удалить старые истории, если их приоритет понижен или их заменили новыми. Такой процесс называется сокращением бэклога. «Отрезанные» истории можно складывать в архив: вдруг когда-нибудь пригодятся? Хотя такое случается редко, ведь бэклог постоянно пополняется новыми материалами.
ЭПИКИ И ИСТОРИИ РАЗНОГО РАЗМЕРА
Истории бывают большими и маленькими. Поскольку за один спринт удается выполнить не так уж много работы, при его планировании полезно оценивать размах истории, чтобы вытянуть в спринт только то, с чем команда справится, например две большие истории или пять маленьких.
В Scrum для оценки размера историй используют так называемые стори-поинты (story points). Каждой истории присваивается значение 1, 2, 3, 5, 8 или 13 (так называемые числа Фибоначчи), олицетворяющее объем усилий, которые, вероятно, потребуются для ее завершения. Самым маленьким историям назначается один стори-поинт — в контексте маркетинга это, например, короткий пост в блоге. Два балла означают историю вдвое большего объема, три стори-поинта — втрое и далее по порядку.
На рис. 14.2 показаны примеры историй со стори-поинтами. Стори-поинты используются вместо примерного количества часов, поскольку члены команды могут потратить на выполнение одной задачи разное время. Опытный специалист сделает работу значительно быстрее, чем начинающий, но ему и больше платят. Абстрактное понятие об относительных усилиях, необходимых для воплощения истории, дает возможность команде выбрать, как распределить работу в спринте.
РИС. 14.2. ШАБЛОНЫ И ПРИМЕРЫ ДЛЯ ИСТОРИИ КЛИЕНТА И СОТРУДНИКА
При планировании спринта из бэклога вытягивают верхние истории и при необходимости делят их на задачи, которые затем добавляют в колонку «Сделать».
В общем случае стори-поинты должны рассматриваться только как первое приближение. Не стоит тратить много времени на точную оценку масштаба истории, пока она находится в бэклоге. Ведь ее приоритет может оказаться таким, что она никогда не попадет в спринт. Команде нужно точно оценить истории в бэклоге и, возможно, скорректировать их при его «причесывании», потому что претенденты на место в следующем спринте — это истории из верхней части списка.
Когда история готова к втягиванию в спринт, команде нужно уточнить оценку необходимых усилий. Обычно это происходит во время планирования как части процесса разделения спринта на задачи. Для их выполнения требуются различные усилия, поэтому им назначаются стори-поинты.
Масштаб истории часто варьируется, так как зависит от степени сложности и того, сколько времени придется потратить на выполнение задачи. Чтобы учесть это, история в бэклоге получает несколько вариантов оценки. В подобных случаях маркетологи позже самостоятельно выбирают, сколько усилий вложить в разработку той или иной истории. В примере со справочником цен мы можем реализовать не 13-балльную, а менее трудоемкую 5-балльную версию, чтобы иметь возможность распределить дополнительные ресурсы на другие истории.
Общее количество стори-поинтов, которое команда может завершить в спринте, называют скоростью спринта. Она различается в разных спринтах, потому что оценки в стори-поинтах приблизительные, а на производительность команды влияют и другие факторы. Со временем средняя скорость превращается в ориентир для определения того, сколько команда способна сделать за один спринт.
Истории, набравшие более 13 баллов, как правило, становятся эпиками. Эпик — это несколько историй, объединенных общей миссией. Заинтересованные лица и команда видят между ними тесную связь. Поскольку любая история по-прежнему ограничена по масштабу, мы можем реализовывать эпики инкрементально, сохраняя гибкость при разработке.
Создание нового сайта — типичный пример эпика, который состоит из многих историй, предназначенных для различных его разделов и функций.
Соотношение между эпиками, историями и задачами показано на рис. 14.3.
РИС. 14.3. ИЕРАРХИЯ ЭПИКОВ, ИСТОРИЙ И ЗАДАЧ
Вы можете включить в истории много других параметров: систему показателей, цветовое кодирование, мнение заинтересованных сторон. Но лучше начинать с основных требований, а затем гибко улучшать маркетинговые истории.
