Продаёте бизнес: что покупатель проверит в вашей инфраструктуре

MAATRIX

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

Почему готовиться нужно заранее, а не в момент переговоров

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

То, на что смотрит покупатель при технической проверке, подробно разобрано в статье про десять вопросов, которые сбивают цену — если вы уже читали её с точки зрения покупателя, самое время перечитать с обратной стороны: не как чек-лист вопросов, на которые нужно красиво ответить в моменте, а как список того, что стоит успеть исправить, пока никто не спрашивает. Разница между продавцом, который на вопрос про бэкапы отвечает «сейчас покажу восстановление», и продавцом, который начинает объяснять, почему бэкапы никогда не проверялись, — это разница в несколько месяцев работы, сделанной заранее.

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

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

На что в целом смотрит опытный покупатель

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

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

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

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

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

Bus factor: главный красный флаг для покупателя

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

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

Подробная методика снижения такой зависимости — в статье про bus factor, равный единице: инвентаризация того, что живёт в одной голове, минимальный документ вместо исчерпывающей wiki, резервный доступ у второго человека, общий менеджер паролей вместо личных заметок. В контексте подготовки к продаже у этой работы появляется дополнительный смысл: покупатель видит не одного незаменимого человека, а систему, которая переживёт его уход.

Практический ориентир: если честно ответить на вопрос «кто, кроме меня, сможет управлять этой инфраструктурой через месяц без моего участия» и ответ — «никто», это самая дорогая по времени часть подготовки, и начинать её нужно раньше остальных пунктов — передача знаний не сжимается под дедлайн так, как сжимается обновление пакетов.

Технический долг: то, что покупатель находит и превращает в скидку

Устаревшие версии ПО, единая точка отказа без резерва, непроверенные бэкапы, ручной деплой через SSH вместо предсказуемого пайплайна — весь этот набор принято называть инфраструктурным долгом, и в отличие от bus factor он обычно на виду: достаточно одного аудита, чтобы найти большую часть таких вещей. Именно поэтому он — самый частый источник переговоров о снижении цены: продавец не может спорить с тем, что версия PHP вышла из поддержки три года назад, это проверяемый факт, а не мнение.

Механика того, как накопленные проблемы переводятся в конкретную скидку — трудоёмкость устранения, вес по срочности, поправка на то, что аудит не находит всё, — подробно разобрана в статье про инфраструктурный долг и цену сделки. Если вы уже смотрели на эту методику со стороны продавца, взгляните на неё ещё раз с другой стороны: каждую строчку из таблицы «проблема — трудоёмкость — стоимость» можно закрыть заранее, пока не нужно объяснять и торговаться.

Разница в экономике заметная: закрыть проблему самостоятельно, в своём темпе, — это время, разложенное на несколько месяцев. Отдать ту же работу покупателю в виде скидки — совсем другая цена: он закладывает в оценку не только трудоёмкость, но и премию за срочность и риск того, что аудит нашёл не всё.

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

Документация: почему её отсутствие выглядит хуже, чем реальные проблемы

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

Причина в том, как читается отсутствие документации: не как «всё так стабильно, что записывать было незачем», а как «никто, включая владельца, до конца не понимает, как это устроено» — индикатор хаотичного управления, даже если по факту всё технически исправно.

Минимальный набор, который стоит иметь до начала переговоров:

• Общая карта инфраструктуры — что где физически развёрнуто, как связаны компоненты, есть ли резервирование. Достаточно компактного документа на один-два экрана, который человек, впервые видящий систему, понимает за пару минут.
• Runbook на случай инцидента — что делать, если сервис упал, кто отвечает, куда смотреть в первую очередь. Отсутствие такого документа читается как «при аварии придётся звонить бывшему владельцу», что возвращает к риску bus factor из предыдущего раздела.
• Список доступов и того, кто ими управляет — не сами пароли (им место в менеджере паролей), а понятная структура: кто администратор, к чему есть доступ, как устроена ротация.
• История инцидентов и того, как их решали — наличие такого списка работает в плюс: покупатель, который видит разобранные проблемы прошлого, доверяет системе больше, чем той, где «инцидентов никогда не было», потому что второе чаще означает, что их просто не отслеживали.

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

План подготовки: с чего начать за несколько месяцев до сделки

Если решение о продаже уже принято, но конкретного покупателя ещё нет, у вас есть ресурс, которого не будет позже, — время без давления дедлайна. Последовательность подготовки строится не по порядку вопросов на due diligence, а по трудоёмкости и по тому, что дороже всего откладывать.

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

Экономика подготовки: почему это не просто гигиена

Есть соблазн отнести всё описанное выше к разряду «общей технической гигиены», которой стоит заниматься просто потому, что это правильно, вне зависимости от продажи. Это верно, но у той же работы есть и прямой финансовый смысл, который стоит проговорить отдельно — иначе легко отложить наведение порядка на «когда будет время».

Инвестиция окупается по двум направлениям. Первое — цена: каждая проблема, найденная покупателем самостоятельно, становится предметом торга не в вашу пользу, а закрытая заранее — просто не появляется в списке аргументов для скидки. Разница между «продать по справедливой цене» и «продать со скидкой за найденные проблемы» может быть куда заметнее, чем стоимость самой подготовки.

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

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

Частые вопросы