Маркетологи — странный народец. Что-то вот там делают, пишут, по клавишам тыц-тыц и на боковую. А платим за что? Работа в чем? Непрозрачно как-то!
А организовывать их вообще кошмар как сложно. Бегают вокруг, что-то придумывают. Мы с этим тоже столкнулись, но выход есть! И в этой статье поделимся опытом и расскажем, через какие метаморфозы пришлось пройти нашему отделу маркетинга.
А в чем проблема-то?
Сейчас уже мало кто помнит, как отдел работал раньше. Но старожилы рассказывают, что было не очень. В промежутках между жалобами на молодежь и сидением в очередях в больницу.
Работали «как попало». Новая задача могла прилететь когда угодно, и было неясно: надо скорее браться за нее или сперва доделать предыдущую. Новичкам было трудно понять, нормально ли они справляются. Да и в целом проблема распространялась на весь отдел: было сложно измерить хорошо работает команда или нет. Никто не понимал, какая норма у сотрудника, можно ли ему докинуть еще с десяток задач, или он попросту не успеет сделать их все. Вкупе с отсутствием приоритетов это порождало какой-то вселенский хаос.
Были и проблемы во взаимодействии. Все проверки, вся работа отдела была завязана на руководителе, который проверял материалы. Это не особенно тормозило процесс. Но что если нанять еще пару сотрудников?
Команда из 3-4 человек практически не взаимодействовала между собой. Каждый занимался какими-то своими делами. Маркетолог мог столкнуться с трудностями и не знать, что коллега только что справился с такой же задачей.
В общем, мы были героями фильма. Мы не успевали все, везде и сразу. Плюс такой подход практически не масштабируется. Найми еще с пяток сотрудников и появится «бутылочное горлышко» — руководитель просто не успеет всех проверить и распределить задачи.
И что делать?
В какой-то момент мы поняли, что хватит это терпеть. Штат планировалось расширять, так что нужно было оптимизировать рабочий процесс. За решением далеко ходить не пришлось: мы решили перенять практики из отдела разработки, которые работают по SCRUM. Подход закрывает сразу три проблемы.
Проблема 1: Планирование и распределение нагрузки
По методологии каждая задача имеет свою «стоимость». Это число отражает сложность каждого таска. Оценка трудозатрат помогает измерить производительность отдельного сотрудника и отдела в целом.
Это помогает видеть общую картину намного лучше. Скажем, один сотрудник написал два материала, а другой снял и смонтировал видео. Кто поработал эффективнее? Или даже не так, мог ли все это сделать один человек?
Мы фиксируем производительность каждого в таблице и выводим средние значения. Спустя пару месяцев работы у нас появилось четкое понимание загрузки каждого сотрудника. Мы знаем, сколько задач может закрыть каждый член команды в день, неделю, месяц. Исходя из этих данных нам стало намного проще строить планы.
Также трудозатраты помогают отследить производительность сотрудника в динамике. Например, если средние значения начали падать, то нужно выяснить причины. Возможно, человек погребен под массой однотипных задач или ему просто пора в отпуск.
Главное здесь — это численные значения, которые можно сопоставить и сравнить.
И если раньше мы планировали как-то так:
То сейчас в этой таблице больше цифр и конкретики:
Проблема 2: Командные взаимодействия
Гибкие методологии строятся на взаимодействии команды. Маркетинг — это не та сфера, где можно все делать в одиночку, нельзя быть профи во всем. Идеальным сценарием будет разделение сфер ответственности. Кто-то отвечает за статьи (это я!), кто-то — за контекстную рекламу и так далее.
И чтобы эффективно работать с контентом, нужны межличностные отношения. Чтобы люди решали вопросы между собой и на выходе получался готовый продукт. Например, определить аудиторию статьи до написания и запланировать соответствующую рассылку. Такой подход позволяет делать более качественный контент
Проблема 3: Беспорядок в задачах
К методологии также прилагаются инструменты наведения порядка в задачах. Те же трудозатраты помогают команде удобно планировать день, не откладывать трудные вещи на потом.
Ставим приоритеты задач: «Низкий», «Средний» и «Высокий». Так уже намного проще понять, что важно закрыть в первую очередь. Благо, что никто не злоупотребляет с высоким приоритетом.
Ежедневные стендапы помогают грамотно организовать работу. Каждое утро команда собирается вместе, каждый рассказывает, что сделал вчера, что будет делать сегодня и какие трудности были. Так все в отделе в курсе, как продвигается работа по маркетинговой стратегии.
Почему спринты и куда мы тратим труд
Спринты в SCRUM подразумевают, что в их конце у команды появляется готовый продукт или его часть. Для маркетинга это не слишком применимо. В конце недели у нас не выходит какой-то один материал или одна рекламная кампания. Из-за этого многие редакции и маркетинговые агентства предпочитают канбан. Есть задачи, есть их статус, но за пределами «выкинуть таск в крайнюю колонку» цели нет.
Но мы все же решили использовать спринты. Потому что так намного проще считать трудозатраты и понимать, какой объем работ мы сможем взять на неделю. Для нас это важно, чтобы равномерно распределять нагрузку.
Особенно это полезно сейчас, когда отдел работает сразу над 4 продуктами, и мы можем отследить, как распределяются трудозатраты. Это удобно с точки зрения бизнеса, ведь у нас есть цифры, и мы можем посчитать рентабельность маркетинговых активностей.
Визуализация рабочего процесса помогает нам оценить прогресс спринта в любой день недели. Это хорошо работает с психологической точки зрения: ты видишь, сколько задач ты уже закрыл и сколько еще осталось. Есть ощущение, что делаешь что-то полезное для компании.
С этим нам помогает наша система Аспро.Agile, мы ее как раз для этого и разрабатывали. Долгое время использовали ее внутри компании и в этом году выпустили в публичный доступ.
Обычно мы не ставим цель спринта, но иногда случается. Чаще всего это релиз нового продукта или акция.
А что в итоге?
Сейчас мы все еще ищем способы оптимизировать свою работу. Видим еще много моментов, которые можно доработать. Все это процесс, причем небыстрый. Нам потребовалось несколько лет, чтобы прийти к формату, в котором нам будет комфортно работать. Хотя возможно, через пару лет мы посмотрим на эту статью и поймем, как же было неудобно.
Главное что методология помогает появляться новым практикам, развивать полезные и отказываться от того, что не работает.
Сочувствую, продавцы аджайлов и до вас добрались.
Всегда поражало то, как эти методологии способны убивать мотивацию тех людей, у которых все в порядке с самоорганизацией и без них.
А agile про «мотивацию» или про «самоорганизацию»?
Про демотивацию тех, у кого все в порядке с планированием, и ибд с нулевым эффектом тех, у кого изначально с этим не очень.
Не умеешь в планирование? Собери митинг! Отвлеки от работы как можно больше людей, чтобы у всех с ним тоже стало плохо!
Продавцы аджайлов нереально отравляют жизнь инженерам. Если удается, то можно взять от методологий лучшее и подходящее и применить вдумчиво (мы спринты натягивали на опс, кстати, сами спринты мне нравятся, но мне не нужен погонщик). Если нет - не вылезаем с созвонов.
Я не могу согласиться с такой интерпретацией Agile, хотя понимаю всё отвратительное влияние псевдо специалистов, которые массовики-затейники.:)
Ну нам-то все равно, мы работали до аджайла и будем работать после, если это после будет. Но пока на любую идею находятся предприимчивые продажники, которые не против присосаться, а в итоге на команду из 5 человек 4 менеджера, программистов не хватает, зато есть аджайл коуч в штате.
Менеджерам меньше платить просто можно)
Идите читайте, что такое аджайл на самом деле. То, что вам попадались плохие менеджеры, не умеющие в организацию процессов, контексты и повестки митингов, не означает, что они это делали из-за аджайла
И что такое "продавцы аджайла" вообще? Agile - манифест на несколько строчек. Если вам его кто "продал", напишите мне кто, мне такие ребята пригодятся в b2b продажах IT продуктов)
Я в курсе, что такое аджайл, скрам, канбан, safe, и к несчастью посчастливилось быть свидетелем того как они стали необходимостью и хайпом.
Насчет "продавцов аджайла" (ща объясню) - аджайл конечно манифест, но есть еще фреймворки и методологии, написаны куча книг, появились тренинги, аджайл коучи, вы действительно думаете, что это от доброты душевной и ради эффективности, и никто на этом не зарабатывает?
Я сдавала itil, например, это платно, а тренинг кажется длился 4 дня по 7 часов. Через пару лет вышла новая версия и новые курсы и сертификации. Тимлиды и пмы бесконечно ездили на курсы по методологиям, начали получать свои сертификаты, это такой же бизнес, как и продажа чего-то еще, позволяющая выпускникам филфака влиться в айти хоть в виде кого.
Я не говорю, что в методологиях нет здравого зерна. Что-то из них можно применять, если команде это подходит. Но попробуйте еще убедить того, кто внедрил например скрам, что вам нужна его модифицированная версия, потому что такие-то и сякие практики плохо вписываются. Очень многие считают что скрам не по книжке не может применяться.
А хорошие вдумчивые менеджеры это редкость, если повезло хоть раз с таким работать, то здорово. Но обычно мидлменеджмент очень погружен в свои собственные амбиции выслужиться пофиг чем, все равно подходит оно внедрению или нет, ведь мидлменеджмент хочет красивые графики и презентации, а еще вот методологии модно, надо внедрить.
Да, ваша проблема с "Agile" на самом деле не проблема с Agile, а проблема с людьми в вашей компании. Давайте приведу пример вам, как разработчику:
1. Аналитик пишет всеобъемлющее ТЗ, после этого вы разрабатываете монолитный продукт несколько месяцев, потом ваш ПМ сдает это все клиенту, а клиент говорит, что нужно подправить там и тут. Это "там и тут" никак вы не закладывали изначально в архитектуре и теперь на исправление + добавление этого нужно еще 3 месяца. Клиент начинает морозиться типа "че вы такие медленные, это же пустяк", возникают натянутые отношения из-за разработки
2. Вы вместе с аналитиком, менеджером и клиентом двигаетесь итеративно, начиная с самого малого. Фидбэк от клиента получаете раз в пару недель и обретаете возможность менять продукт во время его разработки. Пусть даже такой продукт будет разрабатываться тоже 6 месяцев (хотя вы не будете менять монолит раз в 3 месяца), но клиент будет видет результат работы + иметь возможность на него влиять +, скорее всего, даже первые итерации продукта уже будут генерить ему какое-то value
В итоге выходит, что 2 способ приводит к более здоровым отношениям с клиентом (он видит результат не через 3 месяца, а раз в пару недель, и может повлиять на что-то в моменте) и к более экономному отношению к трудозатратам
Это и есть на самом деле Agile.
По поводу того, о чем вы говорите - мое личное мнение, что все адепты скрама автоматически не подпадают под самый первый принцип Agile:
Individuals and interactions over processes and toolsПотому что считают, что дэйли митинги и ретроспективы важнее, чем то, что люди НЕ ХОТЯТ так часто встречаться/созваниваться :)
А Kanban - настолько минималистичная методология, что никаких agile coach'ей не нужно. И уж тем более она не заставляет никого созваниваться постоянно.
Как пример, я руководил разработкой крупного продукта на миллионы $ ARR, с командой в 30 человек, и созванивался с ними раз в месяц. Голоса QA я вообще услышал только через год после старта работы. И работали мы по Agile, закрывая релизы за релизом :) все потому что я обширно подготавливал требования и коммуницировал с командой в основном либо через задачи в JIRA, либо через Slack, а не через дейли стэндапы
В общем, сочувствую вам по поводу ваших менеджеров. Не все мы такие плохие)
Наверное, нужно было упомянуть, что я не разраб, а то что ныне называется "девопс", с широким спектром задач, как проектных, так и операционных и срочных (сегодня делаю инфру и мониторинг, завтра пишу биллинг), плюс я не работаю на галерах/аутстаффе, только в продуктовых компаниях где подобные истории с заказчиками в таком виде не существуют.
Наверное, это объяснит вам мое мнение.
Сейчас я работаю в команде разработчиков по единому процессу, и мне гораздо тяжелее, чем им.
Тем не менее, были и успешные истории адаптации скрама под доделки и операцонные задачи плюс практики айтил, до момента пока остапа не понесло и скраммастер не принес сторипойнты.
Но в основном сейчас печально и за последние 6 лет как я работаю по аджайлоскрамам становится все грустнее из-за негибкости и попытки его втюхать везде.
Ну и к вашему примеру: наличие итераций - это то, что нравится даже мне. Но проблемы не в этом, а в ритуалах и микроменеджменту, который расцветает в таких условиях. Хотя я знакома с ситуацией, когда пишешь acceptance criteria, разраб пишет что-то два спринта и выдает вообще не то, но зачем эти затраты на хлыстание человека, который так делает регулярно? Если есть те, кто не занимается отсебятиной при оговоренных requirements и не затягивает сроки и без погонщиков.
ну, у нас b2b продукты тоже (только крупный b2b, поэтому коммуникация с заказчиком обыденная), т.е. не галера/аутстафф
Но проблемы не в этом, а в ритуалах и микроменеджменту, который расцветает в таких условияхименно про это я и говорю - проблема в людях/менеджменте, не в самом Agile. В других компаниях это выстроено получше
Возможно, но и факт чуваков, впаривающтх курсы, сертификаты, коучинг тоже есть. И потенциальные возможности для нетехнических менеджеров и девочек с филфаков в роли скраммастера распустить хвост, надуть важные щеки и превратить скрам в репортинг. Конечно, вы можете сказать, что "у вас просто аджайла хорошего не было", но на моем опыте реализация говно в 90% случаев, в разных компаниях. Так что тут либо вам повезло (или вы молодец и построили все так, что всем хорошо), либо вы иначе все видите по ту сторону процесса.