Всем привет! Меня зовут Наталья Егорова, я руководитель направления в кластере цифровых продуктов и партнерств в МТС Диджитал. Мы с коллегами ведем внутрикластерные проекты, — улучшаем и автоматизируем процессы, обеспечиваем кризис-менеджмент. Это привычная работа, которая со временем затягивает. Но иногда из нее удается вырваться и поучаствовать в настоящих шпионских играх: проявить свои лучшие софт-скилы, дотошность и накопленный опыт.

Как-то раз в наш кластер должна была влиться новая компания, и нас с коллегами пригласили провести due diligence — риски и возможные расходы на интеграцию стороннего продукта. Бизнесу наша работа понравилась, и мы приняли участие уже не в одной такой «шпионской игре». В них нужно было резко погрузиться в рабочие процессы других команд, оценить их и понять, пытаются ли от тебя что-нибудь скрыть. В этом материале я расскажу, зачем это нужно компании и как выглядит изнутри.

Что же это за авантюра

Due diligence — оценка рисков перед приобретением или поглощением нового продукта или компании. Он бывает разных видов:  юридический, финансовый, налоговый и другие. В этом материале я расскажу про технический due diligence, в котором и принимаю участие.

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

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

Купленные продукты попадают в экосистему МТС, распределяются в кластеры по направленности своего бизнеса. Затем, если это нужно, начинается их адаптация под корпоративные стандарты. Я помогаю интегрироваться тем продуктам, которые попадают в наш кластер, и в моих же интересах, чтобы не было никаких неприятных сюрпризов, а новые коллеги уже знали меня в лицо.

Например, от купленного продукта нам могут достаться цели на год, которые мы в глаза не видели. А их нереально выполнить из-за каких-то технологических особенностей. Допустим, надо поднять удовлетворенность, а пользователи страдают из-за скорости работы сайта. А он плохо работает, потому что тормозит база, которая не предназначена для таких нагрузок. Для нас это означает потерю времени и ресурсов на замену подходящим решением или долгую и неинтересную оптимизацию. Участие в due diligence позволяет увидеть такие вещи заранее и подготовиться к ним.

Как due diligence выглядит изнутри

Ты сидишь за компом, серфишь котиков пишешь очередную документацию или разбираешься с архитектурной схемой. Как вдруг тебе прилетает внезапная встреча через 15 минут. По сути нас вызывают «по свистку», далее начинается обсуждение скоупа и сроков самого due diligence. Как правило, заказчиком оценки очередного проекта выступает бизнес: он идет со своей задачей к команде координаторов из Департамента управления технологиями. Коллеги заполняют бриф и собирают команду, выступая первой точкой контакта.

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

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

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

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

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

Где начинаются шпионские игры

При глубокой оценке проекты выглядят вовсе не такими, какими кажутся сначала. Но это не всегда объективно плохо. Due diligence тем и интересен, что все зависит от деталей и контекста.

Допустим, МТС покупает сервис и рассчитывает, что он еще два года будет выдавать какой-то уровень прибыли. Но мы поставим под сомнение реализуемость этого плана, если железо у сервиса на пределе. Это значит, что достаточно дать ему чуть больше нагрузки — и все упадет.

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

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

Вот можно ли без контекста однозначно сказать, что монолит — это хорошо или плохо?

На мой взгляд, нельзя. Допустим, нам надо налить в сервис много фич и нагнать огромное количество пользователей. В этом случае монолит — это плохо, поскольку он будет неудобен. Его надо распиливать на микросервисы сразу же после покупки. Но планы бизнеса могут быть другие. Возможно, фич планируется добавлять не так много (и не так быстро). Да и вообще стоит присмотреться, как продукт будет существовать в экосистеме, как вольется в коллектив команда разработки, а только потом планировать следующие этапы. В этом случае монолит можно и не трогать. Так что в зависимости от контекста мы предлагаем разные способы минимизации рисков.

К сожалению, у фаундеров могут быть свои мотивы. Мы часто сталкиваемся с тем, что нам отказываются предоставить какую-то информацию. Одни хотят выглядеть лучше, чтобы более выгодно продать бизнес. Другие фаундеры участвуют в нескольких сделках в разных венчурных фондах: на одном из due diligence у меня сложилось впечатление, что в МТС не были заинтересованы, а использовали только для того, чтобы поднять цену у другого покупателя.

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

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

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

А самой неожиданной находкой на моей памяти была копия приобретаемого продукта, выпущенная для других рынков. Кто-то из команды совершенно случайно глянул это приложение и обратил внимание, что оно очень похоже на версию, которую мы смотрели. Мы сделали сниффинг трафика: оба приложения использовали одинаковую структуру методов, имена эндпойнтов и форматы данных. А значит у них одна кодовая база! Для нас это является потенциальным юридическим риском владения, поэтому сделку заблокировали юристы.

Что нужно сеньор-разведчикам

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

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

Моя задача — донести, что мы прекрасно понимаем их «стартапность». А здесь нужны эмпатия, умение наладить контакт и выстроить доверительные отношения. Никто не собирается предъявлять к ним требования как к внутренним продуктам. Просто нужно понять, как потенциально они будут встраиваться в экосистему и развиваться уже внутри МТС.

Подводя итоги

В целом due diligence — отличный способ отвлечься от рутины. Мне нравится узнавать подробности работы компаний в других отраслях. Каждый прошедший через мои руки проект помогает лучше понимать риски при разных наборах вводных.

Это еще и новые знакомства с будущими коллегами, с которыми потом предстоит интегрировать приобретение в экосистему продуктов. Due diligence позволяет настроить базовый уровень доверия друг другу относительно технических компетенций.

Кстати, полученный опыт можно использовать и на текущих проектах компании — вне всяких поглощений. Допустим, когда к нам в кластер попадает новая команда или продукт. Чтобы понять, насколько он зрелый, как выстроены процессы и т. п., мы применяем классические техники due diligence. Да и в целом полезно иногда пройтись по соседним командам, оценить, как у них растет зрелость процессов, как развиваются продукты или, возможно, существуют проблемы.

На этом у меня все, готова ответить на ваши вопросы.