IT-аудит действующего продукта

Что это#

IT-аудит – это независимая оценка разрабатываемого продукта по фактическим материалам проекта: исходным требованиям, коду, архитектуре, инфраструктуре и поведению работающей системы.

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

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

Когда применяется#

IT-аудит нужен, когда:

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

Что проверяем#

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

Технический аудит#

Оцениваем качество реализации и готовность системы к дальнейшей разработке и эксплуатации:

архитектуру и структуру решения;
качество и поддерживаемость кодовой базы;
используемые технологии, библиотеки и внешние зависимости;
реализацию ключевых бизнес-сценариев;
тестирование и покрытие критических участков;
безопасность приложения, данных и инфраструктуры;
информационную безопасность и соответствие требованиям 152-ФЗ «О персональных данных» (по отдельному запросу);
производительность и потенциальные узкие места;
отказоустойчивость, резервное копирование и восстановление после сбоев;
обработку ошибок, логирование и мониторинг;
CI/CD и процесс развёртывания;
управление конфигурацией, секретами и внешними зависимостями;
техническую документацию;
возможность дальнейшего развития и сопровождения продукта;
использование инфраструктурных ресурсов и технические причины эксплуатационных затрат, если необходимые данные доступны.

Главный вопрос этого направления:

Можно ли безопасно развивать и эксплуатировать текущую систему, или накопленные решения создают существенные технические риски?

Аудит соответствия поставленной задаче#

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

В рамках этого направления:

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

Главный вопрос этого направления:

Сделано ли то, что было поставлено в задачу, и как выявленные расхождения влияют на продукт?

Анализ продуктового контекста#

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

В рамках этого направления оцениваем:

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

Этот блок отвечает на вопрос:

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

Методика и критерии оценки#

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

ISO/IEC 25010:2023 – качество программного продукта. Используем модель качества ПО для оценки надёжности, производительности, безопасности, сопровождаемости и других характеристик. В прикладной проверке это переводится в понятные категории: архитектура, код, надёжность, производительность, безопасность, сопровождаемость и масштабирование.
ISO/IEC 5055:2021 – качество кодовой базы. Оцениваем структурные дефекты исходного кода, которые могут влиять на надёжность, безопасность, производительность и стоимость дальнейшей разработки.
OWASP ASVS – техническая безопасность веб-приложений. Учитываем требования к архитектуре, аутентификации, управлению доступом, защите данных, обработке ошибок, API и безопасной конфигурации.
152-ФЗ «О персональных данных» – отдельный контур проверки. По отдельному запросу оцениваем организационные и технические меры защиты персональных данных, процессы доступа, хранения, передачи и регистрации действий в информационной системе.

Что получает собственник#

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

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

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

Порядок проведения аудита#

Формирование области и критериев проверки#

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

Сбор и анализ исходных данных#

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

Формирование и проверка выводов#

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

Итоговый отчёт#

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

Входные данные и зависимости#

Для предметного аудита нам потребуются:

доступ к репозиторию и истории изменений;
описание продукта, архитектуры и текущего состояния проекта;
исходное ТЗ, спецификация, прототипы, backlog или другие материалы с описанием продукта;
доступ к тестовому или демонстрационному окружению;
техническая документация и инструкции по развёртыванию;
описание инфраструктуры, CI/CD, мониторинга и внешних интеграций;
список известных проблем, ограничений и незавершённых сценариев;
контактные лица со стороны собственника, заказчика и команды разработки.

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

Критерии качества аудита#

Качество аудита оценивается по тому, насколько его выводы помогают принять решение:

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

Ограничения и риски#

Без исходной постановки задачи невозможно объективно провести аудит соответствия требованиям. В этом случае можно оценить только техническое состояние и фактически доступные материалы.
Если нет доступа к репозиторию, окружениям или документации, часть выводов будет предварительной и получит соответствующую отметку в отчёте.
Проверка текущего состояния не гарантирует отсутствие всех дефектов: аудит не заменяет полное тестирование продукта или постоянный контроль качества разработки.
Технический аудит не является построчной проверкой всего кода и не заменяет специализированное тестирование на проникновение (пентест).
Углублённая проверка информационной безопасности и соответствия требованиям 152-ФЗ проводится по отдельному запросу и не входит в базовый технический аудит автоматически.
Аудит не устанавливает персональную вину сотрудников или подрядчиков. Его задача – показать состояние системы, подтверждённые факты и последствия для проекта.
Если команда не может предоставить спорные материалы или пояснения, это фиксируется как ограничение достоверности соответствующего вывода.

Стоимость услуг#

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

Ознакомиться с базовыми расценками

Следующий шаг#

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

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