Как сменить подрядчика по сайту: передача аккаунтов, доступов и ответственности

Отделите смену команды от переноса и переделки сайта

Сначала определите причину и ожидаемый результат перехода. Возможно, новая команда должна продолжить поддержку действующей версии. В другом случае ей предстоит сначала разобраться в проекте, а затем предложить доработки. Эти задачи отличаются от немедленного переноса хостинга или редизайна.

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

Согласуйте границы перехода

Запишите, какие сайты, поддомены и сервисы входят в передачу. У компании могут быть основной сайт, рекламные страницы, отдельный каталог и формы, связанные с внешними системами. Передача одного из них не означает, что новая команда автоматически отвечает за остальные.

Назовите результат простыми действиями: новая команда понимает устройство проекта, имеет согласованные права, знает открытые вопросы и может выполнить предусмотренные работы. Укажите, какие действия пока запрещены без дополнительного согласования: например, менять адреса страниц, переносить почту или выпускать новый дизайн.

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

Проверьте управление аккаунтами со стороны компании

Сайт зависит от нескольких ресурсов. На одном аккаунте может находиться домен, на другом — хостинг, на третьем — аналитика. Менеджер, которому открыли редактор страниц, не обязательно может оплатить услуги, пригласить нового исполнителя или восстановить вход.

Соберите карту управления до завершения прежней поддержки. Для каждого ресурса выясните, где он расположен, какая учётная запись используется, кто со стороны компании отвечает за него и как проверяется восстановление управления. Пароли и коды в общий рабочий лист не вписывайте.

Таблица — отправная точка. Добавьте ресурсы, которые действительно используются в вашем проекте: оплату, запись, лицензии, CDN или отдельную базу данных. Не переносите чужие элементы списка в ТЗ, если их нет на вашем сайте.

Вход в CMS не равен управлению всем проектом

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

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

Передайте рабочий контекст, а не только логины

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

Уточните, какая версия материалов соответствует опубликованному сайту. Папка с похожим названием и архив неизвестной даты не отвечают на этот вопрос. Новой команде стоит сопоставить полученные исходники с действующей версией и записать обнаруженные расхождения. Это не обещание автоматически восстановить отсутствующую разработку.

Отдельно запишите неизвестное и незавершённое

Передайте список открытых задач: что начато, что согласовано, что ожидает решения и какие проблемы уже известны. У каждой задачи должны быть понятны текущий статус и следующий ответственный. Иначе новая команда может принять старое ограничение за свежую неисправность или повторно выполнить оплаченную работу.

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

Права на дизайн, код, платные компоненты и использование материалов обсуждайте по фактическим документам. Не считайте, что наличие файла автоматически разрешает передать любую лицензию новому исполнителю. Если условие неизвестно, запишите вопрос и назначьте человека, который его уточнит.

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

Назначьте ответственность на время перехода

Пока прежняя команда ещё работает, а новая уже знакомится с проектом, особенно важно понимать, кто согласует и выпускает изменения. Два исполнителя могут независимо менять одну страницу, обработчик формы или настройки сервиса. Сам факт выдачи доступа не определяет, чья версия должна стать рабочей.

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

Зафиксируйте момент смены ответственного

Опишите, кто до передачи отвечает за текущую версию, кто проверяет новую команду и с какого подтверждённого момента принимается новая зона ответственности. Для разных ресурсов эти моменты могут отличаться. Например, поддержка сайта уже передана, а изменение почтового сервиса вообще не входит в переход.

Договоритесь, куда сообщают о проблеме и кто принимает решение о срочном изменении. Укажите, какие обращения прежняя команда ещё завершает, а какие уже передаются новой. Общая фраза «теперь всем занимается другой подрядчик» недостаточна, если часть связей остаётся у отдельного интегратора.

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

Дайте новой команде подтвердить самостоятельную работу

Передачу полезно проверять наблюдаемыми действиями. Новая команда входит через предназначенные ей учётные записи, находит актуальные материалы и объясняет, как будет выполнять согласованные работы. Если каждый шаг требует участия прежнего исполнителя, часть условий перехода ещё не закрыта.

