Я считаю, что аудиты – одна из сильно недооцененных и мало используемых практик в отечественных IT компаниях. Зачастую причиной этого является негативный опыт с бюрократизированными и бессмысленными аудитами, инициатива проведения которых исходила от руководства компании с целью проверок или насаждения общих стандартов. Естественно, подобные процедуры воспринимаются негативно членами команды на всех уровнях и приводят к непродуктивной трате времени. В этой статье хотелось бы рассмотреть аудиты с точки зрения реальной помощи команде, проекту или компании. Для этого затронем вопросы мотивации проведения аудита, пробежимся по различным видам аудита и разберемся кто может его проводить.

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

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

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

Какие виды аудита бывают? На практике мне приходилось сталкиваться как с общим аудитом, который включает в себя все аспекты разработки, так и с узкопрофильными. Приведу несколько примеров:

– процессный аудит, в рамках которого нужно понять, насколько успешно получается следовать Agile ценностям, работать по методологии XXX, делать Agile трансформацию на всех уровнях или добиваться Continuous Delivery;
– архитектурный аудит с целью сделать ревью текущего архитектурного решения, убедиться что оно удовлетворяет NFR (нефункциональным требованиям), готово к масштабированию под новые цели бизнеса, максимально эффективно решает изначальные задачи;
– инфраструктурный аудит, который помогает сделать оценку текущей инфраструктуры, эффективности ее использования с точки зрения бюджета, скорости развертывания и масштабирования, а также операционных расходов на поддержку;
– аудит уровня безопасности, который помогает профессионально оценить уровень следования NFR и стандартам безопасности, а также обнаружить потенциальные проблемы и уязвимости.

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

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

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

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

В этом случае аудит стоит недорого и приносит очень большую пользу.