Как отличить хороший аудит — 10 признаков

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

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

1. У аудитора есть серьезный опыт в разработке

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

2. Перед аудитом ставится конкретная цель и аудитор о ней знает

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

3. Зафиксированы границы аудита и отсутствует KPI по количеству страниц

Если вы хотите, чтобы исполнитель задумывался о сути, а не об объеме и форме как в школьном сочинении, то не считайте объем отчета характеристикой качества проведенного аудита. 

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

4. Кроме границ у аудита есть бэклог с детальными задачами

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

Утверждение перечня задач в бэклоге — дополнительная возможность направить аудиторов в нужном направлении.

5. Команда заказчика готова давать аудитору дополнительную информацию

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

6. Аудитор готов объяснить каждый вывод аудита

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

7. Аудитор готов дообучить вас

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

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

8. У аудита зафиксирован бюджет, но работы ведутся по Time and Materials

Чтобы перечень задач в бэклоге был гибким, а аудитор был готов отвечать на максимум вопросов и дообучать заказчика, у вас должна быть подходящая модель контрактования — Time and Materials.

Так как задача аудита исследовательская, важно чтобы контракт был гибким. Исполнитель не должен задумываться над каждой вашей просьбой «а не увеличит ли это мои планируемые затраты на проект без увеличения доходов?» С другой стороны, вы должны быть уверены, что сможете сказать на середине работ «давайте вот это посмотрим поглубже, а вот это не нужно так глубоко копать».

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

9. Назначен график еженедельных статус встреч

Аудит — это исследование, а не просто инженерная задача, поэтому вам нужны встречи для корректировки направления. «А туда ли мы копаем» или нужно еще изучить и другие направления. Это поможет на ходу отделять критичные проблемы от тех, которые легко исправить.

10. Результаты аудита обсуждены с текущей командой разработки

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

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

Обязательно соберите обе команды вместе в контролируемой среде, чтобы они сообща смогли прийти к общим выводам. Есть шанс, что во время обсуждения результатов аудита с текущим исполнителем может начаться холивар, но если и вы адекватный, и подрядчик адекватный, и аудитор адекватный, то все пройдет гладко. Главное следить за тем, чтобы обсуждение шло на языке проблем и фактов, а не мнений.

Бывают и другие случаи, в которых аудит помогает улучшить ситуацию. Например:

• задачи, которые раньше делались за 2-3 дня, теперь тянутся неделями,
• сервис стал тормозить,
• у вас нет уверенности, что продукт, написанный подрядчиком, сможет развивать внутренняя команда.

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