{"id":14268,"url":"\/distributions\/14268\/click?bit=1&hash=1e3309842e8b07895e75261917827295839cd5d4d57d48f0ca524f3f535a7946","title":"\u0420\u0430\u0437\u0440\u0435\u0448\u0430\u0442\u044c \u0441\u043e\u0442\u0440\u0443\u0434\u043d\u0438\u043a\u0430\u043c \u0438\u0433\u0440\u0430\u0442\u044c \u043d\u0430 \u0440\u0430\u0431\u043e\u0447\u0435\u043c \u043c\u0435\u0441\u0442\u0435 \u044d\u0444\u0444\u0435\u043a\u0442\u0438\u0432\u043d\u043e?","buttonText":"\u0423\u0437\u043d\u0430\u0442\u044c","imageUuid":"f71e1caf-7964-5525-98be-104bb436cb54"}

Кнут, Канбан и Scrum. Как заставить маркетологов работать?

Маркетологи — странный народец. Что-то вот там делают, пишут, по клавишам тыц-тыц и на боковую. А платим за что? Работа в чем? Непрозрачно как-то!

А организовывать их вообще кошмар как сложно. Бегают вокруг, что-то придумывают. Мы с этим тоже столкнулись, но выход есть! И в этой статье поделимся опытом и расскажем, через какие метаморфозы пришлось пройти нашему отделу маркетинга.

Stockimage.jpg

А в чем проблема-то?

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

Работали «как попало». Новая задача могла прилететь когда угодно, и было неясно: надо скорее браться за нее или сперва доделать предыдущую. Новичкам было трудно понять, нормально ли они справляются. Да и в целом проблема распространялась на весь отдел: было сложно измерить хорошо работает команда или нет. Никто не понимал, какая норма у сотрудника, можно ли ему докинуть еще с десяток задач, или он попросту не успеет сделать их все. Вкупе с отсутствием приоритетов это порождало какой-то вселенский хаос.

Были и проблемы во взаимодействии. Все проверки, вся работа отдела была завязана на руководителе, который проверял материалы. Это не особенно тормозило процесс. Но что если нанять еще пару сотрудников?

Команда из 3-4 человек практически не взаимодействовала между собой. Каждый занимался какими-то своими делами. Маркетолог мог столкнуться с трудностями и не знать, что коллега только что справился с такой же задачей.

В общем, мы были героями фильма. Мы не успевали все, везде и сразу. Плюс такой подход практически не масштабируется. Найми еще с пяток сотрудников и появится «бутылочное горлышко» — руководитель просто не успеет всех проверить и распределить задачи.

И что делать?

В какой-то момент мы поняли, что хватит это терпеть. Штат планировалось расширять, так что нужно было оптимизировать рабочий процесс. За решением далеко ходить не пришлось: мы решили перенять практики из отдела разработки, которые работают по SCRUM. Подход закрывает сразу три проблемы.

Проблема 1: Планирование и распределение нагрузки

По методологии каждая задача имеет свою «стоимость». Это число отражает сложность каждого таска. Оценка трудозатрат помогает измерить производительность отдельного сотрудника и отдела в целом.

Это помогает видеть общую картину намного лучше. Скажем, один сотрудник написал два материала, а другой снял и смонтировал видео. Кто поработал эффективнее? Или даже не так, мог ли все это сделать один человек?

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

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

Главное здесь — это численные значения, которые можно сопоставить и сравнить.

И если раньше мы планировали как-то так:

То сейчас в этой таблице больше цифр и конкретики:

Проблема 2: Командные взаимодействия

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

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

Проблема 3: Беспорядок в задачах

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

Ставим приоритеты задач: «Низкий», «Средний» и «Высокий». Так уже намного проще понять, что важно закрыть в первую очередь. Благо, что никто не злоупотребляет с высоким приоритетом.

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

Почему спринты и куда мы тратим труд

Спринты в SCRUM подразумевают, что в их конце у команды появляется готовый продукт или его часть. Для маркетинга это не слишком применимо. В конце недели у нас не выходит какой-то один материал или одна рекламная кампания. Из-за этого многие редакции и маркетинговые агентства предпочитают канбан. Есть задачи, есть их статус, но за пределами «выкинуть таск в крайнюю колонку» цели нет.

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

Потому что надо было лучше работать, а не писать хокку.

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

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

С этим нам помогает наша система Аспро.Agile, мы ее как раз для этого и разрабатывали. Долгое время использовали ее внутри компании и в этом году выпустили в публичный доступ.

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

