При покупке технологической компании вы покупаете не только продукт. Вместе с ним переходят архитектура, команда, данные, контракты и целая история решений, за последствия которых придётся платить уже новому владельцу.
Поэтому технологический due diligence — не конкурс красоты кода. Его задача — проверить, сможет ли бизнес выполнить план после сделки, какие обязательства ему достаются и что может оказаться дороже, чем выглядит сегодня.
Сначала договоритесь, зачем вообще покупаете компанию
Один и тот же технологический ландшафт может быть вполне подходящим для самостоятельного бизнеса и дорогой проблемой для покупателя, который собирается объединить несколько продуктов.
Если цель — сохранить компанию как отдельный актив, в центре внимания будут устойчивость продукта, способность выпускать изменения, зависимость от ключевых людей и экономика эксплуатации. Если покупатель рассчитывает перенести клиентов, объединить данные или заменить платформу, нужно совсем другое исследование.
Поэтому первый документ проверки — не архитектурная схема. Это короткое описание ожиданий от сделки: что должно продолжить работать без перерыва, что планируется объединить, какие возможности нужно сохранить и какие изменения предполагается провести после покупки.
Без этих ответов аудит легко начинает бороться с монолитом, хотя настоящая проблема может находиться в правах на данные или в невозможности отделить продукт от подрядчика.
Найдите системы, на которых действительно держится бизнес
Не каждый репозиторий стоит одинакового внимания. Сначала полезно пройти путь от действия клиента до бизнес-результата: где создаётся заказ, проходит оплата, рассчитывается стоимость, исполняется обязательство, сохраняется информация.
Затем — посмотреть, какие системы и люди обеспечивают этот путь. Какие интеграции нельзя остановить? Где используется ручная операция, о которой не знают за пределами команды? Что произойдёт, если компонент окажется недоступен не на минуту, а на рабочий день?
Хорошая карта не обязана быть красивой. Она должна показать критические зависимости и владельцев. Если на схеме всё просто, а для объяснения реального процесса нужен один конкретный инженер, это уже важное наблюдение.
Просите свидетельства, а не только ответы
На вопрос «у нас есть резервное копирование?» почти всегда можно получить уверенное «да». Это ещё не говорит о том, что данные действительно получится восстановить.
Гораздо полезнее попросить показать последний успешный сценарий восстановления, историю серьёзного инцидента, путь изменения от задачи до production, примеры отмены релиза и способ выдачи доступов. Не обязательно проводить полноценное техническое испытание всего продукта. Важно хотя бы на критических участках сравнить описание процесса с тем, как он работает на практике.
Здесь нужно разделять три вещи: подтверждённый факт, объяснение команды и гипотезу проверяющего. В отчёте они не должны превращаться в одинаково уверенные выводы. Отсутствие доказательства — не доказательство проблемы, но и не основание считать риск закрытым.
Архитектуру оценивайте по цене изменений
Старый стек не равен плохой архитектуре. Монолит может годами помогать бизнесу меняться быстрее сложной системы из сервисов. И наоборот: модная платформа может быть так связана внутренними зависимостями, что небольшая доработка требует согласования нескольких команд.
Важны не названия технологий, а ограничения: какие изменения регулярно откладываются, где релизы требуют ручной координации, какие компоненты нельзя масштабировать отдельно, почему команда опасается трогать определённый участок.
Попросите разобрать недавнюю нетривиальную доработку: где возникла задержка, что пришлось менять помимо целевой функции, сколько зависимостей обнаружилось по дороге. Такая история часто рассказывает об архитектуре больше, чем десяток диаграмм.
Но даже это не повод автоматически рекомендовать переписывание. Нужно понять, повлияет ли ограничение на план после сделки. Если не повлияет, оно может остаться осознанным компромиссом.
Проверьте, умеет ли организация безопасно менять продукт
Хороший код мало помогает, если каждую поставку сопровождает ручной ритуал, а доступ к production есть только у пары людей. Покупателю важна не абстрактная зрелость инженерных практик, а способность компании развивать продукт без постоянной лотереи.
Посмотрите на релизы, тестирование, контроль изменений, инциденты, восстановление и взаимодействие команд. У кого есть право остановить рискованный запуск? Как команда узнаёт о проблеме? Может ли она откатить изменение? Как быстро понимает, что сломалось?
Не стоит требовать единого процесса от компаний разного размера. Но если результат зависит от скрытых договорённостей, личных связей и незаменимых сотрудников, после смены владельца эта устойчивость может исчезнуть.
Самый дорогой компонент иногда вообще не программный
Кто действительно понимает архитектуру, данные и инфраструктуру? Кто держит отношения с поставщиком? Кто умеет восстановить сервис? И кто принимает решение, если возникла ситуация, которой нет в документации?
Важно различать концентрацию знаний и нормальную экспертность. Один сильный специалист — не дефект. Риск возникает, когда без него нельзя выполнять критическую операцию, а передать знания или ответственность некому.
При покупке компании это особенно существенно: вместе с переходом собственности могут меняться мотивация, роли, подрядчики и привычные способы работы. Если план интеграции строится на предположении, что все ключевые люди останутся и продолжат работать как раньше, такое предположение должно быть явно названо.
Здесь полезно обсуждать не только найм и удержание. Нужны понятные владельцы систем, передача контекста и снижение зависимости от одного человека в наиболее критичных местах.
Данные могут стоить дороже инфраструктуры
Данные часто воспринимают как то, что «лежит в базе». Но для сделки важно, откуда они появились, кто имеет право ими пользоваться, какие системы являются источниками истины и насколько реально их перенести.
Если покупатель собирается объединять продукты, нужно проверить идентификаторы, дубли, качество справочников, историю изменений, ограничения на передачу данных и возможность сверки после миграции. Выглядящая простой интеграция может оказаться отдельным продуктовым проектом.
То же касается восстановления. Наличие копии не означает, что бизнес вернётся к работе в приемлемом состоянии. Нужно понимать, что именно восстанавливается, какие данные могли потеряться и кто проверял этот процесс.
Безопасность, права и поставщики: смотрите на последствия
Вопрос «есть ли политика безопасности?» полезен, но недостаточен. Гораздо важнее выяснить, кто имеет доступ к производственным системам и клиентским данным, как выдаются и отзываются права, где лежат секреты и какие действия оставляют след.
Отдельно проверьте зависимости от облака, внешних API, лицензий, подрядчиков и компонентов, которые компания считает собственными. Может ли бизнес продолжить работу, если меняются условия поставщика? Передаются ли необходимые права вместе со сделкой? Не держится ли значимая функциональность на соглашении, которое нельзя просто перенести на нового владельца?
Зависимость сама по себе не означает ошибку. Иногда покупать готовое выгоднее, чем содержать собственную платформу. Но покупатель должен знать цену выхода и ограничения. Подробнее об этом — в статье про vendor lock-in как бизнес-риск.
Технологическая команда может помочь выявить фактические зависимости, но договорные и правовые выводы требуют проверки профильными специалистами.
Не забудьте цену интеграции
У компании может быть хороший самостоятельный продукт, но это ещё не означает, что его легко встроить в другую организацию. Разные модели данных, процессы выпуска, системы доступа, инструменты поддержки и ответственность за архитектуру способны сделать объединение намного сложнее ожидаемого.
Проверять интеграцию нужно не лозунгом «системы совместимы», а конкретными сценариями. Какие события должны передаваться между продуктами? Кто будет отвечать за качество общих данных? Что изменится для клиентов? Что придётся делать одновременно двум командам и кто имеет право принимать спорные решения?
Если сделка должна дать эффект за счёт объединения технологий, именно эти вопросы относятся к её экономике, а не к факультативной технической части.
Разделите находки на решения, а не на уровни «критичности»
Один из самых бесполезных итогов проверки — длинная таблица, где каждая проблема окрашена своим цветом, но непонятно, что с ней делать. У покупателя есть более прикладная классификация:
- Влияет на саму сделку. Под вопросом непрерывность бизнеса, заявленная ценность актива, права на критический компонент или способность выполнить ключевое условие плана.
- Требует решения сразу после покупки. Риск приемлем при наличии конкретного владельца, плана и ресурсов на исправление.
- Станет проблемой при изменении масштаба или стратегии. Сегодня ограничение терпимо, но его стоимость нужно учитывать в будущем сценарии.
- Можно сознательно оставить. Недостаток существует, но его исправление не создаст соразмерной пользы бизнесу.
Для каждой существенной находки достаточно ответить на несколько вопросов: чем она подтверждена, какой бизнес-сценарий затрагивает, что произойдёт без изменений, от чего зависит стоимость исправления и кто должен принять решение. Если данных пока недостаточно — это тоже надо написать.
Для первоначального разговора о накопленном долге можно использовать калькулятор технического долга, но оценка в нём не заменит проверки системы и плана интеграции.
Как должен выглядеть итоговый отчёт
Я бы начинал его не со списка технологий, а с ответа на главный вопрос: мешает ли что-то в текущей технологической системе выполнить бизнес-план после сделки?
Дальше — несколько наиболее существенных ограничений: факты, последствия, неопределённость, возможные действия и момент, когда решение потребуется. Например, если восстановление критических данных никто не проверял, нельзя честно писать «резервные копии отсутствуют». Но можно зафиксировать, что способность восстановления не подтверждена и что перед принятием риска нужна проверка.
Отдельно стоит показать то, что работает хорошо. Если команда умеет предсказуемо выпускать продукт, архитектура не мешает плану покупателя, а данные и знания управляемы, это тоже влияет на ценность актива. Due diligence — не поиск виноватых.
Наконец, должны быть явно названы ограничения самой проверки: к чему не получили доступ, что не смогли воспроизвести, где оценка основана на интервью, а не на наблюдении. Ложная уверенность опаснее аккуратно обозначенного неизвестного.
В итоге
У покупателя нет задачи получить идеальную технологическую компанию. Ему нужно понимать, что именно он приобретает, какие свободы сохраняет и сколько будет стоить изменить курс.
Хороший technology due diligence не заканчивается фразой «архитектура устарела». Он заканчивается набором решений, которые бизнес может принять до сделки и после неё — без неприятных технологических сюрпризов, которые можно было увидеть заранее.