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

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

• Тексты какого объема и структуры планируются?
• Будут ли картинки? Везде или опционально? Сколько? Что это — фотографии? Иллюстрации? Графики? Как они должны размещаться — отдельно от текста, в тексте, какого размера они будут и т.п.
• Будут ли использоваться гиперссылки в тексте, нужно ли как-то выделять отдельные части текста, где и какие могут быть файлы для скачивания... Я могу продолжать до бесконечности. :-)

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

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

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

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

Однако, за кадром осталось, на мой взгляд, самое главное — как подготовить качественный контент для сайта? Для многих компаний, особенно из сегмента малого бизнеса, подготовка контента — огромная проблема. Распространенное мнение, что наполнить сайт просто — ошибочно. Считаю, что в статье не хватает еще одного блока — как сделать так, чтобы вовремя подготовить правильный контент для сайта. Надеюсь увидеть такое дополнение в виде новой статьи!

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

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

Для дизайн-студии производство контента является не только гарантией избежания рисков, но и логичной услугой, которая позволяет расширять бизнес и заработок.

Контент на сайте — это не контент в напечатанном буклете. И нужно делать макеты дизайна такими, чтобы всегда можно было добавить и дополнительный пункт меню (с длинным и коротким названием), текст в блоке тестировать как короткий, так и длинный (если предусмотрено функционалом). В противном случае, сайт становится заложником дизайна и становится не мобильным. А это сайт, а не полиграфия. Многие про это забывают. Да, конечно есть промо- сайт, там без четкого контнета ни как. И на главной есть элементы сайта, которые рисуются жестко. Если это не сайт «картинка», а более рабочий сайт. Например, интернет магазин. То это все решается баннерными блоками, которые рисуются в зависимости от задачи, по отдельному ТЗ, но одного размера.

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

И надо не забывать, что сайты делаются для заказчика, а не для портфолио. Чисто для портфолио всегда можно реализовывать свои проекты. Если мы говорим о наборе полей, в частности товара. Надо заранее прописывать в ТЗ все необходимые поля. Все остальные доработки за дополнительную плату или бесплатно (на выбор). Очень часть приходится за клиент решать, что ему надо. Чтобы процесс был проще, нужно заставлять клиента заполнять Бриф, как можно более подробный. Если клиент сам не может осилить, значит вместе с ним. При обсуждение предлагаются, какие информационные блоки можно разметить на каждой из уникальных по функционалу страницах.

Чтобы не было висяков, нужно момент готовности оговаривать заранее. Если на сайте есть система управления, то какие проблемы. Сдали, обучили. Клиент сам как готов будет, заполнит. Но чаще всего у них страх перед CMS, как что-то не понятное и страшное. Из-за этого и появляются висяки. Безусловно, контент нужен до начала работ. Клиенты часто это понимают и думают, что все очень быстро сделают когда будет готов сайт. Но, увы, так не всегда происходит и сроки неизбежно затягиваются.

По сути, речь идет о двух проблемах — о проблеме несоответствия предварительного контента реальному и о проблеме непредоставления контента в срок.

Желательно их решать юридически.

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

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

Хотя, конечно, в любом случае лучше иметь контент на старте. Это многое упрощает. По опыту, такое возможно только при разработке небольших промо-ресурсов.

К сожалению статья не понравилась, т.к. всю статью можно было описать одним тезисом «Не возможно сделать правильный проект без проектирования, а проектирование не возможно сделать без контента». Лучше бы Александр описал методы и приемы, КАК именно собирать этот контент, как вытащить у клиента этот контент, как сделать так, чтобы избежать все эти риски, описанные в статье. А это самая сложная работа и все это зависит от менеджера.

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

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

Очевиднее всего это при разработке связок интернет-магазинов с внутренними службами заказчика (1С, САП), когда нужно согласовать форматы передачи данных. Тут, например, все поля карточки товара будут неминуемо указаны.

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

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

В любом случае ошибочно думать, что можно создать весь контент на этапе разработки.

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

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

1. Разработчик слушает клиента

2. Команда разработчика умеет слаженно адаптироваться под ситуацию в данном проекте

3. Заказчик умеет слушать Разработчика.

Этих трех пунктов достаточно. Если диалог между всеми участниками налажен — вероятность удачи проекта значительно возрастает.

Приведу мнение о статье моей коллеги по команде, которая больше меня понимает в контентной части:

«Важно в начале на этапе прототипа договориться с заказчиком и дизайнерами о структуре информации (текст, фото, файлы...) на разных страницах, но не имеет смысла требовать итоговые варианты текста до запятой. Сайт, как правило делается не на 1 год,

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