А что в итоге?

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

Главное что методология помогает появляться новым практикам, развивать полезные и отказываться от того, что не работает.

0
77 комментариев
Написать комментарий...
Александр Стексов

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

Ответить
Развернуть ветку
Сергей Галямов

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

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

Ответить
Развернуть ветку
СлавалС

непрофессионалы не построят качественную систему, а профессионалы и так все сделают качественно без вашего скрама.
И да назовите авторов скрама, а главное какой выдающийся продукт(ы) они сделали.
Вот Линус писал и до сих пор участвует в написании ядра линукса через почтовые рассылки.
А линукс работает от калькулятора, до мейнфрейма - результат более чем успешный.

Ответить
Развернуть ветку
Илья Ланкевич

Удивительно, но у меня под рукой есть авторы: Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Ken Schwaber, Jeff Sutherland, Dave Thomas.
Правда, для других целей и они авторы Agile Manifesto.:) Но я думаю, этого достаточно.
Хочет уточнить, а при чем здесь Torvalds? И почему ядро Линукса вдруг стал «продуктом»?

Ответить
Развернуть ветку
СлавалС

меня не интересуют авторы, меня интересует работающий результат. Сначала хочу посмотреть что они такого сделали, а потом уже пусть рассказывают как.
Вот у торвальдса он есть. А что ядро линукса не продукт?)))

Agile manifest для малограмотных, которые не знакомы с процессом конструирования изделий в индустриальном веке :)
принципы аджайла просто присвоены этими гражданами, но никак не ими придуманы. Ну и там вообще содержимое за все хорошее против всего плохого, при это нигде не указаны границы применения этого, хотя по факту к каждому пункту можно привести опровержение.

Из всего списка знаю только Фаулера и его рассказы о том, как он решал какие-то проблемы в софте, что весьма полезно.

Ответить
Развернуть ветку
Илья Ланкевич

У меня к тебе вопросов больше нет. Ты что видишь (знаешь), то и поешь.
Бог тебе судья.:)
Ядро Линукса - не "работающий результат".:) Но ты этого не видишь.:)
"Сначала хочу посмотреть", ну, так, блядь, возьми и посмотри, кобольный ты наш.:)

Ответить
Развернуть ветку
СлавалС

Ядро линукса не работающий результат? ну-ну.
да 90% бекедной инфраструктуры работает на линкусе.

Ответить
Развернуть ветку
Илья Ланкевич

Работает на линуксе или на ядре линукса?

Ответить
Развернуть ветку
Борис Вишневский

линукс это ядро и есть

Ответить
Развернуть ветку
Илья Ланкевич

Linux — семейство операционных систем на БАЗЕ ЯДРА LINUX и торговая марка.
А в "бекенде" (и не только) используют отдельные оперсистемы на ядре Linux, например, Android в основе имеет ядро Linux.
Это терминологический спор и он лишён практического смысла, я лишь хотел сказать, что ядро Linux не является "продуктом". Да и об этом я спорить не хочу, т.к. не вижу в этом смысла.

Ответить
Развернуть ветку
СлавалС

скажем так, ядро продукт, ОС линукс набор продуктов, которые базируются на ядре и базовой системе.
и любой shell script написанный правильно, будет работать на компе 1980 года и сегодня.
Ровно как и набор базовых компонент, один и тот же.

Ответить
Развернуть ветку
Борис Вишневский

ОС обычно называют GNU/Linux если они открытые и не особо упоминают линукс если ОС выходит за рамки гну/линукса, как это с тем же андроидом

Ответить
Развернуть ветку
Илья Ланкевич

Вот что Линус писал про Linux kernel:
[As] I mentioned a month ago, I'm working on a free version of a Minix-lookalike for AT-386 computers. It has finally reached the stage where it's even usable (though may not be depending on what you want), and I am willing to put out the sources for wider distribution. It is just version 0.02...but I've successfully run bash, gcc, gnu-make, gnu-sed, compress, etc. under it.

Ответить
Развернуть ветку
Илья Ланкевич

Проект GNU лишь один из вариантов, д.б. самый авторитетный из-за участников. Но опять-таки это больше, чем "ядро линукса".

Ответить
Развернуть ветку
СлавалС

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

Ответить
Развернуть ветку
СлавалС

как раз таки на ядре линукса

Ответить
Развернуть ветку
Странный Игрок

Может быть специалист потому и лучший, что работает не на максимум, а на качество?

Ответить
Развернуть ветку
74 комментария
Раскрывать всегда