Автор статьи

Глеб Антоненко

Поделиться статьей:

Виды проблем доработки порталов и сайтов Битрикс24

Поломки и ошибки

Разработка нового функционала ломает старый.

Портал/сайт работает с ошибками.

Портал/сайт может упасть от действий разработчиков.

Необновляемость портала/сайта

Обновления ломают доработанный функционал портала/сайта.

Портал/сайт давно не обновлялся.

💡

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

Данная инструкция поможет дорабатывать портал/сайт и иметь 100% обновляемость.

Зависимость от текущего подрядчика

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

Отсутствуют инструкции по администрированию разработанного функционала.

Поддерживать ваш портал/сайт может только текущий подрядчик.

Часть скриптов или приложений работают на сервере/хостинге подрядчика, а не на вашем.

💡

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

Технический долг

Велись бесконтрольные разработки.

Сменилось несколько специалистов.

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

Результаты аудита портала/сайта показывают накопленные проблемы.

Каждая последующая доработка даётся с большими трудозатратами.

💡

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

Перечисленные выше проблемы напрямую влияют на Ваши расходы.

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

✅

Итоговая цель всех правил – сэкономить бюджет на разработку портала/сайта Битрикс24 и его сопровождение.

12 правил корректной доработки Битрикс24

1️⃣ Не делать разработку там, где уже есть стандартное решение.

Рекомендуем обсуждать постановку задачи с бизнес-аналитиком. Он определит, что можно сделать обычной настройкой, без разработок.

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

Ответственный: Подрядчик.

Плюсы: Экономия бюджета, ускорение по срокам.

2️⃣ Выполнять разработку поэтапно, не пытайтесь целиком написать техническое задание на всю задачу.

Другими словами – это призыв использовать Agile методологию в разработке.

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

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

Но зачастую время потеряно на подготовку, оценку и реализацию не того, что нужно.

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

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

Ответственный: Заказчик.

Плюсы: Экономия бюджета, ускорение по срокам.

3️⃣ Сохранять документацию – техническое задание и инструкцию администратора к каждой разработке.

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

Хранить надежно, в облачном хранилище файлов вашей компании.

Техническое задание необходимо хранить чтобы знать, что ранее было доработано. Это профилактика технического долга и возможность сменить подрядчика.

Инструкция администратора – это информация для того, кто сопровождает ваш портал/сайт. Как изменить настройки, какие данные используются в разработке, что необходимо для её корректной работы. Без неё Вам все время придется задавать вопросы разработчикам.

Ответственный: Подрядчик, Заказчик.

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

4️⃣ Не хардкодить параметры, а выносить их в настройки.

Часто в разработках используются параметры, например: определенный сотрудник, время ожидания, варианты для выбора пользователем.

Разработчики могут указать эти данные в разработке в виде кода – захардкодить. В этом случае, чтобы поменять значение параметра, требуется обращаться к разработчикам.

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

Ответственный: Подрядчик.

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

5️⃣ Создать репозиторий Git для ведения реестра разработок.

Для того чтобы хранить информацию обо всех изменениях в коде, видеть кто, что и когда изменил – необходимо использовать Git. Например, программу gitlab.

Далее необходимо подключить ваш портал Битрикс24 (сайт Битрикс24) к системе Git. Все разработки должны выполняться через Git.

Без этого правила не ясно что делали ранее, кто сломал портал/сайт, как сломали, как быстро вернуть обратно.

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

Ответственный: Подрядчик, Заказчик.

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

6️⃣ Создать копию портала Битрикс (сайта Битрикс24), и добавить в Git.

Без тестовой копии разработка может сломать боевой портал (сайт), поскольку нет возможности проверить работоспособность заранее.

С тестовой копией все разработки, а также обновление портала, проверяются на ней и только потом переносятся на боевой портал (сайт).

Ответственный: Подрядчик, Заказчик.

Плюсы: Предотвращение поломок, обновляемость.

7️⃣ Отозвать доступы FTP, SSH, админку Битрикс24 у разработчиков.

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

Правильно – давать доступ только в Git.

Разработка ведется на локальной копии разработчика. Затем он переносит ее через Git на тестовый портал (сайт). А оттуда её переносят на боевой.

Ответственный: Заказчик.

Плюсы: Предотвращение поломок, обновляемость.

8️⃣ Тестировать все разработки.

Все разработки и обновления необходимо сначала протестировать на тестовом портале (сайте). Затем перенести на боевой и протестировать на нём.

Простой способ проконтролировать качество тестирования – при приёмке попросите подрядчика добавлять в документацию: протокол тестирования на тестовом, протокол тестирования на боевом портале (сайте).

Ответственный: Подрядчик.

Плюсы: Предотвращение поломок.

9️⃣ Проводить код ревью.

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

Код ревью проводится после успешного тестирования на тестовом портале (сайте), перед переносом разработки на боевой.

Цель процедуры – предотвратить попадание некачественного кода на боевой портал (сайт).

Проблема особенно актуальна при работе над проектом от 6 месяцев.

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

Ответственный: Подрядчик.

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

1️⃣0️⃣ Обновлять портал (сайт) правильно.

Обновление портала(сайта) может сломать разработку.

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

Лучше, чтобы портал обновлял подрядчик.

Регламент: обновить тестовый портал (сайт), проверить его работоспособность. Внести корректировки в прошлые разработки, при необходимости. Только затем обновлять боевой портал (сайт).

Ответственный: Подрядчик, Заказчик.

Плюсы: Предотвращение поломок, обновляемость.

1️⃣1️⃣ Раз в квартал проводить обслуживание сервера и сайта.

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

Может потребоваться установить актуальные обновления ПО сервера, оптимизировать базу данных.

Ответственный: Подрядчик.

Плюсы: Предотвращение поломок.

1️⃣2️⃣ Работать с подрядчиком через таск-трекер для сохранения истории.

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

Сразу договоритесь с подрядчиком работать через таск-трекер. Например, Битрикс24, Trello, OkDesk. Конкретный выбор программы не так важен, как соблюдение договоренности вести работу только в ней.

Это позволяет вести учет того, что было реализовано ранее.

Ответственный: Подрядчик, Заказчик.

Плюсы: Ускорение по срокам, независимость от подрядчика.