Как мы организовываем работу SEO-проекта с командой больше десяти человек
На больших и сложных проектах всё всегда идёт не по плану. Из раза в раз мы сталкиваемся с хаосом на проекте, потому что непонятно:
- Что происходило на проекте до нас и что происходит сейчас?
- Кто за что отвечает на стороне клиента?
- Как настроить работу так, чтобы техзадания внедрялись, а не откладывались на потом?
Эти проблемы почти всегда связаны не с технической частью, а с обычными человеческими факторами. Если их не проработать, работа идёт медленно, а результат получается плохим.
Чтобы наладить работу, мы с самого старта проекта стараемся предвидеть все сюрпризы, сделать работу с нами удобной, а наши задачи — понятными. О том, как это делать я рассказал на конференции Optimization в 2017 году. Ниже — видео с выступления и текстовая версия.
Константин Солодянников рассказывает, как организовать работу на проекте с большим количеством людей
Разобраться, что было до нас и что происходит сейчас
Первая проблема появляется ещё на старте проекта — непонятно, что делали прошлые подрядчики и что происходит с SEO на проекте прямо сейчас. Объясню, как это выглядит на примере одного крупного проекта.
Мы выиграли тендер и сразу столкнулись с тремя проблемами:
- Было много зависших задач.
- Сломался регулярный процесс.
- Появились непредвиденные расходы.
Чтобы избежать этих проблем, надо подумать о них заранее:
Найти зависшие задачи. Прошлый подрядчик поставил разработчикам задачу: настроить автоматическую генерацию страниц в каталоге. Затем мы сменили прошлого подрядчика. Про эту задачу мы ничего не знали.
Когда разработчики принесли нам завершённую задачу, это стало сюрпризом. С точки зрения техзадания, всё было хорошо: страницы по товарам создаются автоматически, добавляются в перелинковку и карту сайта. С точки зрения SEO, всё было плохо: появилось много страниц, на которые нет спроса. За это поисковики снизили нам позиции, и трафик упал.
Нам удалось всё починить, но это заняло полгода. Хорошо, что был не сезон и потери в деньгах были не очень значительны.
Разузнать о работающих процессах по оптимизации. Прошлый подрядчик регулярно добавлял на сайт новые продукты и сразу оптимизировал их с помощью контент-менеджера. Руководитель маркетинга ничего про эту задачу не знал, и когда подрядчик ушёл, следить за её выполнением стало некому. Задачи контент-менеджеру не ставили, поэтому он их и не делал. Спустя время руководитель маркетинга начал спрашивать, почему новые продукты нельзя найти в поиске, хотя они должны быть там.
Получилось так, что мы сломали отлаженный процесс, потому что ничего про него не знали. А в итоге упустили часть трафика. Даже брендового.
Учесть все текущие расходы. Клиент не всегда знает, как распределяется бюджет на стороне подрядчика, потому что ему неинтересно вдаваться в SEO-шные детали.
Однажды на одном из проектов у нас возникли дополнительные расходы на десятки тысяч рублей, потому что мы не знали о расходах на арендные ссылки, которые закупал прошлый подрядчик. Это было неприятно и для нас, и для клиента.
Чтобы избежать сюрпризов на новых проектах, нужно глубоко разбираться, что, как и за сколько делал прошлый подрядчик. Для этого мы задаём как можно больше вопросов всем участникам процесса: руководителю, команде проекта, прошлым подрядчикам и менеджерам. Это затягивает начало работы, но значительно добавляет ясности и защищает от ошибок по незнанию.
Определить роль каждого человека
Вторая проблема — долгие согласования. На крупных проектах приходится даже по небольшим задачам общаться с 10–15 людьми, чтобы никто ничего не пропустил. С одной стороны это хорошо, потому что все в курсе происходящего. С другой — плохо, потому что люди видят кучу ненужного и не понимают, нужно ли реагировать.
Когда на проекте много людей, техническое задание или предложение по улучшению быстро тонет в цепочке писем, а до результата не доходит. Работать в таком режиме неудобно и бессмысленно.
Вопросы, которые мы задаём на старте проекта
Чтобы знать, кто за что отвечает и к кому нужно обращаться в разных ситуациях, мы заполняем таблицу людей и ролей на проекте. Это помогает нам понимать, кого и по какому вопросу нужно привлекать, а кого — нет.
В жизни это выглядит так: мы предложили агентству недвижимости сделать видеообзоры офисов, чтобы повысить продажи. Теперь эту задачу нужно согласовать с руководителями и распределить задачи по команде. Подумав, мы поняли, что нам для этого нужно девять человек:
Шаблон таблицы людей и ролей на проекте
Обычно все задачи записывают в одно общее техзадание, и каждый участник самостоятельно ищет свои задачи среди них. Из-за этого часть задач может потеряться.
Чтобы не было путаницы, мы сразу распределяем задачи по людям. Для этого мы находим нужных людей в таблице и пишем для каждого отдельное техзадание. Чтобы отдельные техзадания не терялись, мы добавляем ссылки на них в таблицу. Благодаря этому, каждый участник знает, что ему нужно сделать, а мы знаем, от кого и какой ждать результат.
Вместо одного техзадания, получается несколько, но, благодаря разделению по ролям, с ними проще работать.
Большое количество людей на проекте — это нормально. Чтобы задачи не терялись в большом потоке информации, нужно разделять задачи для каждого отдельного человека. Мы делаем это с помощью таблицы людей и ролей на проекте. В конкретном примере нам удалось согласовать решение и распределить обязанности за 20 минут в скайпе.
Делить задачи по ролям и контролировать работу
Третья проблема — распределение задач по ролям ещё не гарантирует, что задачи будут сделаны.
Бывает так, что мы ставим задачи только нужным людям, но всё равно ничего не происходит. На одном проекте мы научили разработчиков от клиента делать всё правильно и даже сделали вместе несколько задач, но в однажды всё остановилось на три недели.
Причина была в том, что вдобавок к нашим SEO-шным задачам менеджер на стороне клиента ежемесячно набирал список задач от разных отделов компании. Задачи выглядели примерно так: «запустить новый раздел на сайте» или «настроить передачу параметров в АТС из контекстной рекламы». Они казались важнее, поэтому наши SEO-шные задачи быстро уходили на задний план.
Обычно в такой ситуации начинаются длительные и агрессивные переговоры. SEO-шники приходят к менеджерам и спрашивают: «Почему не делаете наше ТЗ? У нас сроки горят». Менеджер в ответ просит подождать ещё одну неделю. Но через неделю всё равно ничего не происходит.
В этот момент важно не давить, не обвинять и ни с кем не ругаться. Нужно всего-то правильно встроиться в работу на стороне клиента:
Описать задачу и ожидаемый эффект. В нашем примере список задач для разработчиков формируется раз в месяц. Наряду с SEO-шными задачами, в него попадают задачи от других отделов.
Менеджер управляет задачами на глаз: в приоритет ставятся задачи от тех, кому важнее или кто первый пришёл. В такой ситуации мы как постановщики задачи должны чётко её описать и рассказать о предполагаемом эффекте. Так мы не просто говорим, что задача срочная, но и объясняем, почему она срочная.
Разделить задачу по ролям и оценить в часах. На этом этапе важно не занижать часы на задачу. Например, задача по технической оптимизации сайта может занимать 80–90 часов, поэтому нельзя писать, что это задача на 1,5 часа.
Если задача большая, лучше самостоятельно разбить её на мелкие и средние. Например, в стандартном техзадании стоит задача «создать несколько разделов на сайте». Разделы нужно разбить в порядке приоритетов по спросу и учесть, насколько у них отличается структура. Если это интернет-магазин, разбивать нужно по спросу и прибыли, а если у разделов разная логика — по логике и спросу. В любом случае надо разбивать задачи так, чтобы первыми шли самые прибыльные и простые.
Придерживаться базовых правил контроля. Клиенту должно быть с нами комфортно — это значит, что нами должно быть легко управлять как подрядчиком. Для этого все нужные люди должны знать о том, что происходит на проекте.
После каждой встречи мы высылаем команде клиента отчёты, в которых описываем, что обсуждали и о чём договорились. Это помогает всем участникам всегда быть в курсе происходящего.
Часто отчёты получаются слишком большими. Из-за этого их либо не читают, либо не понимают. Получается так: мы рассказываем о происходящем, а клиент всё равно остаётся в неведении, потому что отчёт невозможно понять.
Шаблон таблицы внедрения задач
Мы всегда стараемся упростить клиенту эту задачу. Для этого мы описываем самое важное из отчётов в двух-трёх предложениях. Теперь клиент получает не просто отчёт на 30 страниц, а отчёт вместе с краткой выжимкой. Ему необязательно читать весь документ, чтобы быстро понять нужное.
Пример еженедельного отчёта по продвижению проекта
Следить, чтобы ничего не сломалось
Я рассказал только часть тех проблем, которые встречаются в работе на проекте с большим количеством людей. Но даже избавление только от них значительно упростит работу и повысит результаты.
Что нужно сделать:
- Выяснить, что происходило на проекте до вас и что происходит сейчас. В этом поможет наш список вопросов для старта проекта.
- Ставить задачи и согласовывать решения важно только с нужными людьми, чтобы не отвлекать остальных. Для этого полезно использовать таблицу людей и ролей на проекте.
- Наладить процесс работы, чтобы с вами было комфортно работать. Для этого полезно подробно описывать задачи и показывать клиенту, что происходит на проекте.
Всё вместе помогает предотвращать неприятные сюрпризы, доводить задачи до результата и делать нашу работу понятнее.
Вопросы, которые мы задаём на старте проекта
Шаблон таблицы людей и ролей на проекте
Пример еженедельного отчёта по продвижению проекта
Впервые статья была опубликована в Академии IT-Agency, где можно изучить другие материалы об интернет-маркетинге, SEO, CRM, а также управлении, аналитике и устройстве агентства.