Как SEO-агентство перешло на SCRUM и за год выросло X3 по обороту и выручке

SEO-агентство выжило и решило проблему роста благодаря внедрению SCRUM-методологии. Делимся основными принципами и шаблонами скрам-планирования, которые команда адаптировала и внедрила в бизнес-процессы.

До внедрения SCRUM (июль 2023 года) у нас работало 17 человек, SEO-специалисты были разделены на две команды. В командах были тимлиды, которые управляли задачами, следили за сроками выполнения задач, KPI и другими вещами. Мидлы, которые вели проекты, общались с клиентами, и раздавали задачи джунам.

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

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

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

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

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

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

Наконец, уверенно привлекать новых клиентов на обслуживание мы не могли — в CRM 200 незакрытых задач, мы же не справляемся! Да и лидировали проекты мидлы, те самые, которые по большей части тянули проекты.

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

Нужно было что-то менять.

Было понятно, что нам не хватает системы. Другие команды справляются, а мы нет. Значит, выход есть.

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

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

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

Я дал задачу команде прочитать книгу Сазерленда, сообщив, что мы будем переходить на SCRUM, так как это наша возможность навести порядок в процессах и выжить. Прописал минимальные принципы работы по методологии:

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

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

Первое планирование спринта SCUM продлилось почти 4 часа. Команда не очень понимала, что делать — ни Сазерленд, ни кто-либо другой не описывает, как именно работать с задачами по скрам, особенно при адаптации подхода к нашей специфике. Поэтому мы импровизировали.

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

В результате после спринта появились 2 таблички.

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

Таблица со списком задач на спринт. По каждому сотруднику своя колонка с днями спринта, задачи, которые отдаем человеку и часы на эту задачи, проекты, к которому относится задача. Заполнили такую табличку после того, как раскидали задачи в CRM.

Шаблон таблички выложили в открытый доступ. Можете забрать себе и пользоваться.

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

Решали все разговорами, объясняли, что подход действительно важен, нужен и работает. Привыкание случилось довольно быстро. Всего через 2-3 недели недовольство стало исчезать. Теперь все в команде говорят, что с новой системой работать гораздо лучше.

Основные три принципа, о которых говорит сам Сазерленд, — прозрачность, инспекция, адаптация, — мы интегрировали в наши процессы, и сами разработали еще несколько.

Спринт нерушим. Это главное правило, которым мы руководствуемся и которое нам реально помогло. У нас была большая проблема с так называемым телеграм-управлением. В личку ответственному мог постучаться клиент со срочной задачей, коллега с просьбой о помощи. Если просили очень настойчиво — человек откладывал свои задачи и занимался новыми. Понятно, к чему это приводило.

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

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

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

Внимание всем проектам. Равномерно распределяем ресурсы на все проекты вне зависимости от личных предпочтений или активности тех или иных клиентов.

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

Распределение ролей в команде выглядит следующим образом:

Ключевые единицы спринта: проект, задача, день, час. У Сазерленда нет такого понятия, как «проект», есть только «задачи», так что здесь мы тоже адаптировали классический подход.

В конечном счете структура нашего спринта выглядит так.

Подготовка к спринту — отдельный процесс.

Скрам-мастер:

Ответственные по проектам:

Все остальные участники:

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

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

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

Для всего есть регламенты. Изначально я прописал минимальный план, чтобы на первом планировании было понятно, как мы работаем. Но после наш Head of SEO, которая на тот момент была тимлидом первой команды, перешедшей на SCRUM, расписала регламенты работы по методологии, что очень помогло другим сотрудникам и особенно адаптации новичков.

Мы подготовили видео на тему работы по SCRUM. В ролике Head Of SEO Алина подробно рассказывает, как мы планируем спринты, распределяем задачи и проводим совещания.

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

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

Еще один плюс — SCRUM позволил нам активно расти: за год мы выросли в два раза по сотрудникам, проектам и еще больше по обороту. Не испытываем проблем с управлением командой в 30 человек — рабочая методология позволяет расти и дальше.

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

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

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

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

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