Главная Новости

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

Опубликовано: 29.08.2018

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

Меня всегда тянуло на инновации и последние полгода я занимаюсь продвижением YouTube-каналов в агентстве One2 , но до этого руководил отделом Клиентского сервиса в интернет-маркетинговом агентстве PROMO со штатом более 100 сотрудников.

Про отсутствие проектного менеджмента

Когда я пришел в рекламное агентство, то о scrum и речи не было. Мы одновременно работали более с чем 100 клиентами , для работы с ними был отдел аккаунт-менеджеров. Я руководил им, но почти сразу понял, что невозможно эффективно управлять таким количеством проектов без системы.

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

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

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

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

В поисках руководствовался пониманием: работать по-старому дальше нельзя.

Про методологии проектного менеджмента

Не только скрам рассматривали: в IT-компаниях также используют Канбан. По большому счету эта методология подходит практически под любую производственную сферу деятельности.

Канбан требует высокой самоорганизации команды и мотивации, это был не наш случай.

По  Канбану хорошо работать с потоковыми задачами: багфиксом, обработкой клиентских заявок колл-центром. В последнем случае есть четкие Work-in-progress лимиты : количество незавершенных задач, которые могут быть одновременно в работе, ограничено соответственно с количеством операторов. Дальше тебе нужно выстроить приоритизацию — ты просто раздаешь задачи — и они просто выполняются одна за другой.

Основанная задача Канбана — управление

узким горлышком процесса,

ограничивая количество задач в работе.

В Scrum , в частности для маркетинговой компании, две самые ценные вещи — управление пропускной способностью команды и  снижение рисков срыва сроков проекта . Зато Канбан нагляднее, он подходит для сложных бизнес-процессов.

Фреймворк-конкурент скрама — Waterfall . С точки зрения IT-команд в Waterfall приходится писать меньше лишнего кода — со старта делаешь какие-то вещи. Делаешь движок сайта — сразу продумываешь его модули, архитектуру. В скраме схема выглядит так:

рабочее нечто —> настройка —> оптимизация.

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

Про преимущества внедрения скрама в маркетинговом агентстве

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

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

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

Раньше ведь как было — клиенты звонили с многочисленными вопросами и «А где?» «А когда?».

С планированием проблема отпала, доска все прекрасно визуализирует.

После внедрения скрама эффект почувствовали все : и наши клиенты, и сотрудники.

Агентство PROMO попало в ТОП-3 по обороту среди всех перфоманс-агентств. Agile позволил принять и удержать клиентский портфель.

Со скрамом мы  масштабировали бизнес, подняли индекс лояльности NPS, наши бизнес-процессы стали прогнозируемые . Когда я только пришел, основной работой был разбор и анализ негатива. Теперь же опрос клиента проводится для того, чтобы понять, в правильном или нет направлении мы движемся.

Про недостатки внедрения скрама в не IT команду

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

К недостаткам я причисляю и  отсутствие удобного сервиса управления проектами по scrum для не IT команд. Настройка Jira, которую мы использовали, часто требует привлечение технического специалиста. Поэтому сейчас я консультирую Worksection как внедрить скрам-инструменты в систему.

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

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

Про скрам-факапы

Внедрение скрама мы начали с того, что объединились в команды — и тут же допустили первую ошибку. Мы объединили команды вокруг одного Клиента. Объединили в одну команду специалистов контекстной рекламы и SEO.

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

Теперь мы знаем, что объединять команду нужно вокруг бизнес-цели . Такая команда самодостаточна, сможет самостоятельно сделать ценность для клиента.

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

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

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

Объединение в «правильные» команды —

это болезненный процесс.

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

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

Про скрам-мастера

80% успешного внедрения скрама — это хороший скрам-мастер . Даже в Канбане или другой методологии нужен коуч, который поможет команде идти к успеху. У нас эту роль получил групп-аккаунт, который отвечал за продуктивность команды и бесперебойную доставку ценностей для клиента.

Если в вашей команде нет человека, который мог бы получить роль скрам-мастера, найдите того, кому интересно было бы научиться и работать дальше в этой сфере. В крайнем случае скрам-мастера можно найти в IT-компании.

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

Например, у нас была проблема:

аккаунт-менеджеры долго делали отчеты для клиентов. С подачи скрам-мастера настроили автоматизированные отчеты, которые формируются в реальном времени и клиенту не нужно ждать окончания месяца для этого.

Скрам-мастеру важно вывести команду на тот уровень, когда она сможет самостоятельно перформить и дойдет до самостоятельного понимания преимуществ скрама.

Еще скрам-мастер отвечает за чувство безопасности команды , в том числе от клиента и владельца продукта, которые хотят «сделать все и на завтра».

Вспомнил уместный кейс завода Toyota в тему.

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

Про мотивацию и обучение сотрудников

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

В последнее время мы перешли на фиксированную ставку без бонусов (мы не срезали бонусы, а повысили ставку).

Команда знает, что раз в месяц сотрудники получат деньги, независимо от показателей клиента. И они стараются сделать все лучше — не из-под палки, а потому что так хотят действительно.

Скрам-мастеру важно периодически проводить one-to-one с каждым членом команды.

Это общение скрам-мастера с сотрудником о возможных проблемах, «болях», «неустроенностях». Мы ведь заинтересованы в том, чтобы junior-специалисты быстрее становились middle, а те в свою очередь — senior-специалистами и т.д. Agile методологии помогают работать в условиях текучки и роста кадров.

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

Про владельца продукта

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

Стратегия разрабатывается максимум на 3-4 месяца: в SEO нет смысла в долгосрочном планировании, все слишком быстро меняется 

