Аудит ИТ-продукта: как правильно его организовать и что это даст?

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

Что такое аудит, для чего он нужен, каких результатов позволяет добиться и, самое главное, как понять, что вашему во всех отношениях замечательному продукту остро необходим именно аудит?

Что такое аудит ИТ-продукта?

Часто клиент приходит к компании-разработчику с уже готовым мобильным приложением или иным legacy ИТ-продуктом, который хочет модернизировать. Иногда это собственная разработка, иногда – продукт сотрудничества со сторонними подрядчиками, это неважно. Важно, что заказчика этот продукт не устраивает. Продолжая аналогию с медицинскими сериалами, «пациент» чувствует себя плохо. Причем не только окончательный диагноз, но даже сами симптомы плохого самочувствия заказчик часто не в состоянии сформулировать четко. Продукт просто не дает того, что он ожидал. Нет продаж через приложение. Мало регистраций. Нет денежного выхлопа. Общее, не всегда формализуемое ощущение отставания от конкурентов и т. д.

Первое, что важно сделать в таких случаях, – выполнить глубокий аудит продукта, чтобы понять реальную причину его неэффективности. Потому что велика вероятность, что двигать кровати (читай: делать новый продукт по старым лекалам) окажется бесполезно. И только после такой всесторонней оценки принимаем решение, как конкретно будем лечить «пациента».

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

Зачем нужен ИТ-аудит?

Цель медицинской диагностики – опознать болезнь и помочь пациенту выздороветь. Аналогично и здесь: комплексная оценка приложения или ИТ-продукта помогает понять, почему он не решает проблему заказчика (а возможно, и проблему конечного потребителя), в чем конкретно заключается сложность, и что конкретно нужно сделать, чтобы всё заработало как надо.

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

Пример списка UX/UI-доработок после аудита проекта

Кто выполняет аудит?

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

А своими силами можно?

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

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

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

Отмечу еще один важный момент. Для внешнего подрядчика услуга аудита является профильной, а для сотрудников компании – нет. Следовательно, выполнять работы по аудиту продукта сотрудники будут в свободное от основной занятости время (читай: неэффективно). И это в том случае, если ИТ-отдел в вашей компании вообще есть.

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

Но какой именно аудит делать?

Виды аудита

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

UX/UI-аудит

UX/UI-аудит нужен, когда есть признаки, что имеющееся решение неудобно использовать. Более того – именно это неудобство и является причиной проблем с продуктом. В нашей медицинской аналогии это будет ситуация, когда для здоровья пациента ему достаточно поменять режим питания, отказавшись, например, от глютена.

Конечная цель, которую мы преследуем с помощью UX/UI-аудита ИТ, – добиться последовательного и цельного (consistent) пользовательского опыта, позволяющего решить задачи пользователя с минимальным количеством действий. Или даже вообще без них.

Несоответствие интерфейса продукта стандартам юзабилити и отсутствие CJM – это очевидные примеры потенциальных недоработок, которые выявляются в ходе ИТ-аудита. Однако часто всплывают вещи далеко не очевидные, например, влияние психотипа пользователя на опыт его работы с приложением или даже локальные культурные особенности ЦА, которые ухудшают UX.

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

Пример предложений по улучшению пользовательского интерфейса приложения по результатам UX/UI-аудита

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

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

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

Технический аудит выполняется, когда продукт не работает, как должен, по чисто техническим причинам: плохой код, негибкая инфраструктура, плохая организация данных, неэффективные алгоритмы и т. д. Конкретные причины как раз и должен выявить анализ. Аналогия здесь – сельское здравоохранение, когда ближайший врач находится в 30 км (неудачная инфраструктура). Или, скажем, когда нужно поменять препарат (платформу, версию, используемую технологию) на другой, более современный.

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

• проблемы совместимости продукта с устройствами или версиями OS;
  
• нестабильная работа под нагрузкой (нагрузочное тестирование);
  
• проблемы с производительностью (бенчмаркинг);
  
