Почему технический директор (CTO) требует переписать систему с нуля?

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

В чем финансовая опасность подхода «снести старый код и написать новый»?

Возникает эффект «Второй системы». Новая версия пишется в вакууме, сроки затягиваются на 9-12 месяцев, а бюджет вырастает кратно (приходится платить за поддержку старой системы и разработку новой). Все это время бизнес не получает новых функций, теряя долю рынка.

Какая существует альтернатива полному переписыванию ИТ-системы?

Инкрементальная модернизация (поэтапный рефакторинг). Выделяется один конкретный проблемный модуль, который тормозит бизнес (например, поиск по сайту или оформление заказа), и переписывается на новые технологии. Остальные 95% системы продолжают работать и приносить прибыль.

Как собственнику бизнеса проверить обоснованность ультиматума CTO?

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

Аудит ИТ-отдела: что делать, если технический директор требует переписать код с нуля.

УПРАВЛЕНИЕ КОМАНДОЙ

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

Это происходит обычно в пятницу вечером или на планерке, когда вы ожидаете услышать о запуске новой функции, которая принесет деньги. Вместо этого ваш Технический директор (CTO), тяжело вздыхая, произносит фразу-приговор:

«Архитектура никуда не годится. Это легаси-код, его невозможно поддерживать. Если мы хотим двигаться дальше, нужно остановить разработку фич на полгода и переписать всё с нуля на [тут название модного фреймворка]».

Вы в ступоре. Вы платили рыночную или выше зарплату. Вы не вмешивались в процессы, доверяя профессионалу. Бизнес работал, клиенты получали отгрузки. Как мы оказались в точке, где всё, что мы строили, вдруг стало «мусором»?
Давайте разберем, как вы попали в эту ловушку, почему «переписать с нуля» — это часто манипуляция, и как вернуть контроль над своим IT-отделом, не умея писать код.

Почему опытные владельцы бизнеса раз за разом нанимают «технологических гениев» вместо бизнес-партнеров?

Все начинается с собеседования. Ирония в том, что кризис закладывается именно тогда, когда вы думаете, что нашли идеального кандидата.
Нетехнический собственник нанимает CTO эмоционально. Вы слышите уверенный голос, набор сложных терминов (Kubernetes, Microservices, Highload, AI), и в вашей голове складывается картинка:

«Этот парень знает то, чего не знаю я. Он — тот самый гений, который превратит мой бардак в современный IT-продукт».

Где здесь ошибка? Вы искали инженера для решения бизнес-задач, а наняли визионера для реализации его амбиций. Вот типичный сценарий «очарования»:

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

Фаза «Медового месяца» и Технологический Газлайтинг.

Итак, оффер подписан. «Гений» выходит на работу. В компании до него все как-то работало: криво, косо, на старом PHP или 1С, но фуры уезжали, счета выставлялись.
Что происходит дальше? Почему через полгода мы приходим к тупику? Обычно это один из двух сценариев.

Сценарий А: «Для человека с молотком все выглядит как гвоздь»

Ваша система, скорее всего, написана на PHP (Laravel, Symfony, Bitrix, Magento) или, если вы из корпоративного сектора, на Java/C#. Она не идеальна, местами «подтормаживает», но она генерирует выручку последние 5–10 лет.

И вот приходит новый CTO. Он смотрит на ваш код с нескрываемым отвращением.

«Никто нормальный в 2026 году на PHP не пишет. Это мертвый язык. Разработчиков не найдешь, молодежь нос воротит. Нам нужно всё переписать на Go (Golang) или Node.js».

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

В чем риски: CTO предлагает сменить технологию, а не решить проблему.

Стоимость кадра: PHP-разработчик среднего уровня стоит X. Разработчик на Go стоит 2X и его сложнее найти.
Bus Factor (Фактор автобуса): Если ваш новый CTO уйдет, вы останетесь с кодом на редком/сложном языке, который в вашем городе/нише никто не может поддерживать.
Результат: Вместо того чтобы «починить тормоза» на вашем рабочем грузовике, CTO начинает собирать в гараже гоночный болид. Грузовик стоит, болид не едет, деньги уходят.

Сценарий Б: Разработка ради резюме

