Смена подрядчика на Битрикс-проекте: чек-лист для CTO, чтобы не потерять полгода и миллионы

По нашей статистике, около 40% проектов на 1С-Битрикс меняют подрядчика в первые два года после запуска. Причины разные: студия закрылась, ключевой разработчик ушёл, качество работы упало, цены выросли. Но результат один — вам нужно передать проект новой команде, и сделать это так, чтобы бизнес не встал.

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

В этой статье мы предложим конкретный алгоритм, как провести передачу проекта с минимальными потерями. Вы получите систему оценки состояния проекта, методику расчёта реальной стоимости перехода и готовый чек-лист из 25 пунктов для приёмки. Материал будет полезен CTO и CEO, которые уже меняют подрядчика или планируют это сделать в ближайшее время.

Почему это больно: типичные сценарии

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

Кейс: как 2 недели превратились в 4 месяца

Компания N — интернет-магазин бытовой электроники с оборотом 200+ млн рублей в год. Сайт на Битрикс, интеграция с 1С:Управление торговлей, около 50 000 SKU. Предыдущий подрядчик — небольшая студия из трёх человек — работал с проектом 4 года.

В какой-то момент студия сообщила, что закрывается. Дали месяц на передачу дел. Казалось бы, достаточно — ведь всё должно быть задокументировано за 4 года?

Реальность оказалась другой:

• Документации не было вообще. Ни схемы архитектуры, ни описания бизнес-логики, ни даже списка кастомных доработок.
• Комментариев в коде — ноль. 200+ файлов кастомных компонентов без единого пояснения, зачем они нужны.
• Интеграция с 1С — на костылях. Стандартный обмен «доработан» на стороне Битрикс на 70%, логика разбросана по 15 файлам, часть — в обработчиках событий, часть — в агентах, часть — в кронах.
• Доступы — у разработчика на ноутбуке. Root-пароль от сервера знал только один человек, и он уже нашёл новую работу.

Результат: новая команда потратила 4 месяца только на то, чтобы разобраться в проекте и стабилизировать его. Бюджет на «передачу» вырос в 3 раза от первоначальной оценки. Два критичных бага в интеграции с 1С «стреляли» ещё полгода.

Красные флаги при приёмке проекта

Если вы видите хотя бы 3 пункта из этого списка — готовьтесь к сложной передаче:

• Код не в Git (или в Git, но без осмысленной истории коммитов)
• Нет тестового сервера — все изменения катятся сразу на прод
• Деплой через FTP вручную
• Бэкапы «делает хостинг» (а вы ни разу не проверяли)
• Пароли хранятся «в голове» или, ещё хуже, в чате
• Предыдущий подрядчик не может объяснить, как работает интеграция с внешней системой (например, 1С)
• На вопрос «где документация?» отвечают «код — лучшая документация»
• Обновления Битрикса не ставились больше года
• В папке /local/ — хаос из десятков файлов без структуры

Система оценки проекта: 5 уровней зрелости

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

Таблица уровней зрелости

Риск-множитель — это коэффициент, на который нужно умножить базовую оценку трудозатрат. Если вы оцениваете задачу в 100 часов, а проект на уровне 2, реально уйдёт 250–300 часов.

Как определить уровень за 1 день: экспресс-аудит

Вот чек-лист из 15 пунктов. Каждый «да» — это 1 балл. Посчитайте сумму и определите уровень.

Инфраструктура (5 пунктов):

1. Все доступы (хостинг, домены, сервисы) задокументированы и переданы
2. Есть Git-репозиторий с историей коммитов за последний год
3. Существует тестовый сервер (dev или stage)
4. Бэкапы настроены и проверены (вы восстанавливали хотя бы раз)
5. Есть мониторинг (хотя бы uptime и базовые метрики)

Код и архитектура (5 пунктов):

