Как найти общий язык с партнерами по проекту: восемь правил

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

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

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

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

• единые KPI;

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

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

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

На примере проекта «Яндекс.Здоровья» я расскажу, что это за правила.

Подписывайтесь на канал Rusbase в «Яндекс.Дзен», чтобы ничего не пропустить

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Задачи на проектах делятся на два типа:

• стратегические, которые длятся около двух-трех месяцев;
• операционные, которые идут параллельно, занимая гораздо меньше времени.

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

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

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

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

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

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

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

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

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

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

Для этого мы обычно используем два инструмента:

• диаграмму Ганта, где распределяем все задачи по неделям,
• внутренний таск-менеджер, где следим, как они двигаются по этапам к выполнению.

Конкретно на проекте «Яндекс.Здоровья» мы использовали Trello вместо нашего таск-менеджера: так было удобнее объединить работу команд из разных компаний.

Все задачи на проекте мы фиксировали в Trello. Одна неделя — одна колонка с задачами всех специалистов. Каждый видит, кто чем занимается на этой неделе.

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

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

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

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

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

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

• что происходит на проекте,

• в какой зоне мы отстаем,

• в какой ушли вперед.

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

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

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

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

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

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

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

Когда мы начинали работать с «Яндекс.Здоровьем», они искали еще одного специалиста по рекламе. Так как за зону рекламы отвечали мы, нас привлекли к найму сотрудника.

Мы провели предварительное интервью с потенциальным специалистом и одобрили его кандидатуру. Дальше собеседовали и принимали решение в инхаус-команде. В итоге в «Яндекс.Здоровье» взяли человека, которому могли доверять все: и клиент, и мы.

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

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

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

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

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

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