"Никто не подойдет с задачей "на вчера": как в маркетинг-команде Logaster внедрили Scrum

Благодаря методу задачи могут решаться гораздо эффективнее: у каждого четко распланировано время, отлично поставлена коммуникация, а в конце каждого спринта можно увидеть реальный результат и сделать ретроспективу

Logaster.com.ua — онлайн-сервис по созданию фирменного стиля. За 12 лет работы у команды накопился опыт не только по внедрению новых продуктов, но и по организации работы, которым она готова поделиться. Василий Голиней, Scrum-мастер Logaster рассказывает, как компания внедрила Scrum — эффективный метод управления проектами.

По какой системе ваша команда работала сначала?

- Хотя история компании началась в 2008 году, маркетинг-команда собралась только в начале 2012-го — до этого мы разрабатывали продукт и тестировали бизнес-модели.

Первая команда маркетологов состояла из четырех человек. Серьезных планов не строили, маркетинговой стратегии как такой не было, поскольку мы вошли в нишу, которая только формировалась.

Раз в месяц ребята собирались с сооснователем и сами составляли список задач на следующий месяц. Занимались, в основном, контентом и SEO. Некоторые отбрасывали сразу, другие обсуждали более подробно.

Что подтолкнуло вас к внедрению Scrum?

- Наш технический директор Виктор решил перевести на Scrum-процесс команду разработчиков. Это метод управления проектами, при котором команда фокусируется на коротком сроке (спринте) для выполнения задач. Обычно Scrum-команда насчитывает 7-9 людей. Ключевые роли играют Scrum-мастер, который координирует работу участников, и Product Owner, который передает им видение конечного продукта.

Через некоторое время мы посмотрели на успехи ребят. Задачи стали решаться гораздо эффективнее: у каждого четко распланировано время, отлично поставлена коммуникация, а в конце каждого спринта можно увидеть реальный результат и сделать ретроспективу.

Когда команда Logaster начала расти и поделилась на подразделения, старый формат работы потерял актуальность. Сотрудники больше не могли ставить себе задачи сами и в течение одного месяца генерировать контент, а другого — размещать ссылки. Нужна была синхронизация с разработчиками, ведь они делали дополнительный функционал, для которого мы готовили контент, исследования.

Мы решили применить опыт наших разработчиков ко всей команде. Сооснователь компании занял роль Product Owner, а сотрудник из команды маркетинга перешел на позицию Scrum-мастера.

Какие подводные камни были на пути?

- Сопротивление со стороны команды: люди настороженно принимают новое и испытывают стресс. Раньше они могли месяц делать задачу и только потом подводить итоги. В результате десятки часов работы иногда практически не приносили результат для компании.

С внедрением Scrum мы оценили весь потенциал команды в часах и разделили процесс на отдельные задачи. Каждый сотрудник отвечал за конкретное направление, но при этом никто не потерял кросс-функциональность. Мы решили, что каждый может выходить за рамки своих компетенций, чтобы помочь выполнить задание спринта. Это удобно и интересно: всегда можно получить нестандартную задачу и сделать себе вызов.

До этого многие сотрудники и так работали по японской модели: участвовали в техподдержке клиентов, выполняли базовые SEO-задачи, писали статьи в блог, занимались email-рассылкой, приводили партнеров. Такой подход помог узнать свои сильные стороны. Мы и сейчас это практикуем — каждый сотрудник задействован, как минимум, в двух направлениях.

В первый спринт было сложно. Ребята не до конца понимали, где начинается и заканчивается их зона ответственности, как формировать задачи, чтобы вовремя получить конечный продукт, как большую задачу "нарезать" на мелкие и связать их между отделами. Также сотрудники не всегда обновляли статусы по задачам — первое время приходилось об этом напоминать.

Со временем все наладилось. Если сейчас мы выпускаем какой-то функционал, то сразу чувствуется: все на своих местах и делают все сплоченно.

Каковы особенности внедрения Scrum в маркетинг-команду в сравнение с ИТ?

- Мы адаптировали Scrum под себя и отбросили то, что для нас не эффективно. Во-первых, отказались от ежедневных собраний и заменили их на еженедельные.

Во-вторых, изменили постановку задач и пришли к децентрализации команды. Если в ИТ все задачи создают и приоритезируют Product Owner и Scrum-мастер, то у нас гибридная система: 30% задач ребята получают от Scrum-мастера, 50% составляют сами, еще 20% им могут назначить коллеги из других отделов.

Для нас такая система оправдана, поскольку у Product Owner Scrum-мастер нет глубокой экспертности. Они просматривают задачи в глобальном срезе, чтобы понять, приведут ли они к цели, которая сейчас в приоритете компании. По всем направлениям есть свои KPI, каждый квартал мы их пересматриваем.

В-третьих, у нас нет очень детальной нарезки на подзадачи. Обычно из названия задачи уже понятно, что она собой подразумевает, например "Разместить 5 упоминаний о генераторе слоганов" или "Развернуть мейл-промо на TH-локале".

Мы стараемся дать сотрудникам максимум самостоятельности и креативности. Вариант, когда нужно все разложить по полочкам, даже не рассматриваем. Каждый маркетолог несет ответственность за свое направление. Иногда в общий чат сбрасываются идеи и задачи: сотрудник сам понимает, что это касается его, и добавляет в список на следующий спринт.

Какие инструменты используете для работы в Scrum?

- Для управления задачами пользуемся приложением Redmine, которое переписали под себя. Там у каждой команды есть отдельный проект, разделенный на спринты. Вся коммуникация сотрудников происходит в Telegram.

Какие изменения внес Scrum в вашу команду? Отразилось ли это на результатах?

- Закрываем больше задач, есть синхрон между ребятами, каждый из них видит свой вклад. Работу легко координировать, а команда может спокойно работать, ведь никто не подойдет с задачей "на вчера".

Если обсуждаем глобальные планы, например, создать новый функционал, каждый знает свою зону ответственности и может сам сформировать базовые задачи.

Также Scrum позволяет оценить инвестиции (сколько стоит конкретный инструмент или функционал) и посчитать возврат вложенных ресурсов на разные проекты и задачи.

Есть ли какие-то минусы в этой методологии для вас лично?

- Невозможность поставить задачи внезапно, ведь все они планируются в начале спринта, как и время сотрудников. И хотя мы почти три года используем Scrum, все предвидеть сложно.

Обычно мы резервируем несколько часов на внезапные задачи — например, сделать текст под какой-то блок (его нужно перевести и отдать на вычитку на восьми языках). Иногда срочные задачи могут внести небольшой хаос в процесс, так как нужно поменять приоритеты, но обычно это не создает глобальных проблем.

Какие советы вы можете дать тем, кто собирается перевести команду на Scrum?

- Для каждой методологии нужно дорасти. В первую очередь, не стоит следовать ей слепо. Подстраивайте все под себя: уберите то, что мешает, или добавьте то, чего не хватает.

По такому же принципу используйте и ПО. Не спешите покупать дорогое решение: для начала воспользуйтесь бесплатной версией, чтобы понять, подходит ли вам функционал.

При необходимости доработайте под свои нужды, спланируйте коммуникацию между командами, особенно, если у вас их десятки. Подумайте, сможете ли вы легко масштабировать процессы, если через год сотрудников станет втрое больше.

Главное, не бойтесь экспериментировать: команда — это живой организм, и в процессе эволюции вы обязательно найдете свой вариант эффективной работы.