Сайт всё дороже поддерживать: как разобраться в причинах и составить план исправлений

Что в смете относится к накопленному долгу?

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

Дорогая задача и накопленное ограничение

Техническим долгом здесь называем решения и упущения, из-за которых поддержка или последующие изменения требуют лишней работы. Это рабочее определение для обсуждения бюджета существующего сайта на 1С-Битрикс с каталогом и формой обращения. Код изучает специалист. Руководитель оценивает последствия: что мешает менять сайт, как часто препятствие возникает и чем исполнитель подтверждает его причину.

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

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

Что считать признаком проблемы

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

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

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

Откуда взять основания для оценки долга?

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

Связь замечания с устройством сайта

В документации Bitrix Framework системные файлы и пользовательские доработки разделены: для разработок предусмотрена папка /local/, а системная часть находится в /bitrix/. Эти обозначения нужны в отчёте специалиста, когда он объясняет, где расположена доработка. Заказчику не требуется переносить файлы самостоятельно. Ему важно понять, почему текущее расположение увеличивает стоимость обновления и какие действия устранят зависимость.

Тот же официальный материал указывает приоритет версии из /local/, если файл существует и там, и в /bitrix/. Поэтому число найденных файлов ещё не объясняет, какая версия работает. Исполнитель описывает используемое решение и связь с нужной функцией сайта.

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

Повторные затраты и разнообразие работ

За три года сотрудничества с крупной сетью, торгующей лакокрасочными материалами, ШТАБ ИТ выполнил около 700 задач. Среди направлений были интеграции, блог, товарные карточки и страницы сайта. Это объём разнородной работы, который нельзя объявить расходами на технический долг. Для оценки долга нужно отдельно установить ограничения и дополнительные затраты из-за них; количество задач не показывает, какая их часть была вызвана ограничениями прежних решений.

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

В отчёте полезны и неизвестные обстоятельства. Если причина пока не установлена, рядом остаются границы исследования и решение, которое зависит от его результата. Это позволяет утвердить сначала диагностику, не оплачивая заранее весь предполагаемый объём исправлений. Результаты общего обследования можно сопоставить с задачами из технического SEO-аудита, когда препятствие связано с поиском.

В какой последовательности исправлять ограничения?

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

Ближайшая работа задаёт приоритет

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

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

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

Подготовка и восстановление тоже входят в смету

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

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

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

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

Что обсудить до следующего изменения сайта?

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

Состав этапа и его границы

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

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

Не каждое улучшение удобно оценивать по сэкономленным часам. Руководитель выбирает оценку, соответствующую цели: для препятствия обновлению значима готовность к выпуску нужной версии, а для запутанного порядка передачи данных — возможность найти причину расхождения и восстановить сведения, которыми пользуются сотрудники, без нового исследования всего обмена и ручного исправления каждой затронутой записи. Обещание общего ускорения без названного действия сайта не даст ясного основания закрыть этап. Отдельно обсуждают сопровождение после исправления: где хранится описание, кто принимает следующую доработку и какие проверки повторяются при выпуске. Иначе новый специалист начнёт исследование с нуля, а расходы на понимание устройства сайта вернутся в ближайшую заявку. Документацию полезно оценивать по возможности продолжить конкретную работу. Объём переданных страниц не показывает, найдёт ли сотрудник нужное объяснение.

Как проверить пользу выбранного исправления

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

Для обсуждения с ШТАБ ИТ пригодятся завершённые заявки, перечень ближайших изменений и объяснения повторных расходов. Эти материалы помогут определить границы первого исследования и отделить его от последующей разработки. Общие условия регулярной работы разобраны в статье о технической поддержке сайта. Очередь исправлений можно пересматривать вместе с планами бизнеса, сохраняя основания уже принятых решений. С какого повторяющегося препятствия стоит начать, какими данными исполнитель подтвердит его причину и какое действие станет проще после первого этапа?