Кто ответит, если сайт упал после обновления? 5 пунктов, которые должны быть в договоре с разработчиком

Представьте обычный рабочий день. Утром менеджер открывает интернет-магазин — а сайт не работает. Клиенты не могут оформить заказ. Заявки не приходят. CRM молчит. Вчера разработчик обновлял сайт.

Первый вопрос бизнеса обычно звучит так: «Кто это будет исправлять и сколько времени мы будем терять деньги?»

И вот здесь становится понятно, насколько профессионально выстроена работа с разработчиком. Потому что хороший подрядчик — это не тот, кто просто умеет установить обновление или написать код. Это команда, которая заранее понимает риски, умеет их контролировать и знает, что делать, если проблема всё-таки возникла.

Особенно это важно для сайтов на 1С-Битрикс, где один проект может объединять десятки компонентов, модулей и внешних интеграций.

Современный сайт — это не одна программа. Внутри могут одновременно работать:

• каталог товаров;
• корзина и оформление заказа;
• личный кабинет;
• интеграция с CRM;
• онлайн-оплата;
• службы доставки;
• складской учёт;
• обмен с 1С;
• аналитика;
• сторонние модули;
• собственные доработки компании.

Поэтому изменение одного элемента иногда затрагивает другие. Например, обновили компонент каталога — и неожиданно перестал корректно работать фильтр. Обновили модуль — возникла проблема с оформлением заказа. Изменили интеграцию — заявки перестали передаваться в CRM.

Именно поэтому профессиональная разработка — это не просто «обновить и посмотреть, что получится».

Главная задача — не героически спасать сайт после аварии, а снизить вероятность самой аварии. Перед серьёзными изменениями разработчик должен понимать:

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

Проверяются связанные компоненты, интеграции и нестандартные доработки.

Для важных изменений должен быть понятный сценарий восстановления.

После работ необходимо протестировать ключевые пользовательские сценарии. Для интернет-магазина это может быть:

товар → корзина → оформление → оплата → создание заказа → передача заказа в CRM.

Если разработчик проверил только главную страницу и сказал «всё работает», это ещё не полноценное тестирование.

В разработке невозможно гарантировать, что сложный проект никогда не столкнётся с ошибкой. Поэтому второй важный вопрос: «Что произойдёт, если проблема всё-таки возникнет?»

Именно здесь хороший подрядчик отличается от разработчика, который просто «закрывает задачу». У клиента должен быть понятный процесс:

1. Обнаружили проблему. Клиент сообщает об ошибке удобным способом.

2. Определили приоритет. Не каждая ошибка одинаково критична. Если не работает баннер — это одна ситуация. Если невозможно оформить заказ — совсем другая.

3. Определили срок реакции. Клиент понимает, когда команда приступит к проблеме.

4. Провели диагностику. Разработчик определяет причину, а не просто пытается исправить симптом.

5. Восстановили работоспособность. После исправления проверяются связанные функции.

Это и есть нормальный процесс технической поддержки.

Это важный момент, который часто неправильно понимают. Допустим, в договоре с разработчиком указано: «Реакция на критическую ошибку — до 2 часов». Это означает, что команда должна принять обращение и начать работу в установленный срок.

Но это не обязательно означает, что через два часа сайт уже будет работать.

Поэтому профессиональный договор и регламент поддержки должны разделять:

• время реакции;
• время диагностики;
• время восстановления;
• порядок информирования клиента.

Для бизнеса это гораздо полезнее абстрактного обещания «быстро всё исправим».

Здесь тоже всё должно быть прозрачно. Если команда внесла изменения, важно понимать:

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

Именно поэтому мы считаем нормальной практикой фиксировать работы и изменения, а не ограничиваться сообщением в мессенджере: «Всё обновили, проверяйте». Через полгода такая переписка уже мало чем поможет.

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

У небольшого сайта может быть относительно простая архитектура. Но корпоративный портал или интернет-магазин на Bitrix часто представляет собой целую систему. В ней связаны:

Bitrix → модули → собственные компоненты → CRM → 1С → платежи → доставка → аналитика → сервер.

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

Есть простой способ понять подход подрядчика. Задайте ему пять вопросов:

1. Что вы делаете перед обновлением сайта?
2. Как проверяете, что после изменений всё работает?
3. Что произойдёт, если после ваших работ возникнет ошибка?
4. Какой срок реакции на критическую проблему?
5. Как фиксируются изменения и история работ?

Не обязательно ждать длинной юридической формулировки. Хороший разработчик должен суметь простыми словами объяснить весь процесс. Если на эти вопросы есть понятные ответы — уже понятно, что речь идёт не просто о «человеке, который умеет Bitrix», а о системной работе с проектом.

Самая правильная задача договора с разработчиком — не создать конфликт между заказчиком и подрядчиком. Наоборот. Хороший договор фиксирует понятные правила сотрудничества:

что делаем → как делаем → как проверяем → что происходит при проблеме → кто и в какие сроки реагирует.

Это удобно обеим сторонам. Клиент понимает, за что платит и чего может ожидать. Разработчик понимает зону своей ответственности и порядок работы. А в случае проблемы не приходится начинать выяснение отношений с вопроса: «А кто вообще должен это исправлять?»

Надёжность сайта — это не только сервер, код и обновления. Это ещё и процесс, по которому команда работает с проектом.

Поэтому при выборе разработчика стоит смотреть не только на стоимость часа и количество сайтов в портфолио. Спросите, как компания:

• планирует изменения;
• тестирует обновления;
• документирует работы;
• реагирует на критические ошибки;
• сопровождает сайт после запуска;
• отвечает за результат своей работы.

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

Мы можем посмотреть, как сейчас организована работа с вашим сайтом на Bitrix, и бесплатно указать на потенциально слабые места: в процессе обновлений, резервном копировании, тестировании, регламенте поддержки и документации.