Как объединить работу инхаус-команды и агентства

Познакомить инхаус-команду с командой агентства и планом работ

Специалисты, с которыми мы будем работать, должны иметь представление о нашей экспертизе и плане работ.

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

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

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

Назначить сроки и ответственных у задач, установить единые KPI у клиента и агентства

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

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

Директор по маркетингу Яндекс.Здоровья контролировала общий план и вектор движения проекта.

Руководитель перфоманс-маркетинга Яндекс.Здоровья отвечала за проект целиком и за операционное управление: текущие показатели, задачи на день и на неделю.

С нашей стороны ведущий менеджер помогал строить систему и налаживать процессы. Он презентовал и согласовывал решения нашей команды и был точкой опоры для руководителя перформанс-маркетинга Яндекс.Здоровья.

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

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

Согласовать единую логику принятия решений

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

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

Соблюдать принцип «взгляд сверху»

Задачи на проектах делятся на два типа: стратегические и операционные. Стратегические длятся около двух–трёх месяцев, а операционные идут параллельно. Они занимают гораздо меньше времени. Но так как их много и они оттягивают внимание ежедневно, есть риск застрять в операционке.

Чтобы не терять из вида стратегические задачи, мы соблюдаем принцип «взгляд сверху». У обеих команд есть единый ответственный, который ведёт проект. На проекте Яндекс.Здоровья это был наш ведущий менеджер. Он смотрел на то, как мы движемся к финальным целям всего проекта. Если мы отклонялись от курса, ведущий менеджер помогал вернуться назад: например, отменял задачи, которые особо не влияли на результат.

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

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

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

Мы всегда придерживаемся этого правила в работе, поэтому у обеих команд Яндекс.Здоровья был доступ ко всем документам и задачам проекта. Документы хранились на Гугл Диске, а задачи мы фиксировали на специально созданной для проекта доске в Trello.

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

Сформировать общее видение процесса

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

Для этого мы обычно используем два инструмента: диаграмму Ганта и внутренний таск менеджер. В диаграмме распределяем все задачи по неделям, а в таск-менеджере следим, как они двигаются по этапам к выполнению. Конкретно на проекте Яндекс.Здоровья мы использовали Trello вместо нашего таск-менеджера: так было удобнее объединить работу команд из разных компаний.

В Trello мы составляли план на каждую неделю: брали задачи из диаграммы Ганта и распределяли по специалистам. Так все видели, что происходит, на ком какие задачи и как они закрываются. Если что-то шло не так, это было сразу заметно: например, в понедельник мы запланировали 15 задач на неделю, а в среду сделано две — это тревожный сигнал. Мы идём к ребятам, чтобы узнать, в чём сложность и как её устранить.

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

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

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

Проводить регулярные совместные планёрки инхаус-команды и агентства

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

На проекте Яндекс.Здоровья мы проводили три типа планёрок: ежедневные, еженедельные и ежемесячные:

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

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

Ежемесячные планёрки — это что-то вроде ретроспективы. Мы выносили на повестку такие вопросы: статус проекта, чего достигли в цифрах, что сделали.

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

Дать возможность агентству влиять на состав инхаус-команды

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

Когда мы начинали проект Яндекс.Здоровья, в инхаус-команду искали ещё одного специалиста по рекламе. Так как за зону рекламы отвечали мы, нас привлекли к найму сотрудника, которому мы сможем передать все наши наработки. Мы провели предварительное собеседование с потенциальным специалистом и одобрили его кандидатуру. Дальше собеседовали и принимали решение в инхаус-команде. В итоге в Яндекс.Здоровье взяли человека, которому могли доверять все: и клиент, и мы.