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