Самая частая фраза, после которой меня зовут в проект:
«У нас всё завязано на одном разработчике… и он пропал / устал / взял больше денег / ничего не успевает».
Код только у него.
Доступы только у него.
«Как это устроено» — тоже только у него в голове.
Вы по факту не владелец проекта, вы арендатор у одного человека.
И пока всё работает — вроде терпимо.
Пока не наступает момент, когда надо:
- резко доработать сайт под маркетинг,
- починить упавший магазин,
- переехать на новый сервер,
- или просто перестать переплачивать за вечный аврал.
Тут и всплывает страшное:
«А мы вообще можем передать этот Битрикс кому-то ещё, не убив всё?»
Можем. Но не одним письмом «вот доступы, разберёшься?».
Сейчас разложу, как по-человечески выходить из заложников у одного разработчика.
1. Признать вслух: да, сейчас проект в заложниках
Первый честный шаг — перестать делать вид, что всё нормально.
Вот признаки, что вы в заложниках:
- Любая правка = «пишите только ему, другие не разберутся».
- Никто не понимает, как устроен код и инфраструктура.
- Документации ноль: ни по интеграциям, ни по структуре каталога.
- При слове «сменить подрядчика» все дружно говорят: «Лучше не трогать, всё сломается».
Это не «особенность Битрикс».
Это просто отсутствие управления проектом.
Пока вы это оправдываете — вы остаётесь зависимым.
2. Нельзя просто взять и «сбросить» старого разработчика
Самая плохая стратегия:
- Обидеться.
- Отключить доступы.
- Бросить новый подрядчик фразу: «Вот сайт, почини».
Чем это заканчивается:
- новый разработчик тратит кучу времени, чтобы вообще понять, где он оказался;
- старый обижается и, если был единственным, уносит с собой всё: от ssh-ключей до понимания логики обмена с 1С;
- вы живёте между двумя огнями и всё равно ничего не контролируете.
Правильнее — организованный выход, даже если вы уже внутренне кипите.
3. Шаг 1. Собрать и зафиксировать всё, что у вас есть
Прежде чем кого-то менять, нужно собрать проект в одну корзину.
Я всегда начинаю с инвентаризации:
1) Доступы
- домен;
- хостинг/сервер (панель, ssh, ftp, sftp);
- репозиторий (если он вообще есть);
- админка сайта (учётки, права);
- 1С / CRM / платежи / SMS-шлюзы / телефония.
Фиксируем кто к чему имеет доступ сейчас. Спрашиваем у старого разработчика, вытаскиваем из переписок, письма от хостера — всё.
2) Исходники
- где лежит актуальная версия кода (реально актуальная, а не «архив двухлетней давности»);
- есть ли репозиторий (Git/Bitbucket/Gitlab) и что там по веткам;
- есть ли бэкапы файлов и базы.
3) Интеграции
- с чем Битрикс связан: 1С, CRM, службы доставки, платёжки;
- что работает в одну сторону, что в обе;
- где крутятся задачи по обмену (крон, агенты, сторонние скрипты).
Задача — перестать жить в режиме «кажется, у нас всё где-то есть».
4. Шаг 2. Попросить с разработчика не «обиды», а знания
Даже если вы расстаётесь, задача владельца бизнеса — вытащить максимум информации, пока человек на связи.
Я обычно рекомендую официально попросить:
- минимальную документацию по проекту:
- как устроен каталог и инфоблоки;
- какие кастомные модули/компоненты есть;
- где правилось ядро (если вдруг);
- как устроены интеграции (схемы обмена, точки входа);
- карту деплоя:
- как изменения попадают на прод;
- есть ли тестовый стенд;
- кто что выкатывает.
Не надо писать «ты всё сделал плохо».
Надо написать:
«Смотри, нам нужно передать проект так, чтобы никого не похоронить. Давай за это нормально заплатим, но сделаем по-взрослому».
Часто разработчик сам рад избавиться от роли «единственного заложника», если с ним говорить как с партнёром, а не как с врагом.
5. Шаг 3. Забрать управление доступами обратно себе
Пока доступы оформлены «на разработчика», вы не владелец проекта.
Что нужно:
- перевести домен, хостинг, внешние сервисы на ваши аккаунты (юридическое лицо/ваш e-mail, а не почта программиста);
- создать общий корпоративный доступ (например, it@вашдомен.ru), на который завязаны регистрация и восстановление паролей;
- старому разработчику выдавать уже гостевые доступы от вашего аккаунта, а не наоборот.
После этого:
- вы можете при необходимости отключить конкретного человека, не руша всю инфраструктуру;
- новый подрядчик будет подключаться к сервисам через вас, а не забирать ресурсы себе.
6. Шаг 4. Поднять тестовый стенд и выровнять окружение
Перед тем как отдавать проект новым людям, я почти всегда:
- поднимаю тестовую копию сайта (если её нет);
- проверяю, что стенд максимально близок к бою по версиям PHP, Битрикс, модулям;
- настраиваю отдельные доступы к стенду для будущих подрядчиков.
Это позволяет:
- новому разработчику безопасно ковыряться и изучать код;
- старому аккуратно показать, «где что»;
- вам — видеть прогресс без страха «сломают прод».
7. Шаг 5. Найти нового подрядчика — не «кто дешевле», а кто протянет проект дальше
Вот здесь многие делают классическую ошибку:
после дорогого, но единственного разработчика берут самого дешёвого из первых попавшихся.
Результат предсказуем:
через полгода вы сидите в тех же заложниках, только уже у другого человека и с ещё более изнасилованным кодом.
Я бы смотрел на:
- реальный опыт человека/команды именно по 1С-Битрикс;
- готовность объяснять и показывать, а не просто «сделаем — не лезьте»;
- наличие процессов: Git, стенд, бэкапы, релизы.
И сразу проговаривать:
- кто за что отвечает;
- как вы будете планировать задачи;
- как часто показываются результаты;
- что считается успехом в ближайшие 1–3 месяца.
8. Шаг 6. Организовать «переезд с руками», а не «кинул архив и исчез»
Идеальный сценарий:
1. Старый разработчик ещё в процессе:
- отвечает на вопросы нового;
- помогает развернуть проект;
- передаёт нюансы по интеграциям.
2. Новый разработчик:
- поднимает проект у себя на стенде;
- описывает, что видит: проблемы, риски, костыли;
- формирует вместе с вами план «что делаем в первую очередь».
3. Вы:
- контролируете сроки и зоны ответственности;
- не запускаете новую разработку на проде, пока новый человек не разобрался хотя бы в базовых узлах.
Да, это какое-то время двойная оплата.
Но это дешевле, чем потом спасать рухнувший сайт, потому что вы сначала выгнали старого, а потом полгода искали нового.
9. Шаг 7. Встроить защиту от повторного «захвата проекта»
После успешной передачи важно не повторить ту же ошибку.
Минимальная страховка:
- Git-репозиторий проекта, доступный вам (организация, а не личный аккаунт разработчика);
- регулярные бэкапы файлов и базы, которые вы знаете, где лежат и как восстанавливать;
- документация хотя бы на уровне:
- структура инфоблоков;
- схема интеграций;
- базовые инструкции для контента и админки.
И главное — никаких “всё держится на одном человеке”:
- у подрядчика должна быть команда или хотя бы ещё один человек, который в теме;
- у вас внутри должен быть хотя бы один человек, который понимает, что где находится и кого дёргать.
Выход из заложников у одного разработчика — это не про «сменить плохого на хорошего».
Это про то, чтобы снова стать владельцем своего Битрикс-проекта, а не гостем на собственной инфраструктуре.
Как только у вас в руках доступы, исходники, документация и понятный процесс — любой подрядчик становится заменяемым. А это уже совсем другой уровень спокойствия для бизнеса.