Процессинг при создании статейных сайтов.

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

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

Яйцо или курица. Прототип или контент.

Основная проблема потери времени при создании сайтов — это несогласованность процессов и последовательное выполнение разных типов работ.

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

Не спешите плеваться. Первые мысли о том, что проектирование сайтов нужно выполнять исключительно на готовом (реальном) контенте, я помню в постах Нимакса, Сибирикса и еще кого-то из крупных питерских команд еще в 2011-12 годах. Все это мелькало на Хабре, тогда не было единых отраслевых русскоязычных порталов по UX (или я о них не знал тогда), всю инфу находил в блогах и на Хабре.

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

И ни слова о первичном планировании самого контента. Клиент должен дать реальный контент, с ним и будем работать.

Все бы ничего, но у клиента нет контента в 99% случаев. Это если говорить о клиентском сайтострое. 99% клиентов уверены, что контент у них есть, а по факту — его нет.

Если же мы говорим о статейниках (блогах, порталах), запускаемых с нуля, то выпадаем здоровенный (и основной, на мой взгляд) кусок работы. Даже несколько этапов выпадают: планирование, реализация и размещение (оформление) контента.

Кроме того, я абсолютный сторонник идеи, что суть определяет форму. Стратегическое планирование контента определяет все: структуру сайта, функционал, как результат — весь интерфейс. И если мы сначала делаем дизайн, а потом работаем с контентом, то мы обречены потом переделывать техническую часть, иногда на 50% и более.

Вопрос понятен. В чем проблема?

Давайте рассмотрим следующую ситуацию: делаем статейный сайт на 100 статей. Работы запланированы по следующей схеме:

  1. планирование  — сбор СЯ для всех 100 статей
  2. техническая реализация сайта
  3. написание контента
  4. посадка и оформление контента
  5. внутренняя оптимизация, перелинковка итд

Гипотетически, параллельно могут выполняться  только техническая реализация сайта (пока работают семанты или пока пишется контент) и внутренняя оптимизация (размещаем текст, сразу делаем весь пул работ по внутренней оптимизации на 100%). А так работы идут последовательно. Предположим, целях оптимизации времени весь объем статей делим пополам, и сначала пишем и размещаем первые 50 статей, после — вторые 50 статей.

Если вы делаете все самостоятельно, то вы в любом случае делаете все последовательно (если вы не Ю.Цезарь).

Если же вы делаете сайт для кого-то (или кто-то делает сайт для вас), то получается дикая потеря времени, причем, для каждой из сторон.

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

 Гибкое создание контентных сайтов.

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

Я не удивлюсь, если мы тут изобрели велосипед заново (мы вообще мастера в этом деле). Если дальше будет описана банальщина, прошу настоящих сварщиков поделиться названиями работ, где подобная метода описывалась бы.

Эта блок-схема была нарисована еще в марте, делалась она на коленке глубоко ночью. Разные типы блоков итд  не имеют никакого отношения к классическому моделированию бизнес-процессов (ни к одной из моделей*). Это просто визуальная иерархия последовательности событий, которую еще предстоит оформить в нормальном виде, со всеми входящими \ исходящими, владельцами и заказчиками процесса итд.

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

bpm1.2

Расшифровка блок-схемы.

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

2 Начало работ.

2.1 Получение предоплаты. Получение денег именно на этом этапе объясняется просто: последующий анализ тематики, подбор исполнителей, погружение в тематику проектной группой — это все время. Исполнитель и заказчик на этом этапе уже должны быть настроены на сотрудничество.

2.2 Анализ и согласования. Это то самое погружение в тематику и начальный анализ исполнителей. Здесь определяются все «маркетинговые константы» для проекта (ЦА, персонажи, основные сценарии взаимодействия с сайтом, исходя из задач заказчика, конкуренты, остройка, объемы трафа и контента в тематике итд).

3 Внутренняя кухня.

3.1 Анализ конкурентов. Смотрим, кто на что горазд, ищем интересные идеи и инсайты.

3.2 Работа с семантикой. Формируем первичное ядро, выгрузка из всех доступных баз, парсинг, работа с форумами и QA итд.

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

3.4 Назначается ответственный по проекту КМ (контент-менеджер), если хотите — редактор. Он будет отвечать за все вопросы, связанные с реализацией и размещением контента.

4 Внутренние работы

