Trust goal: reduce_risk
Почему передача сайта на поддержку — это отдельный проект
Когда компания меняет подрядчика, кажется, что достаточно передать логины, доступ к серверу и список задач. На практике именно на этом этапе чаще всего появляются риски: старый подрядчик знает проект, но не всегда оставил документацию; новый подрядчик видит только внешнюю часть сайта; бизнесу нужно, чтобы формы, каталог, оплата, CRM и почта продолжали работать без остановки.
Поэтому безопасная передача сайта на поддержку — это не формальность, а короткий управляемый проект. Его цель — не сразу переписать всё, а восстановить контроль: понять, где лежит код, как выкатываются изменения, какие интеграции критичны, какие доступы нужны и где есть зоны риска. Только после этого можно спокойно планировать поддержку и доработки.
Кому это актуально
Материал полезен владельцам рабочих сайтов, интернет-магазинов, CRM и веб-сервисов, которые хотят сменить подрядчика или забрать проект после долгой паузы. Особенно если сайт сделан на 1С-Битрикс, OpenCart, Joomla, Yii, Symfony, Laravel, Node.js или самописной CMS, где многое зависит от конкретной реализации.
Передача проекта особенно важна, если:
- текущий подрядчик отвечает нестабильно;
- нет понятного списка доступов;
- изменения вносятся напрямую на боевой сайт;
- неизвестно, где резервные копии;
- формы заявок, оплата или обмен с CRM уже ломались;
- никто не может быстро объяснить, как устроены интеграции.
Если задача уже срочная, можно начать с разовой доработки или диагностики. Если нужен регулярный процесс, лучше смотреть тарифы поддержки и услугу поддержки сайтов.
Что собрать до передачи проекта
Перед стартом новому подрядчику нужны не только логин и пароль от админки. Чем полнее исходные данные, тем меньше времени уйдёт на догадки и тем ниже риск сломать рабочий сценарий.
Минимальный набор:
- доступ к хостингу или серверу;
- доступ к домену, DNS и SSL-сертификатам;
- доступ к CMS, административной панели и базе данных;
- репозиторий Git, если он есть;
- описание боевого и тестового окружения;
- список интеграций: CRM, 1С, доставка, оплата, телефония, почта, аналитика;
- контакты ответственных за инфраструктуру и бизнес-процессы;
- список критичных страниц и сценариев, которые нельзя ломать.
Если чего-то нет, это не повод останавливать работу. Но отсутствие данных нужно зафиксировать: какие доступы ещё ищем, какие зоны считаются неизвестными, где нужны резервные копии и что нельзя менять без дополнительной проверки.
Какие риски закрывает аккуратный приём
Первый риск — потерять заявки во время первых правок. Новый подрядчик может не знать, что конкретная форма отправляет данные сразу в несколько систем: на почту, в CRM, в аналитику, в PM или внутренний обработчик. Внешне форма может работать, но часть данных перестанет доходить.
Второй риск — сломать интеграцию, которая не видна на сайте. Например, обмен заказами, остатками, статусами, оплатой или доставкой. Поэтому при передаче важно не только смотреть страницы, но и проверять цепочки: что происходит после отправки заявки, заказа, оплаты или изменения статуса.
Третий риск — остаться без отката. Если нет Git, резервной копии или тестового контура, каждая правка становится опаснее. Подрядчик должен честно сказать, где можно работать быстро, а где сначала нужен технический порядок.
Четвёртый риск — неправильные ожидания. Клиент ждёт «быстро исправить пару мелочей», а команда сначала просит доступы, проверяет сервер и читает старый код. Это не бюрократия, а способ не превратить небольшую задачу в аварию.
Как это решает OpenStart
OpenStart работает с поддержкой и развитием сайтов с 2009 года. В таких проектах главный навык — не только написать новый код, но и осторожно войти в уже работающую систему: понять ограничения, не потерять бизнес-сценарии и постепенно навести порядок.
Обычно приём проекта строится поэтапно. Сначала фиксируются доступы и точки ответственности. Затем команда смотрит технологический стек, сервер, CMS, Git, резервные копии, формы, интеграции и критичные страницы. После этого задачи делятся на срочные, плановые и технические долги, которые лучше не трогать без отдельного окна.
Для сайтов на 1С-Битрикс стоит отдельно проверить модульность, обмены, кеширование и права пользователей: см. направление Bitrix. Для проектов с API, очередями, личными кабинетами и серверной логикой полезна экспертиза Node.js. Если сайт связан с продажами и обработкой заявок, важен блок CRM и интеграций.
Что запросить у подрядчика
Перед стартом попросите подрядчика описать не только цену и сроки, но и процесс приёма.
- Какие доступы нужны на первом этапе, а какие можно передать позже.
- Как будет проверяться резервная копия.
- Будет ли тестовый контур или другой безопасный способ проверки.
- Где будут ставиться задачи и храниться история решений.
- Как фиксируются аварийные, срочные и плановые задачи.
- Что подрядчик сделает, если проект без документации.
- Какие действия нельзя выполнять без отдельного согласования.
Если ответы расплывчатые, риск остаётся на стороне клиента. Если процесс понятный, передача проекта проходит спокойнее и быстрее.
FAQ
Можно ли передать сайт на поддержку, если старый подрядчик не отвечает?
Да, но нужно начинать с инвентаризации доступов и резервных копий. Иногда достаточно хостинга и домена, иногда приходится восстанавливать контроль по частям.
Нужно ли сразу делать аудит?
Для небольших задач можно начать с короткой диагностики. Для рабочего сайта с интеграциями лучше провести технический аудит хотя бы по критичным сценариям: заявки, заказы, оплата, почта, CRM, резервные копии.
Можно ли работать без Git?
Можно, но это повышает риск. Хороший первый шаг — зафиксировать текущую версию проекта и настроить понятный способ контроля изменений.
Что делать, если часть доступов нельзя передать сразу?
Нужно явно зафиксировать ограничения. Подрядчик должен понимать, какие зоны он может проверять, а где выводы будут предварительными.
Для редактора
Клиентские имена, внутренние задачи, домены, неподтверждённые цифры, награды и отзывы не использовались. Перед публикацией стоит проверить, что ссылки на `/support`, `/improvement`, `/services/podderzhka-saitov`, `/services/bitrix`, `/services/nodejs`, `/services/crm` актуальны.
Связанные маркетинговые задачи
- Название: подготовить чек-лист передачи сайта на поддержку; stream: sales_materials; priority: high; next_action: оформить список доступов и проверок для КП.
- Название: добавить на страницу поддержки блок «Как принимаем проект»; stream: website_trust; priority: high; next_action: сверить с текущей структурой `/support` и не дублировать SLA.
- Название: выбрать 3 проекта для анонимизированных кейсов по приёму после другого подрядчика; stream: cases; priority: medium; next_action: согласовать, какие детали можно раскрывать.
- Название: подготовить шаблон письма клиенту для запроса доступов; stream: sales_materials; priority: medium; next_action: написать нейтральный текст без технического перегруза.