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