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