Штат раздут, люди перерабатывают — а доходы не растут. Вот как digital-агентство решило эти проблемы

В прошлом году у digital-агентства Webmart Group появилась проблема: штат сотрудников раздувался, но при этом доходы или количество проектов не увеличивались. Нагрузка на специалистов возросла, многие стали оставаться в офисе по вечерам. Но эффект для бизнеса не чувствовался. Задумавшись, как решить проблему и оптимизировать работу, компания решила использовать такой подход, как scrum.

Что получилось в результате? Читайте.

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

Однако все это не приносило должного эффекта в виде роста дохода.

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

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

Что мы имели в начале

Работа агентства была построена следующим образом: sales manager закрывает сделку и передает клиента project manager (далее PM). Исходя из загрузки технического отдела новый клиент уходит — к свободному специалисту этого отдела. И получалось, что любой технический специалист мог выполнять задачи по проекту любого PM. Случалось, что по одному проекту работали поочередно сразу несколько специалистов по настройке рекламных кампаний.

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

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

Как мы оптимизировали рабочий процесс

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

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

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

Внедрение scrum

Шаг 1. Все началось с двух отделов — PPC (отдел контекстной рекламы) и PM (отдел аккаунтинга). Сотрудников мы разделили на команды. Формирование команды строилось на основе оценки трудоемкости проектов и объема работ. Далее определялось количество технических специалистов, необходимых на каждый проект. В результате мы получили несколько команд, в которых был один PM и 2−3 технических специалиста.

Суть в том, что команда работает только над проектами своего PM, а выполнение других задач осуществляется только в крайних случаях. По сути, project manager стал product owner.

Шаг 2. Разработка дополнительной системы мотивации для команд (список плановых показателей на три месяца и бонусы за их достижение).

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

Шаг 4. Создание скрам-доски, где сбоку указаны названия команд, а сверху — этапы работы:

• Список задач
• В процессе
• На согласовании
• Сделано.

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

Шаг 5. Внедрение расписания еженедельных митингов с командой. В ходе этого митинга команда, во главе которой стоит PM, должна подвести итоги предыдущего спринта и обозначить задачи для выполнения — на следующий спринт.

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

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

Новый порядок работы

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

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

Конечно, некоторых клиентов не получалось «подвести» ни под один из подходов полностью. Они могли спланировать примерно 80% задач. Для таких случаев PM закладывал определенное небольшое количество часов на «незапланированные задачи». Да-да, мы начали планировать незапланированное.

В результате: сейчас задачи собираются до 16:00 четверга, после чего начинается недельный митинг (обсуждение итогов). Обсуждается уже проделанная работа, выявляются проблемы и тормозящие работу факторы, сверяется запланированное/потраченное время по проектам, планируются задачи на следующий спринт.

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

Проблемы, с которыми мы столкнулись

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

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

2. Когда один из членов команды не выходил на работу (отпуск, болезнь) — работа в команде начинала разрушаться, а следовательно, срывались сроки. Мы решили эту проблему вот так:

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

Что мы получили после внедрения scrum

1. Сотрудники технических отделов стали быстрее и лучше выполнять свои задачи за счет того, что:

а) Мы нашли огромное количество процессов при анализе планируемого/затраченного времени, которые тормозили работу, и занялись оптимизацией.

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

• Уменьшение количества ошибок (на 56%)
• Уменьшение числа правок со стороны клиентов (на 45%) 
• Улучшение KPI по проектам (в среднем в проектах с KPI их рост составил 17%).

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

И этот ресурс необходимо еще загрузить проектами.

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

Что мы планируем дальше делать по scrum

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

• Делать scrum более «чистым», добавляя некоторые атрибуты классической модели, например, обязательные ежедневные stand up-митинги
• Продолжить оптимизацию рабочего процесса, выявить и устранить потери, в первую очередь качественные и временные
• Пробуем вводить ретроспективы спринтов для того, чтобы получать фидбэк от всей команды (ретроспектива спринта — это регулярные встречи команд, на которых они обсуждают результат своей работы, проблемы, успехи)
• Экспериментируем с метриками: например, пробуем составлять BurnDown-диаграммы (диаграмма, показывающая сделанное и оставшееся количество задач в текущем спринте).

Плюс к этому мы хотим перевести на подобный формат работы и другие отделы компании.