Можно также создавать на доске участки для задач, находящихся вне основного рабочего процесса — например, зону сортировки. Здесь располагаются (для ознакомления) вопросы, возникшие в ходе спринта и ожидающие рассмотрения на следующий день на стендапе. Иногда такие задачи быстро решаются и перемещаются в столбец «Готово», или их ставят в очередь, обычно обособленную от списка выполняемых задач. В неотложных случаях, при необходимости освободить место, задачи из зоны сортировки перемещают в столбец «Сделать», вытесняя оттуда другие.
Другие участки, не входящие в общий поток, могут включать «промежуточную корзину» для задач, вытесненных из текущего спринта для того, чтобы освободить место для чего-то срочного. Есть также «корзина для убитых» — это задачи, работа над которыми прервалась в ходе спринта из-за изменения обстоятельств и не будет возобновлена. Команда может изучить содержимое корзин при обзоре спринта. Расширенная версия маркетинговой доски на пять этапов с добавлением этих функций показана на рис. 13.3.
РИС. 13.3. ПРИМЕР РАСШИРЕННОЙ КАНБАН-ДОСКИ ДЛЯ МАРКЕТИНГА
Конечно, существует множество способов организации канбан-доски, но вначале лучше выбрать самый простой вариант и дать команде возможность итерационно модифицировать ее от спринта к спринту.
В крупных маркетинговых компаниях, где есть несколько команд или независимых маркетинговых программ, вам, вероятно, захочется управлять их работой с помощью отдельных канбан-досок (чтобы ни одна из них не стала чересчур громоздкой). Тем более что все доски могут иметь свой дизайн, учитывающий характер работы каждой команды или программы.
Наконец, напомним: мы рассказали, как организовать канбан-доску в виде доски с заметками, но она может быть оформлена и в электронном виде. Существует широкий выбор программного обеспечения для создания канбан-доски и работы с ней, включая множество веб-инструментов (некоторые из них бесплатные).
Использование программного обеспечения в этом случае дает много преимуществ. Если члены вашей команды или компании находятся в разных местах, то больше подойдет интерактивная доска, поскольку она должна быть доступна всем. Кроме того, ПО поможет исполнять правила работы с канбан-доской, такие как ограничения WIP и принцип вытягивания; облегчит редактирование задач, избавив от необходимости полностью переписывать заметки; поможет нарисовать график движения задач по потоку и обеспечить возможности для архивирования и поиска задач, выполнявшихся некоторое время назад.
Если же все члены команды работают в одном здании, лучше пользоваться обычной доской. Ее обычно размещают на видном месте, чтобы члены команды и другие заинтересованные лица могли видеть состояние спринта. Кроме того, есть особая прелесть в перемещении карточек вручную, а не на экране компьютера. Особенно приятно передвигать карточку в столбец «Готово». В общем, выбор за вами, и со временем он может меняться.
Глава 14. Задачи как истории на пути покупателя
* * *
Мы уже говорили о задачах как единицах работы, передвигающихся по канбан-доске в течение agile-спринта. Однако мы определили их как «части работы, которые могут быть завершены за один спринт». Для начала это приемлемо. Просто подробно описывайте задачи на листочках или их электронных эквивалентах. Определите приоритеты, возьмите несколько наиболее важных задач на спринт и по мере выполнения перемещайте карточки по канбан-доске.
Впрочем, мы можем вывести поток задач в более мощный фреймворк. Добавив задаче еще несколько характеристик и организуя их в значимые группы, мы вырабатываем клиентоориентированный подход, чтобы крепко связать свои тактические усилия с крупными стратегическими целями.
Думайте историями, а не задачами
В ходе гибкой разработки программного обеспечения возникло такое новшество, как пользовательские истории. Вместо того чтобы задавать себе вопрос о том, что можно добавить в программу (как часто делает разработчик, который будет реализовывать новую функцию), члены команды пишут краткую историю, которая объясняет, почему пользователь хотел бы применять эту функцию.
Такие повествования, состоящие из одного-двух предложений, называются пользовательскими историями. Шаблон для их написания выглядит примерно так: «Играя роль пользователя, я хочу получить нужные функции, чтобы извлечь из них пользу». Например, пользовательская история сотрудника HR-отдела звучит так: «Как руководитель я хочу видеть запросы на отпуск на одном экране календаря, чтобы избежать в графике накладок, когда слишком много сотрудников отдыхали бы одновременно».
Казалось бы, написание пользовательских историй вместо запроса функций — мелочь. Но эта мелочь способна сильно повлиять на отношение разработчика к задаче. Если команда представляет не абстрактного пользователя, а человека, который хочет получить определенную функцию, она способна спроектировать и реализовать максимально полезное для клиентов решение. Пользовательская история, словно компас, указывает разработчикам правильное решение из десятков возможных вариантов.
Маркетинг тоже может применить эту концепцию. Поскольку термин «пользователь» больше относится к программному обеспечению, мы можем назвать свою историей на пути покупателя. Надоело штамповать маркетинговые материалы и выполнять задания вроде «Срочно опубликовать справочник цен!». Давайте создавать контент и опыт, которые действительно обращаются к потенциальным и существующим клиентам, по мере того как те принимают решение о покупке и строят отношения с компанией.
Мы хотим думать об истории покупателя. Значит, ее сюжет будет примерно таким: в роли покупателя я хотел бы получить контент или опыт, поскольку получу от этого пользу (причина). Пример такой истории: «Как потенциальный клиент я хотел бы получить справочник цен или интерактивный калькулятор, чтобы определить, впишется ли ваше решение в наш бюджет».
Маркетинг — это умение рассказывать истории. Поэтому маркетологам нужно ясно видеть главных действующих лиц (клиентов) и понимать их мотивы. В самом деле, каждое взаимодействие маркетинга с потенциальным или реальным потребителем вносит вклад в повествование, ведущееся от имени бренда. Поэтому все, что влияет на опыт взаимоотношений людей с компанией — от функций сайта до сборника историй для социальных сетей, — может оказаться полезным с точки зрения создания историй на пути покупателя. Чтобы встроить такие истории почти во все свои работы, придется потренироваться.
Как и у пользовательских историй, наиболее ценная часть истории покупателя — это ответы на вопросы «кто?» и «для чего?». В такой истории покупатель выглядит реалистичным, если он описан очень конкретно. Вспомним провозглашаемую agile-маркетингом ценность: «узкие группы клиентов вместо обезличенного массового маркетинга». В нашей истории это может быть определенный сегмент аудитории или, как в нашем примере, этап на пути потребителя. Если вы разработали индивидуализированные профили покупателей, то их можно успешно использовать для обыгрывания роли в ваших историях. Необходимо как можно точнее представить себе аудиторию, для которой мы работаем.
