[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$f2t7nk3zuqm3dj":3},{"slug":4,"title":5,"published":6,"publishedAt":7,"createdAt":7,"section":8,"preview":9,"heroImage":8,"previewImage":10,"headMarkup":11,"lifecycleId":42,"bodyMd":43,"bodyHtml":44},"kto-dolzhen-uchastvovat-v-razrabotke-sayta-so-storony-zakazchika","Кто должен участвовать в разработке сайта со стороны заказчика",true,"2026-07-16T09:00:00+03:00",null,"Какие роли нужны со стороны заказчика при разработке сайта: решения, зоны ответственности, порядок согласования и контроль сроков.","\u002Fcontent-media\u002Farticles\u002Fkto-dolzhen-uchastvovat-v-razrabotke-sayta-so-storony-zakazchika\u002Fassets\u002F5157e0748c1a.webp",[12],{"tag":13,"type":14,"key":15,"json":16},"script","application\u002Fld+json","kto-dolzhen-uchastvovat-v-razrabotke-sayta-so-storony-zakazchika-faq",{"@context":17,"@type":18,"mainEntity":19},"https:\u002F\u002Fschema.org","FAQPage",[20,26,30,34,38],{"@type":21,"name":22,"acceptedAnswer":23},"Question","Можно ли назначить одного человека на все роли?",{"@type":24,"text":25},"Answer","В небольшой компании один сотрудник может совмещать роли, но решения всё равно стоит разделить в плане. Иначе незаметно пропадает проверка контента, маршрута заявки или технического доступа.",{"@type":21,"name":27,"acceptedAnswer":28},"Когда подключать IT?",{"@type":24,"text":29},"До оценки интеграций и выбора архитектуры. Позднее подключение часто выявляет ограничения домена, CRM или размещения уже после утверждения макетов.",{"@type":21,"name":31,"acceptedAnswer":32},"Должны ли продажи согласовывать каждую страницу?",{"@type":24,"text":33},"Нет. Продажам нужны страницы и сценарии, которые влияют на квалификацию обращения, аргументацию и передачу контекста. Редакционные правки можно вести по отдельному маршруту.",{"@type":21,"name":35,"acceptedAnswer":36},"Кто утверждает изменения после старта?",{"@type":24,"text":37},"Это фиксирует руководитель проекта: какие изменения может принять владелец раздела, а какие меняют срок, бюджет или интеграции и требуют общего решения.",{"@type":21,"name":39,"acceptedAnswer":40},"Как не растянуть согласование?",{"@type":24,"text":41},"Заранее задать пакет для проверки, срок ответа и правило эскалации. Комментарий без владельца и срока не должен оставаться задачей подрядчика.","lc_565eac60de2c2933106dac216858644f","# Кто должен участвовать в разработке сайта со стороны заказчика\n\nРабота над сайтом может остановиться и после старта подрядчика, если у заказчика не подтверждён список услуг, продажи не описали вопросы клиентов, IT не согласовало доступ к системам, а юрист получает форму на проверку в день релиза. Один менеджер проекта не может принимать эти решения за все подразделения.\nДо старта полезно не собирать большой комитет, а назвать владельцев конкретных решений. Тогда вопрос «кто согласует?» заменяется на список: кто отвечает за цель страницы, кто подтверждает факт, кто выдаёт доступ и кто принимает сценарий заявки.\n\n## Руководитель проекта отвечает за границы работы\n\nРуководитель со стороны заказчика собирает решения в один план, назначает сроки и снимает противоречия между подразделениями. Он не обязан писать тексты или проверять код, но должен определить, что входит в первый релиз, как меняется объём работ и кто имеет право подтвердить результат. Без этой роли подрядчик получает несколько несовместимых поручений в переписке.\n\n## Маркетинг формулирует задачу страницы\n\nМаркетолог описывает аудиторию, предложение, источники трафика, доказательства и целевое действие. Ему важно передать не только список блоков, но и ограничения: какие обещания нельзя использовать, какие сегменты требуют отдельной страницы, какие кампании уже ведут на существующие URL. Метрики и цели аналитики согласуют до дизайна, иначе после запуска трудно понять, что именно измеряет счётчик.\n\n## Продажи проверяют путь до обращения\n\nОтдел продаж приносит реальные вопросы, признаки качественного обращения и данные, которые нужны для первого контакта. Это не означает, что все вопросы превращаются в обязательные поля формы. Продажи помогают разделить то, что посетитель должен увидеть на сайте, и то, что менеджер уточнит в разговоре.\n\n![Карта ролей проекта](\u002Fcontent-media\u002Farticles\u002Fkto-dolzhen-uchastvovat-v-razrabotke-sayta-so-storony-zakazchika\u002Fassets\u002F946f4f16ed48.webp)\n\n## Эксперты и редакторы подтверждают фактуру\n\nЭксперт направления отвечает за технические условия, ограничения услуги, документы и примеры, разрешённые к публикации. Редактор приводит материал к структуре страницы и отслеживает версии. Если факты хранятся только в устных комментариях, после согласования невозможно проверить, какая формулировка была утверждена.\n\n## IT выдаёт доступы и описывает интеграции\n\nIT подтверждает владельцев домена, хостинга, аналитики, почты, CRM и внешних сервисов. Для каждой интеграции нужен маршрут данных, технический контакт и тестовый сценарий. Просьба «подключить позже» допустима только когда понятно, как сайт работает до подключения и кто принимает риск ручной обработки.\n\n## Юрист подключается до готовой формы\n\nЮристу передают цель сбора данных, поля формы, текст согласия, ссылки на документы и сценарий уведомлений. Он не выбирает цвет кнопки, но подтверждает условия, которые нельзя исправить одной заменой текста после запуска. При отраслевых требованиях и специальных категориях данных нужна отдельная профильная проверка.\n\n## Приёмку распределяют по сценариям\n\nФинальная проверка не должна сводиться к просмотру главной страницы. Маркетинг проверяет смысл и события, продажи — качество карточки обращения, IT — доступы и обмен, редактор — контент и ссылки. Руководитель проекта фиксирует результат и решение по найденным дефектам.\n\n## Часто задаваемые вопросы\n\n### Можно ли назначить одного человека на все роли?\n\nВ небольшой компании один сотрудник может совмещать роли, но решения всё равно стоит разделить в плане. Иначе незаметно пропадает проверка контента, маршрута заявки или технического доступа.\n\n### Когда подключать IT?\n\nДо оценки интеграций и выбора архитектуры. Позднее подключение часто выявляет ограничения домена, CRM или размещения уже после утверждения макетов.\n\n### Должны ли продажи согласовывать каждую страницу?\n\nНет. Продажам нужны страницы и сценарии, которые влияют на квалификацию обращения, аргументацию и передачу контекста. Редакционные правки можно вести по отдельному маршруту.\n\n### Кто утверждает изменения после старта?\n\nЭто фиксирует руководитель проекта: какие изменения может принять владелец раздела, а какие меняют срок, бюджет или интеграции и требуют общего решения.\n\n### Как не растянуть согласование?\n\nЗаранее задать пакет для проверки, срок ответа и правило эскалации. Комментарий без владельца и срока не должен оставаться задачей подрядчика.\n\n## Рабочая таблица ответственности\n\nДля старта достаточно одной таблицы: решение, владелец, участники консультации, срок, входные материалы и способ подтверждения. В неё попадают структура услуг, факты для публикации, форма, маршрут CRM, доступы, юридические тексты и дата приёмки. Если решение меняется, в таблице остаётся причина и новый ответственный. Это помогает не возвращаться к устным договорённостям после смены участников проекта.\n\nОсобое внимание уделяют решениям на стыке подразделений. Например, продажа может запросить поле в форме, но маркетинг отвечает за конверсию, IT — за передачу в CRM, а юрист — за текст согласия. Одного согласования недостаточно: нужен сценарий проверки, по которому команда увидит карточку обращения и подтвердит, что поле действительно используется.\n\n## Итог\n\nСостав участников определяется не должностями в оргструктуре, а решениями, которые нужно принять до релиза. Если у формы, интеграции, текста и приёмочного сценария есть владелец и способ подтверждения, подрядчик получает проверяемые входные данные, а заказчик сохраняет контроль над результатом.\n","\u003Ch1>Кто должен участвовать в разработке сайта со стороны заказчика\u003C\u002Fh1>\n\u003Cp>Работа над сайтом может остановиться и после старта подрядчика, если у заказчика не подтверждён список услуг, продажи не описали вопросы клиентов, IT не согласовало доступ к системам, а юрист получает форму на проверку в день релиза. Один менеджер проекта не может принимать эти решения за все подразделения.\nДо старта полезно не собирать большой комитет, а назвать владельцев конкретных решений. Тогда вопрос «кто согласует?» заменяется на список: кто отвечает за цель страницы, кто подтверждает факт, кто выдаёт доступ и кто принимает сценарий заявки.\u003C\u002Fp>\n\u003Ch2>Руководитель проекта отвечает за границы работы\u003C\u002Fh2>\n\u003Cp>Руководитель со стороны заказчика собирает решения в один план, назначает сроки и снимает противоречия между подразделениями. Он не обязан писать тексты или проверять код, но должен определить, что входит в первый релиз, как меняется объём работ и кто имеет право подтвердить результат. Без этой роли подрядчик получает несколько несовместимых поручений в переписке.\u003C\u002Fp>\n\u003Ch2>Маркетинг формулирует задачу страницы\u003C\u002Fh2>\n\u003Cp>Маркетолог описывает аудиторию, предложение, источники трафика, доказательства и целевое действие. Ему важно передать не только список блоков, но и ограничения: какие обещания нельзя использовать, какие сегменты требуют отдельной страницы, какие кампании уже ведут на существующие URL. Метрики и цели аналитики согласуют до дизайна, иначе после запуска трудно понять, что именно измеряет счётчик.\u003C\u002Fp>\n\u003Ch2>Продажи проверяют путь до обращения\u003C\u002Fh2>\n\u003Cp>Отдел продаж приносит реальные вопросы, признаки качественного обращения и данные, которые нужны для первого контакта. Это не означает, что все вопросы превращаются в обязательные поля формы. Продажи помогают разделить то, что посетитель должен увидеть на сайте, и то, что менеджер уточнит в разговоре.\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fcontent-media\u002Farticles\u002Fkto-dolzhen-uchastvovat-v-razrabotke-sayta-so-storony-zakazchika\u002Fassets\u002F946f4f16ed48.webp\" alt=\"Карта ролей проекта\">\u003C\u002Fp>\n\u003Ch2>Эксперты и редакторы подтверждают фактуру\u003C\u002Fh2>\n\u003Cp>Эксперт направления отвечает за технические условия, ограничения услуги, документы и примеры, разрешённые к публикации. Редактор приводит материал к структуре страницы и отслеживает версии. Если факты хранятся только в устных комментариях, после согласования невозможно проверить, какая формулировка была утверждена.\u003C\u002Fp>\n\u003Ch2>IT выдаёт доступы и описывает интеграции\u003C\u002Fh2>\n\u003Cp>IT подтверждает владельцев домена, хостинга, аналитики, почты, CRM и внешних сервисов. Для каждой интеграции нужен маршрут данных, технический контакт и тестовый сценарий. Просьба «подключить позже» допустима только когда понятно, как сайт работает до подключения и кто принимает риск ручной обработки.\u003C\u002Fp>\n\u003Ch2>Юрист подключается до готовой формы\u003C\u002Fh2>\n\u003Cp>Юристу передают цель сбора данных, поля формы, текст согласия, ссылки на документы и сценарий уведомлений. Он не выбирает цвет кнопки, но подтверждает условия, которые нельзя исправить одной заменой текста после запуска. При отраслевых требованиях и специальных категориях данных нужна отдельная профильная проверка.\u003C\u002Fp>\n\u003Ch2>Приёмку распределяют по сценариям\u003C\u002Fh2>\n\u003Cp>Финальная проверка не должна сводиться к просмотру главной страницы. Маркетинг проверяет смысл и события, продажи — качество карточки обращения, IT — доступы и обмен, редактор — контент и ссылки. Руководитель проекта фиксирует результат и решение по найденным дефектам.\u003C\u002Fp>\n\u003Ch2>Часто задаваемые вопросы\u003C\u002Fh2>\n\u003Ch3>Можно ли назначить одного человека на все роли?\u003C\u002Fh3>\n\u003Cp>В небольшой компании один сотрудник может совмещать роли, но решения всё равно стоит разделить в плане. Иначе незаметно пропадает проверка контента, маршрута заявки или технического доступа.\u003C\u002Fp>\n\u003Ch3>Когда подключать IT?\u003C\u002Fh3>\n\u003Cp>До оценки интеграций и выбора архитектуры. Позднее подключение часто выявляет ограничения домена, CRM или размещения уже после утверждения макетов.\u003C\u002Fp>\n\u003Ch3>Должны ли продажи согласовывать каждую страницу?\u003C\u002Fh3>\n\u003Cp>Нет. Продажам нужны страницы и сценарии, которые влияют на квалификацию обращения, аргументацию и передачу контекста. Редакционные правки можно вести по отдельному маршруту.\u003C\u002Fp>\n\u003Ch3>Кто утверждает изменения после старта?\u003C\u002Fh3>\n\u003Cp>Это фиксирует руководитель проекта: какие изменения может принять владелец раздела, а какие меняют срок, бюджет или интеграции и требуют общего решения.\u003C\u002Fp>\n\u003Ch3>Как не растянуть согласование?\u003C\u002Fh3>\n\u003Cp>Заранее задать пакет для проверки, срок ответа и правило эскалации. Комментарий без владельца и срока не должен оставаться задачей подрядчика.\u003C\u002Fp>\n\u003Ch2>Рабочая таблица ответственности\u003C\u002Fh2>\n\u003Cp>Для старта достаточно одной таблицы: решение, владелец, участники консультации, срок, входные материалы и способ подтверждения. В неё попадают структура услуг, факты для публикации, форма, маршрут CRM, доступы, юридические тексты и дата приёмки. Если решение меняется, в таблице остаётся причина и новый ответственный. Это помогает не возвращаться к устным договорённостям после смены участников проекта.\u003C\u002Fp>\n\u003Cp>Особое внимание уделяют решениям на стыке подразделений. Например, продажа может запросить поле в форме, но маркетинг отвечает за конверсию, IT — за передачу в CRM, а юрист — за текст согласия. Одного согласования недостаточно: нужен сценарий проверки, по которому команда увидит карточку обращения и подтвердит, что поле действительно используется.\u003C\u002Fp>\n\u003Ch2>Итог\u003C\u002Fh2>\n\u003Cp>Состав участников определяется не должностями в оргструктуре, а решениями, которые нужно принять до релиза. Если у формы, интеграции, текста и приёмочного сценария есть владелец и способ подтверждения, подрядчик получает проверяемые входные данные, а заказчик сохраняет контроль над результатом.\u003C\u002Fp>\n"]