Разработка корпоративного сайта редко буксует из-за кода. Чаще команда получает противоречивые решения о контенте, ролях, источниках данных и обработке заявок. Каждое по отдельности выглядит небольшим — пока не затрагивает макет, CMS или интеграцию. Дальше правка одной формулировки превращается в переделку страниц, схемы данных и тестов.
Вот что стоит закрыть до старта дизайна.
Цель сайта и граница первого релиза
«Рассказать о компании» — не цель. Нужно конкретное действие посетителя: оставить запрос, найти документацию, выбрать дилера, скачать материал, войти в закрытый раздел. От формулировки зависят страницы, поля форм и аналитика. Для каждого ключевого сценария нужен владелец со стороны бизнеса.
Граница первого релиза важнее списка пожеланий. В неё входят сценарии, без которых сайт нельзя запускать, и явно не входят идеи, которые можно проверить позже. Когда границы нет, любой новый комментарий к макету начинает выглядеть как обязательная часть проекта.
Структура и владельцы контента
Разделы сайта не равны пунктам меню. Для каждой страницы определяют задачу, аудиторию, источник фактов, автора, согласующего и дату готовности. Это особенно важно для услуг, кейсов, сертификатов, вакансий и материалов для партнёров — разработчик не может достоверно заполнить их вместо владельца.
Макет на условных заглушках часто скрывает проблемы. Длинные названия, таблицы, фотографии разного формата и юридические блоки нужно проверить реальными текстами до первой публикации.
Данные и справочники
Если сайт показывает каталог, филиалы, сотрудников, документы или цены, для каждого объекта назначают один источник правды. Запись может создаваться в учётной системе, CMS или вручную редактором, но не во всех местах сразу — иначе следующая выгрузка перезапишет правку, а команда будет спорить, где находится «правильная» версия.
В решении фиксируют устойчивый идентификатор, поля для публикации, частоту обновления и правило удаления. Связь по названию товара или компании ненадёжна: название меняется, а старая ссылка или заказ остаются.
Интеграции и обработка заявок
Форма должна иметь маршрут после нажатия кнопки: какие данные передаются, куда создаётся обращение, как выбирается ответственный, что видит менеджер и что происходит при ошибке. Требования «интегрировать с CRM» недостаточно — CRM может хранить лид, сделку, контакт или задачу, и у каждой сущности свои правила.
Для каждой интеграции записывают владельца, доступы, тестовый контур, допустимую задержку и способ контроля сбоев. Реальные токены и пароли в рабочий план не вставляют — достаточно указать, кто выдаёт доступ и где он хранится по внутреннему регламенту.
Роли, права и редактура
Редактор, маркетолог, администратор и внешний подрядчик не должны получать одинаковые права только ради удобства настройки. Нужно определить, кто создаёт черновик, кто публикует, кто меняет шаблоны и кто имеет доступ к обращениям. Права на действие и область данных описывают отдельно.
Для закрытых разделов проверяют не только вход пользователя, но и смену роли, отзыв доступа и прямую ссылку на документ. Скрытый пункт меню не заменяет проверку прав на сервере.
Приёмка и журнал решений
Приёмочные сценарии готовят до разработки: посетитель отправляет форму, редактор публикует материал, пользователь с ограниченной ролью открывает документ, данные обновляются из источника. У каждого сценария — ожидаемый результат и принимающий. Формулировка «работает корректно» критерием не является.
Все решения удобно хранить в одном реестре: дата, формулировка, владелец, ссылка на материал, затронутые страницы, статус. Изменённую запись не удаляют бесследно. Так команда не получает две версии одного требования из разных чатов.
Вывод
Рабочий реестр решений не заменяет проектирование, но делает его возможным. Если у цели, данных, прав и интеграций есть владелец и проверяемый результат, разработка получает не набор мнений, а согласованные требования.
Top comments (0)