Чек-лист технического due diligence
Это рабочий чек-лист, по которому я веду технические проверки. Выложен целиком: 44 пункта в восьми категориях, в том порядке, в каком я иду по ним на реальной сделке. Ни формы, ни почты, ни PDF за подпиской. Скопируйте его к себе в шаблон и проверьте следующую сделку сами.
Чек-лист технического due diligence — это структурированный список вопросов, по которому инвестор или покупатель оценивает код, инфраструктуру и инженерную команду компании до закрытия сделки. Ниже — тот самый чек-лист, по которому Олег Сотников ведёт реальные проверки: восемь категорий — архитектура и запас прочности, качество кода и происхождение AI-кода, команда и bus factor, безопасность и комплаенс, инфраструктура и траектория расходов, данные и права, метрики продукта и поставки, эксплуатация — и 44 проверяемых пункта. Он выложен на этой странице целиком, без формы и почты, чтобы команда сделки могла сделать первичный отсев сама.
Как им пользоваться
Сузьте под сделку
Миноритарный раунд и полная покупка требуют разной глубины. Отметьте категории, от которых зависит именно ваша сделка: для инвестиций это обычно риски команды и траектория расходов, для покупки — права на код и безопасность. Остальное тоже проходим, только быстрее.
Идите по пунктам с доказательствами
Разбирайте отмеченные категории с инженерами, которые строили систему, а не только с CTO. По каждому ответу просите артефакт: выгрузку биллинга, граф коммитов, постмортем, отчёт сканера лицензий. Большинство серьёзных находок начинается с расхождения между тем, что написано в документации, и тем, что видно в репозитории.
Взвесьте находки по влиянию на сделку
Отсортируйте красные пункты по тому, во что обойдётся починка в деньгах и месяцах. Дальше решите, что двигает цену, что становится условием закрытия, а что просто уходит в работу на первый квартал после сделки. Длинный список мелких замечаний и один пункт, останавливающий разработку на квартал, — это разные риски.
Чек-лист
Ставьте каждому пункту зелёный, жёлтый или красный. Зелёный — вы видели доказательство. Жёлтый — ответ есть, артефакта за ним нет. Красный — проблема в самом ответе. Всё, что осталось жёлтым к концу проверки, идёт в отчёт как открытый риск: слова основателя — это информация, а не подтверждение.
Архитектура и запас прочности
- Возьмите схему архитектуры, нарисованную инженером, который работает с системой, а не ту, что лежит в презентации для продаж.
- Найдите единые точки отказа — одна база, одна очередь, один регион — и спросите, что происходит при отказе каждой.
- Проследите самый нагруженный путь чтения от начала до конца и посчитайте его стоимость при десятикратном трафике.
- Проверьте, выдержит ли модель данных планы по продукту или следующая функция потребует миграции, которую никто не оценивал.
- Поищите состояние, спрятанное на отдельных машинах: локальный диск, кэши в памяти процесса, cron на сервере, настроенном руками.
- Спросите, о каком архитектурном решении команда жалеет и почему до сих пор его не откатила.
Качество кода и происхождение AI-кода
- Измерьте покрытие тестами на путях, по которым идут деньги, а не среднее по репозиторию.
- Спросите, какую долю кода написала LLM, и сверьте ответ с размерами коммитов и временем их появления.
- Возьмите три файла с наибольшей долей AI-кода и попросите инженера объяснить их построчно.
- Проверьте, покрыт ли AI-код тестами, которые писала команда, или тестами от той же модели.
- Прочитайте последние тридцать пул-реквестов: глубину ревью, время до мержа, кто кого апрувит.
- Посчитайте мёртвый код, дублирующиеся модули и TODO старше года — по ним видно, как команда обходится с техдолгом.
Команда и bus factor
- Сопоставьте историю коммитов с оргструктурой и найдите каждый компонент с единственным автором.
- Назовите двух человек, чей уход остановит разработку на квартал.
- Сверьте удерживающие бонусы, сроки отработки и даты вестинга с ожидаемой датой закрытия.
- Спросите, кто дежурит, как часто и насколько график на бумаге совпадает с логами дежурств.
- Выясните, сколько занимает онбординг нового инженера — по сроку до его первого деплоя в продакшен.
Безопасность и комплаенс
- Прогоните историю репозитория на секреты и убедитесь, что найденные ротировали.
- Посмотрите, у кого есть доступ в продакшен, когда его в последний раз пересматривали и как он отзывается при увольнении.
- Соберите известные уязвимости в дереве зависимостей и посмотрите, сколько висит самая старая критическая.
- Запросите отчёт последнего пентеста и то, что по нему починили, а не только сертификат.
- Там, где заявлены SOC 2, GDPR или HIPAA, отделите уже внедрённые контроли от тех, что пока стоят в плане.
- Для AI-функций установите, какие данные клиентов уходят какому провайдеру моделей и что этот провайдер у себя хранит.
Инфраструктура и траектория расходов
- Поднимите счета за облако за двенадцать месяцев и наложите кривую на выручку и нагрузку.
- Отделите фиксированную стоимость платформы от стоимости на клиента и пересчитайте маржу на объёмах из модели сделки.
- Проверьте расходы на токены LLM в пересчёте на активного пользователя и что с ними станет при заложенном росте.
- Найдите инфраструктуру, за которую никто не может отчитаться: брошенные окружения, забытые снапшоты, простаивающие кластеры.
- Убедитесь, что окружение воспроизводится из кода, а не живёт только в консоли, где его когда-то настроили руками.
Данные, права и лицензии
- Убедитесь, что компании принадлежит каждая строка кода: сотрудники, подрядчики, агентства и ушедшие сооснователи.
- Сверьте бумаги о передаче прав с именами в истории git.
- Прогоните сканер лицензий и отметьте обязательства copyleft во всём, что уходит клиентам.
- Установите, какие права у компании на данные, на которых она обучает или дообучает модели.
- Проверьте, разрешают ли условия провайдера моделей то коммерческое использование, на котором держится продукт.
Продукт и метрики поставки
- Возьмите частоту деплоев и время от коммита до продакшена из пайплайна, а не по памяти.
- Посмотрите долю неудачных изменений и то, как часто релиз откатывают.
- Сравните, что реально выкатили за два последних квартала, с тем, что обещал роадмап.
- Проследите динамику багов за двенадцать месяцев: сколько заводят против того, сколько закрывают.
- Спросите, что команда выпустила и клиенты не стали этим пользоваться — и как в компании об этом узнали.
Эксплуатация и история инцидентов
- Прочитайте все постмортемы за последние двенадцать месяцев и спросите, почему за остальные месяцы их нет.
- Сверьте реальный аптайм с тем, что обещано в договорах с клиентами.
- Убедитесь, что бэкапы есть и что из них недавно кто-то восстанавливался.
- Спросите среднее время восстановления и отдельно — среднее время обнаружения.
- Установите, кого поднимают в три часа ночи и остаётся ли этот человек после сделки.
- Проверьте покрытие мониторингом: о каких отказах команда узнаёт с дашбордов, а о каких — от клиентов.
Частые вопросы
Что проверяют в техническом due diligence?
Технический due diligence охватывает архитектуру и запас прочности, качество кода и долю написанного нейросетями, инженерную команду и зависимость от ключевых людей, безопасность и комплаенс, инфраструктуру и траекторию расходов, данные и права на код, метрики поставки продукта и историю эксплуатации. Под всем этим лежит один вопрос: потянет ли технология тот план, по которому оценена сделка, и во сколько обойдётся починить то, что не потянет. Каждая находка должна приходить с доказательством и оценкой, сколько работы уйдёт на починку.
Кто должен проводить технический due diligence?
Тот, кто сам строил и эксплуатировал системы того масштаба, на который претендует проверяемая компания, а не консультант, заполняющий форму. Вся ценность в том, какой вопрос человек задаст следом: за красивой цифрой покрытия могут стоять тесты, которые ничего не проверяют, а за ровным счётом за облако — стоимость на клиента, которая переворачивается на пятикратном росте. В руках практика чек-лист даёт находки, в руках заполнителя форм — документ.
Какие красные флаги в техническом due diligence самые серьёзные?
Три встречаются чаще прочих. Bus factor, равный единице, когда систему, на которой держится бизнес, понимает один инженер. Код, написанный нейросетью, без тестов вокруг него и без единого человека в штате, кто объяснит, что он делает. И расходы на инфраструктуру, за которые никто не может отчитаться: счёт растёт быстрее нагрузки, окружения брошены, владельца нет. Всё это чинится, и всё это стоит реальных денег и месяцев, что должно отражаться в цене.
На каком этапе сделки проводят технический due diligence?
После term sheet или письма о намерениях и до того, как сделку одобрит инвесткомитет или совет директоров. Раньше — обычно нет доступов, которые компания готова дать; позже — находки приходят, когда цена уже зафиксирована и торговаться нечем. Обычное окно — за две-три недели до даты решения: в него укладывается проверка на одну-две недели с запасом на уточнения. Первичный отсев по этому чек-листу можно делать гораздо раньше, для этого он и нужен.
Проверка на вашей сделке
Тот же чек-лист, только проходит его тот, кто его написал. Одна-две недели, письменный отчёт с красными флагами в начале и план на первые 100 дней после закрытия.
Цену считаю под сделку: дневная ставка или фиксированный объём, письменно и до начала работ.
По теме
Риски сделки, риски команды и то, что код, написанный нейросетью, оставляет после себя.
