Что подготовить заказчику до старта разработки: документы, доступы и ответственный

Короткий ответ: до старта разработки заказчику нужно собрать три вещи. Документы, без которых сайт нельзя запустить законно: реквизиты, политику обработки персональных данных, для магазина — условия продажи и доставки. Доступы к домену, хостингу, Метрике, CRM, 1С и платёжному сервису — переданные так, чтобы их можно было отозвать. И одного ответственного с вашей стороны, который отвечает на вопросы за оговорённое время. Остальное, включая техническую часть ТЗ, обычно берёт на себя студия.

Почему подготовка заказчика влияет на срок?

Потому что срок в договоре считается не с даты подписания. В типовом договоре Roboweb.team он идёт в рабочих днях «с момента поступления предоплаты и предоставления Заказчиком исходных материалов», а среди обязанностей заказчика прямо названы материалы, доступы и своевременное согласование этапов.

На практике это выглядит так: корпоративный сайт по прайсу делается за 3–4 дня (от 56 000 ₽), лендинг — за 2 дня (от 24 000 ₽). При таких сроках неделя ожидания доступа к хостингу или ответа юриста длиннее, чем вся разработка. Сама сборка редко бывает узким местом: узким местом оказываются согласования. Подробно о том, из чего складывается срок, — в статье «Сколько времени делается сайт».

В первом приложении к нашему договору — техническом задании — для этого есть отдельные строки: «Материалы Заказчика» и «Репозиторий, хостинг и аккаунты Заказчика». Если заполнить их до подписания, у обеих сторон с первого дня есть список того, что передаётся, и споров «мы ждали от вас» не возникает. Как составить само ТЗ, разобрано в статье «Как составить ТЗ без опыта»; здесь речь только о том, что нужно собрать вокруг него.

Какие документы нужны сайту?

Минимум — реквизиты компании и политика обработки персональных данных, если на сайте есть хотя бы одна форма. Магазину дополнительно нужны условия продажи, оплаты, доставки и возврата. Тексты этих документов пишет ваш юрист или вы сами, разработчик их размещает и связывает с формами.

Разберём по типам документов.

• Реквизиты. Полное наименование, ИНН, ОГРН или ОГРНИП, юридический и фактический адрес, телефон и почта. Они нужны для подвала сайта, страницы контактов и договора с нами. Пришлите карточку организации одним файлом — её не придётся переписывать по кусочкам.
• Политика обработки персональных данных. Часть 2 ст. 18.1 закона 152-ФЗ требует от оператора, который собирает данные через интернет, опубликовать политику на страницах, где идёт сбор. Форма заявки «имя и телефон» — уже сбор. Политика должна описывать вашу реальную обработку: какие формы, куда уходят заявки, какие сервисы подключены.
• Текст согласия на обработку данных. Оформляется отдельно от других документов, а в форме — отдельным чекбоксом, который человек ставит сам. Какие ещё требования 152-ФЗ касаются форм, в том числе локализация и уведомление Роскомнадзора, — в статье «Где хранить данные из форм сайта по 152-ФЗ».
• Условия продажи для магазина. По п. 2 ст. 26.1 закона о защите прав потребителей при дистанционной продаже покупатель до заключения договора должен получить сведения о продавце (полное наименование, адрес), о товаре, цене, доставке, гарантийном сроке и порядке оплаты. Значит, к запуску магазина эти условия должны быть сформулированы — их нельзя «дописать потом».
• Оферта или пользовательское соглашение. Обычно нужны, если на сайте есть онлайн-оплата, личный кабинет или платная услуга. Если сайт только собирает заявки, а договор вы заключаете отдельно, оферта на сайте обычно не требуется — уточните это у юриста.
• Документы о правах на материалы. По договору заказчик гарантирует, что у него есть права на передаваемые тексты, фото и логотипы. Если логотип рисовал дизайнер-фрилансер, а фото снимал фотограф, проверьте, что права оформлены на компанию.

Чего от вас точно не потребуется для обычного сайта: лицензий, свидетельств о регистрации сайта как СМИ, сертификатов на сам сайт. Если кто-то просит такие бумаги для корпоративного сайта, уточните, зачем: для типового сайта компании их нет в перечне обязательных.