Проверяйте ровно ту самостоятельность, которая нужна по составу поддержки. Редактору контента не обязательно иметь права менять сервер. Команда, отвечающая за выпуск кода, должна понимать этот процесс и его ограничения. Максимальные права «на всякий случай» не являются критерием качества передачи.

Для проверки изменений согласуйте отдельную тестовую задачу, место выполнения и допустимый объём. Это может быть небольшое изменение в тестовой среде с проверкой результата. Не проверяйте компетентность нового исполнителя случайными правками на живом сайте. Разделение сред описано в статье о тестовом и рабочем сайте.

Отдельно обсудите обращения клиентов: кто может проверить форму, почту и связанную систему, какие тестовые данные разрешены и кто подтверждает результат. Смена исполнителя не доказывает доставку заявок. В учебном комплекте ниже никаких входов в аккаунты и отправок сообщений нет.

Учебный пример: лист перехода по шести ресурсам

Представим вымышленный сайт и шесть ресурсов: домен, хостинг, CMS, почту, аналитику и внешнюю интеграцию. Для упражнения по каждому ресурсу отмечены ответственный, управление со стороны компании, проверенный доступ новой команды, получение материалов и известность зависимостей.

Локальная проверка читает только записанные отметки. Она не подтверждает их правдивость и не проверяет реальные права. Статус «Условия в листе заполнены» означает, что выбранные сведения присутствуют и положительные отметки проставлены. Это повод обсудить завершение этапа с владельцем, а не разрешение отключить прежнего исполнителя.

Откройте лист перехода для просмотра и печати или скачайте ZIP с примером. Внутри есть пустой CSV-бланк, шесть заполненных ситуаций и необязательная локальная проверка на Python. Команда и ожидаемые результаты описаны в README. Программирование для заполнения листа не требуется.

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

Используйте пустой лист для обсуждения с обеими командами. Вместо положительной отметки по предположению запишите открытый вопрос и следующего ответственного. Не помещайте в реестр пароли, ключи, коды восстановления, секретные ссылки и персональные данные. Это лист договорённостей, а не хранилище секретов.

Завершайте старые доступы по подтверждённому плану

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

Сначала установите принадлежность учётных записей и связей. Не удаляйте незнакомые записи только потому, что меняется подрядчик: они могут обслуживать работающую интеграцию или другой ресурс компании. Если зависимость неизвестна, уточните её до изменения.

Показательный пример — правила управления владельцами в Google Search Console. Удалённый подтверждённый владелец может восстановить доступ, пока сохраняются его способы подтверждения. При этом Google предупреждает, что один токен может использоваться в нескольких сервисах. Поэтому проверяют именно относящиеся к нужному пользователю способы и их зависимости, а не удаляют все проверочные файлы и записи подряд.

После согласованных изменений проверьте доступ компании, работу новой команды и затронутые связи. Запишите оставшиеся исключения: например, временное участие прежнего специалиста по конкретной задаче. У исключения должны быть цель, ответственный и условие завершения, а не бессрочное объяснение «может пригодиться».

Этот порядок не гарантирует отсутствие всех неизвестных доступов и не заменяет отдельный аудит, если есть признаки инцидента. Статья и учебный сценарий никаких прав не отзывают и секретов не меняют.

Что обсудить с новым подрядчиком до начала работ

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

1. Определите, какие работы новая команда принимает сейчас, а какие остаются за пределами перехода.
2. Назовите ответственного от компании и владельцев внешних зависимостей.
3. Согласуйте материалы и способ проверки их актуальности относительно работающего сайта.
4. Запишите действия, которыми новая команда подтвердит самостоятельность в своём объёме работ.
5. Установите условия завершения старых прав и порядок проверки затронутых сервисов.
6. Зафиксируйте, кто отвечает за оставшиеся вопросы после передачи и как принимается результат.

Обсудить такой переход можно в рамках поддержки сайта. Сначала нужно понять устройство проекта и требуемую ответственность, затем согласовать состав работ. Этот разговор не означает автоматического переноса, редизайна или заранее известной стоимости обслуживания.