Короткий ответ
Решение “переписать проект с нуля” нельзя принимать только из усталости от старой системы. Иногда переписывание действительно нужно, но часто сначала выгоднее стабилизировать критичные сценарии, восстановить документацию, разобрать технический долг и локально переработать самые рискованные зоны.
Правильный вопрос не “старый проект плохой или хороший”. Правильный вопрос: что в нём ещё работает, что мешает развитию, какие риски нельзя оставить и какой путь даст бизнесу управляемый результат быстрее и безопаснее.
Если проект уже похож на технический тупик, решение о переписывании нужно принимать после диагностики причин, а не по эмоциям команды или подрядчика.
Почему идея переписать всё выглядит привлекательной
Когда проект долго развивается без порядка, переписывание кажется чистым выходом. Можно убрать старый код, выбрать современный стек, заново описать архитектуру и больше не поддерживать накопленные компромиссы.
Но для бизнеса переписывание с нуля означает не только новый код. Это повторное прохождение всех решений, которые уже накопились в старой системе:
- роли пользователей;
- статусы и исключения;
- интеграции с CRM, 1C, складами, платежами или внутренними сервисами;
- ручные операции сотрудников;
- права доступа;
- отчёты;
- импорт и экспорт данных;
- неочевидные бизнес-правила;
- сценарии, о которых помнят только отдельные люди.
Если всё это не зафиксировать, новая система может получиться технологически свежее, но управленчески такой же проблемной.
Риски переписывания без диагностики
Главный риск - переписать не проблему, а интерфейс проблемы. Команда сделает новую версию, но унаследует старые неописанные процессы, данные и зависимости.
Чаще всего появляются такие риски:
- старая система продолжает жить, потому что новая не закрыла все сценарии;
- сроки переписывания растут из-за скрытой бизнес-логики;
- пользователи не могут перейти на новую версию без ручных обходов;
- интеграции приходится восстанавливать по факту, а не по документации;
- бизнес месяцами платит за две системы: старую поддержку и новую разработку;
- новая команда повторяет архитектурные ошибки, потому что не поняла причины старых.
Поэтому перед переписыванием нужен не спор о вкусе кода, а карта фактов: что сломано, что работает, что можно сохранить, что опасно трогать и где требуется новое проектирование.
Когда достаточно стабилизации
Стабилизация подходит, если проект ещё выполняет критичные функции и его можно вернуть в управляемое состояние без полной замены.
Обычно это разумный первый шаг, если:
- основные бизнес-сценарии работают, но релизы стали рискованными;
- часть модулей стабильна, а проблемы сосредоточены в нескольких зонах;
- интеграции важны, но их можно описать и защитить;
- команда понимает часть системы, но не видит общей картины;
- документация неполная, но её можно восстановить;
- пользователи зависят от текущей системы каждый день;
- бизнесу важнее снизить риск ближайших релизов, чем строить новую платформу несколько месяцев.
Стабилизация не означает “оставить всё как есть”. Это управляемый этап: защитить критичные сценарии, описать зависимости, убрать самые дорогие ограничения и вернуть предсказуемость.
Когда переписывание может быть оправдано
Переписывание имеет смысл, когда текущая система не просто неудобна, а объективно не поддерживает дальнейшую бизнес-логику.
Признаки:
- архитектура не позволяет реализовать ключевые сценарии без обходных решений;
- данные устроены так, что ошибки невозможно контролировать точечно;
- критичные модули ломаются после каждой существенной доработки;
- безопасность, производительность или поддержка упираются в устаревшие ограничения;
- документацию нельзя восстановить в достаточном виде без глубокого расследования;
- стоимость стабилизации приближается к стоимости нового проектирования;
- бизнес меняет модель работы, и старая система больше не соответствует процессам.
Даже в этом случае переписывание должно начинаться не с разработки, а с проектирования границ: что переносим, что закрываем, что временно поддерживаем, какие данные мигрируем и как не остановить текущую работу.
Когда сначала нужен аудит
Аудит нужен, если команда или подрядчик не могут доказать, почему выбранный сценарий правильный.
Например:
- подрядчик говорит “нужно переписать”, но не показывает карту причин;
- внутренняя команда просит время на рефакторинг, но не связывает его с бизнес-рисками;
- новая команда предлагает начать заново, не разобрав старые интеграции;
- собственник не понимает, что из текущей системы ещё имеет ценность;
- оценки стабилизации и переписывания сильно расходятся;
- документации нет, а проект нужно развивать или передавать.
В такой ситуации полезнее начать с аудита проблемного проекта или аудита web-проекта, а не выбирать между двумя дорогими гипотезами.
Симптом -> решение
| Симптом | Что это может означать | Разумный следующий шаг |
|---|---|---|
| Простые доработки стали дорогими | Скрытые зависимости, технический долг, неописанная логика | Сначала оценить долг и карту зависимостей |
| После релизов ломаются старые функции | Нет регрессионных проверок, слабый релизный процесс, связность модулей | Стабилизировать критичные сценарии и релизы |
| Команда боится менять систему | Нет документации, тестов, владельцев знаний или понятной архитектуры | Восстановить карту проекта и зоны риска |
| Интеграции работают нестабильно | Не описаны обмены, источники данных и точки ошибок | Составить карту интеграций и данных |
| Подрядчик предлагает переписать всё | Возможно, причина реальная, но не доказана фактами | Провести независимую диагностику до бюджета |
| Пользователи ежедневно работают в старой системе | Нельзя остановить проект на время новой разработки | Сначала стабилизация, затем параллельный roadmap |
| Бизнес-модель изменилась | Старая архитектура может не подходить новому процессу | Проектировать целевой контур и план миграции |
Как сравнить три сценария
Перед решением удобно сравнивать не “старое против нового”, а три сценария.
1. Стабилизировать текущий проект
Подходит, если проект ещё можно поддерживать, а главная проблема - хаос, долг, слабые релизы, неполная документация или плохая прозрачность.
Результат: меньше аварий, понятнее оценки, безопаснее ближайшие доработки.
2. Локально переработать проблемные зоны
Подходит, если большая часть системы работает, но есть модули, которые постоянно создают риски: интеграции, права, отчёты, импорт данных, личный кабинет или админка.
Результат: точечная архитектурная переработка без остановки всего проекта.
3. Проектировать новую систему
Подходит, если текущая архитектура не поддерживает бизнес-процесс, а стабилизация только отсрочит проблему.
Результат: новая архитектура, но с планом миграции, сохранения данных, поддержки старой системы и постепенного перехода.
Что запросить у команды до решения
Перед тем как согласовать переписывание или большой рефакторинг, запросите у подрядчика или внутренней команды конкретные материалы:
- карту модулей и зависимостей;
- список критичных бизнес-сценариев;
- список интеграций и источников данных;
- оценку технического долга по критичности;
- список зон, которые нельзя менять без риска;
- историю релизов и повторяющихся дефектов;
- перечень документации, которой не хватает;
- сравнение сценариев: стабилизация, локальная переработка, переписывание;
- критерии, по которым станет понятно, что выбранный путь успешен.
Если этих материалов нет, сначала стоит восстановить минимальную техническую документацию web-проекта и собрать roadmap восстановления.
Практичный порядок действий
- Зафиксировать текущее состояние: что работает, что ломается, что нельзя останавливать.
- Собрать карту модулей, данных, интеграций, ролей и релизов.
- Отделить симптомы от причин: сроки, регрессии, долг, документация, подрядчик, архитектура.
- Разделить проект на части: сохраняем, стабилизируем, локально перерабатываем, проектируем заново.
- Оценить стоимость и риск каждого сценария.
- Сформировать roadmap: ближайшие стабилизирующие шаги, среднесрочные решения и критерии перехода к новой архитектуре.
- Только после этого принимать решение о переписывании.
Такой подход помогает не застрять между двумя крайностями: “терпеть старую систему” и “срочно переписать всё”.
Связанные материалы
| Материал | Когда полезен |
|---|---|
| Проект в техническом тупике | Если доработки стали дорогими, сроки плывут, команда боится изменений |
| Roadmap восстановления проблемного проекта | Если нужно разложить восстановление на этапы |
| Как оценить технический долг web-портала | Если нужно понять, какой долг критичен, а какой можно держать под контролем |
| Восстановление web/AI-проекта | Если нужно перейти от диагностики к стабилизации и плану восстановления |
| Чек-лист проблемного web-проекта | Если нужно собрать первые признаки и подготовить разговор с командой |
Практический вывод
Переписывание проекта - это не техническая кнопка “начать заново”, а управленческое решение с риском для бюджета, сроков, пользователей и данных.
Если проект ещё можно стабилизировать, лучше сначала вернуть управляемость. Если система действительно не поддерживает бизнес, переписывание должно идти по roadmap: с картой причин, миграцией данных, сохранением критичных сценариев и понятными критериями успеха.
