Оспаривайте предложение о переписывании кода аргументами, а не страхом

Почему предложения переписать кажутся трудными для оценки

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

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

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

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

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

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

Доказательства, которые стоит требовать

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

Затем разберите каждую проблему по источнику. Некоторые проблемы вызваны кодом, который трудно менять. Другие — неясным объёмом работ, медленными ревью, слабым тестированием или разрушенным процессом релиза. Основатели часто слышат «код — это проблема», когда команда на самом деле имеет в виду «наш способ работы в беспорядке».

Достаточно простой таблицы. Она должна отвечать на пять базовых вопросов:

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

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

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

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

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

Метрики, вводящие основателей в заблуждение

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

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

Story points и velocity тоже могут вводить в заблуждение. Команды оценивают работу по‑разному, и многие со временем меняют шкалу. Если одна команда говорит, что делает 80 очков в спринт, а другая — 30, это почти ничего не говорит, если они не оценивают задания одинаково. Velocity — привычка команды, а не доказательство того, что система не подлежит ремонту.

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

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

Покрытие тестами имеет ту же проблему. Отчёт „85%“ может скрывать хрупкий код, слабые тесты или отсутствие покрытия в рискованных областях. Отчёт „35%“ тоже не доказывает необходимость переписывания. Покрытие важно только в связке с провалами релизов, ускользнувшими дефектами и тем, насколько безопасно команда может менять код.

Быстрая проверка помогает. Спросите, какая метрика связана с потерянным доходом, оттоком, простоями или пропущенными релизами. Попросите тренд за 6–12 месяцев, а не снимок за неделю. Спросите, какие проблемы решит фокусированный рефактор без полного ребилда. И что останется сломанным даже после переписывания.

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

Когда настоящая проблема — процесс

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

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

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

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

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

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

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

Как шаг за шагом оспорить претензию

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

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

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

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

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

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

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

Самое простое правило: отложите большое решение до завершения proof task. Промоутеры продают надежду; маленькие доставленные результаты с ней спорят труднее.

Когда переписывание действительно имеет смысл

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

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

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

Ребилд также имеет смысл, когда система уже не соответствует продукту, который вы продаёте. Инструмент для кастомных проектов может не вытянуть self‑serve SaaS. Один‑тенантное приложение может сломаться, когда нужно обслуживать многих клиентов одним продуктом. Тут решение «переписать vs рефакторить» — бизнес‑решение, а не только кодовое.

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

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

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

Простой пример из стартапа

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Переписать звучит чисто и смело. Часто это маскировка: никто не зафиксировал реальную бизнес‑боль.

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

Хорошее предложение показывает больше, чем обиду разработчиков. Инженеры могут быть правы — текущий код тормозит. Но основателям стоит спросить, что чувствуют клиенты. Дольше ли пользователи ждут исправлений? Срываются ли переговоры с продажами из‑за отсутствующей фичи? Тратит ли поддержка часы на одну и ту же поломку каждую неделю? Если никто не связывает переписывание с клиентской болью, кейс слаб.

Перед утверждением проверьте пять вещей:

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

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

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

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

Если хотите одно простое правило: скажите «нет», пока команда не покажет бизнес‑боль, реальные варианты, маленький тест и план для грязного переходного периода.

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

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

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

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

Следующие шаги могут быть простыми:

• Записать претензию на переписывание на одной странице.
• Назвать хотя бы одну альтернативу без ребилда.
• Начать с одной дорогостоящей проблемы в 90‑дневном плане.
• Назначить владельца для каждого решения.
• Установить дату решения до конца встречи.

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

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