Вернуться в блог

12 и еще один симптом того, что вашему IT-продукту нужен аудит

12 и еще один симптом того, что вашему IT-продукту нужен аудит
Содержание

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

Всем привет. На связи Влад Кармаков, CEO и основатель Siberian.pro — компании по разработке мобильных и веб-приложений, цифровых экосистем и AI-решений. Сегодня поговорим об аудите IT-продуктов. Что это, для чего нужно, каких результатов позволяет добиться и — самое главное! — как, черт возьми, понять, что вашему во всех отношениях замечательному продукту остро нужен аудит.

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

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

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

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

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

Зачем нужен IT-аудит продукта?

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

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

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

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

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

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

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

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

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

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

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

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

Виды аудита

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

UX/UI-аудит

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Самый комплексный аудит АйТи-продукта в целом. В чем цель продукта? Как мы понимаем, что эта цель достигнута, по каким метрикам? Действительно ли продукт работает так, как заказчик думает, и решает проблемы его клиентов или это только кажется? Может быть, боль потребителя и вовсе в чем-то другом? Ответы поможет получить продуктовый аудит.

В качестве медицинской аналогии здесь отлично подходит анекдот про человека со сломанным указательным пальцем. Покажите, где болит. Здесь, вот здесь и даже здесь. Другая аналогия: выбран неправильный подход к лечению (гомеопатия) или неинформативные метрики состояния здоровья (меряем температуру, а надо делать КТ). 

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

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

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

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

Вот как это может выглядеть на примере анализа некоего мобильного приложения в сфере здравоохранения:

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

  1. Формулируются гипотезы — возможные причины проблем.
  1. Затем гипотезы проверяются: 

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

б) строим дерево метрик, чтобы понять, каким метрикам важно уделять внимание на каждом этапе жизненного цикла продукта;

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

г) проводим интервью с ЦА, чтобы подтвердить или опровергнуть наши предположения.

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

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

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

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

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

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

Конкретно мы такой вид аудита делаем только по запросу клиента, но для полноты картины его упомянуть надо. 

Бизнес-аудит — это когда мы выходим за рамки конкретного продукта и рассматриваем позиционирование на рынке и метрики бизнеса в целом.

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

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

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

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

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

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

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

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

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

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

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

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

Отклонение метрик от желаемых значений является симптомом того, что с IT-продуктом что-то не в порядке. 

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

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

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

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

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

 

***

Спустя две сотни успешно завершенных проектов мы в Siberian.pro понимаем, насколько важно заранее определить направление развития IT-продукта для его успеха. А если этого по каким-то причинам не было сделано, для исправления ошибок всегда есть аудит ИТ-продукта. С удовольствием возьмем его на себя.

Больше историй о разработке, продуктовой аналитике и управлении командой удаленных сотрудников – в моем Telegram-канале.

 

Что ещё почитать по теме

Загрузить ещё