У нашего product owner такие функции:

формирование бэклога, удаление и приоритизация задач, корректировка стратегии на основе данных, полученных от команды, при этом он  отвечает перед клиентами за результат. В нашем бизнесе важный стейкхолдер — это Google, который оценивает сайт. Потому что если клиент согласует тебе тексты или согласует эту стратегию, трафик у него не пойдёт. Трафик у него пойдет только, если тебе эти задачи согласует Google. Поэтому задача двойная: получить одобрение «робота», дающего трафик, и клиента.

Про организацию скрама вне IT-сферы

Внедрение scrum в нашу не IT команду мы начали с  формирования команд под каждое из 3 направлений SEO (управление ссылочной массой, создание контент и доработки сайта). Если раньше были отдельно копирайтеры и редакторы, линкбилдеры и SEO-аналитики, то  внедряя скрам мы перемешали специалистов друг с другом и сформировали новые структурные единицы.

В каждой команде есть аккаунт-менеджер, который вместе со специалистами доставляет ценность для клиентов.

Начали мы работать по месячному планированию, которое разбивали на спринты. Так пытались снизить риск отсутствия результата в конце месяца.

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

Еще одна особенность скрама — в IT-компаниях он внедряется по щелчку. Есть подробные методички, где расписано что сделать, чтобы скрам заработал.

Что такое инкремент в IT? Работающий продукт. Что такое демо ? Показ того, как работает продукт. Запустили программу, посмотрели — работает, и это хорошо.

У нас как у SEO-специалистов продукт всегда работает.

Как написание контента на работе продукта отражается? Что такое инкремент в SEO? А что показывать в презентации? Предположим, мы написали текст и разместили его на сайте. Это работающий или неработающий продукт? Поэтому мы очень много времени потратили на адаптацию IT-терминологии под наши нужды. Это оказалось самым сложным и адаптацию ушло более 3-х месяцев.

Про длительность спринта

С длительностью спринта мы экспериментируем. Как только начали внедрять scrum в нашу не IT команду, за стартовое значения приняли 1 неделю. Сейчас же некоторые команды перешли на двухнедельный спринт. Со спринтом в 1 неделю увеличивается динамика, можно быстро прогнать процесс и понять, где есть ошибки. Идет линия

«планирование —> стендапы —> демо —> ретроспектива»,

и все по новой. На таких спринтах можно быстро научить сотрудников, да и самим понять, как все работает.

Ключевая рекомендация по

продолжительности спринта scrum в маркетинге:

выбирайте срок, которого достаточно,

чтобы сделать полезную вещь.

В конце спринта всегда должен быть результат, иначе в нем нет смысла. Но увеличивая продолжительность спринта — вы увеличиваете риск срыва сроков.

Про скрам-инструменты (и не только)

Мы активно пользуемся инструментами скрама и взяли несколько из других методологий.

Мы использовали — покер-планирование.

Он помогает людям проговаривать свои мысли. Для нас это было возможностью обучить специалистов и обеспечить более глубокое погружение в задачу. Не только оценить задачи.

Как у нас происходит покер?

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

Диаграмму Ганта, несмотря на ее удобство мы не используем, потому что для скрама она не нужна. Зато взяли аналог инструмента «парное программирование» из  экстремального программирования Agile-семейства. Оно дает хорошие результаты, но из-за дороговизны используем его только в критичных моментах.

Также внедрили HADI-циклы, которые ближе к  бережливому производству (а конкретно Lean Startup) с его петлей «build —> measure —> learn» .

HADI-циклы — это то же самое:

«гипотеза —> action —> дата —> инсайт».

Как они работают?

Ты генерируешь гипотезы — то, в чем не уверен: сработает или нет. Если задача понятная и нужная, ее нет смысла обрабатывать на HADI-цикле, ее место в обычном спринте. Далее смотришь, какая из гипотез сработала и насколько хорошо, и запускаешь на спринт (или отбрасываешь).

Пример гипотезы:

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

В чем главное преимущество HADI-цикла?

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

Гипотезы важно документировать, даже если не сработали  — тогда в следующем спринте можно протестировать другую гипотезу. Важно также, чтобы у экспериментов не было «конфликта интересов» (например, направленность на одну и ту же веб-страницу). Иначе невозможно идентифицировать влияние гипотезы на результат.

Про тайм-трекинг

Мы не проводим тайм-трекинг. Для нас это табу — высчитывать, сколько человек отработал часов в течении недели, и потом говорить: «Что-то ты мало задач берешь». Все потому что учитываем фокус-фактор каждой команды: кто-то более производительный, кто-то — менее.

У нас часы — это усредненный показатель. На их основе берем реальное рабочее время команды и по разработанному коэффициенту высчитываем, сколько времени на какой проект пошло.

7 советов по внедрению скрама в неайтишной сфере

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

Текущий спринт должен всегда оставаться константой, все остальное — бэклог, приоритет — могут меняться на ходу. Не переводите бездумно всю компанию на скрам. Так, у нас копирайтеры работают по канбану , потому что у текстов нет приоритетов — просто их надо сделать как можно быстрее. Задайте оптимальный размер команды  — для скрама в не IT команде это от 5 до 7 человек. Организуйте рабочее пространство отдельно для каждой команды. Это можно сделать даже в open-space офисе, добавив несколько оффлайновых скрам-досок. Проявляйте инициативу. Если руководство не хочет реализовать скрам, то ничего не получится: оно всё заглохнет где-то внизу.

Интервью брала Кристина Лисовская ,

статью писал Ярослав Борута.
rss