Как обновить СМИ и не облажаться

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

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

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

Риск номер один, самый серьезный – если этого «кто-то» у нас нет ни своего, ни на аутсорсинге, и нам нужно срочно объявлять в розыск нового подрядчика. Это скажется на реализации, если новый подрядчик не знает внутренней инфраструктуры проекта, причем не только программной, а всей системы в целом. Он значительно затянет со сроками, если вообще не уйдет из проекта вместе с вашими нервами, деньгами и временем. Во-первых, не зная тонкостей, они недооценят проект и провалятся в дебиторскую яму посреди разработки. Во-вторых, сюрпризы начнутся в конце back-end этапа разработки, и начнут шлейфом за собой тащить на дно дизайн, front-end и ответственных менеджеров, то есть – практически всю команду, которая должна получать зарплату и делать новые проекты.

Риск номер два– текущий разработчик некомпетентен. Кидайте ему эту статью, риск станет в разы ниже. Хорошо, если он разрабатывал проект. Гораздо хуже – если компания работает с вами недавно и так же, как и в первом случае, плохо знакома с инфраструктурой.

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

Сохранение базы URL

В СМИ почти всегда много страниц в поиске, на него всегда много внешних ссылок из разных источников, сайтов и партнерских сетей. Крайне важно соблюсти ту же структуру и сохранить базу URL такой, какой она была до этого. Не рассматривайте ситуацию, что сделать это невозможно, поскольку это приведет к падению в выдаче, где-то вы забудете сделать правильный редирект, где-то ссылка будет битой или нерабочей, где-то появятся дубли ссылок при переезде на новую CMS и придется всё вычищать. Старайтесь сохранить базу всеми силами и способами. При этом также надо учитывать, например, такие неочевидные моменты, как если к URL статьи добавляются цифровые ID как требование агрегатора Яндекс.Новостей.

Преемственность базы данных

Это, наверное, пункт из записной книги Капитана Очевидности, но смотрите структуру базы данных и тип базы данных в целом, и оценивайте силы команды на перенос данных. Например, PostgreSQL и MySQL. Думайте заранее, как вы будете переносить все десятки тысяч постов из PostgreSQL в MySQL, как будет кореллировать структура старой и новой базы, и учитывайте это все при проектировании нового дизайна.

Преемственность содержимого материалов

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

  • 5 типов заголовков;
  • 3 типа галерей;
  • 10 типов шорткодов;
  • 4 типа нумерованных и маркированных списков;
  • и еще несколько специфических фишек;

Клиент пришел, сказал – быть новым. Проектировщик спроектировал, менеджер согласовал, дизайнер нарисовал, менеджер согласовал, front-end сделал свою работу, back-end – свою, и тут начался перенос. Дело в том, что в новой версии дизайна типов заголовков всего 3, галерея – одна, а шорткодов всего 5, и они были настолько красивые, что все забыли обо всех остальных носителях контента. Возникает вопрос, в каком виде отображать все десять тысяч ранее опубликованных материалов, имеющих элементы, не сверстанные в новом дизайне? Менеджер начинает бегать, дизайнер рисовать, верстальщик – верстать, и так далее, а всё это, наряду с другими пунктами – золотое время.

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

Работа с партнерскими сетями и агрегаторами

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

Коды, счетчики, аналитика, пиксели

Это мало кто забывает, но все равно помните, ага.

Рекламные блоки

Основной доход большинства СМИ – рекламный. Нужно предусматривать размещение рекламных блоков на более доходных местах, если они были до этого, либо предположить какие места будут наиболее доходны, или рекламных блоков еще не было. Это делается на этапе проектирования.

Также не забудьте:

  • Изучить предложение рекламных партнеров по количеству рекламы блока определенной высоты/ширины. Если ее мало – партнерская система может заменить на другой формат, и тогда на сайте образуется некрасивая «дырка»;
  • Узнать, будет ли реклама в нужном размере и формате показана именно вашей целевой аудитории;
  • Предусматривает ли вообще рекламная система желаемый дизайнером формат рекламы;

Изображения для превью

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

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

Бекапы

Делайте бекапы.

Написать
нам письмо
info@brcl.ru
Любые вопросы и предложения
107031, г. Москва
Столешников 11
Показать на карте