Оцените кодовую базу перед первой беседой об приобретении

Почему списка функций недостаточно

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

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

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

Представьте SaaS-продукт с довольными клиентами и стабильной выручкой. Демонстрация работает. Но релизы зависят от ручных шагов, только основатель понимает фоновые задания, и никто не тестировал полное восстановление из бэкапа. Продукт всё ещё имеет ценность. Но покупатель видит вместе с ней операционный риск.

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

Пять показателей, которые имеют значение

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

Используйте одну шкалу от 1 до 5 для всех областей:

• 1 значит небезопасно или неясно
• 3 значит работает, но с реальными пробелами
• 5 значит повторяемо, задокументировано и вызывает доверие

Оцените эти пять областей:

• Безопасность деплоя
• Владение
• Глубина тестов
• Базовая безопасность
• Восстановление данных

Одного числа недостаточно. Добавьте одно короткое предложение с доказательством для каждой оценки. Эта заметка должна объяснить, почему оценка справедлива.

Хорошая запись выглядит так: "Безопасность деплоя: 4/5 — релизы проходят через CI, шаги отката записаны, за последний месяц не было экстренных исправлений после релизов."

Это даёт покупателю конкретику для обсуждения. Держите кратко: одна оценка, одно предложение, одна причина.

Как проводить проверку

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

Первый проход не требует большой группы. Часто достаточно одного инженера и одного продуктового владельца.

Сам обзор прост:

• Проверьте, может ли новый человек собрать репозиторий по письменным заметкам.
• Попросите одного инженера пройти по системе, потоку деплоя и сказать, кого зовут при поломке.
• Попросите продуктового владельца указать бизнес-критичные пути, ритм релизов и известные слабые места.
• Просмотрите последние релизы, прогон тестов, оповещения и записи бэкапов.
• Заполните карточку оценок доказательствами: логи CI, тикеты, скриншоты и метки времени.

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

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

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

Как оценивать безопасность деплоя

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

Начните с недавней истории. Спросите про последние 5–10 релизов. Сколько прошло чисто? Сколько потребовали хотфикс, откат или ночные правки? Если никто это не отслеживает, оценка должна опуститься.

Более безопасная установка имеет сборку, которая работает одинаково каждый раз, шаги релиза записаны и есть план отката, которым люди действительно пользовались. Если кто-то говорит: "мы можем откатиться", спросите, сколько времени это занимает и кто это делал раньше. Теоретический откат считается мало.

Несколько вопросов обычно выявляют реальный процесс:

• Кто может задеплоить, если обычный ответственный отсутствует?
• Где хранятся шаги релиза?
• Какие части всё ещё делаются вручную?
• Что чаще всего ломается при релизах?
• Как вы откатываете плохой релиз?

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

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

Как оценивать владение

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

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

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

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

Предупреждающие сигналы знакомы:

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

Владение в порядке, когда имена, запасные люди и рабочие документы совпадают.

Как оценивать глубину тестов

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

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

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

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

Эти вопросы обычно попадают в точку:

• Какие пользовательские сценарии никогда не должны падать?
• Какие области вызвали последние пять багов или инцидентов?
• Что инженеры всё ещё тестируют вручную перед релизом?
• Какие пути CI пропускает, потому что они медленные или нестабильные?

Осторожно с зелёными пайплайнами. Билд может проходить, при этом пропуская миграции БД, отказы сторонних API, частичные деплои или кейсы с правами. Оценивайте глубину тестов по тому, насколько хорошо тесты покрывают вероятные точки отказа, а не по тому, как часто панелька показывает "green".

Как оценивать базовую безопасность

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

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

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

Несколько проверок находят много проблем:

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

Логи тоже важны. Команде не нужен большой стек безопасности, чтобы сделать это правильно, но нужны записи о попытках входа, действиях админов, платёжных событиях и доступе к чувствительным данным клиентов. Если покупатель спросит: "Кто изменил эту настройку на прошлой неделе?" — команда должна дать ответ.

Одна слабая область встречается часто. Четыре слабые области сразу обычно означают, что система росла без достаточного контроля, и покупатели быстро это увидят.

Как оценивать восстановление данных

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

Начните с прямого вопроса: "Когда вы в последний раз восстанавливали реальные данные из бэкапа в рабочую систему?" Если команда не может назвать дату, план восстановления, вероятно, живёт в документе, а не на практике.

Затем проверьте четыре факта:

• как часто запускаются бэкапы
• как долго их хранят
• где они хранятся
• находятся ли бэкапы вне основного продакшн-аккаунта или сервера

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

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

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

Точный ответ выглядит конкретно: "Мы тестировали восстановление в прошлом месяце, оно заняло 42 минуты, и нам пришлось поправить один отсутствующий секрет окружения." Это гораздо лучше, чем "Мы всё автоматически бэкапим."

Распространённые ошибки в переговорах о покупке

Быстрая доставка может скрывать рискованную инженерию. Покупатели часто слышат: "мы деплоим каждый день" и предполагают, что процесс безопасен. Это мало что говорит. Если каждый релиз зависит от ручных правок, ночных проверок или одного инженера, темп скрывает хрупкость, а не доказывает силу.

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

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

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

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

Когда разговор скатывается к обещаниям, возвращайте его к доказательствам:

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

Это быстро меняет тон. Список функций укорачивается, но картина становится яснее.

Пример простой карточки оценок

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

Реалистичный первый проход может выглядеть так:

• Безопасность деплоя: 4/5 — команда выпускает каждую неделю, отслеживает ошибки после релиза и умеет откатываться.
• Владение: 3/5 — два инженера держат большую часть знаний по бэкенду, заметки по передаче тонкие.
• Глубина тестов: 3/5 — есть тесты для биллинга и логина, но многие пользовательские сценарии всё ещё требуют ручной проверки.
• Базовая безопасность: 3/5 — правила доступа неплохи, секреты хранятся правильно, обновления происходят, но ревью проходят неформально.
• Восстановление данных: 1/5 — бэкапы идут по расписанию, но никто не тестировал полное восстановление месяцами.

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

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

30-дневный план уборки может сильно улучшить картину:

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

Кодовая база не обязана быть идеальной. Покупатели в основном хотят доказательств, что команда понимает свои слабые места и умеет их исправлять.

Быстрые проверки перед встречей

Покупатели быстро замечают два момента: знаете ли вы свою систему и можете ли это доказать. Короткий набор материалов лучше длинной презентации со скриншотами продукта.

Приготовьте одну страницу с пятью показателями рядом. Для каждой оценки добавьте одну строку доказательства с числом, датой или коротким фактом. Например: "Безопасность деплоя: 4/5 — 22 продакшн-релиза за 45 дней, один откат, восстановление за 7 минут." Такие детали успокаивают людей.

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

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

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

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

Что делать дальше

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

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

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

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

Если нужен такой второй взгляд, Oleg Sotnikov на oleg.is проводит ревью рисков кодовой базы по архитектуре, деплою, тестированию, базовой безопасности и операциям. Он работает как Fractional CTO и советник стартапов — внешний взгляд помогает основателям превратить технические находки в понятное резюме для переговоров с покупателями.

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