Смена разработчика сайта: как передать проект без потери доступа и задач

Передаётся возможность работать, а не папка файлов

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

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

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

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

Доступы, которые остаются у компании

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

• Домен. Известны регистратор, учётная запись владельца, контакты для восстановления и ответственный за продление. Доступ к файлам сайта не подменяет управление доменом.
• Размещение. Компания знает, где находится сайт, кто оплачивает услуги и как обратиться в поддержку. Новый исполнитель получил нужные технические права.
• Система управления. Созданы отдельные учётные записи для сотрудников и подрядчика. Проверены восстановление доступа и полномочия каждой роли.
• Внешние сервисы. Названы владельцы аккаунтов аналитики, почты, CRM, доставки и других подключений, которые использует сайт.

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

Как передать аналитику без нового счётчика

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

В справке Яндекс Метрики о доступе разделяются «Только просмотр», «Редактирование» и «Аналитика». При просмотре доступны статистика и настройки, но нельзя управлять целями и доступами. Редактирование даёт широкие возможности, однако не позволяет удалить счётчик или перенести его на другой аккаунт. Поэтому при передаче отдельно устанавливают владельца счётчика и полномочия приглашённого подрядчика.

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

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

Комплект, из которого можно восстановить сайт

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

• Исходные материалы. Переданы код, тема оформления, используемые расширения и собственные доработки с пояснением их назначения.
• Данные. Известно, где хранятся материалы, заявки и настройки. Для передачи выбрана копия, которую принимающая команда умеет восстановить.
• Медиафайлы. Есть изображения, документы и прочие загрузки, на которые ссылаются страницы.
• Инструкция запуска. Описаны необходимые программы и порядок получения рабочей версии. Ручные шаги тоже записаны.
• Лицензии. Указаны платные компоненты, владелец подписки и правила дальнейшего обновления.

Для WordPress официальное руководство по резервированию прямо разделяет файлы и базу данных: для полного восстановления обычного сайта нужны обе части. Выгрузка базы может храниться в формате SQL, в том числе в сжатом виде, а скачивание каталога сайта обычно не забирает базу автоматически. Эти детали стоит уточнить у исполнителя по фактически переданному комплекту. Название архива «полная копия» его состав не объясняет. Копию испытывают отдельно от рабочего сайта. Если при восстановлении пропала часть фотографий или новая команда вручную ищет недостающий плагин, передача ещё продолжается. Выявленные пробелы возвращают прежнему исполнителю конкретным списком, пока он доступен для вопросов.

Незавершённая работа и известные недостатки

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

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

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

Переходный период без двух владельцев выпуска

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

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

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

Что принимающая команда готова показать владельцу

Разговор о завершении передачи полезно начать так: «Какое небольшое изменение вы сможете выпустить самостоятельно и как вернёте прежнюю версию, если оно нарушит форму заявки?» В ответе будут видны пробелы, которые не обнаруживаются при обмене папками и паролями. Начните с показа на копии.

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

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

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