Виталий Цимбалюк: как сделать скрам в non-IT компании?

Я занимаюсь маркетингом практически всю жизнь. До того, как начал продвигать YouTube-каналы в One2, я руководил отделом клиентского сервиса в агентстве PROMO. Меня всегда привлекали инновации, так что встреча с методологией Scrum была вопросом времени.

Как я пришел к проектному менеджменту

В рекламном агентстве я стал руководителем отдела аккаунт-менеджеров. Системы управления проектами не было. Мы не успевали выполнить обязательства по договору или делали работу некачественно. Поэтому я стал трабл-шутером по негативу от клиентов. Это был путь в никуда: я не мог предупредить проблему, а работал с последствиями.

Я начал искать некий набор инструментов, который мог бы исправить ситуацию. Тогда еще не знал об Agile и Scrum, тем более о том, как применять методологию Scrum в non-IT командах.

Я стал трабл-шутером по негативу от клиентов.

Как мы выбрали методологию проектного менеджмента

Вначале мы смотрели на Канбан. Он особенно хорош для потоковых задач типа багфикса и обработки заявок в колл-центре. Но для внедрения Канбана нужна команда с высокими уровнями мотивации и организации. Это был не наш случай.

Смотрели также на Waterfall. Он хорош для IT-команд, потому что из-за четкой последовательности этапов нужно писать меньше кода, идете по нарастающей. Тот же проект в Scrum будет выглядеть по-другому:


В надежности Waterfall скрывается его недостаток — большой риск сорвать сроки. Бизнес хочет получить результат в ближайшее время, а не прождать целый год, чтобы убедиться: выбранная стратегия не работает. Scrum лишен этой «болячки».

Какие инструменты Scrum подойдут маркетинговому агентству

1. скрам-доски. В скрам-досках виден статус задачи и можно определить, где возник затор (например, слишком много задач находятся на стадии обсуждения с клиентом). Мы дали клиентам доступ к скрам-доскам, чтобы они могли отслеживать статус задач. Это колоссально снизило нагрузку на аккаунт-менеджеров
2. ежедневные стендапы. Каждый член команды по очереди рассказывает о результатах за прошлый день, даёт обещание на текущий день и делится проблемами. Благодаря ежедневному стендапу можно понять, что происходит в компании и как сделать работу эффективнее
3. планирование. Делает процесс работы прозрачным для руководителя и клиента. Мы приглашали отдельных клиентов и вместе решали, какие задачи ставить на следующие спринты.
4. ретроспектива. Можно понять, какие ошибки допустили, как их можно исправить (например, как увеличить одновременное количество задач в работе без потери качества).
5. демонстрация продукта. Это презентация того, что команда успела сделать за спринт. Каждый участник команды показывают свою часть продукта. Демонстрация продукта дает возможность быстро внести изменения, улучшить продукт и не тратить время на ранние презентации полноценного продукта.

Раньше моей основной работой был анализ негатива клиента. После внедрения Scrum мы стали опрашивать клиента для того, чтобы понять, в правильном ли мы направлении движемся. Мы также подняли индекс поддержки потребителя (NPS).

Какие недостатки Scrum для non-IT команд?

У скрама есть три главных недостатка:

1. Бизнес-процессы становятся дороже. Мы ввели должность product owner, потому что никто из команды не потянул бы такую важную роль. Это дорогой специалист. Product owner, как и Scrum master, напрямую не создают ценность, они находятся за рамками команды, и по сути попадают в категорию накладных расходов.
2. Нет удобного сервиса управления проектами по Scrum для non-IT команд. Раньше мы использовали Jira, но для её настройки зачастую нужно привлекать специалиста.
3. IT-терминология в скраме не адаптирована под non-IT компании. Для IT-компаний есть подробные методички, где расписано, как заставить Scrum работать. Объясняется терминология: инкремент — это работающий продукт, демо — показ того, как продукт работает. В нашем случае было непонятно, как написание контента отражается на работе продукта. А что такое инкремент в SEO? Если мы написали текст и разместили его на сайте — это работающий продукт? У нас ушло более трех месяцев на то, чтобы адаптировать IT-терминологию под наши нужды.

Как мы провалили внедрение Scrum

Внедрение Scrum мы начали с объединения в команды. И сразу допустили две ошибки.




Ошибка № 2. Не определили сразу, кто должен выполнять функции скрам-мастера и владельца продукта.

• Команды объединяют вокруг одной функции. Отдел просто переименовывают в команду. Проблема в том, что если клиенту нужен сайт, то в команде должен быть программист, дизайнер и менеджер. Отдел маркетинга с бренд-менеджерами сайт не сделают.
• Компания боится разрушить текущую структуру. Реальный пример. Один аккаунт-менеджер вел несколько проектов, с каждым из которых работают разные SEO-специалисты. Проекты распределяются на основе загрузки SEO-специалистов. Предположим, специалист получил в работу 10 проектов с разной приоритетностью. Приоритеты выставляет проектный менеджер, и в этой компании их было несколько. В лучшем случае SEO-специалист выполнял самую понятную задачу, в худшем — задачу аккаунт-менеджера, который больше всех кричал.

