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

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

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

— доверие команды клиента к нашей экспертизе;

— здоровая коммуникация;

— единые KPI;

— прозрачность процессов;

— синхронизация команд.

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

Рассказываем на примере проекта Яндекс. Здоровья, что это за правила.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Но бывает и по-другому: когда кто-то из инхаус-команды игнорирует задачи или срывает сроки. Это подрывает весь процесс.

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

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

Правила решают всё

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

На время совместной работы с командой с Яндекс. Здоровье мы стали партнёром проекта и чётко следовали правилам совместной работы. В результате за короткий срок мы усилили команду и помогли настроить процессы.

Впервые статья была опубликована в издании Rusbase.