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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

UX/UI-аудит

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Эта статья была опубликована в издании IT-World, а больше историй о разработке, продуктовой аналитике и управлении удаленной командой – в моем Telegram-канале Публично о личном. Дневник CEO IT-компании.