Содержание
Когда уходит разработчик или вся команда разработки, система не ломается в день увольнения. Она ломается позже: при первом серьёзном сбое, обновлении или окончании сертификата, когда рядом уже нет людей, которые знают, как всё устроено. Поэтому главное, что можно сделать, это использовать оставшиеся недели: перевести все доступы на компанию, записать знания о системе и передать её новым людям, пока старые ещё на связи.
Почему уход команды опасен, даже если всё работает
В разработке есть понятие «фактор автобуса» (bus factor): сколько человек должно внезапно исчезнуть, чтобы проект встал. В небольших компаниях он часто равен единице. Один программист знает, где лежат бэкапы, как перезапустить зависшую выгрузку и почему в коде стоит странная проверка, без которой падает оплата.
Пока этот человек на месте, всё выглядит надёжно. После ухода это проявляется постепенно: система встречает ситуации, которые раньше решались «по памяти», и каждый раз решать их некому.
- Первые недели. Сайт работает, обращения закрываются по инструкции.
- Первый нестандартный сбой. Никто не знает, с какой стороны к нему подойти. Простой длится часы вместо минут.
- Истекают сроки. SSL-сертификат, домен, оплата сервера с личной карты ушедшего сотрудника.
- Первое обновление. Обновили PHP, библиотеку или интеграцию с внешним сервисом, и сломалось то, о чём никто не знал.
Сколько времени есть на передачу
По Трудовому кодексу сотрудник предупреждает об увольнении не позднее чем за две недели (статья 80 ТК РФ). Для передачи системы это очень мало, поэтому начинайте её в тот же день, когда узнали об уходе.
Если команду сокращают по решению компании, сроки в ваших руках: при сокращении штата сотрудников предупреждают минимум за два месяца (статья 180 ТК РФ). Этого обычно хватает, если начать передачу сразу. Для небольшого сайта нужно две-три недели, для платформы из нескольких сервисов от месяца, и часть этого времени старая и новая команды должны работать вместе.
Что забрать до ухода: доступы
Записать пароли в таблицу недостаточно. Каждый доступ нужно перевести на компанию, чтобы после ухода он не зависел от личного аккаунта сотрудника.
- Домен. Проверьте, кто указан администратором. По данным ComNews, 72,7% доменов .ru оформлены на физических лиц, и среди них много записанных на сотрудников. С 1 сентября 2026 года администраторы проходят идентификацию через Госуслуги. Если домен записан на ушедшего сотрудника и он её не пройдёт, при продлении домен можно потерять.
- Хостинг и облако. Аккаунт на компании, оплата с карты компании, у руководителя есть вход.
- Репозиторий с кодом. Организация на GitHub или GitLab принадлежит компании, сотрудники только участники.
- Аккаунты разработчика в магазинах приложений, если есть мобильное приложение.
- Ключи API и токены. Платёжные системы, карты, SMS, почтовые сервисы. Ключи, выпущенные на личные аккаунты, нужно перевыпустить.
- Почта и мониторинг. Уведомления о сбоях, письма от хостинга и регистратора должны приходить на общий адрес компании.
Подробный чек-лист доступов и документов есть в статье «Работа с легаси-кодом: как передать проект новой команде».
Что забрать до ухода: знания
Доступы можно восстановить и через месяц. Знания, которые ушли вместе с людьми, восстанавливаются из кода и логов, долго и дорого.
- Карта системы. Из каких частей состоит, где работает, как части связаны между собой и с внешними сервисами.
- Как развернуть и выпустить релиз. Пошагово, так, чтобы человек со стороны мог повторить.
- Что запускается по расписанию. Выгрузки, рассылки, бэкапы, синхронизации, и что будет, если какая-то из них не сработает.
- Известные проблемы и обходные пути. Тот самый список «если упало вот это, сделай вот так», который обычно живёт только в голове.
- Сессии по системе с записью. Час-два на каждую крупную часть. Уходящий разработчик показывает код и рассказывает, почему сделано именно так. Записи остаются у компании.
- Разбор последних инцидентов. Что ломалось за полгода, как чинили, что осталось недоделанным.
Кому отдать систему: нанять замену или внешнюю команду
Вариантов три, и у каждого свои риски. Выбор зависит от того, насколько система важна для денег бизнеса и как часто в ней что-то меняется.
| Критерий | Нанять в штат | Фрилансер | Внешняя команда по SLA |
|---|---|---|---|
| Скорость старта | Поиск и адаптация занимают месяцы | Быстро, если нашёлся подходящий | Быстро, после разбора системы |
| Зависимость от одного человека | Остаётся | Высокая | Нет, систему знает команда |
| Кто отвечает ночью и в выходные | Как договоритесь | Обычно никто | Сроки реакции в договоре |
| Подходит, когда | Много постоянной разработки | Редкие мелкие задачи | Система приносит деньги каждый день |
Часто работает комбинация: внешняя команда держит систему и отвечает за сбои по SLA, а когда в компании появится постоянный поток задач, вы нанимаете своего разработчика и передаёте ему развитие. Поддержка при этом может остаться снаружи, как страховка.
Если команда уже ушла
Если передать систему не успели, порядок другой. Сначала соберите все доступы и сделайте полную копию сайта и базы, затем проверьте сроки домена, сертификатов и платежей. После этого систему нужно разобрать заново: понять, из чего она состоит, что в ней уже сломано и что сломается следующим. Этот сценарий похож на пропажу подрядчика, его мы разобрали в статье «Разработчик пропал: как забрать сайт, код и доступы».
Когда звать внешнюю команду
Внешняя команда нужна, когда систему должны держать люди, которые не уйдут вместе с одним сотрудником. Это ситуация, когда разработку сокращают или выводят на аутсорс, а сайт или платформа продолжают приносить деньги каждый день.
Мы начинаем с аудита: разбираем код, данные, инфраструктуру и нагрузку, а уходящая команда в это время ещё может ответить на вопросы. Для ориентира: у клиента под NDA, международной платформы взаиморасчётов, мы разобрали 8 систем за 3 недели. Дальше систему можно взять на поддержку по SLA: сроки реакции записаны в договоре, а один состав ведёт проект от разбора до сопровождения, без передачи между людьми.
Частые вопросы
Уволился единственный программист. С чего начать?
С доступов и копии. Проверьте, что домен, хостинг, репозиторий и платные сервисы оформлены на компанию и у вас есть вход, сделайте полную копию сайта и базы. Затем ищите, кто разберёт систему: без этого первый серьёзный сбой затянется надолго.
Сколько времени нужно на передачу системы?
Для небольшого сайта хватает двух-трёх недель с участием уходящего разработчика. Для платформы из нескольких сервисов закладывайте от месяца, включая период, когда старая и новая команды работают параллельно.
Хватит ли документации, если разработчик её напишет?
Документация нужна, но одной её мало. Самое ценное знание это почему система устроена именно так и что делать в нестандартных ситуациях. Его передают живыми сессиями с записью, разбором инцидентов и работой в паре.
Что выгоднее: нанять нового разработчика или отдать поддержку на аутсорс?
Если задач на разработку много и они постоянные, нужен свой человек. Если система важна для выручки, а изменений немного, надёжнее внешняя команда по SLA: она не зависит от одного сотрудника и отвечает за сбои по договору.
Можно ли передать систему внешней команде, если своя ещё работает?
Да, и это лучший вариант. Новая команда разбирает систему, пока старая отвечает на вопросы, а переключение происходит, когда новые люди уже сами выпускают релизы и чинят сбои.
