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