{"id":14291,"url":"\/distributions\/14291\/click?bit=1&hash=257d5375fbb462be671b713a7a4184bd5d4f9c6ce46e0d204104db0e88eadadd","title":"\u0420\u0435\u043a\u043b\u0430\u043c\u0430 \u043d\u0430 Ozon \u0434\u043b\u044f \u0442\u0435\u0445, \u043a\u0442\u043e \u043d\u0438\u0447\u0435\u0433\u043e \u0442\u0430\u043c \u043d\u0435 \u043f\u0440\u043e\u0434\u0430\u0451\u0442","buttonText":"","imageUuid":""}

Аудит IT продукта как потенциальная точка роста вашего бизнеса

Всем привет! Сегодня поговорим про аудит ИТ продуктов. Кому? Зачем? И что он дает? Меня зовут Антон Репьев, я – основатель аутсорсинговой IT-компании A2SEVEN. Более 13 лет мы разрабатываем веб и мобильные приложения на заказ по всему миру. Мы не понаслышке знаем, как важно серьезно подходить к разработке ПО с первых шагов.

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

Первый тип

Стартапы развиваются очень быстро, и тогда они придерживаются принципов: «Некогда обсуждать, надо делать!», «Херак, херак и в продакшин, а там уже разберемся». В таких проектах часто нет технических заданий или они очень быстро теряют свою актуальность, есть проблемы с архитектурными решениями, так как изначально планировали одно, но в процессе пять раз все поменяли.

Второй тип

Стартапы организуются со слабой технической командой либо малым опытом в построении архитектурных решений. Часто из-за того, что нет возможности или умений правильно подобрать нужного технического человека. В таких проектах часто придерживаются подхода: «У меня есть друг айтишник, институт на одни пятерки окончил, он точно сможет сделать крутое решение», или «Ваше решение очень дорогое, у подруги моей мамы есть сын, он сделает все за 50 тысяч».

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

Знакомо? А мне очень. За свою карьеру я встречал десятки таких проектов. Часто мы сами были той самой командой, перед которой стояла задача разработать и запустить проект в очень сжатые сроки. И да, бывало мы специально упрощали функционал или архитектурные решения, чтобы успеть в срок с заделом на то, что когда все «полетит», то уже сделать правильно. Так рождается технический долг, который без своевременной и правильной работы с ним, может привести к дорогостоящим последствиям. А бывало и такое, что нам приходили проекты, которые приходилось полностью переписывать из-за слабой компетенции предыдущей команды.

Что делать, чтобы минимизировать эти риски?

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

У нас довольно большой опыт проведения аудитов. Чаще всего мы проводим аудит в двух случаях.

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

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

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

Этапы аудита

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

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

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

Цель аудита ИТ продукта

Затем согласовываются и обсуждаются этапы.

Этапы проведения аудита ИТ продукта

В зависимости от целей, не все этапы аудита необходимы.

Этап «Анализ ТЗ и системы»

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

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

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

Этап «Код-ревью»

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

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

Пример отчета. Code Review, часть 1
Пример отчета. Code Review, часть 2

Этап «Аудит архитектуры приложения и баз данных»

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

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

Пример отчета. Архитектура (Backend)  
Пример отчета. Проблематика

Этап «Аудит безопасности системы»

На этом этапе техническая команда проверяет различные уязвимости, аутентификацию, политику паролей, контроль доступа, DAST – тестирование черного ящика, OWASP топ 10 и многое другое. Залогом быстрого и качественного результата является плотное сотрудничество с технической командой клиента или же системным администратором. Этап может занимать от нескольких дней до нескольких недель, в зависимости от проекта.

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

Пример отчета. Политика паролей
Пример отчета. Рекомендации

Этап «Нагрузочное тестирование»

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

Сроки плавающие и зависят сложности и архитектуры приложения. В самом простом варианте это может занять 2 – 3 дня, в сложных вариантах может занять до месяца. В результате аудита предоставляется детализированный отчет с рекомендациями.

Этап «UI/UX исследование»

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

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

Как аудит помогает росту бизнеса

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

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

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

Если вы собираетесь проводить аудит своего продукта или только думаете об этом, напишите мне, я готов ответить на ваши вопросы и помочь если нужно!

0
Комментарии
-3 комментариев
Раскрывать всегда