Какие доступы передать разработчику и как безопасно?

Только те, которые нужны для работ по ТЗ, и только так, чтобы их можно было отозвать: отдельный пользователь, ключ API или приглашение по логину вместо вашего основного пароля. Владельцем аккаунтов остаётесь вы, разработчик получает роль.

Хорошая проверка для любого доступа: сможете ли вы после окончания работ одним действием его закрыть, не меняя пароли всей компании? Если нет — способ передачи стоит пересмотреть.

• Приглашения вместо паролей. Многие сервисы позволяют выдать доступ по логину. В Яндекс Метрике, например, это раздел «Настройка → Доступ»: можно добавить пользователя по логину Яндекса с уровнем «Только просмотр», «Редактирование» или «Аналитика» (справка Метрики). Для настройки счётчика и целей достаточно редактирования, удалить счётчик или передать его другому аккаунту с этим уровнем нельзя.
• Отдельные учётные записи. Для хостинга — отдельный пользователь или SSH-ключ разработчика, для 1С — отдельный пользователь с правами только на нужные разделы, для CRM — отдельный ключ API или вебхук. Так в журналах видно, кто что делал, и доступ закрывается удалением одной записи.
• Пароли — не в общем чате. Если без пароля не обойтись, передайте его через менеджер паролей или одноразовую ссылку, а логин и пароль — разными сообщениями. Не пересылайте пароли в общих чатах с десятью участниками и не храните их в письме «Доступы к сайту».
• Двухфакторный вход. Если на аккаунте включены коды по SMS на телефон директора, договоритесь заранее, кто и как быстро их будет пересылать. Решать это вечером в пятницу перед запуском — плохая идея.
• Отзыв после работ. После акта удалите временных пользователей и смените пароли, которые передавали. Доступы для поддержки оставляйте только если подписан договор на неё.

Подробно о том, на кого регистрировать домен и хостинг и почему не на подрядчика, — в статье «На кого оформлять домен и хостинг сайта». Здесь важно одно: если домена и хостинга ещё нет, их оформление можно вести параллельно со сборкой, они нужны к публикации, а не к первому дню.

Отдельная история — мобильные приложения. Публиковать приложение от имени компании в App Store можно только с аккаунтом организации, а для него Apple требует номер D-U-N-S. По справке Apple, номер выдаётся до 5 рабочих дней, и ещё до 2 рабочих дней данные идут в Apple. Если вы заказываете мобильное приложение, начните оформление аккаунта разработчика в день подписания договора, а не за неделю до релиза.

Система	Что нужно разработчику	Как передать безопасно	Когда понадобится
Домен (регистратор)	Поменять DNS-записи: направить домен на сервер, подключить почту	Вы сами меняете записи по инструкции или временно даёте вход с последующей сменой пароля	К публикации, обычно в конце работ
Хостинг или сервер	Развернуть сайт, настроить HTTPS, резервные копии	Отдельный пользователь или SSH-ключ разработчика, который потом удаляется	К сборке на рабочем адресе
Яндекс Метрика	Поставить счётчик, настроить цели	Доступ по логину Яндекса с уровнем «Редактирование» в настройках счётчика	К запуску
CRM	Принимать заявки и заказы с сайта	Отдельный ключ API или вебхук с правами только на нужные сущности	К подключению форм
1С	Обмен товарами, остатками, заказами	Отдельный пользователь 1С с узкими правами; доступ к опубликованной базе	С первых дней, если обмен — основа проекта
Платёжный сервис	Подключить приём оплаты	Тестовые ключи сразу, рабочие — после договора с эквайером, через менеджер паролей	К тестированию заказов

Кто отвечает за проект в вашей компании?

Один человек, у которого есть время на проект и право принимать решения: согласовать макет, ответить на вопрос о логике, подписать акт. Без такого ответственного вопросы ходят по кругу между директором, маркетологом и бухгалтером, а срок растёт.

Ответственный не обязан разбираться в разработке. Его задачи — организационные:

