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