Профессиональный технический аудит от любительского (назовем его так) будет отличаться глубиной погружения. Конечно, можно формально запустить проверяющие код программы (их называют линтеры), и остановиться на этом, сказав: «Вася, все плохо, давай переделывать». Однако при таком подходе не станет понятно, что именно в продукте плохо работает, и как это чинить.
Оговоримся, что речь тут пойдет не о формальном аудите, когда важен сам факт его проведения. Мы за пользу, поэтому аудит ради аудита не рассматриваем вообще. Все, что вы прочтете дальше, будет относиться к описанию проведения технического аудита продукта, результатом которого становится реальное улучшение системы, а не просто листок с ее недочетами.
Когда нужен аудит
- Не ясно, как развивать продукт и делать его работающим на новые бизнес-цели
- Сервис не выдает прежних результатов (конверсия, производительность, показатели в поиске), хотя все вроде работает
- Нет времени на пересмотр системы, потому что команда занята другими более срочными задачами
- Задачи, которые раньше разработчики закрывали за пару дней, теперь занимают по несколько недель
Внешний аудит – это свежий взгляд на разработку. Он помогает оценить текущее положение дел или то, как на продукт «прикладывается» стратегия его развития. Чтобы понять, как сделать продукт лучше, нужно объективно измерить его характеристики. Об этом и поговорим.
Исследовательская задача и польза решения
Когда к нам приходят за аудитом, мы делаем его «как для себя». Дело в том, что после аудита отношения с заказчиками зачастую не заканчиваются – мы уже в качестве разработчиков подхватываем проект на развитие и начинаем заниматься его улучшением. Заказчик видит, что мы хорошо погружаемся в продукт, быстро понимаем его внутреннее устройство и можем предложить полезные изменения, которые принесут пользу бизнесу. Поэтому подход к аудиту всегда нацелен не на формальную проверку системы, а на «что бы нас не устраивало, если бы продукт разрабатывали мы?».
Основная часть нашей экспертизы построена на разработке, а не на аудите, и это плюс для наших заказчиков – после аудита они получают не просто список проблем, а еще и список возможных решений в предложенных обстоятельствах.
Например, один из наших недавних проектов – аудит для Buddy.ai. Ребятам нужно было узнать, как сделать сервис готовым к расширению и привести на него больше органического трафика. Заказчик понимал, что сил и экспертизы внутренней команды перестало хватать для реализации желаемой функциональности и развития продукта. Мы изучили кодовую базу сервиса, протестировали его производительность и возможности к масштабированию.
После исследования мы описали ряд несовершенств, прямо влияющих на «боли» заказчика, и предложили улучшения. Среди них: рефакторинг, подготовка к расширению сервиса – сегментирование и оптимизация кода, смена SPA-подход на статическую генерацию контента для приведения трафика и возможности SEO-оптимизации.
Задачи по улучшению продукта, которые мы определили по результатам аудита, были нами же оценены и приоритезированы с оглядкой на бизнес-цели.
Заказчик должен понимать, что точно нужно сделать прямо сейчас, а что можно отложить на попозже, при этом не потеряв в эффективности и работоспособности продукта.
Целеполагание: не распыляться на все подряд
Обычно продукты, которые уже зарекомендовали себя на рынке и кому-то приносят пользу, расширяются. Добавляются новые фичи, и количество потенциальных проблем и поломок растет. Если заняться исправлением всего и сразу, можно не закончить никогда, ведь совершенству предела нет.
Чтобы не закапываться в аудите навечно, стоит его правильно осмыслить, поставив цель его проведения. Например, это может быть оценка возможностей сервиса к масштабированию (как в примере выше), или мы хотим улучшить пользовательский опыт с точки зрения какого-то отдельного процесса среди массы доступных юзерам. Словом, должно быть такое место в продукте, улучшение которого сильнее всего нужно компании на текущем этапе.
Четкая и понятная цель поможет сфокусироваться на критических проблемах и оставить на потом те, что не влияют на достижение цели. А правильная приоритезация задач – один из ключей к здоровому проекту. Поэтому вместе с отчетом по аудиту заказчику нужно предоставить список решений с приоритетами. Возможно, на текущем этапе он захочет исправить только «горящие» проблемы, ведь уже после этого сервис начнет работать лучше.
Пояснения и дообучение
Бывает так, что заказчик вместе со своей командой сразу видит связь между существующий в продукте проблемой и ее решением. Например, в нашем кейсе с Buddy.ai владелец продукта ясно понимал, что проблемы производительности сервиса связаны с отсутствием сегментации некоторых частей кода, которые были перенесены из конструктора когда-то. Поэтому мы быстро согласовали необходимость разделения и структуризации кодовой базы проекта для роста производительности. Тут связь была очевидной.
Не всегда, однако, решение проблемы и его необходимость оказываются прозрачными. Порой нужно объяснить выводы аудита заказчику, потому что ему может недоставать технических знаний для понимания сути решения. Например, однажды среди проблем системы мы обнаружили слишком медленную скорость сборки проекта. Для владельца продукта это сперва показалось мелочью – ему не было понятно, зачем прицельно работать над этим показателем. Мы объяснили, что, если вместо нескольких секунд сборка занимает несколько минут, а команда разработчиков большая, умножаем одно на другое и получаем значительное замедление процесса разработки продукта в целом. Это пусть и не самый очевидный недочет, но его исправление необходимо для улучшения системы.
Важно дать заказчику понять суть найденных проблем и их решений ровно настолько, чтобы он не допустил подобных недочетов в будущем и знал, что должна сделать команда для этого. Иначе говоря – чем более полной будет картина по результатам аудита, тем лучше и качественнее он проведен. Заказчик аудита, конечно, тоже должен быть готов к «погружению», но это уже другая сторона вопроса.
Для чего мы это написали
Чтобы развеять предрассудки и сформировать ожидания. Само по себе понятие аудита кажется чем-то формальным и далеким от практического улучшения системы. Мы же считаем, что технический аудит ИТ-продукта нужно воспринимать как анализ крови у людей. Без анализа нельзя подобрать правильное лечение, а значит и по-настоящему помочь пациенту. Точно так же и без аудита вряд ли получится узнать, что именно сбоит в системе и мешает достичь желаемых результатов.