• собрать внутри компании ответы на вопросы студии и прислать их одним сообщением, а не пятью противоречащими;
• знать, у кого какой доступ, и уметь быстро его получить у владельца аккаунта;
• согласовать или вернуть с замечаниями макет и сборку в оговорённый срок;
• подписать акт или направить мотивированный отказ — по нашему договору на это есть 5 рабочих дней, после чего работы считаются принятыми.

Частая ошибка — назначить ответственным сотрудника без полномочий. Он собирает правки, но окончательное слово за директором, который видит макет только на приёмке и разворачивает концепцию. В тарифе включено до 2 раундов правок в рамках согласованной структуры; смена концепции после согласования — уже новый объём работ. Поэтому человека с правом последнего слова стоит позвать хотя бы на согласование макета.

Ещё одна деталь: договоритесь о канале. По договору документы и переписка по электронной почте сторон имеют юридическую силу. Рабочие вопросы удобно решать в мессенджере, но согласование макета, замечания к сборке и акт стоит фиксировать письмом — тогда через месяц не придётся искать, кто и что утвердил.

Как быстро отвечать на вопросы, чтобы не сдвигать срок?

Ориентир — в течение рабочего дня на рабочие вопросы и 1–2 рабочих дня на согласование макета и сборки. Когда весь проект занимает несколько дней, каждый день ожидания ответа почти напрямую добавляется к сроку.

Что помогает держать темп:

1. Договоритесь о сроках ответа на старте. Запишите, кто отвечает и за сколько. Это не формальность: если ответа нет, студии понятно, к кому идти, а вам — почему сдвинулась дата.
2. Собирайте замечания одним списком. Один сводный список правок по макету обрабатывается быстрее, чем двадцать сообщений в течение дня, и не тратит раунд правок на мелочи.
3. Предупреждайте об отпусках. Если ответственный уходит в отпуск в середине проекта, назначьте замену с теми же полномочиями и предупредите студию.
4. Отвечайте «не знаю, решите сами», когда так и есть. Это нормальный ответ. Например, на вопрос о порядке блоков на внутренней странице студия предложит вариант по опыту — а вы сэкономите день на обсуждение.

Если вопрос требует согласования внутри компании — юриста, службы безопасности, бухгалтерии, — скажите об этом сразу и назовите реальный срок. Честное «ответим в четверг» удобнее для планирования, чем «сегодня-завтра», которое растягивается на неделю.

Что можно не готовить?

Техническую часть: структуру данных, требования к вёрстке, выбор технологий, схему интеграций, настройку сервера. Это работа студии, она оформит её в ТЗ и согласует с вами. От вас — цель, сценарии и ответы на вопросы.

Вот что студия берёт на себя по тарифам из прайса:

• Структуру и прототип. Вы рассказываете, что должен сделать посетитель, мы предлагаем структуру и макет.
• Техническое ТЗ. По брифу и разговору оформляем ТЗ и спецификацию к договору.
• Публикацию. Размещение на вашем домене, настройка HTTPS, подключение форм и аналитики входят в лендинг и корпоративный сайт.
• Базовое SEO. Заголовки, описания страниц, разметка для соцсетей.
• Схему интеграции. В тарифе интеграций (от 32 000 ₽, от 2 дней) первым этапом идёт аудит: какие системы связать, форматы данных, точки обмена. Вам не нужно заранее описывать API своей CRM — достаточно доступа и понимания, что куда должно попадать.
• Инструкцию. После сдачи вы получаете краткую инструкцию: как менять тексты и куда приходят заявки.

Контент — отдельная тема. В корпоративный сайт по прайсу входят тексты и наполнение по вашим данным; в лендинге копирайтинг, покупка и съёмка фото — за доплату. В любом случае от вас нужны факты: услуги, цены, условия, реальные фото производства или команды, если хотите их на сайте. Какие из них соберёт студия, а какие только вы, обсуждаем на брифе.

Когда подготовка почти не нужна: если вы заказываете Telegram-бота для заявок (от 16 000 ₽, 1–2 дня), достаточно токена бота, который владелец получает в Telegram, и понимания, куда отправлять заявки. Юридический пакет для него проще — но если бот собирает телефоны, политика обработки данных всё равно понадобится.

