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

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

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

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

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

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

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

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

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

Отдельно сайт могут использовать партнёры, соискатели, действующие клиенты и представители СМИ. Каждой группе нужны разные сведения.

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

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

После задач и аудиторий можно переходить к карте сайта. Она показывает основные разделы, вложенность страниц и связи между ними.

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

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

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

Именно количество уникальных типов страниц сильнее влияет на объём разработки, чем общее количество URL.

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

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

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

Для корпоративного сайта под ключ полезно заранее определить требования к URL, метатегам, заголовкам, внутренней перелинковке, sitemap.xml, robots.txt и управлению индексированием.

Если новый сайт заменяет старый, в ТЗ также стоит включить перенос SEO-значимых страниц и настройку редиректов со старых адресов.

После общей карты сайта имеет смысл подготовить требования к основным шаблонам.

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

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

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

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

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

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

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

Фразы «современный», «премиальный», «стильный» или «как у лидеров рынка» слишком субъективны. Для одного человека современный дизайн — минимализм, для другого — насыщенная анимация и яркая графика.

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

Можно приложить несколько референсов и объяснить, что именно в них нравится: композиция первого экрана, типографика, работа с фотографиями, плотность информации или подача карточек.

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

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

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

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

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

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

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

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

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

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

Формы часто воспринимаются как простой элемент, хотя именно через них сайт передаёт коммерческие обращения.

В ТЗ следует указать, какие формы нужны и где они размещаются. Например, «Получить консультацию», «Запросить расчёт», «Отправить техническое задание», «Стать партнёром» и «Откликнуться на вакансию».

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

Если пользователь отправляет форму со страницы конкретной услуги, в CRM желательно автоматически передавать название этой услуги. Если он пришёл из рекламы, полезно сохранять источник и метки кампании.

Так менеджер получает не только телефон, но и контекст обращения.

Фраза «интеграция с CRM» слишком широкая для технического задания.

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

Например, заявка с формы консультации создаёт лид или сделку, передаёт имя, телефон, email, комментарий, страницу отправки и UTM-метки. Обращения по отдельным направлениям могут автоматически направляться разным менеджерам.

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

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

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

Это могут быть товары, цены, остатки, характеристики, контрагенты, заказы, документы или другие данные.

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

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

До начала интеграции полезно проверить качество данных внутри 1С. Если характеристики товаров заполнены по-разному или отсутствует единая структура категорий, часть подготовки придётся выполнять ещё до подключения сайта.

Кроме CRM и 1С корпоративный сайт может взаимодействовать с телефонией, платёжными системами, сервисами доставки, картами, системами email-рассылок, онлайн-записью и другими платформами.

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

Если выбор ещё не сделан, в ТЗ можно зафиксировать задачу, которую необходимо решить. Например, «нужно принимать онлайн-оплату банковскими картами» или «необходимо показывать свободное время специалистов».

Так подрядчик сможет предложить подходящий вариант и отдельно оценить его реализацию.

Система управления влияет на дальнейшую эксплуатацию сайта. Поэтому в ТЗ стоит указать, какие материалы сотрудники должны редактировать самостоятельно.

Обычно это услуги, проекты, новости, сотрудники, вакансии, документы, категории каталога и SEO-поля.

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

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

Если проект создаётся на конкретной CMS из-за внутренних требований или существующей инфраструктуры компании, это также фиксируется в документе.

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

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

Если используются Яндекс Метрика, рекламные системы или CRM, данные должны быть связаны между собой настолько, насколько это необходимо бизнесу.

Для компаний с большим количеством телефонных обращений может потребоваться коллтрекинг. Без него часть заявок будет невозможно корректно привязать к источнику рекламы или SEO.

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

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

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

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

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

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

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

Если корпоративный сайт уже существует, в ТЗ нужно включить миграцию.

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

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

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

Даже хорошее техническое задание не спасает проект, если внутри компании неизвестно, кто принимает решения.

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

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

В ТЗ или регламенте проекта полезно зафиксировать этапы: структура, прототип, дизайн, программирование, наполнение, тестирование и запуск. После утверждения этапа существенные изменения должны оцениваться отдельно.

Формулировка «сайт должен быть полностью готов» слишком неопределённая.

Лучше заранее описать, по каким критериям проект считается завершённым. Например, разработаны и наполнены согласованные разделы, формы работают и передают данные в CRM, мобильная версия протестирована, подключена аналитика, настроены редиректы и опубликованы необходимые документы.

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

Такие критерии упрощают финальное тестирование и приёмку.

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

Исключение — существующие ограничения компании. Например, IT-отдел требует определённую CMS, серверную инфраструктуру или интеграционный протокол. В таком случае требования необходимо указать заранее.

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

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

Техническое задание не должно заменять прототип и дизайн.

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

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

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

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

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

До начала разработки полезно собрать всё, что поможет команде разобраться в бизнесе.

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

Отдельно стоит подготовить список используемых систем: CRM, 1С, телефония, сервисы рассылок, аналитика и другие инструменты, с которыми сайт должен взаимодействовать.

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

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

Поэтому качественное ТЗ обычно создаётся совместно.

Компания предоставляет задачи, материалы, процессы и требования. Разработчик анализирует информацию, предлагает структуру, задаёт уточняющие вопросы и переводит бизнес-потребности в функциональные требования.

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

Чем точнее определён объём проекта, тем точнее его можно оценить.

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

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

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

При этом архитектура должна заранее учитывать такое развитие.

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

Вторая — использовать слишком общие требования: «удобный сайт», «современный дизайн», «хорошее SEO», «интеграция с CRM». Каждое такое требование нужно переводить в конкретные задачи.

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

Четвёртая — добавлять интеграции после утверждения архитектуры. CRM, 1С и личный кабинет могут влиять на структуру данных и интерфейсы.

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

Шестая — пытаться заранее описать все дизайнерские решения. ТЗ должно задавать рамки и требования, но оставлять место для профессионального проектирования.

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

Понятно ли, зачем компании нужен сайт и какие задачи считаются приоритетными? Определены ли аудитории? Есть ли карта страниц? Понятно ли, какие типы контента будут размещаться и кто их готовит?

Зафиксированы ли формы и интеграции? Понятно ли, какую информацию нужно передавать в CRM и 1С? Есть ли требования к SEO, аналитике и мобильной версии?

Отдельно нужно проверить, определены ли ответственные со стороны компании и порядок согласования.

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

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

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

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

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