Техническая поддержка сайтов на 1С-Битрикс

Берём на техническую поддержку существующие проекты на 1С-Битрикс — от корпоративных сайтов до интернет-магазинов и сложных веб-сервисов.

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

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

Не начинаем доработки вслепую. Сначала разбираемся, что именно нам передали и в каком состоянии находится проект.

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

Технический долг может долго оставаться незаметным. Сайт работает — но каждое следующее изменение становится сложнее и рискованнее.

Признаки накопившегося технического долга:

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

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

Цель — сделать дальнейшую поддержку и развитие сайта предсказуемее, не останавливая работающий проект.

Обновление старого проекта может превратиться в отдельную инженерную задачу.

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

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

Задача — не просто установить новую версию, а сохранить работоспособность сайта после обновления.

Сайт может работать без ошибок и всё равно перестать соответствовать потребностям компании.

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

В рамках технической поддержки можем не только обслуживать существующий функционал, но и развивать проект:

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

Так поддержка превращается из постоянного исправления проблем в управляемое развитие цифрового продукта.

Если текущая команда не справляется с проектом, смена подрядчика не должна означать разработку сайта заново.

Начинаем с передачи доступов, исходного кода, документации и информации о текущих задачах. Изучаем проект и фиксируем критичные зависимости.

После этого формируем список первоочередных работ и постепенно принимаем разработку на себя.

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

Сам возраст сайта не означает, что его нужно переписывать.

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

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

Мы сначала оцениваем состояние проекта и только после этого рекомендуем продолжать развитие существующего сайта или планировать его замену.

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

Переносим сайты с 1С-Битрикс на Drupal или WordPress и в обратном направлении. Анализируем существующий функционал, данные, интеграции и SEO-требования, чтобы определить, что необходимо сохранить при переходе.

Миграцию предлагаем не вместо поддержки, а тогда, когда она становится экономически и технически более рациональным решением.

Вы ставите задачи команде поддержки, а мы оцениваем их, определяем приоритет и подключаем необходимых специалистов.

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

Для крупных задач предварительно оцениваем объём работ и согласовываем их выполнение.

Разработчики используют ИИ-инструменты при работе с кодом: для анализа существующего проекта, поиска причин ошибок, страховки от человеческого фактора, подготовки и проверки решений, рефакторинга и других задач, где они помогают сократить рутинную работу.

Это позволяет экономить до 40% бюджета на отдельных задачах: разработчик тратит меньше оплачиваемого времени, а в тот же пакет часов помещается больше доработок.

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

Количество разработчиков зависит от задач.

Для регулярного обслуживания небольшого проекта может быть достаточно одного специалиста. Если одновременно необходимо исправлять технические проблемы, разрабатывать новый функционал и готовить крупное обновление, можем увеличить команду.

При необходимости к проекту подключается до 6 разработчиков.

Вы оплачиваете пакет часов, а состав команды подбираем исходя из задач проекта.

Мы не работаем в режиме 24/7, поэтому не обещаем круглосуточную реакцию на обращения.

Если для проекта критично гарантированное время реакции и устранения определённых типов проблем, условия SLA можем согласовать отдельно и закрепить в договоре.

Так требования к скорости реакции определяются реальными потребностями проекта, а не формальной отметкой «24/7».

Расскажите, что происходит с проектом сейчас: нужно исправить ошибку, разобраться в чужом коде, обновить систему, устранить технический долг, разработать новую функцию или полностью сменить подрядчика.

Изучим задачу и предложим подходящий формат работы.