Блок про поисковые системы вообще странно приплетен — как будто больше для массовости».

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

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

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

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

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

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

Конечно, и тут есть свои подводные камни: недостаточная осведомленность агенства в бизнесе клиента может увеличить сроки подготовки контента. А клиент, обычно, хочет как можно скорее приступить к разработке сайта. Здесь нужно убеждать его в том, что для получения качественного конечного продукта (сайта), ему просто необходимо не менее качественное содержание.

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

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

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

90% заказчиков не успевают подготовить контент к моменту готовности сайта. Это — данность, с которой приходиться жить и бороться.

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

Каждый этап разработки должен быть актирован и оплачен.

Если разработчик наполняет сайт — это отдельное соглашение, отдельный акт, отдельная оплата.

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

Будьте независимы от скорости работы заказчика, не соглашайтесь на финальную оплату после «Увижу сайт под рабочим именем — оплачу» — это ловушка.

Клиент будет сколько угодно долго затягивать выплаты, ссылаясь на этот пункт. Есть проектный сервер — пусть клиент наполняет там.. Наполнит — перенесёте в течение дня.

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

НО, я не видел ни одного заказчика, который бы имел на руках готовый контент до начала разработок.

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

Если после утверждения дизайна заказчик что-то вспомнил — ради Бога. Любой каприз за Ваши деньги.. Не очень приятная, но вполне штатная ситуация.

Касательно реакций Яндекса на контент — до клиента нужно сразу доносить требования по уникальности текстов.
95% клиентов тупо делают копипаст с заменой пары предложений.

Имейте контакт с копирайтером и предлагайте рерайт клиентских текстов до нужной степени уникальности.

Резюмируя статью: полезно знать набор проблем, но ещё более полезно знать набор решений.

Автору — спасибо за поднятую тему.

Как я понимаю, мы продолжаем тему «как не надо работать с клиентом», начатую Дмитрием Гарником в статье про бесплатные тендеры. :)

Во-первых, определимся с терминами. Контент — это все-таки конкретный текст конкретной страницы. Автор же пишет о том, что правильно назвать структурой и функционалом сайта. Не обязательно до начала разработки писать весь контент (рассказ об истории компании, тексты конкретных акций и т.п.). А вот структуру продумать обязательно, причем максимально подробно. И в процессе продумывания структуры и функционала мы как раз выясним, что товарных групп или разделов сайта не 5, а 9, что нужно рисовать 2 уровня подменю и т.п. В этом автор прав.

А вот дальше странные вещи описаны. В какой момент структура сайта продумывается и кем? Судя по статье — на этапе сдачи сайта и клиентом. А как же так получилось? Разве Заказчик до того, как все сверстали, не утвердил дизайн и ТЗ? А до того, как приступить к дизайну и ТЗ, до заключения договора, до составления сметы с заказчиком не обсуждается структура и функционал сайта?

Цитата: «Под определением „подробное описание товара в каталоге“ студия и заказчик подразумевали разные вещи». Я извиняюсь, а почему студия, перед тем как выставлять смету и заключать договор, не изучила каталог? Как можно договор заключать непонятно о каком сайте?! У нас процесс обстоит примерно так. До тех пор, пока минимум два человека (аналитик, составляющий смету, и IT-директор) не будут точно понимать предмет разработки, никакой сметы не будет. Даже если менеджер по работе с клиентом говорит, что смета нужна срочно, заказчик готов прямо сейчас заключить договор, этого не будет. А будут вопросы, встречи, согласования структуры и функционала, и только потом смета. Потому что лучше 300 тыс. потерять, чем убытков получить на миллион.

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

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

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

Если заказчик утвердил дизайн и ТЗ, но на этапе сдачи у него опять возникли фантазии, то он опять идет в коммерческий отдел, а переверстывать утвержденный дизайн и перепрограммировать сайт, сделанный по утвержденному ТЗ, студия за свой счет не будет.

Да, разумеется, всего в ТЗ не предусмотришь, и ряд идей клиента, возникших на этапе сдачи, мы делаем. Но, во-первых, это мелочи, во-вторых, «коэффициент геморроя» мы закладываем в цену, в-третьих, даже процесс фантазий регламентирован (ограничено число списков фантазий и сроки, в которые заказчик имеет возможность фантазировать). И мы всегда знаем, что процесс сдачи у нас займет месяц-полтора, в течение которых мы потратим 2-3 дня чистого времени на работу, и не ноем по этому поводу.

