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 км (неудачная инфраструктура). Или, скажем, когда нужно поменять препарат (платформу, версию, используемую технологию) на другой, более современный.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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