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