Далее по тексту: «Испортить свой дизайн». Представим типичную для нас ситуацию, когда заказчик четко не поставил задачу по дизайну, мы нарисовали макет, он передумал и захотел добавить одних блоков, убавить других. Есть ли вероятность порчи дизайна? Да, есть. Виноват ли в этом клиент? Не очень. Мы ведь на то и дизайнеры, чтобы не портить дизайн независимо от того, что в нем надо нарисовать. То есть по большому счету нечеткая постановка задачи клиентом грозит нам тем, что первый вариант дизайна (иногда и второй) мы выбросим в мусор. Жалко, конечно, но не катастрофа. Выход из этого простой — с самого начала учитываем в смете выброс части работы в мусор. Причем сумма в смете для разных клиентов отличается — если клиент понятия не имеет, она велика, если клиент четко знает, чего хочет, она меньше. Вот и вся проблема.

Далее: «Не доделать сайт или получить висяк», «Не получить оставшуюся часть оплаты или сработать с большим убытком». А как это получается, что сайт не сдается из-за отсутствия контента? Неужели Вы в договоре пишете, что готовы ждать сдачи сайта и постоплаты до тех пор, пока заказчик не удосужится текст написать, даже если на это уйдет миллион лет? Если да, то это Ваша ошибка. Если Вы вынуждены, размещая контент, перелопачивать сайт — опять Ваша ошибка.

Клиент просто следует русской пословице «кто пашет, того и погоняют». Если Вы ему предоставили неограниченный объем работ за ограниченную сумму денег, то с чего ему Вас жалеть?

Далее «Вряд ли студия и заказчик сохранят хорошие отношения, когда заказчик будет требовать то на одной странице разместить..., то вместо маленького дополнительного блочка ... поставить галерею ... и т.п». Почему вряд ли? Ничего плохого нет в том, что заказчик 5-10-15 раз попросит Вас что-то переделать дизайне. Наоборот, чем тщательнее он будет подходить к макетам, тем меньше Вам придется переделывать на сдаче.

Далее: «Плохая организация труда и перегрузка сотрудников студии». Вообще нет слов... И зачем же Вы плохо организовываете свой собственный труд? :) И главное, почему считаете, что заказчик в этом виноват? :) Он никаким боком не обязан заниматься организацией Вашего труда. Потратьте время, составьте нормальный регламент работы, включите его в договор. И после этого не будете иметь этих проблем.

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

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

Возможно, я утрирую, но получается, что заказчик, который не является профессионалом в области веб-сайтинга, должен знать, какой у него будет сайт, вплоть до последней буквы, а разработчик (профессионал в этой области) заморачиваться этим не должен? Ему все вынь, да полож, останется только рамочки для контента нарисовать? И заказчики, получается, обращаются к профи (к Вам) для того, чтобы все равно за Вас думать? Класс!

Допустим на секунду, что случилось чудо — заказчик максимально четко поставили задачу, предоставил материалы, Вы сделали сайт некого бренда для мультибрендовой компании, а тут бац, на сдаче самое высокое руководство за пределами РФ приняло решение о ребрендинге (у нас такое произошло месяц назад), и Ваша версия сайта объективно больше никому не нужна. Что делаем? По Вашей схеме перелопачиваем с нуля за свой счет. Выходит, не контент — корень зла...

Флаг Вам в руки, ребят, но я повторю мысль, высказанную в комментарии к статье Гарника — нет смысла ждать волшебных, удобных для Вас заказчиков. Их не существует в природе. Нужно учиться работать с имеющимися заказчиками, а значит подсказывать им, думать за них и, самое главное, организовывать их работу с Вами и Вашу работу с ними.

Грустно, больно и обидно, что так еще много студий у нас не знают, как организовать себя и клиента, и плачут, и терпят убытки. А самое обидное, что выводы делают неправильные о том, что виноват клиент...

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

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

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

Легкий и остроумный способ показать заказчику, насколько важен контент. Поможет менеджерам продавать эту услугу: http://www.pronauku.com/chto-takoe-kontent/

Прекрасный сайт о производстве контента от Елизаветы Орешниковой. Поможет правильно организовать работу над контентом: http://designthe.info/

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

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

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

Единственный путь, протиснуться между этими двумя крайностями. Мы требуем от клиентов предоставления контента на первом этапе работ, параллельно с проектированием сайта. В контракте есть жесткий график предоставления материалов в соответствии с утвержденной структурой. Но как показывает практика, если контента не было на момент заключения контракта, график его предоставления заказчиком выполнен не будет. Мы фиксируем факт ответственности в этом моменте и получаем описанную автором проблему с затягиванием сроков сдачи проекта, формально не имея претензий по этому поводу.