• баги (QA-тестирование);
  
• кривая архитектура системы;
  
• проблемы с масштабируемостью и т. д.

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

• Актуальность версий используемых библиотек. Выяснилось, что порядка 200 библиотек требуют обновления в силу использования не самой свежей версии Python.
  
• Безопасность. Ряд бэкенд-библиотек, критичных для безопасности, также требовали обновления.
  
• Инфраструктура. Технический аудит проекта показал наличие неоптимальных и неиспользуемых интеграций, а также неэффективный пайплайн CD/CI, в котором многое делалось вручную. Это потенциально могло привести к проблемам с обновлением и поддержкой проекта в будущем.
  
• Качество кода. Аудит выявил большие проблемы с архитектурой кода и отсутствием внятной логики в его модульной структуре. В перспективе это могло вылиться в практическую невозможность дальнейшего масштабирования проекта, а у заказчика оно было в планах. 
• Best practices. Ход разработки далеко не всегда следовал рекомендованным лучшим практикам.

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

Аудит процессов разработки

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

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

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

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

• добиться единообразия и согласовать производственные процессы со всеми участниками;
  
• создать стандарты процессов разработки, включая требования к коду, требования к документации, процессы тестирования и релиза и т.д., 
• сформулировать максимально точное определение готовности продукта к релизу;
  
• стандартизировать работу с Git, например обеспечить информативные комментарии к коммитам и Merge Requests.

Продуктовый аудит

Самый комплексный аудит ИТ-продукта в целом. В чем цель продукта? По каким метрикам мы понимаем, что эта цель достигнута? Действительно ли продукт работает так, как ожидает заказчик, и решает проблемы его клиентов или это только кажется? Может быть, проблема потребителя и вовсе в чем-то другом? Ответы поможет получить продуктовый аудит. В качестве медицинской аналогии здесь отлично подходит анекдот про человека со сломанным указательным пальцем: «Покажите, где болит?» – «Здесь, вот здесь и даже здесь». Другая аналогия: выбран неправильный подход к лечению (гомеопатия) или неинформативные метрики состояния здоровья (меряем температуру, а надо делать КТ).

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

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

Диагностика подобных проблем выполняется поэтапно:

1. С помощью инструмента Lean Canvas наглядно формируется модель бизнеса. Здесь пока нет никаких хитростей, вся информация уже имеется в голове руководителя, мы просто ее систематизируем. Вот как это может выглядеть на примере анализа некоего мобильного приложения в сфере здравоохранения:

Визуализация с помощью Lean Canvas позволяет наглядно сформулировать ключевую проблему бизнеса и обозначить пути ее решения.

2. Формулируются гипотезы – возможные причины проблем. 

3. Затем гипотезы проверяются:

• строим CJM, чтобы понять, как вообще клиент находит продукт и принимает решение им воспользоваться, и можно ли этот путь сделать короче;
  
• строим дерево метрик, чтобы понять, каким метрикам важно уделять внимание на каждом этапе жизненного цикла продукта;
  
• определяем типичные user flow, то есть последовательности действий пользователя во ходе взаимодействия с продуктом. Это позволяет не только найти проблемы в интерфейсе, но и потенциально выявить изначально неверные решения в проектировании продукта;
  
• проводим интервью с ЦА, чтобы подтвердить или опровергнуть наши предположения.

4. На основе полученной информации формулируются истинный источник проблемы и конкретные способы ее решения.

Мы представили основные этапы ИТ-аудита, но в реальности каждый случай, конечно, имеет свои нюансы, поэтому это лишь общий скелет.

Пример. Клиент обратился к компании-разработчику за доработкой интерфейса онлайн-магазина, чтобы поднять конверсию в покупки. Однако в ходе продуктового аудита выяснилось, что изначальная гипотеза о проблемах на этапе оформления заказа неверна. Да, там были UX/UI-проблемы и сам дизайн не был оптимальным, но основная доля посетителей терялась задолго до корзины.

