Нояб. 18

Что делать, если на вас падает Due Diligence Audit. Опыт РМ'а

Меня зовут Константин Болотин. Я Project Manager в компании Sigma Software. Я управляю сложным проектом в AdTech-домене, который призван помочь корпорациям в построении и оптимизации их рекламных кампаний. На проекте мы делаем полноценный Product Development от идеи и гипотезы до релизов и бага на Production. Сотрудничаем с Google и Facebook. Всего на YouTube около 4 000 000 каналов, мы отсортировали более 100 000 самых популярных worldwide и плотно с ними работаем. Далее в статье будет чуть больше деталей о проекте, но NDA никто не отменял.

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

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

Проект

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

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

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

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

Аудит

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

Из письма мы также узнали, что технический аудит будет касаться:

Software Architecture Review.
SDLC, Code & Documentation Review.
System Architecture, DevOps, Security.
Product Development Processes, Methodology & Tools.
Ability to Execute.

На первом этапе был звонок с представителями аудиторской компании. Изучив примерную адженду, стало понятно, что необходимо обновить документацию на Confluence, а именно заархивировать устаревшие материалы. Также необходимо было в кратчайшие сроки внести изменения в архитектурную диаграмму, ведь с этого начинается технический аудит. Более того, необходимо было поделиться всевозможными доступами во все части проекта.

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

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

Ко второму звонку никакой специальной подготовки не было просто потому, что вопросы заранее получить не удалось. Но все снова прошло гладко. На этот раз представитель аудиторской компании был один, управились за час, причем около получаса наш владелец продукта повторно объяснял бизнес-идею системы. Вопросы были простые и скорее уточняющие: про Branching Strategy, масштабирование системы, планы и roadmap.

Из интересного:

Аудиторы, кроме всевозможных доступов во все части системы, просили ссылки на LinkedIn-профайлы сотрудников. Это показалось странным, и мы их не шарили, согласовав это с клиентом.
Аудиторы хорошо подкованы технически и очень взрослые. Вот прям взрослые. В наших реалиях редко встретишь пожилого человека, который расспрашивает тебя о GitHub, Branching или Scrum. Надо морально быть к этому готовым.
Когда они узнали, что у нас в системе имеется Machine Learning классификатор, то запросили детальное описание его структуры, частей кода и принципа работы. Согласовав с клиентом, решили обойтись верхнеуровневым описанием и при необходимости детальным пояснением на звонке. Выслушав нас, аудиторы предложили помощь своих коллег из Data Science, чтобы внедрить «непоправимые» улучшения в наше решение. Мы от этого предложения отказались. А что именно улучшить и как, в свою очередь, отказались рассказать аудиторы.

Результат

Обратной связи не было достаточно долго, и только через 3–4 недели Product Owner сообщил, что технический аудит пройден отлично. Я искренне был этому рад, хотя другого результата и не ожидал, теперь было очень интересно узнать детали и увидеть отчет. Еще через 3–4 недели удалось получить и его. Отчет подтвердил успешное прохождение нашей командой технического аудита. По каждому разделу был приведен краткий комментарий от аудитора и его отзыв, как обстоят дела.

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

Кроме того, получили от аудиторов один небезынтересный комментарий: «The Sigma Software team executes well on the requirements they are given. However, they are limited on their ability to contribute in the reverse direction».

Вот это прям в точку. Мы действительно ограничены по разным причинам, но нам точно есть куда развиваться. Что предприняли? Во-первых, начали еще глубже погружаться в доменные знания продукта. А во-вторых, решили более плотно поработать с Product Owner по всем Scrum-церемониям. В двух словах, что предприняли:

Было: создание общего roadmap → совместная работа по приоритетам и требованиям → релиз-пленнинг → релиз.

Стало: совместное создание roadmap → совместная работа по приоритетам и требованиям → общие grooming sessions и работа по UX/UI → общие Sprint Plannings → поставки и User Acceptance Testing каждый спринт.

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

Советы

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

Как зачастую бывает, аудит начинается с просмотра архитектурной диаграммы. Само собой разумеется, что ее надо держать в актуальном состоянии, это очевидно. А вот что не очевидно, так это то, что ее надо презентовать другим техническим специалистам, обосновывая те или иные решения, которые, собственно, и привели ее к такому виду. Я рекомендую потренироваться разок над презентацией диаграммы перед аудитом, и вполне возможно, вы определите для себя, что надо вспомнить или дополнительно изучить.
Задокументируйте ваш актуальный SDLC. Аудиторы, как и большинство РМ’ов, понимают, что многие работают по «скраму собственного приготовления» и когда видят у вас в документации красивую Scrum-диаграмму и что все написано как в книжке, это прям красный флаг: документация ради документации и повод для дополнительных вопросов.
Зарегистрируйте ваш техдолг. В документации, в задачах, да где угодно, главное, чтобы вы понимали, что у вас есть, и управляли им. В нашем случае много внимания уделили пояснению подхода к менеджменту техдолга и его отслеживанию.
Внимательно следите за тем, какие артефакты у вас просят для проведения аудита. Например, я все еще не знаю, только догадываюсь, зачем аудиторам LinkedIn-профайлы коллег. Ведь на аудит это никак не влияет. Более того, сперва они просили root-доступы в репозитории, когда им дали read-only, никаких вопросов или проблем не последовало. Может быть, это часть проверки? Дадут ли без разбирательств права админа :)

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

Вывод: польза от аудита не в фидбэке, а в подготовке к этому аудиту :)

Чтобы не пропустить новые статьи Константина Болотина — подпишитесь на него в телеграм-боте Ленты DOU.