1. Структура /local/ соответствует стандартам Битрикс ( https://docs.1c-bitrix.ru/ )
2. Кастомные компоненты имеют понятные названия и лежат в правильных папках
3. Нет хардкода паролей и ключей в коде
4. Composer/npm используются для управления зависимостями
5. Обновления ядра Битрикс ставились в последние 6 месяцев

Документация и процессы (5 пунктов):

1. Есть описание архитектуры (хотя бы схема)
2. Задокументирована бизнес-логика нетривиальных модулей
3. Есть инструкция по деплою
4. Ведётся трекер задач с историей
5. Проводятся код-ревью (хотя бы для критичных изменений)

Интерпретация результатов:

• 0–3 балла → Уровень 1 (Хаос)
• 4–6 баллов → Уровень 2 (Базовый)
• 7–10 баллов → Уровень 3 (Управляемый)
• 11–13 баллов → Уровень 4 (Зрелый)
• 14–15 баллов → Уровень 5 (Передаваемый)

Из практики: 80% проектов, которые к нам приходят на поддержку — это уровни 1–2. Уровень 4–5 встречается только у компаний с собственной in-house командой или у тех, кто изначально выстраивал процессы.

Методика расчёта стоимости перехода

Теперь переведём всё в деньги. Вот формула, которую мы используем:

Стоимость перехода = (Базовая оценка × Риск-множитель) + Скрытые затраты

Компоненты базовой оценки

1. Технический аудит — 40–80 часов

• Анализ кодовой базы
• Проверка безопасности
• Оценка технического долга
• Документирование текущего состояния

2. Восстановление/создание документации — 20–100 часов

• Схема архитектуры
• Описание интеграций
• Бизнес-логика кастомных модулей
• Инструкции по деплою и обслуживанию

3. Настройка инфраструктуры — 16–40 часов

• Развёртывание dev/stage-окружения
• Настройка CI/CD
• Перенос репозитория и настройка процессов
• Настройка мониторинга и алертов

4. Онбординг команды — 40–80 часов на разработчика

• Изучение проекта
• Разбор кастомных решений
• Погружение в бизнес-логику
• Первые задачи под присмотром

Скрытые затраты (о которых часто забывают)

Простой бизнеса во время передачи В переходный период скорость разработки падает в 2–3 раза. Новые фичи откладываются, баги фиксятся медленнее. Если ваш бизнес зависит от скорости изменений — закладывайте это в расчёт.

Юридические расходы

• Права на код: кому принадлежит то, что написал подрядчик?
• NDA и передача данных
• Расторжение договора с предыдущим подрядчиком

Потеря данных и конфигураций Если доступы не были переданы корректно — часть данных может быть утеряна. Восстановление конфигураций внешних сервисов (платёжки, доставка, CRM) может занять недели.

Технический долг, который вскроется позже После передачи обязательно всплывут проблемы, которые не были видны на этапе аудита. Закладывайте буфер 20–30% на неожиданности.

Важно: Это стоимость именно передачи проекта, а не его поддержки. Дальнейшая поддержка будет оцениваться отдельно, но если передача проведена качественно — стоимость поддержки будет ниже на 30–50%.

Чек-лист приёмки проекта: 25 пунктов

Этот чек-лист можно использовать как акт приёма-передачи. Пройдитесь по каждому пункту вместе с предыдущим подрядчиком и зафиксируйте статус.

Блок A: Доступы и инфраструктура

1. Хостинг/сервер — root-доступ, панель управления

2. Домены — доступ к регистратору, DNS-записи

3. SSL-сертификаты — где выпущены, когда истекают

4. Почтовые сервисы — SMTP, транзакционные письма

5. CDN — доступ и настройки (если используется)

6. Внешние API — платёжные системы, доставка, CRM

7. Мониторинг — доступы к сервисам мониторинга

8. Бэкапы — где хранятся, как восстанавливать

Блок B: Кодовая база

9. Git-репозиторий — полная история коммитов

10. Ветки — структура веток (prod, dev, feature)

11. Лицензия Битрикс — ключ, срок действия, на кого оформлена

12. Сторонние модули — лицензии, исходники, контакты разработчиков

13. Composer/npm — зависимости актуальны, lock-файлы в репозитория

14. Кастомные компоненты — список с кратким описанием

15. Интеграции — 1С, CRM, ERP: схема обмена, расписание, логи

Блок C: Документация

16. Архитектура — схема компонентов и их взаимосвязей

17. Бизнес-логика — описание нетривиальных модулей

18. Инструкция по деплою — шаги для выкатки изменений

19. Известные проблемы — workarounds, костыли, технический долг

20. Контакты — ключевые люди (разработчики, менеджеры, заказчики)

Блок D: Данные и безопасность

21. Бэкап БД — актуальный дамп базы данных

22. Выгрузка контента — медиафайлы, документы

23. Логи — логи за последние 3–6 месяцев

24. Аудит безопасности — результаты последнего сканирования

25. Смена паролей — все пароли изменены после передачи

Из практики: Пункт 25 критически важен. Мы видели случаи, когда бывший подрядчик (или его уволенный сотрудник) заходил на сервер спустя месяцы после передачи. Меняйте ВСЕ пароли: сервер, база данных, админка Битрикс, FTP, панель хостинга, внешние сервисы.

Переходный период: как не уронить прод

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

Параллельная работа двух команд

Оптимальный вариант — 2–4 недели параллельной работы. Старая команда ещё доступна для вопросов, новая уже погружается в проект.

Как это организовать:

• Выделите конкретные часы для созвонов (например, ежедневный стендап в 11:00)
• Фиксируйте все ответы в письменном виде (Telegram, Битрикс24)
• Новая команда ведёт «дневник» — записывает всё неочевидное, что узнаёт
• Старая команда не берёт новых задач, только отвечает на вопросы и фиксит критичные баги

Заморозка крупных изменений

На время передачи (и ещё 2–4 недели после) — никаких больших релизов. Только:

• Критичные баги, влияющие на продажи
• Баги безопасности
• Мелкие правки контента

Всё остальное — в бэклог. Это болезненно для бизнеса, но попытка делать крупные изменения на незнакомом проекте заканчивается ещё большими проблемами.

Приоритеты переходного периода

1. Первые 2 недели: стабилизация. Понять, как всё работает, не сломать ничего критичного.
2. Недели 3–4: поддержка. Начать закрывать текущие баги и мелкие задачи.
3. Недели 5–8: нормализация. Выйти на плановую скорость разработки.
4. Месяц 3+: развитие. Начать закрывать технический долг и делать улучшения.

Эскалационная матрица

Договоритесь заранее, что делать в критических ситуациях:

KPI для новой команды на первые 90 дней

Не требуйте сразу подвигов. Разумные KPI для переходного периода:

Месяц 1:

• Все критичные баги закрываются в течение 24 часов
• Uptime не ниже 99%
• Документация текущего состояния готова

Месяц 2:

• Время реакции на задачи — не более 4 часов
• Закрыто 80% бэклога багов
• Dev-окружение полностью настроено

Месяц 3:

• Скорость разработки — 70–80% от плановой
• Первые улучшения инфраструктуры (CI/CD, мониторинг)
• План по закрытию технического долга

Заключение

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

• Сократить время адаптации с месяцев до недель
• Снизить риски потери данных и простоя
• Сэкономить бюджет за счёт точной оценки вместо «примерно»

Главное правило: инвестиция в качественную передачу окупается в 3–5 раз на последующей поддержке. Проекты, принятые «на скорую руку», потом годами тянут за собой проблемы и перерасход бюджета.

Если вы сейчас в процессе смены подрядчика или планируете это сделать — используйте чек-лист и методику из этой статьи. А если нужна помощь с аудитом или приёмкой проекта — мы проведём экспресс-оценку за 1–2 дня и дадим честную картину того, с чем вы имеете дело.