Разговор, который случается чаще, чем хотелось бы. Компания хочет обновить сайт, зовёт нового человека и на первом же шаге выясняется, что домен зарегистрирован на прежнего подрядчика, хостинг оплачивается с его карты, а почта администратора — его личная или на чужом домене.
Работать в такой ситуации можно только с его согласия. А он, допустим, обиделся на вас по какой-то причине. Или уехал. Или просто не отвечает.
Это не про плохих людей. Почти всегда так сложилось само собой: на старте нужно было быстро запуститься, регистрировал тот, кто умел, и никто не думал, что через пять лет это станет проблемой. Разберём, что должно быть вашим и как это проверить за один вечер.
Главный признак: не «есть доступ», а «могу вернуть без подрядчика»
Ключевая проверка простая. Спросите себя: если человек, который всё настраивал, завтра исчезнет — смогу ли я восстановить контроль сам?
Наличие пароля к личному кабинету регистратора домена или хостера здесь не показатель. Пароль меняется за одну секунду тем, кто указан владельцем. Значение имеет только одна вещь: на кого оформлена учётная запись и на какой адрес почты приходит восстановление доступа.
Что должно быть оформлено на вас
Пройдитесь по списку — с большой вероятностью пара пунктов вас удивит.
Домен. Самый ценный актив и самый частый сюрприз. Должен быть зарегистрирован на вашу компанию или на вас, с вашими контактами. Потерять домен — значит потерять адрес сайта, почту на нём и годы вложений в продвижение (узнаваемость).
DNS домена. Домен может быть оформлен на вас, а записи, которые говорят «сайт живёт здесь, почта здесь», — зачастую в панели подрядчика. Тогда переехать на другой хостинг или сменить почту без него не выйдет: домен ваш, а управление им — нет. Проверьте, в чьём кабинете живёт зона домена.
Хостинг или сервер. Договор и оплата — с вами или вашей компанией. Вариант «подрядчик держит наши сайты у себя на сервере» устраивает вас ровно до первой ссоры.
Служебная почта. Тот самый адрес, на который приходит восстановление паролей от всего остального. Он должен быть на вашем домене и лучше создавать его на компанию, а не на конкретного сотрудника (ну только если это не адрес директора). Личная почта сотрудника или подрядчика в этой роли — корень большинства неприятных историй.
Второй фактор и телефон восстановления. У всех серьёзных сервисов вход защищён кодом из приложения или SMS. Если этот код приходит на телефон подрядчика, то всё указанное выше — формальность: логин ваш, а войти вы не можете. Второй фактор должен быть привязан к вашему устройству и рабочему номеру компании.
Учётная запись в CRM и её администратор. Права главного администратора — у вас, а не только у интегратора (внедренца). Подрядчику дают минимально необходимый доступ, а не владение.
Ключи доступа к сервисам. Те строчки, через которые системы разговаривают друг с другом. Они должны выпускаться из ваших личных кабинетов и на служебные учётные записи компании. Ключ, выпущенный с личного кабинета подрядчика, вместе с ним и уйдёт.
Исходный код. Он должен где-то лежать и быть вам доступен — в вашем хранилище кода или, как минимум, переданным вам архивом с описанием, как это запускается. «Код у меня на компьютере» — это не место хранения: рано или поздно вы его потеряете.
Данные. База клиентов, содержимое сайта, накопленная переписка. Вы должны уметь получить их выгрузку самостоятельно, не спрашивая технического разрешения у кого-то.
Рекламные кабинеты и аналитика. Их обычно вспоминают последними, а между тем в них накопленная статистика за годы и переносить её некуда.
Аккаунты в соцсетях, мессенджерах и на картах. Сообщество, канал, чат-бот, карточка компании на картах. Их создают «с личного» и владельцем остаётся человек, а не компания. Отзывы и подписчики за годы не переносятся никуда.
Резервные копии. Отдельный пункт: копии должны существовать и обязательно лежать не только на том же сервере, но и где-то ещё, а также быть проверенными. Копия, из которой ни разу не пробовали восстановиться — это «надежда на светлое будущее», а не копия))
Про данные клиентов — отдельно
Есть вещь, которая не зависит от договорённостей с подрядчиком: ответственность за персональные данные клиентов остаётся на вас. Это ваша база, вы её собрали и отвечать за то, как она хранится и кому доступна, будете вы — независимо от того, кто настраивал сервер.
Из этого следует практический вывод. Стоит хотя бы примерно знать, где физически лежат данные ваших клиентов и у кого есть к ним доступ. Не для документов, а просто чтобы не узнать это в самый неудачный и неподходящий момент.
Что именно проверяют в такой ситуации и где чаще всего находятся сюрпризы — разбирал отдельно: аудит сайта по 152-ФЗ.
Что просить на старте работ
Пять пунктов, которые нужно проговорить до начала, а не после. Нормальный подрядчик отнесётся к ним спокойно — я и сам предлагаю это первым.
- Все регистрации — на вас. Домен, хостинг, кабинеты сервисов оформляются на вашу компанию. Подрядчик получает минимально необходимый доступ, а не владение.
- Служебная почта заведена заранее и лежит у вас. С неё регистрируется всё остальное.
- Список доступов ведётся письменно. Что/где заведено, на кого оформлено, где/когда оплачивается. Один документ, обновляемый по мере работы.
- Код, данные и права на них — ваши. Код и данные передаются по ходу работы, а не «в конце, если попросите». Права на код и материалы — исходники макетов, фото, тексты — тоже ваши: в договоре нужна прямая строка о том, что права на них переходят к вам. Без такой строки принадлежность прав придётся выяснять задним числом — и выяснять в момент ссоры.
- Проговорено, что происходит при расставании. Как передаются доступы, в какой срок, что остаётся у подрядчика. Лучше — письменно в договоре.
Это не про недоверие. Даже с самым порядочным человеком случается всякое: больница, переезд, смена рода занятия и т.д. Правильно оформленные доступы защищают обе стороны: вас — от паралича в работе, подрядчика — от разговоров в духе «а вы нам ничего не отдали».
Если уже сложилось не так
Действуйте спокойно и по одному пункту. Начните с самого болезненного: домен и почта. Дальше хостинг, кабинеты, код.
Разговор строится не как претензия, а как наведение порядка: «нам нужно оформить всё на компанию, помоги перенести». В большинстве случаев подрядчик соглашается без всяких сложностей — ему это тоже удобнее.
А если на просьбу передать доступы человек отвечает отказом или начинает торговаться, вы получили крайне ценную информацию. И круто, что получили её в этот момент, а не когда что-то случилось…
Заодно проверьте, что происходит с уже собранными связками: ключ, выпущенный на чужую учётную запись, однажды истекает — и обмен встаёт молча. Про это отдельно: почему интеграция «на коленке» ломается через полгода.
Если не уверены, что у вас на руках — соберите список из статьи и пройдитесь по пунктам. Пройти его целиком — работа на один вечер. Нужен взгляд со стороны — напишите, посмотрим, где тонко/рискованно. Обращайтесь, решим вашу задачу!