4.1 Аналитический отдел готовит первичную семантику и первичную структуру сайта (СЯ1 и СС1). Это пока гипотезы по поводу собранных зон интересов (да, нам запросы нужны не для того, чтобы «вставить  в текст 2-3 раза», а для формирования потенциальных зон интересов ЦА. Об этом будем говорить подробнее в дальнейших статьях.

4.2 HR задачи — поиск райтеров и экспертов в тематике. В идеале — чтобы это было два в одном, но такое происходит редко.

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

5 Expert time/ Согласования с экспертом. На блок-схеме этот пункт не зря выделен. Специалист должен вместе с аналитиком проработать и семантику, и структуру сайта, чтобы отсеять все лишнее, добавить своих идей, проверить в целом предоставленный материал на достоверность и отсутствие бреда.

пример из практики: проект по тротуарной плитке и брусчатке. Запрос — брусчатка 30х30 купить. Казалось бы, вполне нормальный запрос. А специалист его отсекает — брусчатки такого размера не бывает. Для текущего проекта этот запрос не нужен.

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

6 Формируем структуру сайта. У нас появляется каркас, на который будем насаживать «мясо» в дальнейшем. Каждый раздел имеет сопроводительное описание (для тех отдела и КМ-а).

Дальше начинается более гибкая часть работ.

7 Первый раздел.

7.1 Выбирается первый раздел сайта для наполнения.

7.2 Формируется окончательная семантика под этот раздел

8 Проверка. Все это еще раз проверяется и утверждается экспертом.

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

9 Наполнение контентом раздел 1.

9.1 формируются все ТЗ на материалы этого раздела

9.2 Питч КМу — аналитик рассказывает контент-менеджеру все моменты по данному разделу, основные инсайты, идеи итд. Элементарное взаимодействие между отделами при передаче материалов.

9.3 Заказ райтеру — исполнителям уходят ТЗ на статьи.

9.4 Написание тестового пула статей — это 5-10 статей, которые необходимы для согласования с заказчиком всех моментов по стилистике, оформлению итд.

9.5 Проверка тестового пула статей КМом.

9.6 Посадка тестового пула статей на сайт.

9.7 Презентация клиенту. Согласования, правки, изменения, доработки итд. Обратите внимание, что параллельно ведутся проверки по составленным чек-листам и базовая внутренняя seo-оптимизация самих статей (урлы, тайтлы, описания, альты итд итп).

9.8 Если все ок — сайт открывается к индексации. У нас уже есть первые 10 статей, у нас есть согласованные  с заказчиком правила оформления контента, у нас есть все, чтобы оперативно писать и размещать последующий контент, при этом снижены риски для ситуаций «переделать все статьи вот так вот». Работу можно поставить на поток, сайт постоянно наполняется, мы не теряем время на индексации материалов, мы не теряем время на ожиданиях, простоях итд. Бинго.

9.9 — 9.х  Циклы по реализации и размещению остальных пулов контента

10 техническая часть.

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

Все этапы там стандартные, не вижу смысла их как-то отдельно описывать. Остановлюсь предметно всего на ряде моментов:

  • дизайн обязательно нужно презентовать клиенту лично, с комментариями и оперативными ответами на вопросы. Иначе это превратится в игру «угадай мой вкус», которая не нужна ни клиенту, ни исполнителю. Вам нужна возможность объяснить сразу, почему интерфейс именно такой, какие умные вещи туда вложены. И сразу же услышать встречные вопросы или возражения клиента. Подробнее об этом лучше почитать здесь и  здесь
  • сайт до момента запуска обязательно закрыт от индексации. И в роботс, и на хосте, и еще как угодно. Просто примите как факт — до отмашки сверху сайт всегда закрыт от индексации. Это на руку всем — и вам, и заказчику, если «что-то пойдет не так». Ну и переиндексация сайта гуглом — это тот еще праздник, особенно если он сожрет все ваши «hello world»
  • у нас все эти задачи существенно облегчены за счет работы с нашей сборкой wp-mfc. Времени на поднятие нового проекта уходит минимум.

11 Аналитики не спят.

Пока КМ разбирается с текущим пулом контента, семанты и аналитики мучают эксперта и готовят задание на следующий пул статей. Чтобы не было окон в работе всей команды.

12 Сопутствующие процессы.

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

Резюме.

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

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

Очень хочу услышать ваше мнение по всему увиденному, очень надеюсь, что вы смогли осилить всю эту простыню текста и вникнуть в детали. Большое вам за это спасибо.

Оставайтесь с нами, сегодня вас ждет еще одна публикация. А завтра еще одна. И так до конца июня.

Лайки, шеры, ссылки итд — как обычно ).

ps я спешу разместить сабж, чтобы не подумали, что я слил марафон. Вычитка, правка опечаток, стилизация текста в ближайшее время.

banner750x90v2

Поделиться:
  • Вадим

    Какова была бы стоимость такого проекта и время от начала заказа до запуска?