«У вас волчанка», — произносит врач, и пациент, а с ним и зритель облегченно вздыхают. Гениальный диагност расшифровал наконец загадочные симптомы и назначил лечение. Теперь все будет в порядке. Но это в кино. В реальности же понять, почему с любовью выпестованное приложение, в которое вложили кучу денег и усилий, не дает эффекта, бывает непросто.
Всем привет. На связи Влад Кармаков, CEO и основатель Siberian.pro — компании по разработке мобильных и веб-приложений, цифровых экосистем и AI-решений. Сегодня поговорим об аудите IT-продуктов. Что это, для чего нужно, каких результатов позволяет добиться и — самое главное! — как, черт возьми, понять, что вашему во всех отношениях замечательному продукту остро нужен аудит.
Что такое аудит IT-продукта?
Приступая к сотрудничеству с тем или иным заказчиком в качестве разработчика продукта, мы далеко не всегда начинаем работу с нуля. Очень часто клиент приходит к нам с уже готовым мобильным приложением или иным legacy IT-продуктом, который заказчик решил модернизировать с нашей помощью. Иногда это собственная разработка, иногда — продукт сотрудничества со сторонними подрядчиками, это неважно. Важно, что заказчика этот продукт не устраивает. Продолжая аналогию с медицинскими сериалами, «пациент» чувствует себя плохо. Причем не только окончательный диагноз, но даже сами симптомы плохого самочувствия заказчик часто не в состоянии сформулировать четко.
Продукт просто не дает того, что заказчик ожидал. Нет продаж через приложение. Мало регистраций. Нет денежного выхлопа. Общее, не всегда формализуемое ощущение отставания от конкурентов и т.д.
Первое, что мы в Siberian.pro делаем в таких случаях — выполняем глубокий аудит продукта заказчика, чтобы понять реальную причину неэффективности имеющегося решения. Потому что велика вероятность, что двигать кровати (читай: делать новый продукт по старым лекалам) окажется бесполезно. И только после такой всесторонней оценки принимаем решение о том, как конкретно будем лечить «пациента».
Итак, аудит IT-продукта — это всесторонняя диагностика, оценка продукта — мобильного или веб-приложения, веб-сайта, комплексной системы и т.д. по нескольким ключевым направлениям: используемые технологии, инфраструктура, организация процессов, продуктовый аудит, UX/UI и некоторые другие. Подробнее — ниже. Но сначала не менее насущный вопрос.
Зачем нужен IT-аудит продукта?
Цель медицинской диагностики — опознать болезнь и помочь пациенту выздороветь. Аналогично здесь. Комплексная оценка приложения или IT-продукта помогает понять, почему продукт не решает проблему заказчика (а возможно, и проблему конечного потребителя), в чем конкретно заключается сложность, и что конкретно нужно сделать, чтобы все заработало как надо.
Обратите внимание на выделение: конкретно. Потому что на выходе заказчик получает не водянистый PDF с красивыми картинками и формулировками уровня «рекомендуется повысить вовлеченность аудитории при помощи средств геймификации», а точные указания на проблемы и не менее точные варианты их решения. Это важно, потому что цель заказчика — выздороветь, а не замазать косметикой трупные пятна.
Кто выполняет аудит?
В зависимости от вида аудита консультации по IT-продукту дают разные специалисты. Предполагаю, что в разных организациях это может быть реализовано по-разному, но у нас в Siberian.pro над аудитом обычно работают наиболее опытные разработчики, продуктовые аналитики и тестировщики. Каждый — в зоне своей компетенции, но обязательно в тесной кооперации с остальными.
А своими силами можно?
Можно. Но, как правило, не нужно. Конечно, IT — это не медицина, где чересчур вдохновенное самолечение может и к летальному исходу привести. Но и в нашей сфере опытом и добрым словом можно добиться больше, чем одним только добрым словом.
Специализированный провайдер услуги ИТ-аудита быстрее и точнее сможет определить источник проблемы. Не только за счет опыта, но и за счет готовых методик исследования рынка, стандартных опросных листов и кастомного инструментария.
Насмотренность тоже играет огромную роль. Внешний аналитик менее зашорен и не ограничен рамками одной сферы или ниши. Через специалистов Siberian.pro проходят десятки продуктов, а значит мы заранее знаем типовые проблемные места, можем быстро их локализовать и предложить несколько уже опробованных решений.
Отмечу еще один важный момент. Для внешнего подрядчика услуга аудита является профильной, а для сотрудников компании — нет. Следовательно, выполнять работы по аудиту продукта сотрудники будут в свободное от основной занятости время (читай: неэффективно). И это в том случае, если IT-отдел в вашей компании вообще есть.
Кроме того, сам факт того, что бизнес испытывает не вполне понятные ему самому трудности то ли с работой продукта, то ли с его позиционированием на рынке, говорит не в пользу самолечения. Впрочем, повторюсь, вполне реально воспитать команду аналитиков в собственном коллективе и проводить аудит исключительно своими силами.
Но какой именно аудит делать?
Виды аудита
Давайте перечислим основные виды аудита ИТ-продукта. Сразу оговорюсь, что классификация во многом условна и, так сказать, не приколочена гвоздями.
UX/UI-аудит
UX/UI-аудит нужен, когда есть признаки, что имеющееся решение неудобно использовать. Более того — именно это неудобство и является причиной проблем с продуктом. В нашей медицинской аналогии это будет ситуация, когда для здоровья пациенту достаточно поменять режим питания, отказавшись, например, от глютена.
Конечная цель, которую мы преследуем с помощью UX/UI-аудита ИТ, — добиться последовательного и цельного (consistent) пользовательского опыта, позволяющего решить задачи пользователя с минимальным количеством действий. Или даже вообще без них.
Несоответствие интерфейса продукта стандартам юзабилити и отсутствие CJM — это очевидные примеры потенциальных недоработок, которые подвергаются проверке в ходе ИТ аудита. Однако часто всплывают вещи далеко не очевидные, например, влияние психотипа пользователя на опыт его работы с приложением или даже локальные культурные особенности ЦА, которые ухудшают UX.
Результатом аудита являются конкретные рекомендации по улучшению пользовательского опыта и концепт нового UI, учитывающего эти рекомендации. Например, фрагмент UI после аудита, показанный на скриншоте выше, предлагает следующие улучшения:
- более рационально используется экранное пространство за счет улучшенной компоновки элементов;
- более удобный фильтр;
- гармоничное расположение элементов управления;
- увеличен размер кнопок и других важных элементов управления;
- выделено место для показа специальных предложений;
- уменьшен размер кнопок быстрого фильтра.
Технический аудит
Технический аудит ИТ выполняется, когда продукт не работает, как должен, по чисто техническим причинам — плохой код, негибкая инфраструктура, плохая организация данных, неэффективные алгоритмы и т.д. Конкретные причины как раз и должен выявить анализ.
Аналогия здесь — сельское здравоохранение, когда ближайший врач находится в 30 км (неудачная инфраструктура). Или, скажем, когда нужно поменять препарат (платформу, версию, используемую технологию) на другой, более современный.
Конечная цель технического аудита — добиться гладкой работы продукта, и как следствие, уменьшить затраты на разработку и всевозможные операционные издержки: обслуживание, поддержку, хостинг и т.д. В ряде случаев результатом проведения ИТ аудита будет отказ заказчика от услуг имеющегося подрядчика.
Несколько примеров проблем, которые аудит помогает выявить:
- проблемы совместимости продукта с устройствами или версиями OS;
- нестабильная работа под нагрузкой (нагрузочное тестирование);
- проблемы с производительностью (бенчмаркинг);
- баги (QA-тестирование);
- кривая архитектура системы;
- проблемы с масштабируемостью и т.д.
Например, в ходе технического аудита для одного из наших клиентов, специалисты Siberian.pro выявили несколько проблем, в том числе критичных:
- Актуальность версий используемых библиотек. Выяснилось, что порядка 200 библиотек требуют обновления в силу использования не самой свежей версии Python.
- Безопасность. Ряд бэкенд-библиотек, критичных для безопасности, также требовали обновления.
- Инфраструктура. Технический аудит проекта показал наличие неоптимальных и неиспользуемых интеграций, а также неэффективный пайплайн CD/CI, в котором многое делалось вручную. Это потенциально могло привести к проблемам с обновлением и поддержкой проекта в будущем.
- Качество кода. Аудит выявил большие проблемы с архитектурой кода и отсутствием внятной логики в его модульной структуре. В перспективе это могло вылиться в практическую невозможность дальнейшего масштабирования проекта. А у заказчика это было в планах.
- Best practices. Ход разработки далеко не всегда следовал рекомендуемым лучшим практикам.
По результатам аудита заказчик получил ряд конкретных рекомендаций по исправлению ситуации. Хотя в данном случае он предпочел просто разработать с нашей помощью новое приложение.
Аудит процессов разработки
В случае аутсорсной или собственной разработки с его помощью можно выявить узкие места в процессе разработки продукта, из-за которых разработка идет слишком долго или обходится слишком дорого, что в итоге делает и сам продукт нерентабельным.
Аналогия — назначенное правильное лечение не помогает, потому что пациент запивает таблетки грейпфрутовым соком. Или вообще их не принимает. Аудит ИТ процессов здесь может помочь.
Конечная цель проверки IT процессов — проанализировать весь ход разработки от и до, т.е. от постановки задачи и выработки требований к продукту, аналитики и продуктового дизайна, до программирования и менеджмента процесса разработки в компании. Максимально упростить эти процессы, убрать все лишние звенья и циклы — все то, что пожирает ресурсы компании, но само по себе не дает реального измеримого результата.
Вышеприведенный пример включал не только технический аудит, но и аудит процессов разработки. Вообще эти два вида IT-анализа тесно связаны и часто выполняются совместно.
В частности, именно в ходе аудита процессов мы выявили перегруженность CI/CD и отсутствие единообразия в подходах к разработке и документированию на разных этапах проекта. По результатам ИТ-аудита проекта мы дали заказчику ряд рекомендаций:
- добиться единообразия и согласовать производственные процессы между всеми участниками;
- создать стандарты процессов разработки, включая требования к коду, требования к документации, процессы тестирования и релиза и т.д.
- сформулировать максимально точное определение готовности продукта к релизу;
- стандартизировать работу с Git, например, обеспечить информативные комментарии к коммитам и Merge Requests.
Продуктовый аудит
Самый комплексный аудит АйТи-продукта в целом. В чем цель продукта? Как мы понимаем, что эта цель достигнута, по каким метрикам? Действительно ли продукт работает так, как заказчик думает, и решает проблемы его клиентов или это только кажется? Может быть, боль потребителя и вовсе в чем-то другом? Ответы поможет получить продуктовый аудит.
В качестве медицинской аналогии здесь отлично подходит анекдот про человека со сломанным указательным пальцем. Покажите, где болит. Здесь, вот здесь и даже здесь. Другая аналогия: выбран неправильный подход к лечению (гомеопатия) или неинформативные метрики состояния здоровья (меряем температуру, а надо делать КТ).
Продуктовый аудит помогает выявить проблемы с продуктом, лежащие вне плоскости его практической реализации. Например:
- Бизнес запустил программу лояльности, а пользователи ожидали онлайн-заказы через приложение.
- Бизнес позиционирует продукт как самый дешевый на рынке, но тот таковым не является.
- Бизнес анализирует количественные метрики взаимодействия пользователей с продуктом, но игнорирует качественные.
- Бизнес ориентируется на мужскую аудиторию, а по факту приложением пользуется женская.
- и т.д.
Диагностика подобных проблем выполняется поэтапно:
- С помощью инструмента Lean Canvas наглядно формируется модель бизнеса. Здесь пока нет никаких хитростей, вся информация уже имеется в голове руководителя, мы просто ее систематизируем.
Вот как это может выглядеть на примере анализа некоего мобильного приложения в сфере здравоохранения:
Визуализация с помощью Lean Canvas позволяет наглядно сформулировать ключевую проблему бизнеса и обозначить пути ее решения.
- Формулируются гипотезы — возможные причины проблем.
- Затем гипотезы проверяются:
а) строим CJM, чтобы понять, как вообще клиент находит продукт и принимает решение им воспользоваться, и можно ли этот путь сделать короче;
б) строим дерево метрик, чтобы понять, каким метрикам важно уделять внимание на каждом этапе жизненного цикла продукта;
в) определяем типичные user flow, т.е. последовательности действий пользователя во ходе взаимодействия с продуктом. Это не только позволяет найти проблемы в интерфейсе, но и потенциально выявить изначально неверные решения в проектировании продукта;
г) проводим интервью с ЦА, чтобы подтвердить или опровергнуть наши предположения.
- На основе полученной информации формулируется истинный источник проблемы и конкретные способы ее решения.
Это основные этапы ИТ аудита, но в реальности каждый случай, конечно, имеет свои нюансы, поэтому это лишь общий скелет.
Пример. Клиент обратился в Siberian.pro за доработкой интерфейса онлайн-магазина, чтобы поднять конверсию в покупки. Однако в ходе продуктового аудита выяснилось, что изначальная гипотеза о проблемах на этапе оформления заказа неверна. Да, там были UX/UI-проблемы и сам дизайн не был оптимальным, но основная доля посетителей терялась задолго до корзины.
Более детальный анализ поведения пользователей и глубинные интервью показали, что ЦА не до конца осознает ценность продукта нашего клиента, рассматривая его исключительно как товар, тогда как наш клиент предлагал еще и массу сопутствующих услуг, ценность которых никак не подчеркивалась в существующем предложении.
Т.е. наш заказчик работал в формате традиционного онлайн-магазина, предполагая, что именно этого ждет потребитель, и в результате был вынужден конкурировать с другими магазинами и крупными маркетплейсами. А правильнее оказалось изменить концепцию продукта и предлагать комплекс из товаров и услуг по подписке.
Бизнес-аудит
Конкретно мы такой вид аудита делаем только по запросу клиента, но для полноты картины его упомянуть надо.
Бизнес-аудит — это когда мы выходим за рамки конкретного продукта и рассматриваем позиционирование на рынке и метрики бизнеса в целом.
От проблемы к решению
Здесь нужно отметить один важный момент. Поскольку цель аудита — получить годный продукт, который качественно адресует проблему потребителя, любой из вышеприведенных анализов начинается с рассмотрения классической цепочки «Боль > Потребность > Решение».
Потребитель имеет какую-то боль/проблему. Как следствие, у него возникает потребность в устранении этой боли или проблемы и он начинает искать решение. Например, в виде приложения.
Так вот, разные виды аудита ИТ-продукта призваны оценить, в каком месте применительно к продукту эта цепочка рвется. Иногда решение, которое продукт предлагает клиенту, ничего не решает или решает не так, как ему нужно. Иногда проблема глубже, и решение нацелено не на реальную потребность потребителя, а на какую-то другую, которую, как нам кажется, он хочет удовлетворить. В ряде случаев приходится копать еще глубже и разбираться, а существует ли вообще та боль, которую продукт был призван облегчить?
Поэтому любой аудит это:
- Анализ целевой аудитории, ее болей и потребностей.
- Анализ целей, задач и УТП продукта по отношению к ЦА.
- «Распаковка» продукта — что, как и почему в нем реализовано. Как именно продукт решит проблему ЦА.
- User flow и Customer Journey Maps.
- Карта ключевых метрик, с помощью которых мы можем понять, что продукт достигает заявленных целей и решает проблемы потребителя.
Шаблоны типа Lean Canvas отлично помогают структурировать всю необходимую для аудита информацию. Естественно, исходные данные для аудита мы черпаем из взаимодействия с заказчиком. Например, в Siberian.pro для этого существуют специальные опросные листы, примерно такие:
Как понять, что IT-продукту нужен аудит?
В финальной части статьи попробую сформулировать основные признаки того, что продукт нуждается в том или ином виде аудита.
Врач понимает, что пациент болен, по симптомам. Симптомами в данном случае будут различные признаки того, что продукт не достигает своих целей. Именно поэтому любая разработка по-хорошему должна начинаться с обозначения целей продукта и выбора метрик, с помощью которых можно оценить успешность достижения этих целей.
Метрики бывают количественные и качественные. Количественные показатели можно точно измерить, а качественные лишь оценить. Кроме того, некоторые метрики относятся только к маркетингу — по ним мы отслеживаем успех продукта на рынке. Другие — к бизнесу в целом. По ним можно оценить влияние продукта на финансовую успешность бизнеса.
Отклонение метрик от желаемых значений является симптомом того, что с IT-продуктом что-то не в порядке.
Основные симптомы того, что продукту или приложению нужен аудит, следующие:
- Низкая конверсия. Пользователи есть, но в клиентов они конвертируются плохо.
- Низкая вовлеченность. Пользователи слабо взаимодействуют с продуктом. Например, небольшая продолжительность рабочей сессии или малое их количество.
- Низкий retention rate. Пользователи не возвращаются к приложению.
- Низкая пожизненная ценность на клиента (LTV). Например, если клиент не продлевает подписку или остается на бесплатном тарифе.
- Низкий средний доход на пользователя (ARPU). Может указывать на то, что выбрана не самая эффективная модель монетизации продукта.
- Низкий ROI. Может указывать на завышенную стоимость разработки или поддержки продукта.
- Высокий процент оттока клиентов (churn rate). Продукт не «цепляет» клиентов и они уходят.
Среди качественных показателей можно выделить следующие:
- Плохие отзывы пользователей. Даже если в отзывах мало конкретики, сам факт большого объема негатива указывает на проблемы в той или иной части цепочки «Боль > Потребность > Решение».
- Обзоры, опросы, интервью. К любому экспертному мнению, даже если это мнение конкурентов, стоит прислушаться.
- Сравнение с конкурентами. В силу того, что доступа к данным конкурентов нет, сравнение во многом идет по качественным критериям. Грубо говоря, бизнес чувствует или опасается, что его продукт чем-то уступает конкурентам – по функциональности, по используемым технологиям, по дизайну UI, и т.д.
- Продукт не достигает своей цели. Например, ставилась цель довести долю продаж товара через приложение до 20%, но она не достигнута за намеченное время.
- Запланированное масштабирование продукта испытывает трудности. Не самый очевидный симптом. Потому что вендору проще предположить, что в ходе масштабирования возникли проблемы. Тогда как дело в изначально неправильно спроектированной архитектуре продукта или в непонимании своей ЦА. И именно это является реальной причиной пробуксовок и проблем с масштабированием. Антибиотики не помогают, но причина не в том, что антибиотик плохой, а в том, что у пациента вирус, а не бактериальная инфекция.
- Продуктом не пользуются сотрудники самой компании. Неформальный, но порой весьма показательный критерий.
Если вы как CEO, CMO или коммерческий директор компании наблюдаете какие-то из этих симптомов, возможно, имеет смысл сдать анализы обратиться к аналитике, чтобы понять причины, выявить проблемы и недоработки на всех стадиях разработки IT-продукта. А потом перейти к конкретным действиям, которые позволят продукту «выстрелить».
***
Спустя две сотни успешно завершенных проектов мы в Siberian.pro понимаем, насколько важно заранее определить направление развития IT-продукта для его успеха. А если этого по каким-то причинам не было сделано, для исправления ошибок всегда есть аудит ИТ-продукта. С удовольствием возьмем его на себя.
Больше историй о разработке, продуктовой аналитике и управлении командой удаленных сотрудников – в моем Telegram-канале.