Рано или поздно каждый сайт на 1С-Битрикс перерастает то состояние, в котором его когда-то запустили. Появляется новый способ оплаты, меняется логика скидок, отдел продаж просит доработать личный кабинет B2B-клиентов, маркетинг требует нестандартный фильтр в каталоге. Всё это — не повод переделывать сайт заново, а классическая задача на доработку существующего функционала.
Доработка сайта на 1С-Битрикс — это отдельный вид работ, который требует другого подхода, чем разработка с нуля: другой процесс, другая оценка рисков, другие компетенции подрядчика. Ошибка на этом этапе обходится дороже, чем в новом проекте, потому что под изменения попадает уже работающий сайт с реальными заказами, клиентами и историей данных.
В этой статье разбираем, что технически считается доработкой, какие сценарии встречаются чаще всего, можно ли безопасно дорабатывать сайт, сделанный другим подрядчиком, и как должен быть устроен процесс, чтобы изменения не привели к простою боевого сайта. Мы в TRUWEB занимаемся разработкой и доработкой на 1С-Битрикс с 2011 года, реализовали более 250 проектов и работаем по договору — поэтому опираемся на практику, а не на теорию.
Важно сразу разделить два похожих, но разных по сути запроса. «Доработать сайт» — это добавить или изменить конкретную функцию в рамках того, что уже есть. «Переделать сайт» — это пересмотреть архитектуру целиком, часто с миграцией на новую структуру данных или другую версию модулей. Путаница между этими двумя формулировками — частая причина завышенных ожиданий по срокам и бюджету, поэтому первый разговор с подрядчиком всегда должен закончиться однозначным ответом: перед нами доработка существующей логики или, по сути, новый проект под видом доработки.
Доработка — это изменение уже существующего сайта: добавление, изменение или расширение функциональности в рамках действующей архитектуры проекта. В отличие от разработки с нуля, доработка не начинается с чистого листа — она встраивается в существующую структуру инфоблоков, компонентов, шаблонов и модулей, и обязана учитывать то, что уже работает и не должно сломаться.
К доработке в терминах 1С-Битрикс обычно относят:
Разработка с нуля, в свою очередь, — это создание сайта или крупного модуля с чистого листа: проектирование структуры инфоблоков, выбор и настройка модулей, вёрстка и интеграция шаблонов, построение бизнес-логики без оглядки на существующий код. У неё другой набор рисков — они связаны с проектированием архитектуры, а не с совместимостью с уже написанным. Подробно о том, как устроена разработка и поддержка на 1С-Битрикс в целом, мы писали в общем гиде по разработке и поддержке на 1С-Битрикс.
Граница между доработкой и новым проектом не всегда очевидна по формулировке задачи — иногда «добавить раздел» на практике означает переработать половину каталога. Поэтому один из первых шагов в работе с любой такой задачей — это техническая оценка, которая и определяет, доработка это или фактически отдельный проект.
Есть и промежуточные случаи, когда формально это доработка, а по трудозатратам она сопоставима с небольшим отдельным проектом. Например, если под новый раздел каталога нужно не просто изменить шаблон, а ввести новый тип инфоблока со своей структурой свойств, торговыми предложениями и логикой ценообразования — объём работ может быть сопоставим с разработкой отдельного модуля. В таких случаях честная оценка подрядчика важнее формальной классификации задачи: заказчику нужно понимать реальный объём работ, а не то, как эта задача называется в договоре.
На практике большинство обращений укладывается в несколько повторяющихся сценариев. У них разный уровень сложности и разная зона риска, но общий принцип одинаковый: доработка меняет одну функциональную область сайта, не затрагивая при этом архитектуру целиком. Рассмотрим их подробнее — это помогает понять логику работы над задачей и то, какие технические компоненты Битрикса обычно задействованы.
Стандартный компонент "Смарт-фильтр" в 1С-Битрикс закрывает базовые сценарии фильтрации по свойствам товара, но не покрывает более сложные случаи: комбинированные фильтры по нескольким инфоблокам, фильтрацию по вычисляемым значениям (например, наличию у нескольких поставщиков), интерактивные фильтры с зависимыми полями. Доработка в этом случае — это расширение логики выборки товаров, кастомизация шаблона фильтра и, часто, оптимизация запросов к базе данных, чтобы фильтр не замедлял каталог при росте числа товаров.
Оформление заказа — самый чувствительный к ошибкам узел сайта: любая недоработка здесь напрямую бьёт по конверсии и выручке. Типичные задачи — добавить шаг с выбором способа получения, изменить логику расчёта доставки, встроить проверку промокодов, изменить обязательные поля под требования конкретного бизнеса. Технически это работа с модулем "Интернет-магазин", обработчиками событий заказа и, часто, кастомными компонентами оформления вместо стандартных.
Личный кабинет для оптовых и корпоративных клиентов почти всегда требует индивидуальной доработки: персональные цены и скидки, история заказов по договору, доступ нескольких сотрудников с разными правами, выгрузка документов, повторный заказ по шаблону. Здесь доработка затрагивает не только фронтенд личного кабинета, но и модель данных — часто нужно расширять инфоблоки пользователей и добавлять новые сущности для хранения договорных условий.
Когда в структуру сайта добавляется принципиально новый тип раздела — например, база знаний, каталог франшиз или раздел с калькулятором — типовой шаблон каталога или новостей для него не подходит. Нужна кастомизация шаблона компонента и, зачастую, создание нового типа инфоблока под структуру данных раздела, с учётом уже существующей системы дизайна сайта, чтобы новый раздел не выглядел чужеродным.
Интеграции — с 1С, CRM, складской системой, службами доставки, платёжными шлюзами — редко работают "навсегда без изменений": меняются форматы обмена данными, появляются новые поля, обновляются API внешних сервисов. Доработка интеграции — это, как правило, изменение обработчиков обмена, маппинга полей и логики синхронизации, при этом важно не нарушить уже работающий поток данных для других процессов, завязанных на ту же интеграцию.
Да, но это отдельная категория задач с собственными рисками, и не каждый подрядчик берётся за неё без предварительного анализа. Прежде чем начать любую доработку чужого сайта, ответственный подрядчик проводит разбор существующего кода: смотрит, насколько он соответствует стандартам разработки на 1С-Битрикс, есть ли изменения в ядре (что является грубым нарушением и источником проблем при обновлениях), как построена архитектура инфоблоков, задокументированы ли кастомные модули.
Типичные риски работы с чужим кодом:
По итогам такого разбора подрядчик формирует честную оценку: за какие задачи он готов взяться сразу, где нужен дополнительный аудит перед стартом, а где риски настолько велики, что дешевле и надёжнее спроектировать часть функционала заново, чем встраивать доработку в существующий хаос. Если ситуация с текущим сайтом непрозрачна, разумный первый шаг — заказать отдельный аудит сайта, который даст объективную картину состояния кода и архитектуры до начала любых доработок. О том, на что вообще стоит смотреть при выборе подрядчика для таких задач, мы подробно писали в статье как выбрать подрядчика по разработке на 1С-Битрикс.
Есть и обратная сторона вопроса: за что подрядчик обычно не готов браться без оговорок. Это ситуации, когда сайт содержит критичные изменения в закрытом виде — например, часть логики зашифрована или доступна только через лицензионный модуль стороннего разработчика без возможности его модифицировать, а сама доработка требует именно вмешательства в эту часть. В таком случае честный подрядчик прямо скажет, что задачу в текущем виде не решить без замены закрытого компонента, вместо того чтобы браться за работу с заведомо непредсказуемым результатом. Аналогично — если структура базы данных настолько отклоняется от стандартов Битрикса, что риск повредить данные при любом изменении выше, чем ценность самой доработки, разумный подрядчик предложит сначала привести данные в порядок, а уже потом дорабатывать функциональность поверх них.
Технически грамотная доработка всегда проходит через одну и ту же последовательность этапов, вне зависимости от масштаба задачи.
1. Заявка. Заказчик формулирует задачу — часто на уровне бизнес-требования ("нужно, чтобы клиенты могли повторить прошлый заказ в один клик"), а не технического задания. На этом этапе важно зафиксировать не только желаемый результат, но и ограничения: сроки, влияние на другие процессы, кто из сотрудников заказчика будет тестировать результат.
2. Оценка. Подрядчик анализирует, как задача ложится на существующую архитектуру сайта: какие инфоблоки, компоненты и модули затронуты, есть ли конфликты с уже реализованной логикой, потребуется ли миграция данных. По итогам формируется оценка объёма работ и план реализации.
3. Тестовая копия сайта. Перед любым изменением кода разворачивается копия сайта — с актуальной базой данных и файлами, изолированная от боевого окружения. Именно на ней ведётся вся дальнейшая разработка.
4. Разработка. Изменения вносятся в тестовом контуре: доработка компонентов, обработчиков событий, шаблонов, интеграций — в зависимости от задачи. Хорошая практика — вести изменения так, чтобы их можно было накатить на боевой сайт предсказуемым набором файлов и SQL-изменений, а не вручную "по памяти".
5. Тестирование. Проверяется как сама новая функциональность, так и то, что доработка не сломала существующие процессы — оформление заказа, работающие интеграции, личный кабинет. На проекты со сложной бизнес-логикой имеет смысл привлекать к тестированию и сотрудников заказчика, которые ежедневно работают с сайтом.
6. Релиз на боевой сайт. Изменения переносятся на продакшен в заранее согласованное окно, с планом отката на случай непредвиденной проблемы. После релиза — контрольная проверка на боевом сайте.
Для небольших доработок весь цикл может занимать считаные дни, для комплексных изменений — например, доработки B2B-личного кабинета с новой моделью данных — растягивается на недели, потому что тестирование такой задачи требует времени на проверку всех сценариев использования, включая пограничные случаи: что происходит с существующими заказами, старыми пользователями без новых атрибутов, ранее оформленными скидками. Важно, что порядок этапов не сокращается независимо от размера задачи — меняется только их длительность.
Соблазн внести небольшое изменение сразу на боевом сайте — пропустить шаг с тестовой копией "ради экономии времени" — встречается часто, особенно когда задача кажется простой. На практике это один из самых частых источников серьёзных инцидентов на проектах, где раньше не было регламента доработок.
Что происходит при доработке без тестового контура:
Тестовая копия сайта — это не бюрократическая формальность, а прямая защита работающего бизнеса заказчика от простоя и потери данных. Регламент, при котором любая доработка сначала проверяется на копии и только потом переносится на боевой сайт, — обязательная часть нормального сопровождения проекта, вне зависимости от того, насколько простой кажется задача на первый взгляд: даже однострочное изменение в обработчике события способно повлиять на процесс, который напрямую с этим обработчиком не связан на первый взгляд. Подробнее о том, что в принципе входит в грамотное сопровождение сайта, можно прочитать в статье техподдержка и сопровождение сайта: что входит, а услугу в целом мы описываем на странице поддержка и развитие.
Доработка требует не только знания 1С-Битрикс в целом, но и понимания конкретного проекта: как устроены его инфоблоки, какие есть нестандартные обработчики, какие интеграции завязаны друг на друга, где в коде есть "хрупкие" места, оставшиеся от предыдущих доработок. Подрядчик, который уже держит сайт на постоянном сопровождении, обладает этим знанием без дополнительного времени на изучение проекта.
Для стороннего подрядчика, впервые взявшегося за доработку чужого сайта, первый этап — это всегда разбор архитектуры и кода, который занимает время и увеличивает объём задачи, даже если сама доработка технически несложная. У подрядчика на постоянной поддержке этого этапа нет: он уже знает, как задача встроится в существующую логику, какие компоненты переиспользовать, а что менять аккуратно из-за скрытых зависимостей.
Это напрямую экономит время и деньги заказчика: меньше часов уходит на погружение в проект, ниже риск ошибки из-за незнания нюансов архитектуры, быстрее происходит тестирование, потому что известно заранее, какие части сайта критично проверить после изменения. Это одна из причин, по которой имеет смысл рассматривать разработку и последующее сопровождение как связанные, а не разрозненные задачи — что мы подробно разбираем на странице услуги разработка сайтов. Наглядный пример такого подхода — развитие корпоративного сайта производителя мебели уже после запуска, разобранное в кейсе сайт производителя мебели: проект продолжает дорабатываться по мере роста бизнеса заказчика, силами той же команды, что вела разработку.
Есть и практический побочный эффект такого подхода: подрядчик на постоянной поддержке видит доработку не как изолированную задачу, а в контексте общего состояния сайта. Он заранее знает, какие части системы перегружены запросами, где раньше уже возникали проблемы с производительностью, какие интеграции чувствительны к изменениям. Это позволяет закладывать в доработку не только текущее требование, но и небольшой запас на дальнейшее развитие — например, проектировать новую сущность в инфоблоках так, чтобы её было проще расширить в следующий раз, а не переделывать заново при очередном запросе бизнеса.
Стоимость доработки на 1С-Битрикс не может быть фиксированной по прайс-листу — в отличие от типовых пакетных услуг, каждая задача доработки индивидуальна по объёму затрагиваемого кода и данных. Оценка формируется исходя из конкретного объёма работ, а не по шаблону "доработка каталога стоит X".
На объём и, соответственно, стоимость влияют:
Поэтому первый шаг для любой задачи доработки — это техническая оценка на стороне подрядчика, а не запрос "сколько стоит доработать личный кабинет" без деталей. Чем точнее сформулирована задача и чем прозрачнее состояние текущего кода, тем точнее и быстрее можно получить обоснованную оценку объёма работ.
На практике полезно сразу договориться о формате оценки: разбита ли она по этапам процесса (анализ, разработка, тестирование, релиз) или дана общей суммой на весь объём. Постатейная оценка удобнее для заказчика — она показывает, за что именно платится каждая часть бюджета, и позволяет при необходимости скорректировать объём задачи, если, например, часть функциональности можно упростить без потери ценности для бизнеса. Также стоит заранее уточнить, входит ли в оценку тестирование смежных процессов, которые доработка может затронуть косвенно — это частый источник расхождений между ожидаемым и итоговым объёмом работ, если не обсудить его на этапе оценки.
Если хотя бы половина пунктов не выполняется — например, архитектура сайта устарела настолько, что новую функциональность физически некуда встроить без переработки ядра проекта, — стоит обсудить с подрядчиком, не выгоднее ли в конкретном случае спроектировать эту часть заново, чем растягивать доработку поверх изначально не рассчитанной на неё структуры.
Интернет-магазин INTERNO — это ритейлер и поставщик дизайнерских предметов интерьера, освещения и мебели из Европы, Азии и Америки.
Смотреть кейс →Разбираем, из чего реально состоит техподдержка сайта на 1С-Битрикс, сколько она стоит и по каким признакам понятно, что сайту она уже нужна.
Читать →Чек-лист вопросов и красных флагов, который стоит пройти перед тем, как отдавать проект на 1С-Битрикс подрядчику.
Читать →