Вопросы перед переписыванием: что должны спрашивать менторы

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

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

Большинство небольших команд платят за переписывание не только кодом. Они платят временем.

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

Обычно цена проявляется очень приземлённо:

• обращения в поддержку дольше остаются без ответа
• обещанные исправления сдвигаются
• продажи становятся сложнее
• клиенты теряют терпение

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

Из-за этого появляется жёсткое разделение. Один продукт приносит деньги. Другой съедает команду. Малые компании ощущают это разделение очень быстро.

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

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

Сначала спросите про команду

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

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

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

Хорошо работает короткий набор вопросов:

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

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

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

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

Сначала спросите про запас денег

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

Сначала спросите одну простую цифру: сколько месяцев денег осталось при текущем темпе расходов. Не принимайте расплывчатый ответ вроде «должны дотянуть до лета». Ментору нужна дата, потому что совет о переписывании сильно меняется, если у компании осталось 12 месяцев, а не четыре.

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

Следующий вопрос — там, где многие команды начинают говорить честно. Сколько времени они могут потратить, не выпуская ничего, что заметят клиенты? Для одних стартапов это две недели. Для других — один цикл релиза. Если ответ звучит как «наверное, пару месяцев», значит, никто не считал.

Переписывание почти всегда съедает время до того, как приносит заметную ценность. Даже небольшая команда может сжечь 6–10 недель на пересборку входа, биллинга, админки, тестов и деплоя, прежде чем клиент увидит хоть одно улучшение. Поэтому запас денег нужно обсуждать в самом начале, а не после code review.

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

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

Сначала спросите, в чём именно риск продукта

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

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

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

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

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

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

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

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

Сначала спросите, откуда идёт давление клиентов

Давление клиентов легко понять неправильно. Основатель говорит, что пользователи недовольны, и ментор сразу думает о переписывании. Но так пропускается главный вопрос: чем именно недовольны клиенты?

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

Спросите конкретно:

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

Ответы быстро меняют совет.

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

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

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

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

Используйте ответы именно в таком порядке

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

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

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

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

Хороший порядок выглядит так:

1. Какое давление со стороны клиентов есть прямо сейчас?
2. Сколько runway останется, если доставка замедлится?
3. Может ли эта команда продолжать выпускать изменения, пока идёт переписывание?
4. Какое самое маленькое изменение снимет текущую боль?
5. Это указывает на патч, замену модуля или настоящее переписывание?

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

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

Реалистичный пример из небольшого стартапа

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

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

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

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

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

Их план был простым:

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

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

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

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

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

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

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

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

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

Хороший совет ментора всегда привязан к реальным ограничениям команды:

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

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

Быстрая проверка перед тем, как сказать «переписать»

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

Используйте короткий тест «да или нет»:

• Может ли команда описать точную проблему одним предложением? «Деплои ломаются, потому что текущее приложение не может разделять данные клиентов» — это ясно. «Кодовая база ужасная» — нет.
• Могут ли основатели сказать, сколько runway съест переписывание, в месяцах? Реальный ответ звучит как «четыре месяца расходов плюс ещё месяц более медленной работы продаж», а не «наверное, квартал».
• Могут ли клиенты пережить задержку? Если нет, есть ли у команды переходный план вроде ограниченного патча, ручной поддержки или частичного релиза?
• Отпала ли у команды необходимость в меньшем исправлении, которое убирает главный риск? Если узкое изменение решает блокер, полное переписывание обычно не лучший выбор.

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

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

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

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

Что делать дальше, если картина всё ещё неясна

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

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

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

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

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

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

Если в комнате всё ещё не получается отделить боль кода от бизнес-риска, помогает внешний взгляд. Олег Сотников на oleg.is занимается такой работой как fractional CTO и консультант для стартапов, и короткая консультация может помочь разобраться с давлением продукта, ограничениями команды и рисками поставки до того, как компания возьмёт на себя полную переделку. Цель простая: сделать следующий шаг маленьким, полезным и таким, о котором потом не придётся жалеть.