Какие ошибки заказчика сдвигают старт?

Чаще всего — доступы, которых нет ни у кого в компании, и юридические тексты, которые начали писать в день запуска. Обе проблемы решаются за неделю до старта, но не за час до публикации.

• Домен на бывшем сотруднике или старом подрядчике. Восстановление прав занимает время и не зависит от студии. Проверьте администратора домена до подписания договора.
• Пароль от хостинга «где-то был». Восстановление через почту, к которой нет доступа, — частая причина задержки. Проверьте вход заранее.
• Политика с чужого сайта. Скопированный текст с чужими сервисами и целями не описывает вашу обработку данных — и заменять его придётся всё равно.
• Платёжный сервис не подключён. Договор с эквайером и проверка магазина идут на стороне банка или платёжного сервиса. Разработку можно вести на тестовых ключах, но к запуску интернет-магазина рабочее подключение должно быть готово.
• Нет решающего лица на согласовании. Макет утверждает один человек, а на приёмке появляется второй с другим видением.

Чек-лист на одну страницу

Распечатайте или скопируйте этот список и отметьте, что готово. Всё, что не отмечено, назовите студии на брифе — так в ТЗ сразу попадут сроки и ответственные.

• Карточка организации с реквизитами — одним файлом.
• Ответственный за проект: имя, телефон, почта, кто его замещает.
• Человек с правом последнего слова — будет на согласовании макета.
• Оговорённый срок ответа: рабочие вопросы — в течение дня, согласования — 1–2 рабочих дня.
• Политика обработки персональных данных и текст согласия — у юриста в работе или готовы.
• Для магазина: условия продажи, оплаты, доставки и возврата.
• Права на логотип, фото и тексты подтверждены.
• Домен оформлен на компанию или ИП, вход в кабинет регистратора проверен.
• Хостинг или сервер: вход проверен, или решено, что его оформите параллельно.
• Яндекс Метрика: счётчик есть — готовы выдать доступ по логину; нет — студия создаст его на ваш аккаунт.
• CRM и 1С: кто выдаст отдельного пользователя или ключ API.
• Платёжный сервис: договор заключён или в процессе, тестовые ключи доступны.
• Для приложения: аккаунт разработчика и, для организации, номер D-U-N-S — в работе.
• Канал связи и почта для согласований и акта.

Если половина пунктов пока пустая, это не повод откладывать разговор. Заполните бриф проекта — по нему видно, чего не хватает, и что из этого действительно нужно к старту, а что — только к публикации. Цену и срок называем после брифа и фиксируем в договоре до начала работ.

Короткие ответы на частые вопросы

Можно ли начать разработку, если у компании ещё нет домена и хостинга?

Да. Сборку можно вести на тестовом адресе, а домен и хостинг оформить параллельно — они нужны к публикации. Регистрируйте их на компанию или ИП, а не на подрядчика; оплачиваете вы их напрямую у регистратора и провайдера.

Нужно ли давать разработчику пароль от личного кабинета регистратора?

Не обязательно. Чаще всего достаточно, чтобы вы сами поменяли две-три DNS-записи по нашей инструкции. Если удобнее отдать вход, после публикации смените пароль и проверьте, что почта для восстановления — ваша.

Кто готовит политику обработки персональных данных для сайта?

Текст политики и согласия — зона юриста заказчика, потому что они описывают вашу обработку данных. Разработчик размещает документы на сайте, ставит ссылки у каждой формы и делает отдельный чекбокс согласия.

Что будет, если заказчик долго не присылает материалы?

Срок по типовому договору считается с поступления предоплаты и предоставления исходных материалов, поэтому задержка материалов сдвигает и дату сдачи. Чтобы этого не было, договоритесь о сроке ответа и назначьте одного ответственного.

Нужен ли ответственный, если компания маленькая и решает всё директор?

Да, но им может быть сам директор. Важно не количество людей, а то, чтобы один человек собирал ответы, отвечал в оговорённый срок и имел право согласовать макет и подписать акт.

Услуги и кейсы по теме: мобильные приложения · интеграция с 1С и CRM от 32 000 ₽ · цены и сроки