Короткий ответ
Восстановление проблемного web-проекта начинается не с переписывания и не со смены команды. Первый шаг - получить фактическую картину: что работает, что блокирует развитие, какие риски критичны и какие решения нельзя принимать вслепую.
Roadmap восстановления нужен, чтобы бизнес не метался между срочными багами, новыми подрядчиками и идеей “переписать всё”. Он разделяет работу на этапы: стабилизация, диагностика, план, восстановление документации, аккуратное развитие.
Если главный вопрос сейчас звучит как “переписывать проект или спасать текущий”, сначала полезно разобрать критерии в статье переписывать проект или сначала стабилизировать.
Шаг 1. Зафиксировать состояние
Перед изменениями нужно остановить хаос в информации. Пока нет общей картины, каждая новая задача может усилить проблему.
На первом шаге собирают:
- текущий список задач и ошибок;
- ближайшие обязательства перед клиентами или подразделениями;
- доступы к репозиторию, серверу, домену и внешним сервисам;
- список ключевых модулей;
- список интеграций с CRM, 1C, платёжными системами или внутренними сервисами;
- текущую документацию, даже если она неполная;
- список людей, которые знают критичную логику.
Цель этапа - не исправить всё, а понять, чем проект реально является сейчас.
Шаг 2. Отделить симптомы от причин
Проблемный проект обычно проявляется через симптомы: срывы сроков, дорогие доработки, баги после релизов, зависимость от одного разработчика, недоверие к подрядчику. Но roadmap должен строиться не по симптомам, а по причинам.
Например, частые ошибки после релиза могут быть вызваны не только слабым тестированием. Причина может быть в неописанной бизнес-логике, тесной связке модулей, ручных обменах с CRM или отсутствии среды для проверки.
Полезно разобрать проект по пяти слоям:
- бизнес-логика и роли пользователей;
- архитектура и код;
- данные и интеграции;
- процесс разработки и релизов;
- документация и передача знаний.
Если проект уже находится в техническом тупике, без такого разбора новые задачи будут оцениваться всё дороже.
Шаг 3. Выделить критичные зоны
Не все проблемы нужно решать сразу. Восстановление начинается с зон, которые влияют на бизнес сильнее всего.
Критичными обычно становятся:
- функции, без которых пользователи не могут работать;
- интеграции, где теряются или искажаются данные;
- модули, которые ломаются после каждой доработки;
- доступы и инфраструктура, завязанные на отдельных людей;
- релизный процесс без понятного отката;
- документы, без которых проект нельзя передать.
На этом этапе важно не распыляться. Roadmap должен показывать, что стабилизировать в первую очередь, что можно отложить, а что требует отдельного проектирования.
Шаг 4. Сформировать план восстановления
Хороший план восстановления не выглядит как список всех хотелок. Он связывает проблемы с действиями и ожидаемым результатом.
В плане стоит зафиксировать:
- цель этапа;
- технические задачи;
- бизнес-риски, которые закрываются;
- ответственных;
- критерии готовности;
- зависимости от подрядчика или бизнеса;
- что должно быть задокументировано после выполнения.
Например: “описать интеграции” - слишком общая задача. Лучше: “составить карту обменов с CRM и 1C, указать направление данных, частоту обмена, владельцев, точки ошибок и действия при сбое”.
Такой подход делает восстановление управляемым.
Шаг 5. Решить, нужна ли смена подрядчика
Смена команды может быть правильным решением, но она не должна быть первым рефлексом. Если проект не описан, новая команда начнёт с дорогого расследования и унаследует те же риски.
До смены подрядчика стоит подготовить:
- актуальную карту проекта;
- список известных рисков;
- инструкцию по запуску и деплою;
- описание ключевых бизнес-сценариев;
- перечень открытых технических решений;
- план первого месяца для новой команды.
Если передача неизбежна, полезна статья как подготовить проект к передаче новой команде. Если нужна независимая диагностика, подходит аудит проблемного проекта.
Шаг 6. Вернуть плановое развитие
После стабилизации возникает соблазн сразу вернуться к большому списку доработок. Лучше сначала ввести правила, которые не дадут проекту снова уйти в хаос.
Нужны:
- критерии готовности задач;
- регулярная актуализация документации;
- карта влияния доработок на модули и интеграции;
- понятный процесс релизов;
- список зон, где перед оценкой нужна диагностика;
- технический владелец решений.
После этого проект можно развивать спокойнее: доработки становятся понятнее, риски видимее, а разговор с подрядчиком предметнее.
Практический вывод
Roadmap восстановления нужен, чтобы не лечить проблемный проект набором срочных реакций. Он переводит ситуацию в управляемую последовательность: факты, причины, критичные зоны, план, документация, развитие.
Если проект уже нестабилен или сроки сорваны, разумный первый шаг - чек-лист проблемного web-проекта или услуга восстановления web/AI-проекта.
