Как объяснить технический долг на языке, понятном покупателю

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

Технический долг пугает покупателей не самим термином. Он пугает тем, что звучит как бесконечная история.

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

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

Размытые формулировки делают риск больше, чем он может быть на самом деле. «Старая архитектура», «костыльный код» и «наследованные проблемы» могут означать что угодно. Возможно, один слабый сервис требует двух недель работы. А возможно, компания стоит перед шестимесячной переделкой, более медленными релизами и очередью из обращений в поддержку. Если вы не объясните проблему, покупатели часто выбирают второй вариант.

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

Краткое и конкретное объяснение быстро меняет тон разговора.

«У нас много технического долга стартапа.»

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

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

Когда основатели плохо объясняют технический долг, покупатели не слышат технические детали. Они слышат риск без потолка.

Что покупатели хотят услышать

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

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

«Наш сервис оформления заказа нужно переработать» звучит как заметка инженера. «Изменения в оформлении заказа занимают 18 дней вместо 5, мы теряем примерно один спринт каждый квартал на исправления ошибок, а ошибки в счетах затронули 3% аккаунтов в прошлом месяце» — это уже проблема, которую покупатель может оценить в деньгах.

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

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

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

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

Назовите цену проблемы

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

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

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

Используйте реальные цифры, даже если они приблизительные. Если каждый релиз требует на 18 инженерных часов больше, а ваша усреднённая стоимость часа — $70, это $1,260 потерь на релиз. Если вы выпускаете продукт четыре раза в месяц, это около $5,000 в месяц ещё до учёта поддержки и переделок. Добавьте десять часов поддержки и два дублирующих инструмента — и сумма быстро вырастет.

Не делайте вид, что вы уверены больше, чем на самом деле. Дайте диапазон и объясните, от чего он зависит. «Мы оцениваем от $35,000 до $60,000 на исправление самых рискованных зон. Нижняя граница включает деплой, покрытие тестами и сервис биллинга. Верхняя — ещё и отчётность с правами пользователей». Это звучит гораздо лучше, чем «в системе есть какой-то долг».

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

Покажите влияние на сроки

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

Назовите релиз или функцию под риском, а потом скажите, сколько времени это должно занимать в нормальной ситуации и сколько занимает сейчас. Работает простое сравнение: «Обновление цен раньше занимало 2 недели. Сейчас оно занимает 6, потому что три старых сервиса требуют ручных изменений и полного регрессионного прогона». Это даёт покупателю задержку, которую можно просчитать.

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

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

Простой пример из SaaS делает это наглядным. Допустим, команда хочет выпустить SSO для более крупных клиентов. В обычном квартале команда бы сформировала задачу за несколько дней, реализовала её за три недели и выпустила к концу месяца. Сейчас же слой авторизации затрагивает биллинг и роли пользователей так, что никому полностью не доверяют. Инженеры замедляются. QA ждёт стабильных сборок. Поддержка не может подготовить документацию. Продажи не могут обещать дату.

А потом ответьте на вопрос, который волнует покупателей больше всего: что будет, если ничего не менять ещё один квартал? Возможно, релиз сдвинется с Q2 на Q3. Возможно, две встречи по продлению пройдут до выхода функции. Возможно, команда потратит ещё 120 часов на исправления вместо работы над новым продуктом. Вот так выглядит влияние на сроки на языке покупателя: задержка, зависимость и цена ожидания.

Покажите влияние на клиентов

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

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

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

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

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

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

Хорошие объяснения звучат просто: «Наш сервис выгрузки не справляется при высокой нагрузке. Маленькие аккаунты почти не замечают этого. Крупные клиенты в тот же день открывают тикеты в поддержку, а команды онбординга тратят часы на повторный запуск задач вручную». Это уже реальная картина для оценки.

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

Используйте простое объяснение из пяти шагов

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

1. Начните с одного простого предложения о проблеме. Скажите обычными словами: «Изменения в биллинге занимают слишком много времени, потому что правила биллинга разбросаны по четырём разным сервисам».
2. Назовите участок продукта, к которому это относится. Покупателю нужно понимать, где живёт риск: в оформлении заказа, онбординге, отчётности, поиске или мобильной синхронизации.
3. Добавьте цифры. Назовите примерную стоимость, задержку и боль пользователя. Можно сказать, что это добавляет две инженерные недели в квартал, замедляет релизы на пять дней и создаёт 40 тикетов в поддержку в месяц.
4. Назовите обходной путь и его пределы. Объясните, как команда справляется сейчас: дополнительный ручной QA, ночные hotfix, или один старший инженер проверяет каждый релиз. Затем скажите, почему это перестаёт работать по мере роста объёма.
5. Назовите исправление, объём работ и ожидаемый результат. Держите всё просто: что именно вы измените, сколько это займёт и что должно стать лучше после завершения.

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

Хороший вариант укладывается в одну минуту: «Наш модуль отчётности сложно менять, потому что логика данных разделена между старыми задачами и новыми API. Из-за этого каждый релиз задерживается примерно на 6 дней и откладывает работу для крупных клиентов, которые ждут кастомные отчёты. Сейчас мы держим это на ручных проверках, но это ломается, когда накладываются два релиза. Мы можем привести всё в порядок за 4 недели, и тогда изменения в отчётах будут выходить примерно вдвое быстрее».

Реалистичный пример из небольшой SaaS-команды

Представьте SaaS-компанию из 12 человек, которой покупатель задаёт вопросы о системе биллинга. Основатель говорит: «Бэкенд выглядит неаккуратно, и там у нас есть технический долг». Обычно такой ответ никуда не ведёт. «Неаккуратно» — слишком расплывчато. Покупатель не может превратить это в риск, стоимость или сроки.

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

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

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

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

Вот тот сдвиг, который делает такие разговоры рабочими. Убирайте ярлыки вроде «наследованный код» или «неаккуратный бэкенд». Говорите, что ломается, как часто это замедляет релизы, сколько это стоит в часах инженеров и что чувствуют клиенты, когда всё идёт не так.

Тогда разговор остаётся с вами.

Ошибки, которые основатели делают на встречах с покупателем

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

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

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

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

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

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

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

Короткая проверка перед звонком

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

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

Помогает простая проверка перед встречей:

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

Короткий пример помогает больше, чем длинный технический ответ. Вместо «наш бэкенд нужно привести в порядок» скажите: «Две части биллинга всё ещё требуют ручных проверок. Это добавляет примерно четыре часа к каждому релизу и повышает риск ошибки в счёте. Мы отложили исправление, потому что сначала нужно было выпустить две крупные клиентские просьбы. Один спринт уберёт большую часть ручной работы».

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

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

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

Затем разберите эту страницу вместе с инженерной командой и финансами в одной комнате. Инженеры должны оценить объём исправления, риск задержки и риск сбоя, если командa оставит проблему как есть. Финансы должны превратить это в цифры, которые покупатель сможет сравнить: дополнительные расходы на персонал, потерянная выручка, стоимость поддержки и риск продления.

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

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

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

Одна привычка сильно облегчает задачу: заменяйте ярлыки эффектами. Не говорите «наш бэкенд требует доработки». Скажите: «Этот сервис добавляет две лишние недели к каждому корпоративному релизу и увеличивает число тикетов в поддержку после каждого развёртывания». С таким ответом уже можно работать.

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