Чем поддержка сайта отличается от доработки?
Чтобы различать форматы работ, полезно помнить:
-
поддержка отвечает за устойчивую работу существующих функций;
-
доработка меняет уже работающую функцию по новым правилам;
-
развитие создаёт новый пользовательский или бизнес-сценарий;
-
аудит показывает риски, ограничения и порядок дальнейших работ;
-
обновление может быть задачей поддержки, но адаптация индивидуального кода после него иногда становится доработкой.
Частая ситуация: компания просит «быстро добавить поле в заказ». Если поле нужно только вывести на странице, это локальная доработка. Если оно должно поступать из 1С, сохраняться в заказе, передаваться в CRM и учитываться в личном кабинете, задача меняет несколько связанных сценариев. Тогда её нельзя оценивать как простое изменение одного экрана.
В Ameton сначала уточняют, что именно должно измениться для бизнеса и какая существующая функция будет затронута. Такой разбор помогает не выдавать развитие сайта за «обычную поддержку» и не выпускать критичные исправления в общем потоке доработок.
Что такое поддержка сайта и доработка
Поддержка сайта — это регулярная работа над стабильностью, безопасностью и управляемостью уже существующего решения. Доработка — это изменение конкретной функции сайта, чтобы она работала по новым правилам или закрывала новую потребность бизнеса.
|
Вид работ |
Основная цель |
Пример задачи |
Результат |
|
Техническая поддержка |
Сохранить работоспособность и снизить риски |
Восстановить форму заявки, проверить обновление, устранить ошибку обмена |
Критичный сценарий снова работает корректно |
|
Доработка |
Изменить существующую функцию |
Добавить новый статус заказа или изменить правило расчёта доставки |
Функция работает по новым требованиям |
|
Развитие |
Поддержать новый бизнес-процесс |
Запустить кабинет дилера с персональными ценами |
Сайт решает новую задачу компании |
|
Аудит |
Понять состояние проекта и его ограничения |
Проверить код, сервер, интеграции и накопленные ошибки |
Есть реестр рисков и план дальнейших действий |
Поддержка не означает только реакцию на поломки. Она нужна, чтобы сайт оставался понятным для изменений: у команды есть контекст проекта, приоритеты задач, правила выпуска и информация о критичных сценариях.
Что входит в техническую поддержку сайта
Техническая поддержка объединяет эксплуатацию сайта и контроль изменений, которые могут повлиять на его ключевые функции.
|
Направление |
Что делает команда |
Какой риск снижает |
|
Стабильность |
Диагностирует ошибки в формах, авторизации, заказе, оплате и других важных сценариях |
Простои, потеря заявок и заказов |
|
Обновления |
Проверяет совместимость платформы, модулей и индивидуальных компонентов |
Ошибки после изменения зависимостей |
|
Резервное копирование |
Контролирует создание, хранение и проверку восстановления копий |
Потеря данных и невозможность быстро восстановить сайт |
|
Безопасность |
Управляет доступами, проверяет права, журналы событий и индивидуальный код |
Несанкционированный доступ и инциденты |
|
Интеграции |
Контролирует обмен с 1С, CRM, оплатой, доставкой и другими сервисами |
Неверные цены, остатки, статусы и дубли |
|
Развитие |
Оценивает и выпускает согласованные доработки |
Накопление случайных и конфликтующих изменений |
Подробный состав регулярных работ зависит от роли сайта. Для корпоративного сайта критичны формы и публикации, для интернет-магазина — заказ, оплата, цены и остатки, а для B2B-портала — авторизация, роли, документы и персональные условия. Подробнее о составе работ можно прочитать в статье «Что входит в техническую поддержку сайта на 1С-Битрикс».
Когда задача поддержки превращается в доработку
Задача перестаёт быть поддержкой, когда для её решения нужно изменить бизнес-логику, интерфейс или состав данных, а не восстановить прежнюю работу сайта.
|
Запрос |
Что это чаще всего |
Почему |
|
После обновления перестала отправляться форма |
Поддержка |
Нужно вернуть прежний рабочий сценарий |
|
Добавить в форму новый обязательный параметр |
Доработка |
Меняются данные, которые собирает и обрабатывает сайт |
|
Восстановить обмен товарами после сбоя |
Поддержка |
Команда возвращает существующий процесс передачи данных |
|
Передавать в 1С новый тип цены |
Доработка |
Меняется состав и правило обмена |
|
Исправить ошибку отображения статуса заказа |
Поддержка |
Задача возвращает корректный результат существующей функции |
|
Добавить согласование заказа между ролями |
Развитие |
На сайте появляется новый процесс работы пользователей |
Пример из практики: заказчик обратился с просьбой исправить отображение скидки в личном кабинете. При проверке выяснилось, что проблема возникла не в интерфейсе, а в изменившемся правиле передачи цен из учётной системы. Временное исправление отображения не устранило бы причину. Команда сначала восстановила корректный обмен, а изменение правил расчёта и показа скидок оформила отдельной доработкой.
Главный критерий простой: поддержка возвращает согласованный результат, а доработка меняет сам согласованный результат.
Как связаны поддержка, доработка, развитие и аудит
Поддержка, доработка, развитие и аудит образуют единый процесс управления сайтом, но отвечают за разные этапы его жизненного цикла.
Сайт на 1С-Битрикс обычно связан с интеграциями и бизнес-сценариями пользователей. CMS управляет структурой сайта, каталогом, пользователями и модулями. API — это интерфейс обмена данными между системами: через него сайт может получать товары и цены из 1С или передавать заказы в CRM. Изменение одного звена может затронуть остальные.
Связь выглядит так:
Бизнес-задача → пользовательский сценарий → сайт → API → 1С / CRM / внешний сервис → проверка результата
Если компания меняет правило цен, доработка может потребовать изменения обмена с 1С, личного кабинета и карточки товара. После выпуска этой доработки поддержка контролирует, что новый сценарий продолжает работать при обновлениях, ошибках обмена и дальнейших изменениях.
Какой формат работ выбрать
Выбор формата зависит от роли сайта, регулярности изменений и того, понятна ли текущая архитектура проекта.
|
Формат |
Когда подходит |
Что закрывает |
Ограничение |
|
Регулярная поддержка |
Сайт участвует в продажах, обслуживании клиентов или внутренних процессах |
Инциденты, обновления, контроль интеграций, плановые доработки |
Требует постоянного контекста проекта и согласованных правил работы |
|
Периодическое обслуживание |
Небольшой сайт редко меняется и не имеет критичных интеграций |
Плановые проверки, обновления, резервное копирование, отдельные задачи |
Не заменяет оперативную реакцию на сложные инциденты |
|
Разовые доработки |
Нужно изменить конкретную функцию с понятными границами |
Новые поля, интерфейсы, правила, интеграционные изменения |
Без общего контроля изменения могут конфликтовать с существующей архитектурой |
|
Предварительный аудит |
Сайт передаётся новой команде, плохо документирован или накопил ошибки |
Диагностику рисков, карту систем, план входа в проект |
Сам по себе не заменяет поддержку и развитие |
Регулярная поддержка обычно нужна интернет-магазинам, B2B-порталам и сайтам с интеграциями. Для лендинга или небольшого корпоративного сайта без постоянных изменений часто достаточно периодического обслуживания и отдельных доработок по мере необходимости.
Почему изменения нельзя выпускать без проверки результата
Любое изменение сайта может затронуть больше функций, чем видно в постановке задачи. Поэтому поддержка отвечает не за сам факт публикации изменения, а за проверку результата в критичном сценарии.
Цепочка безопасного изменения выглядит так:
Изменение кода → затронутые компоненты → скрытый риск → проверка бизнес-результата
Например, обновление платёжного модуля может не повлиять на загрузку страниц, но нарушить передачу обязательного параметра при оплате. Внешне интернет-магазин продолжит работать, однако часть покупателей не сможет завершить заказ. Проверять нужно не только открытие формы, а весь путь: корзина, оформление, оплата, создание заказа и передача его статуса.
Тот же принцип действует для интеграций. Поддержка контролирует не только наличие соединения с внешней системой, но и результат обмена: пришли ли товары, цены и остатки; передались ли заказы и оплаты; не появились ли дубли; можно ли безопасно повторить неудачную операцию.
Как принять сайт на поддержку от другого подрядчика
Передача сайта на поддержку начинается с восстановления управляемости проекта, а не с первой срочной задачи.
Команда последовательно выполняет пять шагов:
-
Собирает управляемые доступы к сайту, серверу, домену, репозиторию, резервным копиям и внешним сервисам.
-
Составляет карту интеграций и определяет ответственных за 1С, CRM, оплату, хостинг и другие системы.
-
Фиксирует критичные сценарии: заявку, заказ, оплату, авторизацию, обмен данными или работу личного кабинета.
-
Проводит первичную диагностику кода, инфраструктуры, обновлений, безопасности и накопленных ошибок.
-
Формирует очередь критичных, плановых и профилактических задач.
Результат этого этапа — карта доступов и интеграций, список критичных сценариев и первичный реестр рисков. Отсутствие документации не делает передачу невозможной, но увеличивает объём аудита: новой команде нужно восстановить контекст до крупных изменений.
Что подготовить для первой оценки поддержки
Для первой оценки поддержки нужно описать роль сайта и его критичные функции, а не только передать ссылку на главную страницу.
Обычно полезно подготовить:
-
адрес сайта;
-
критичные пользовательские сценарии;
-
список интеграций и внешних сервисов;
-
известные ошибки и ближайшие задачи развития;
-
доступы к инфраструктуре, репозиторию и резервным копиям;
-
сведения о тестовой среде и документации.
Если сайт передаётся от другой команды, содержит индивидуальные компоненты или связан с несколькими системами, предварительный аудит обычно полезнее немедленного перехода к регулярным работам.
От чего зависит стоимость поддержки
Стоимость поддержки зависит от сложности его архитектуры. На оценку влияют тип и роль проекта, наличие интернет-магазина или личного кабинета, число и критичность интеграций, требования к SLA, состояние кода и инфраструктуры, наличие тестовой среды, объём изменений и качество документации.