С 30 ноября по 1 декабря в Москве проходила конференция Optimization 2017. В рамках секции «Управление digital-проектами» Константин Солодянников (IT-Agency) выступил с докладом «Работа с человеческими факторами на SEO-проектах с большим количеством людей».
Спикер поделился тонкостями в организации и управлении на крупных проектах с большим количеством людей. Не с точки зрения руководителя digital, а точки зрения старшего SEO-специалиста или руководителя SEO.
С точки зрения SEO-шника, на таких больших и сложных проектах есть только одна стабильная вещь: все всегда идет не так, как планировали.
Проблемы обычно такие:
— что происходит с SEO до нас и сейчас?
— кто все эти люди и кто за что отвечает?
— как встроиться в процессы и сделать так, чтобы ТЗ внедрялись?
Что делать? Как минимум заводить таблички и налаживать коммуникации. Но это лишь борьба со следствиями. Предлагаю вам посмотреть глубже, в конкретику.
Как минимум:
Как максимум:
Начнем по порядку. Первая из проблем появляется еще на старте проекта.
Непонятно, что вообще происходит с SEO и что именно делали прошлые подрядчики.
Расскажу на примере кейса запуска крупного проекта через тендер.
С чем столкнулись при запуске. Во-первых, с кучей зависших задач, во-вторых со сломанным процессом регулярных работ по оптимизации, в-третьих, с внезапными расходами в несколько десятков тысяч рублей на арендные ссылки.
Теперь о каждом сюрпризе подробнее.
Прошлый подрядчик поставил команде внедрения большую и сложную задачу по увеличению количества посадочных страниц в каталоге. Причем так, чтобы страницы появлялись автоматически.
Т.е. ребята просто перемножили всё на всё и отдали разработчикам. Те в свою очередь честно сделали и принесли через две недели. С точки зрения ТЗ все круто — страницы создаются автоматически, добавляются в перелинковку и карту сайта.
Постановщик задачи остался бы доволен. Но все же создавать страницы «всё на всё» — бессмысленно и скорее вредно. Да, вся семантика охвачена, но появляется куча страниц, на которые нет спроса. Пример выкатки таких изменений — на скриншоте.
Получили кучу бесполезных мусорных страниц для поиска.
Поиск слегка обиделся и начал снижать позиции и трафик. Потом, конечно, все починили, но осадочек остался.
В результате потратили время на разработку и не сделали важное. Потому что из-за одной небольшой, но важной ошибки трафик может просесть на полгода. Хорошо, что не в сезон и потери не очень значительные.
Просить весь стэк задач и инфраструктуру еще до запуска, например, так, как на скриншоте.
Тогда бы сразу узнали, что будет дополнительная работа с контентом, которую вела прошлая команда. Учли бы требования к оптимизации с учетом специфики Битрикса и знали к кому идти с вопросами.
Вторая часть кейса — сломанные регулярные процессы. До нашего запуска ребята регулярно добавляли на сайт новые продукты и сразу оптимизировали их руками контент-менеджера. С их уходом за процессом никто не стал следить, руководитель маркетинга тоже был не в курсе. Задачи не приходили контент-менеджеру и, соответственно, не делались.
В итоге получили вопросы от маркетолога, почему новые добавленные продукты не ищутся в поиске, а должны бы. И недополучили какое-то количество трафика.
Сразу спросить про все дополнительные процессы и у клиента, и у подрядчика. А потом сделать инструкцию к задаче для контент-менеджера. Так и процесс не упустим, и регулярную работу человеку облегчим.
На закуску, мой любимый пример про дополнительные десятки тысяч рублей расходов на оплату ссылок. Так получается, когда клиент не в курсе распределения бюджета на стороне агентства и платит за какие-то ссылки, не уточняя их количество. Потому что не принято да и незачем лезть в сеошные вещи.
По итогу получаем прикольный сюрприз для нас и клиента в виде дополнительной суммы на оплату ссылок. Конечно, в итоге договорились и большую часть сняли. Но ощущения незабываемые. Теперь знаем, что всегда нужно учитывать все внешние бюджеты от подрядчиков и показывать их на берегу, перед оценкой и стартом работ.
Такие примеры показывают, как важно всегда еще перед стартом любого проекта узнавать о подводных камнях и задавать максимум вопросов — руководителю и команде проекта, прошлым подрядчикам и менеджерам. На старте занимает много времени, но и ясности становится больше. А количество неприятных сюрпризов —меньше.
На хорошем уровне развития бизнеса неизбежно появляется дополнительная бюрократия. Это ни хорошо, ни плохо. Просто чтобы организовать работу более 500 человек, нужны все эти департаменты, направления, службы, отделы.
Весело становится, когда с таким десятком ролей и людей надо что-то согласовать. Обычно в таком случае все уходит в почту на 10–15 человек в копии, чуть лучше —если в таск-трекер и общий отчет. Когда все видят — хорошо. Но обратная сторона медали — люди видят кучу ненужного. Сложно работать, когда тебе каждый день в почту приходят письма и непонятно, нужно ли тебе на них вообще реагировать.
И так техническое задание или предложение по улучшению отправляется в увлекательное путешествие и обрастает Re:Re:Re. Но не делается.
Завести табличку с описанием людей, их ролей на проекте и контактов.
Кто за что отвечает, к кому можно обратиться. И наоборот, к кому необязательно идти и ставить в копию. Еще круче — собрать нескольких людей на один общий созвон, для которого они реально нужны.
Суть — на конкретных блоках и бизнес-центрах хорошо бы показывать посетителю видеообзор, чтобы он мог видеть почти вживую обстановку, состояние офисов и вид из окна. В режиме общения по почте внедрить такие изменения почти нереально — люди просто не смогут оценить, что конкретно им нужно сделать.
В качестве примера — оцените все количество людей, которые договорились на одной планерке.
В ролях:
— руководитель отдела продаж, который впишет требования к видеозаписям в инструкцию для брокеров,
— дизайнер, который создает требования к видео и его размещению на сайте,
— маркетолог, который будет использовать видео как преимущество,
— технический директор, который курирует все технические процессы,
— тим-лид разработки, который назначает исполнителей и управляет сроками,
— программист, который сделает автоматический импорт из YouTube на сайт,
— верстальщик, который сделает так, чтобы видео можно было и с телефона смотреть,
— и SEO-шник с менеджером, которые всех собрали и договорились.
Задача согласования решена за 20 минут. Новые видео будут регулярно появляться.
Следующий шаг — помочь внедрить такие сложные задачи. На примере видео: для контентщика, верстальщика и программиста — это разные части задачи. Первому нужно написать регламент для названия и описания видеозаписи, второму — требования к верстке и микроразметке, а к третьему — требования к импорту из YouTube.
Так получаем три ТЗ вместо одного, но работать с ним будет проще конкретным людям, из-за деления по ролям.
Сами ТЗ сводим в единую табличку, которая служит общим таск-трекером. Каждый участник команды видит, что нужно делать ему, и не ищет свои задачи в списках других.
Дублирование во внешних системах — это нормально, если предупреждать на берегу.
Моя задача, как SEO-шника, регулярно все задачи показывать, обновлять и отслеживать.
Большое количество людей на проекте — это нормально. Давайте их классифицировать, кластеризировать. Мы же SEO-шники. И давать каждой группе только то, что ей нужно делать, внедрять изменения только на нужных группах.
Сразу все лучше не станет, но появится системность и меньше сюрпризов.
Теперь пора разобраться, как это все точечно внедрять в процессы.
Кажется, что внедрение в процессы — это просто. Взяли и завели общую табличку, расставили задачи по нужным людям, контролируем и управляем. На самом деле нет.
Такие изменения еще не гарантируют внедрение ТЗ.
Вроде все сюрпризы и подводные камни первых двух этапов прошли, научили разработку и копирайтера сразу делать все правильно. Даже сделали несколько небольших задач.
А потом пришла пауза и задачи встали на три недели.
Обычно тут наступает тупняк и время длительных агрессивных переговоров в духе «почему ничего не делаете, м*даки?!». У нас задачи стоят и сроки горят! А менеджер на стороне клиента виновато прячет глаза и говорит: «Ребят, вот сейчас все будет, еще недельку надо».
Да просто до безобразия. Сесть и внимательно расспросить, не ругать и не наезжать. Спрашивать о процессе внедрения больших изменений, кто еще ставит задачи и как человек управляет потоком. Agile или Waterfall — неважно. Важно поймать тот момент, когда список задач на итерацию только формируется.
И влезть туда. В примере список задач на команду выглядит как месячный план с основными задачами на поддержку и развитие:
Если линейно добавить наши задачи — они так и останутся на последних местах и приоритетах. Надо продвинуть их в ТОП через те самые человеческие факторы.
Во-первых, четко описать каждую задачу и предполагаемый эффект. При расфасовке большого количества важного из сложного мозг выберет понятное.
Во-вторых, делить задачи на роли и делать примерную оценку по часам даже на своей стороне. Естественно, не обманывать и не занимать. А самим придумывать, как разбить большую сложную задачу на несколько небольших и средней сложности.
На примере стандартного ТЗ по созданию нескольких новых разделов сразу разбить в порядке приоритетов по спросу и учесть, насколько надо перепиливать структуру. Если это интернет-магазин, то смотреть по спросу и прибыли. Когда разделы в разной логике и с несколькими сущностями — например, отзывы или вопросы-ответы — делить по логике и спросу. Делать то, что проще и прибыльнее.
А чтобы человеку было приятнее с нами работать, придерживаться базового набора организационных вещей. Сделать так, чтобы нас было легко контролировать.
Для начала начать отправлять текстовые отчеты с любой встречи в почту. Фиксировать все договоренности, обсуждаемые проблемы и результаты.
Еще писать к таким письмам и отчетам текстовые выжимки, буквально пару абзацев. Чтобы человек не читал огромные письма, не смотрел непонятные таблички. А видел то, что ему нужно.
Результаты такой проработки человеческих факторов не заставят себя долго ждать. Управленцы будут довольны, что мы экономим их время пояснением каждой задачи, краткими выжимками и обсуждениями. В результате наши задачи будут в ТОПе, будут быстрее внедряться и приносить результат.
Вне SEO этот совет применим для всех. Работа должна быть комфортной для нас.
Мы разобрали только небольшую долю тех проблем, которые возникают регулярно и мешают внедрять изменения и получать результат вовремя и без напряга.
На запуске важно следить за зависшими задачами, регулярными работами и всеми дополнительными расходами проекта. В голове держать не надо, просто пройти по списку.
В командах от 20 человек важно следить за тем, кто именно с нами работает, какую занимает роль и как может повлиять на решение. Поможет таблица людей и ролей на проекте. Работать только с теми людьми, которые реально нужны для выполнения задачи и ставить им задачи по ролям.
На встраивании в процессы важно сделать так, чтобы человеку было комфортно с нами работать. Не наезжать, а спокойно обсуждать и искать решения. Сами решения делать как можно «отделимее» и проще.
Для того, чтобы проверить проработку человеческих факторов у себя на проекте —воспользуйтесь табличкой .