10 отличий качественного аудита от халтуры
Привет, это Максим Павлов из KTS. Мы создаём IT-продукты для бизнеса.
Наткнулся я на комментарий под статьёй, что ещё не было ни одного аудитора, который бы не сказал, что у вас всё плохо и надо переделывать. Такое и правда часто бывает. Рассказываю, как ещё можно отличить хороший аудит от плохого
Помимо подхода «всё плохо, переделывайте» бывает так, что компании, которые профессионально занимаются только аудитом, ограничиваются запуском линтеров — программ для автоматической проверки кода на соответствие стандартам. Отчеты линтеров они преобразуют в отчет для заказчиков, кроме этого выдают крохи экспертной информации. В итоге заказчик не получает глубокого понимания текущей ситуации.
Наш подход сильно отличается. Поскольку основная специализация KTS — создание цифровых продуктов, а не их аудит, поэтому и смотрим мы на код как разработчики. С позиции «если бы проект передавали нам на развитие, что бы нас смутило?»
Например, недавно к нам обратились Level Group с задачей провести аудит их сайта. По итогам заказчику удалось определить новые точки роста и лучше понять техническую сторону разработки. Выводы заказчика из аудита и рассказ, как Level выросли из стартапа в топ-3 застройщиков Москвы за 7 лет, — в статье Натальи, руководителя разработки сайта Level.
Дальше рассказываю по пунктам, чем плодотворный аудит отличается от формального запуска линтеров или критикования всего и всех.
#1. У аудитора есть серьёзный опыт в разработке
Если цель у аудита не формальная, то желательно искать как подрядчика не компанию-аудитора, а компанию с подтвержденным опытом создания продуктов на релевантном стеке. Кроме непосредственно аудита у компании с опытом в разработке можно в рамках работ по аудиту узнать способы решения существующих проблем.
#2. Перед аудитом ставится конкретная цель и аудитор о ней знает
Если проект кому-то нужен и активно развивается, то у него в любом случае будут места, которые реализованы плохо. Наличие цели аудита позволяет сфокусироваться только на тех проблемах, которые напрямую коррелируют с целями бизнеса.
В нашем случае это был вопрос, насколько сервис готов к внедрению сложных фичей и насколько код отчуждаем от подрядчика. Каждый участник аудита на нашей стороне исходил из этой цели при анализе. Нюансы, не относящиеся к цели, можно пропустить и копать лишь в сторону цели.
#3. Зафиксированы границы аудита и отсутствует KPI по количеству страниц
Если вы хотите, чтобы исполнитель задумывался о сути, а не об объёме и форме как в школьном сочинении, то не считайте объём отчёта характеристикой качества проведённого аудита. В нашем случае было 80 страниц отчета по фронтенду и 10 страниц по бэкенду, но это не значит, что бэк был проанализирован хуже.
Лучше договоритесь об объективных границах, в которых должен быть проведен аудит. В случае с сайтом это ключевые разделы, страницы и функции, которые должны обязательно попасть в аудит.
#4. Кроме границ у аудита есть бэклог с детальными задачами
Детальный бэклог сложно составить перед стартом проекта, не увидев код. Поэтому первую неделю после получения доступов лучше посвятить составлению детального бэклога исходя из перечня элементов системы и планируемых работ.
Утверждение перечня задач в бэклоге — дополнительная возможность направить аудиторов в нужном направлении.
#5. Команда заказчика готова давать аудитору дополнительную информацию
Сначала мы думали, что хватит дать доступ к коду, но в итоге для рекомендаций пришлось погружаться в типовые задачи, состав команды как на стороне подрядчика так и заказчика, планы по росту, наиболее часто изменяемые фичи.
#6. Аудитор готов объяснить каждый вывод аудита
Заранее договоритесь, что каждый непонятный пункт должен быть объяснен, а также должны быть описаны риски, которые вам грозят из-за существующих проблем, а также пути их устранения.
#7. Аудитор готов дообучить вас
Одна из задач заказчика — смочь в следующий раз больше влиять на процесс разработки. Для этого заказчику нужно быть готовым изучать детали и погружаться в технику.
Аудитор должен быть готов объяснять смежные области, понимание которых нужно для составления полной картины. Важно, чтобы заказчик не только понял, в чём суть проблем и к чему они ведут, а настолько разобрался, чтобы не допустить этих ошибок в будущем.
#8. У аудита зафиксирован бюджет, но работы ведутся по Time and Materials
Чтобы перечень задач в бэклоге был гибким, а аудитор был готов отвечать на максимум вопросов и дообучать заказчика, у вас должна быть подходящая модель контрактования — Time and Materials.
Так как задача аудита исследовательская, важно чтобы контракт был гибким. Исполнитель не должен задумываться над каждой вашей просьбой «а не увеличит ли это мои планируемые затраты на проект без увеличения доходов?» С другой стороны, вы должны быть уверены, что сможете сказать на середине работ «давайте вот это посмотрим поглубже, а вот это не нужно так глубоко копать».
При этом любое исследование можно проводить бесконечно. Поэтому бюджет аудита должен быть зафиксирован и соразмерен планируемому эффекту для бизнеса. Обе стороны должны понимать границы бюджета и принимать решения по ходу работ исходя из этих границ.
#9. Назначен график еженедельных статус встреч
Аудит — это исследование, а не просто инженерная задача, поэтому вам нужны встречи для корректировки направления. «А туда ли мы копаем» или нужно ещё изучить и другие направления. Это поможет на ходу отделять критичные проблемы от тех, которые легко исправить.
#10. Результаты аудита обсуждены с текущей командой разработки
В разработке, как и в любой инженерной задаче, всегда есть как минимум несколько вариантов решения одного и того же вопроса. А значит, когда сторонняя команда проводит аудит, её выводы могут расходиться с привычным подходом команды разработчиков.
Поэтому важно, чтобы аудиторы договорились с командой разработчиков о том, как будут решаться обнаруженные проблемы, ещё до окончания своей работы. В противном случае велик риск столкнуться с ситуацией, в которой команда разработчиков посмотрит на итоги аудита и скажет, что либо так никто не делает, либо предлагаемые решения — попросту лишние.
Обязательно соберите обе команды вместе в контролируемой среде, чтобы они сообща смогли прийти к общим выводам. Есть шанс, что во время обсуждения результатов аудита с текущим исполнителем может начаться холивар, но если и вы адекватный, и подрядчик адекватный, и аудитор адекватный, то всё пройдёт гладко. Главное следить за тем, чтобы обсуждение шло на языке проблем и фактов, а не мнений.
Зачем я написал эту статью
Очень надеюсь, что у вас разработка идёт бодро и ничего не тормозит.
Если вам, как и Level Group, нужен свежий взгляд на вашу разработку при изменении стратегии роста или объективно измерить характеристики качества сайта, то приходите к нам за аудитом.
Бывают и другие случаи, в которых аудит помогает улучшить ситуацию. Например:
- задачи, которые раньше делались за 2-3 дня, теперь тянутся неделями,
- сервис стал тормозить,
- у вас нет уверенности, что продукт, написанный подрядчиком, сможет развивать внутренняя команда,
Пишите в Телеграм.