Более детальный анализ поведения пользователей и глубинные интервью (??) показали, что ЦА не до конца осознает ценность продукта клиента, рассматривая его исключительно как товар, тогда как клиент предлагал еще и массу сопутствующих услуг, ценность которых никак не подчеркивалась в существующем предложении. То есть заказчик работал в формате традиционного онлайн-магазина, предполагая, что именно этого ожидает потребитель, и в результате был вынужден конкурировать с другими магазинами и крупными маркетплейсами. А правильнее оказалось изменить концепцию продукта и предлагать комплекс из товаров и услуг по подписке.

Бизнес-аудит

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

От проблемы к решению

Здесь нужно отметить один важный момент: любой из вышеприведенных анализов начинается с рассмотрения классической цепочки «Боль – Потребность – Решение».

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

Поэтому любой аудит – это:

1. Анализ целевой аудитории, ее болей и потребностей.
   
2. Анализ целей, задач и УТП продукта по отношению к ЦА.
   
3. «Распаковка» продукта – что, как и почему в нем реализовано. Как именно продукт решит проблему ЦА.
   
4. User flow и Customer Journey Maps.
   
5. Карта ключевых метрик, с помощью которых мы можем понять, что продукт достигает заявленных целей и решает проблемы потребителя.

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

Шаблон компании Workspace

Как понять, что IT-продукту нужен аудит?

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

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

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

Основные симптомы того, что продукту или приложению нужен аудит, следующие:

• Низкая конверсия. Пользователи есть, но в клиентов они конвертируются плохо.
  
• Низкая вовлеченность. Пользователи слабо взаимодействуют с продуктом. Например, небольшая продолжительность рабочей сессии или малое их количество.
  
• Низкий retention rate. Пользователи не возвращаются к приложению.
  
• Низкая пожизненная ценность на клиента (???) (LTV). Например, если клиент не продлевает подписку или остается на бесплатном тарифе.
  
• Низкий средний доход на пользователя (ARPU). Может указывать на то, что выбрана не самая эффективная модель монетизации продукта.
  
• Низкий ROI. Может указывать на завышенную стоимость разработки или поддержки продукта.
  
• Высокий процент оттока клиентов (churn rate). Продукт не «цепляет» клиентов, и они уходят.

Среди качественных показателей можно выделить следующие:

• «Плохие» отзывы пользователей. Даже если в отзывах мало конкретики, сам факт большого объема негатива указывает на проблемы в той или иной части цепочки «Боль – Потребность – Решение».
  
• Обзоры, опросы, интервью. К любому экспертному мнению, даже если это мнение конкурентов, стоит прислушаться.
  
• Сравнение с продуктом конкурентов. В силу того, что доступа к данным конкурентов нет, сравнение во многом идет по качественным критериям. Грубо говоря, бизнес чувствует или опасается, что его продукт чем-то уступает аналогам конкурентов – по функциональности, по используемым технологиям, по дизайну UI и т. д.
  
• Продукт не достигает своей цели. Например, ставилась цель довести долю продаж товара через приложение до 20%, но она не достигнута за намеченное время.
  
• Запланированное масштабирование продукта испытывает трудности. Не самый очевидный симптом. Вендору проще предположить, что в ходе масштабирования возникли проблемы, тогда как дело в изначально неправильно спроектированной архитектуре продукта или в непонимании своей ЦА. И именно это является реальной причиной пробуксовок и проблем с масштабированием. Антибиотики не помогают, но причина не в том, что антибиотик плохой, а в том, что у пациента вирус, а не бактериальная инфекция.
  
• Продуктом не пользуются сотрудники самой компании. Неформальный, но порой весьма показательный критерий.

Если вы как CEO, CMO или коммерческий директор компании наблюдаете какие-то из этих симптомов, возможно, имеет смысл «сдать анализы» – обратиться к аналитике, чтобы понять причины, выявить проблемы и недоработки на всех стадиях разработки ИТ-продукта. А потом перейти к конкретным действиям, которые позволят продукту «выстрелить».