Объединение в «правильные» команды —
это болезненный процесс.

Зачем нужен Scrum-мастер?

У Toyota есть интересный кейс на тему скрам-мастера. На заводе к механику приставили людей для оптимизации работы. Механику платили за час работы, и платили много, так что нужно было увеличить эффективность работы и уменьшить затраты. Увидели, что механик долго ищет нужный ключ — прикрепили к нему подмастерье, который подавал ключи. Подумали еще и сделали проще: нарисовали на полу трафареты для инструментов и подмастерье утром до начала работы раскладывал их.

Так что 80% успешного внедрения скрама — это хороший скрам-мастер. Если у вас нет человека, который мог бы взять на себя эту роль, найдите того, кому интересно было бы учиться и работать дальше в этой сфере. В крайнем случае ищите скрам-мастера в IT-компаниях.

Неочевидные функции скрам-мастера:

• Чувствует, где команда не дорабатывает, где можно ускориться, а где — лучше притормозить. Это как щит от горящих дедлайнов и хаоса.
• Отвечает за чувство безопасности команды. В том числе от клиента, который хочет «сделать всё и на вчера». К примеру, мы столкнулись с такой проблемой: аккаунт-менеджеры долго делали отчеты для клиентов. С подачи скрам-мастера настроили автоматизированные отчеты, которые формируются в реальном времени. Теперь клиент не ждет конца месяца, чтобы понять, как идут дела. Все довольны.
• Выводит команду на тот уровень, когда она будет пользоваться Scrum по собственному желанию.
• Общается с каждым членом команды one-to-one. О проблемах и болях сотрудника. Так junior-специалисты быстрее станут middle, а middle-специалисты — senior. Уменьшится текучка кадров.

Зачем нужен product owner?

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

Что делает наш product owner?

• формирует бэклог;
• удаляет и расставляет приоритеты задач;
• корректирует стратегии на основе данных, полученных от команды;
• отвечает перед клиентами за результат.

Как мы внедрили Scrum в non-IT компанию


Команды сформировали под каждое из трех направлений SEO:

1. управление ссылочной массой
2. создание контента
3. доработка сайта.

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


Спринт выглядит так:

Часть команд мы перевели на двухнедельный спринт. Учтите, что чем дольше спринт — тем выше риск сорвать сроки.

В работе используем такие инструменты:

• покер-планирование. Техника дает возможность оценить сложность и объем задач, которые нужно будет решать в ходе создания продукта. В покер-планировании принимают участие все члены команды. С помощью карт оценивают задачи и принимают коллегиальные решения;
• аналог парного программирования из экстремального программирования. Над задачей работает несколько людей за одним рабочим местом. Наглядное воплощение правила «Одна голова хорошо, а две — лучше». Мы используем её в критические моменты;
• HADI-циклы. Алгоритм проверки спорных гипотез, который помогает заслужить доверие клиента. Подробнее о HADI-циклах — чуть ниже.

Что такое HADI-циклы и как их использовать?

Что это? HADI-цикл — алгоритм проверки гипотезы, который выглядит так:


HADI-циклы похожи на петлю Lean Startup:


Как это работает? Ты генерируешь гипотезы, в работоспособности которых не уверен. Если задача понятная и нужная, её нет смысла обрабатывать на HADI-цикле. После проверки гипотезы определяешь, сработала она или нет, и насколько хорошо. Если сработала — запускаешь на спринт, если нет — отбрасываешь.

7 советов о том, как внедрить Scrum, если вы — не IT

1. Начните с обучения. Почитайте специализированную литературу, сходите на тренинг.
2. Определите, кто ваш стейкхолдер (заинтересованная сторона). И далее работайте на то, чтобы донести ценность и клиенту, и стейкхолдеру.
3. Спринт должен оставаться неизменным. Не бойтесь менять всё остальное.
4. Не переводите всю компанию на Scrum, просто потому что «это круто». Например, наши копирайтеры работают по Канбану, так как у текстов нет приоритетов — просто их надо делать как можно быстрее.
5. Определите оптимальный размер команды. По моему опыту это пять-семь человек в non-IT компаниях.
6. Организуйте отдельное рабочее пространство для каждой команды. Если у вас open space офис, добавьте офлайновые скрам-доски.
7. Проявляйте инициативу в реализации Scrum. Если руководство не понимает, зачем нужна новая методология, ничего не получится.

Интервью брала Кристина Лисовская,
статью писал Ярослав Борута.