Это еще более опасная ловушка. Ваш CTO — амбициозный парень. Он видит, что на рынке зарплаты выше у тех, кто умеет работать с (условно) микросервисами и облаками AWS. Но он с ними никогда не работал. Ваша компания становится для него полигоном.

Как это выглядит:

Месяц 1: Он говорит: «Нам нужно внедрить Kubernetes для масштабируемости». Вы киваете (звучит круто!).
Месяц 3: Вся команда занята настройкой сложной инфраструктуры. Продуктовых обновлений нет. «Мы настраиваем фундамент», — говорит CTO.
Месяц 6: Система стала настолько сложной, что для поддержки нужно нанять еще двух DevOps-инженеров. Любое изменение требует недели тестов.

Собственник оплачивает обучение сотрудника. CTO получает строчку в резюме «Migrated monolith to microservices» и уходит на зарплату x2 в другую компанию, оставляя вам руины, в которых никто другой не может разобраться.

Важно понимать: В 90% случаев среднему бизнесу (e-com, логистика, услуги) не нужны технологии Google или Netflix. Вам нужна надежная «Тойота», а вам собирают болид Формулы-1, который требует бригаду механиков и ломается на каждой кочке.

Ранняя диагностика: Как понять, что вас ведут к «Сносу»?

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

На собеседовании: «Фокус на инструменте, а не на результате»

Задайте один вопрос: «Представь, что у нас старый, запутанный код, который приносит 1 млн евро в месяц. Но добавлять новые фичи сложно. Твои действия?»

Красный флаг :

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

Даже не спросил, какие именно проблемы у бизнеса (скорость? отказы? стоимость поддержки?). Он уже лечит пациента, не видя анализов.
Зеленый флаг:

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

Через 1 месяц: «Эффект невидимки»

Вы наняли человека месяц назад, платите зарплату. Что происходит?
Сигнал тревоги:

Нет релизов. Вообще никаких. Даже мелких правок.
Ответ: «Я настраиваю окружение», «Мы разворачиваем окружение», «Мы приводим в порядок репозитории».

Простите за прямоту, но это имитация бурной деятельности. Настроить среду для работы можно за 2–3 дня. Месяц без результата в малом/среднем бизнесе — это недопустимо.

Через 3 месяца: «Все сложнее, чем мы думали»

Сигнал тревоги:

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

Через 6 месяцев: Точка невозврата

Если к этому моменту бизнес не получил ощутимой пользы (ускорение процессов, новые функции, автоматизация), а бюджет на ИТ вырос в 2 раза — поздравляю, вы в заложниках. CTO построил систему, которую понимает только он. Уволить его страшно «все рухнет», оставлять — дорого.

Перевод с языка ИТ на язык денег: Сколько стоит «Переписать всё»?

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

Ваш новый CTO предлагает: «Давайте построим рядом идеальный автоматизированный склад с роботами! Это займет 3 месяца».

Вы соглашаетесь. И вот реальность:

Вы платите аренду за два склада (старый работает, новый строится).
Михалыч саботирует работу.
Роботы для нового склада застряли на таможне.
Через 6 месяцев у вас нет ни нового склада, ни денег, а старый начал разваливаться, потому что его никто не обслуживал.

В IT это называется «Эффект второй системы». Вторая версия всегда планируется идеальной, перегружается функционалом и... никогда не запускается вовремя.

Ожидание vs Реальность

Параметр	Ожидание (Что вам продал CTO)	Реальность (Статистика 80% проектов)
Сроки	«За 3–4 месяца сделаем первую версию на новом стеке».	9–12 месяцев до первого рабочего релиза. Все это время бизнес не получает новых функций.
Бюджет	Фиксированная сумма на команду разработки.	x2.5 от бюджета. Вы платите команде поддержки старой системы + команде разработки новой.
Функционал	«Сразу сделаем круче, быстрее, с ИИ».	Паритет функций. Вы тратите год, чтобы просто повторить то, что уже работало в старой системе.
Риски	«Никаких багов, чистая архитектура».	Новая система имеет новые баги, о которых вы еще не знаете. Старая система была «боевой» и проверенной годами.
Бизнес-ценность	Рост продаж за счет скорости.	Стагнация. Пока конкуренты внедряют функции на «кривом» PHP, вы строите «идеальный код» в вакууме.

