Технический чек‑лист перед переговорами с покупателем

Почему уверенность покупателя рушится рано

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

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

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

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

Короткий технический чек‑лист помогает превратить разрозненные знания в одну понятную историю. Цель не в том, чтобы всё звучало идеально. Покупатели больше доверяют, когда слышат открытые ответы типа: "У нас было два серьёзных инцидента, мы их исправили и поменяли мониторинг для этой службы."

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

Что должна охватывать ваша история

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

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

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

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

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

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

Владение безопасностью должно читаться как «телефонная книга», а не набор политик. Если покупатель спросит: "Кто разбирается с утечкой учётных данных в 2:00 ночи?" — у вас должен быть прямой ответ. И если унаследованный сервис всё ещё зависит от одного инженера и лишён нормального мониторинга, назовите его сейчас. Покупатель воспримет известную слабость лучше, чем неожиданность.

Постройте пакет в пяти шагах

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

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

Затем соберите пакет в этом порядке:

1. Создайте одностраничную карту системы. Держите её простой. Покажите, что где работает, кто с кем общается и какие части остановят бизнес при падении.
2. Вытяните точные числа за последние 12–24 месяца. Покупателю важна история доступности, инциденты, расходы на облако, затраты на инструменты и крупные тренды использования.
3. Добавьте короткие заметки там, где выборы требуют контекста. Объясните, почему вы выбрали тот или иной облачный провайдер, базу данных или паттерн деплоя. Две–три честные фразы достаточно.
4. Поставьте владельца рядом с каждой темой. Один человек отвечает за вопросы по архитектуре, один — за безопасность, один — за расходы, и один — за целостность всего набора.
5. Проведите репетицию. Попросите кого‑то внутри компании или внешнего советника сыграть роль покупателя и надавить на слабые места.

Эти короткие заметки важнее, чем кажется. Покупатель обычно примет компромисс, если команда может его ясно объяснить. Его насторожит, если ответ меняется в зависимости от того, кто говорит.

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

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

Объясняйте архитектурные решения простым языком

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

Используйте причинно‑следственную логику. "Мы выбрали небольшой Node.js API и одну PostgreSQL, потому что продукт был новый, в команде было двое инженеров, и нам нужны были быстрые релизы" — это работает гораздо лучше, чем плотная схема из десяти блоков без контекста.

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

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

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

Держите тон спокойным. Не нужно защищать каждое решение. Покажите, что команда понимала, почему приняла то или иное решение, знала слабые места и убрала то, что больше не имело смысла.

Покажите историю доступности без приукрашивания

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

Начните с базовых чисел. Укажите, сколько инцидентов у вас было за последние 12–24 месяца, как долго они длились и что именно почувствовали пользователи. Если один простой замедлил работу приложения на 15 минут, а другой блокировал платежи 42 минуты — скажите это прямо.

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

Держите описания инцидентов скучными и прямыми. "Пул подключений к базе заполнился во время всплеска трафика. Сбой логина длился 18 минут. Мы увеличили лимиты, вынесли одну задачу из основной базы и добавили алерт на рост очереди." Это звучит правдоподобно, потому что конкретно.

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

Положите дисциплину расходов на стол

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

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

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

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

Автоматизация тоже сюда относится. Если AI‑помощник для ревью кода, тестирования или деплоя экономит ручное время — скажите это конкретно: "AI‑ревью кода экономит примерно 5 часов инженера в неделю." "Мы используем AI для повышения эффективности" — бесполезно.

Сделайте ответственность за безопасность очевидной

Безопасность пугает покупателей, когда звучит как разделённая, но неназванная задача. Чёткий ответ лучше длинной речи. Назовите человека, кто утверждает доступы, кто ставит патчи и кто просматривает алерты, даже если один человек закрывает несколько ролей.

Пишите роли и имена простым языком. "CTO утверждает доступ в продакшен." "Ведущий инженер обновляет зависимости приложения каждый спринт." "Наш подрядчик по инфраструктуре патчит серверы по вторникам." Это читается лучше, чем "это делает команда".

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

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

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

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

Эта часть чек‑листа не требует шлифовки. Ей нужны имена, даты и доказательства того, что работа назначена и будет выполнена.

Простой пример перед встречей с покупателем

Представьте основательницу SaaS, выходящую на первый звонок с покупателем с одной страницей вместо презентации. Вверху — три числа: 99.98% доступности за 12 месяцев, расходы на облако стабильны три квартала подряд и один именованный владелец за ревью безопасности и реакцию на инциденты.

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

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

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

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

Распространённые ошибки, которые ослабляют позицию

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

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

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

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

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

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

Быстрая проверка перед началом дилидженса

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

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

Используйте этот короткий тест перед первой серьёзной беседой:

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

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

Если вы не проходите этот тест, остановитесь и приведите историю в порядок до начала дилидженса.

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

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

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

Держите план простым:

• пометьте каждую открытую проблему как «исправить сейчас», «ясно объяснить» или «принять как риск";
• проведите один мок‑звонок с основателями, техническим лидом и тем, кто отвечает за финансы или безопасность;
• попросите внешнего рецензента бросить вызов расплывчатым ответам, отсутствию доказательств и слабым объяснениям архитектуры;
• превратите каждое слабое место в короткую заметку с фактами, датами и явным владельцем.

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

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

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