Отдельно можно рассмотреть опыт написания контента под диктовку клиента. Здесь удачных примеров тоже единицы. Каждый, кто хоть раз проходил этот путь знает, что утвердить тексты гораздо сложнее, чем дизайн. Поэтому здесь единственным решением, как и в вышеописанном случае, остается «пограничная» ситуация — когда студия компилирует и редактирует контент предоставленный заказчиком.

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

В итоге, через год-два, сайт превращается в кучу беспорядочных страниц непотребного вида, и его приходится заказывать еще раз.

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

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

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

Гораздо эффективней будет сфокусироваться на том, что действительно важно для компании заказчика. Возможно, будет достаточно одного телефона и объяснения зачем посетителю сайта нужно по нему позвонить. Понимание того, что должен содержать сайт с точки зрения не разделов, а смысла — самый первый и самый важный этап разработки. А участие в нем — обоюдная ответственность обеих сторон.

Content is king — как говорится в старой русской поговорке.

Очень актуальная тема.

Хочу поделиться причинами, почему теперь и у нас контент — этап номер 1, и плюсами этого нововведения:

1. Авторский контроль за качеством материалов — хорошо и для клиента, и для нас.
2. Если подойти к наполнению с душой, то заказчик сам предложит вам заниматься дальнейшей поддержкой.
3. Дополнительное тестирование сайта происходит сразу во время наполнения. Ошибки обнаруживает наш специалист, а не сотрудник клиента. Есть возможность оперативно исправить недочеты.
4. Ни одна по-настоящему крутая рекламная кампания не обходится без хорошего контента.
   
   Верно и обратное — плохой контент может испортить любой сайт.
   
   А мы хотим, чтобы наши сайты были крутыми.
    
5. Сроки проектов удалось сократить на треть.
6. Клиент теперь получает готовый продукт, а не ищет копирайтера, фотографа и контент менеджера.
7. Мы получаем довольного и счастливого клиента, да еще и на завершающей стадии проекта.
8. Клиент получает идеальный сайт, который максимально соответствует его задачам.

Контент действительно king. Да здравствует контент!

Автор совершенно правильно обозначил риски, связанные с контентом. Действительно, принцип «мы платим — вы делаете всё остальное» к сайтам неприменим, так как в любом случае заказчик должен затратить какие-то ресурсы (временные, административные) на подготовку контента.

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

В нашей практике для предотвращения описанных в статье Александра ситуаций используется пункт договора, согласно которому исполнитель не начинает никаких работ до получения от заказчика минимально необходимого объёма контента. В приложении указано, что это за контент, в каком виде он должен быть предоставлен и в какие сроки.

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

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

Отличная статья.

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

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

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

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

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

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

Запомните, заказчик НИКОГДА не подготовит вам качественного контента. У него нет на это ни времени, ни способностей, ни желания. Если арт-директор способен раз за разом приезжать к клиенту и терзать его на тему «нравится, не нравится», почему при подготовке содержания веб-студии проявляют такую пассивность?

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

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

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

Выхода обычно три:

1. Делать «универсальный» дизайн, не имеющий ограничений при публикации контента любого количества, а также хорошо масштабируемую структуру.
2. Добиться предоставления имеющегося контента, вместе с заказчиком подготовить его к публикации, объяснить, как будет лучше и править (при необходимости).
3. Принципиально не браться за работу при отсутствии у заказчика четкого понимания своих желаний и большей части контента.

В первом случае существует опасность дойти до примитивизма в дизайн-макете, поэтому необходимы действительно профессиональные дизайнеры и проектировщики.

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

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

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

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

Я считаю, что организация наполнения сайта целиком и полностью входит в обязанности основного менеджера проекта, который может быть как на стороне заказчика, так и на стороне исполнителя. Именно менеджер проекта должен на этапе брифа добиться ответов на вопросы — кто за какую информацию отвечает? Как, когда и кем она обновляется? В каких объемах? Кто отвечает за актуальность? Менеджер должен прописать зоны ответственности по всей карте сайта, как по первичному наполнению, так и по дальнейшим обновлениям, и согласовать этот документ со всеми фигурантами. Такой процесс помогает еще на этапе разработке выяснить, что и в каких объемах действительно можно получить, и на дальнейшее понять — увидите вы через год на своем проекте, например, в качестве иллюстраций, профессионально обработанные фотографии или там будут фото с мобильников сотрудников; будет ли нормально наполненная новостная лента или, например, последняя новость будет датирована датой запуска сайта, etc.