Инсайт Архитектора: Бизнесу не нужен идеальный код. Бизнесу нужна скорость доставки ценности клиенту. Если «кривой» код позволяет выпустить акцию к «Черной пятнице» за 2 дня, а «идеальный» требует 2 недели тестов — «кривой» код побеждает.

Методология выхода из кризиса.

Хорошо, мы поняли, что «переписывать с нуля» — это дорого и долго. Но что делать, если система действительно тормозит, а разработчики воют от боли? Убираем эмоции и считаем стоимость одной функции.

1. Внедряем метрику (Интуитивная логика).

Спросите CTO: «Сколько времени займет добавить кнопку "Купить в 1 клик"?»

Если ответ: «Неделю, потому что надо рефакторить модуль корзины», — запишите это.

2. Считаем деньги (Факты).

Формула проста:

Стоимость разработки функции = (Зарплата команды в час × Часы на разработку) + (Часы на исправление багов после релиза)

Пример из жизни:

Компания А (Легаси-код, но грамотный процесс): Задача занимает 4 часа. Стоимость: $200.
Компания Б (Процесс «Переписывания»): Та же задача. Разработчик говорит: «Не могу внедрить в старое, давайте сделаем микросервис». Время: 40 часов. Стоимость: $2000.

Вы платите $1800 сверху не за бизнес-ценность, а за амбиции или некомпетентность архитектора.

3. Альтернатива.

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

Как это выглядит:

Выделяем один маленький кусок, который реально тормозит (например, поиск по сайту).
Переписываем только его на новую технологию (пусть будет тот самый Go или ElasticSearch).
Остальная система (95%) работает как раньше.
Проверяем: стало лучше? Дешевле поддерживать? Если да — берем следующий кусок.

Что на самом деле стоит за требованием «всё переписать с нуля» через полгода работы?

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

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

Вопрос №1. «Если мы не будем переписывать всё с нуля, что именно сломается и когда?»

Цель: Проверить реалистичность угрозы.

Плохой ответ: «Ну, всё работает на честном слове... В любой момент может упасть... Разработчики уволятся...». (Это манипуляция страхом без фактов).

Хороший ответ: «Сервер базы данных сейчас загружен на 95%. Если трафик вырастет еще на 10% (это примерно через 2 месяца по вашему плану продаж), сайт ляжет в пиковые часы. Нам нужно переписать модуль работы с базой, чтобы этого избежать». Это аргументированный риск.

Вопрос №2. «Почему мы не можем переписать только проблемный кусок?»

Цель: Проверить гибкость мышления.

Плохой ответ: «Там всё так связано, что нельзя тронуть одно, не сломав другое. Архитектура — монолит. Я не отвечаю за результат».

Хороший ответ: «Можем. Это будет дольше в настройке, но безопаснее. Давайте выделим модуль "Склад" в отдельный сервис и перепишем его, а остальное пока не трогаем».

Вопрос №3. «Покажи мне план: как мы будем зарабатывать деньги во время переписывания?»

Цель: Напомнить, что ИТ обслуживает бизнес, а не наоборот.

Плохой ответ: «Мы заморозим выпуск новых функций на полгода. Бизнесу придется подождать, зато потом полетим».

Хороший ответ: «Мы выделим 30% времени команды на рефакторинг (переписывание), а 70% оставим на текущие задачи бизнеса. Скорость упадет, но не остановится».

Вопрос №4. «Как изменится стоимость разработки функции после переписывания? Дай прогноз в цифрах».

Цель: Перевести разговор в плоскость инвестиций.

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

Хороший ответ: «Сейчас добавление нового поставщика занимает 40 часов ($2000). После рефакторинга мы автоматизируем интеграцию, и это будет занимать 4 часа ($200). Мы отобьем затраты на переписывание за 8 месяцев».

Вопрос №5. «Есть ли у нас документация по текущей системе?»

Цель: Понять, управляет ли он хаосом.

Плохой ответ: «Код — лучшая документация. Там всё понятно, если ты сеньор».

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

Заключение.

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

Но в 80% случаев, которые я вижу как Технический заказчик, ультиматум CTO — это смесь перфекционизма, желания обновить резюме за ваш счет и неумения работать с чужим кодом.

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

Что делать прямо сейчас:

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

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