7 глава
Работа команды
В этой главе рассмотрим, как должна работать команда по Agile-маркетингу, какие методы взаимодействия и инструменты лучше всего использовать. Тут мы обратимся к двум самым популярным методологиям для управления проектами – Scrum и Kanban, которые наиболее часто применяются сторонниками Agile.
Прежде всего несколько слов о том, чем Agile так хорош для маркетинга. Как мы уже говорили, эта сфера сегодня подвергается изменениям еженедельно, а иногда и ежедневно. События, которые происходят в мире, очень быстро отражаются на информационном поле, на коммуникациях, на проблемах и потребностях аудитории. Если следовать классическому подходу с его не очень гибкой системой планирования и отсутствием возможности вносить быстрые изменения, проводить тесты, вряд ли получится идти в ногу со временем. Помимо того, что Agile – это не просто гибкость, а контролируемая гибкость за счет использования блоков с четко определенной ответственностью за результат. И эта методология может помочь не только сэкономить время и ресурсы при реализации проектов, но и избежать срывов, переносов и прочих внештатных ситуаций.
Scrum и Kanban в командном зачете
Следование Agile при реализации маркетинговых проектов предполагает, что команда не опирается только на заранее созданные подробные планы. Гораздо важнее для специалистов ориентироваться на постоянно меняющиеся условия внешней и внутренней среды и учитывать обратную связь от заказчиков и пользователей. Это поощряет участников проекта экспериментировать и искать новые решения, не ограничивая себя жесткими рамками и стандартами.
Scrum и Kanban – представители методологий Agile-семейства. Оба считаются гибкими и итеративными. Перед тем, как разобраться в разнице между ними, давайте кратко поговорим о том, что их объединяет.
Scrum основан на структуре. Его главная особенность состоит в том, что над каждым проектом работает универсальная команда специалистов, к которой присоединяется еще два человека: владелец продукта и Scrum-мастер. Первый соединяет команду с заказчиком и следит за развитием проекта, второй помогает первому организовать процесс: решает бытовые проблемы, проводит общие собрания, мотивирует команду и следит за соблюдением Scrum-подхода.
Scrum делит рабочий процесс на спринты – обычно это периоды от недели до месяца, в зависимости от проекта и команды. Перед спринтом формулируются задачи на данный спринт, в конце обсуждаются результаты, а команда начинает новый спринт. Спринты очень удобно сравнивать между собой, что позволяет управлять эффективностью работы.
Kanban основан на балансе. Его задача состоит в том, чтобы обеспечить гармоничное сбалансированное взаимодействие разных специалистов внутри команды и избежать ситуации, когда программисты или аналитики работают сутками, а SMM-щики жалуются на отсутствие новых задач.
В Kanban нет ролей владельца продукта и Scrum-мастера, вся команда едина. Бизнес-процесс делится не на универсальные спринты, а на стадии выполнения конкретных задач: «Планируется», «Разрабатывается», «Тестируется», «Завершено» и др.
Ключевой показатель эффективности в Kanban – это среднее время прохождения задачи по доске. Если она проходит быстро, значит, команда работала продуктивно и слаженно. Если затягивается, необходимо разобраться, на каком этапе и почему возникли задержки и чью работу надо оптимизировать.
Для визуализации Agile-подходов используют доски: физические и электронные. Они позволяют сделать рабочий процесс открытым и понятным для всех специалистов, что важно, когда у команды нет одного формального руководителя.
Основная разница между Scrum и Kanban – в длине итераций. В первом они не превышают 2 недели, и до конца спринта новые задачи не ставятся, во втором они не ограничены во времени, и список заданий можно постоянно пополнять.
В Scrum задачи принято оценивать в Story points или в часах. Без оценки не получится сформировать спринт, ведь нам нужно знать, успеем ли мы сделать задачи за 2 недели. Через 2 недели мы получаем ценную статистику – сколько часов или Story points команда смогла сделать за спринт. Velocity – это производительность команды за один спринт. Этот параметр позволяет Scrum-мастеру предсказать, где команда будет через 2 недели.
Kanban дает больше гибкости, если под гибкостью понимать частоту смены приоритетов. Допустим, вчера началось тестирование нового инструмента, а уже сегодня команда узнала, что у него нулевая эффективность. Специалисты могут доработать его «на лету», переделав настройки.
Вместо того, чтобы использовать временные рамки для управления своей работой, как это делает команда Scrum, команда Kanban применяет ограничения WIP. Каждое состояние работы имеет верхний предел продуктивной работы.
Пределы WIP варьируются от команды к команде и от одного состояния работы к другому. Например, ваша команда из пяти человек может иметь ограничение WIP 10 в столбце «Выполнение», что позволяет каждому человеку работать над двумя вещами одновременно. Однако лимит проверяемой работы может отличаться в зависимости от того, сколько времени занимает этот этап рабочего процесса, сколько человек назначено для проверки работы и других факторов.
В Kanban не принято делать оценку. Это опционально, команда решает сама. Здесь нет понятия «скорость работы команды», считается только среднее время на задачу. Время это считается с помощью специального отчета – Cycle Time.
В отличие от Scrum, Kanban не предписывает способ управления работой, регулярные встречи и не создает уникальных ролей в команде. Этот подход предполагает, что у вас уже есть какая-то форма процесса управления работой, и вы хотите постоянно улучшать ее. Это делает Kanban более легким, чем Scrum, для маркетинговых команд, потому что вы можете начать Kanban с небольшими затратами на обучение.
Kanban также легко адаптируется к меняющимся условиям. Никакие две команды – даже в одном отделе – не реализуют его одинаково. Это имеет смысл: узкие места в рабочем процессе каждой команды различны, поэтому стратегия улучшения каждой команды также различна.
Таким образом, можно сделать вывод, что в Scrum наша цель – закончить спринт, в Kanban – задачу. Agile – очень гибкая методика, и таковыми являются оба этих подхода, однако Kanban более гибкий. Если сравнить основные рассматриваемые нами подходы к реализации проектов с транспортом, то можно сказать, что классический подход – это не очень новый экспресс. Он движется без остановок в пункт назначения, иногда медленнее, иногда быстрее, по пути что-то ломается, но полную информацию о неисправностях мы узнаем лишь в конце пути. И ремонт можно будет произвести не раньше. Scrum – это автобус, который останавливается время от времени, но лишь на определенных остановках, где люди выходят и выходят группами. А Kanban – это микроавтобус, который останавливается там и тогда, где хотят пассажиры.
