После аудита был выделен технический долг, восстановлена карта модулей и предложен план стабилизации без полной остановки проекта.
Карта разбора
Ситуация, риски и решение
B2B-портал продолжал работать, но каждое новое изменение цепляло соседние сценарии, а причины задержек становились непрозрачными.
- рост стоимости доработок без понятной причины
- ошибки после релизов в соседних модулях
- передача проекта новой команде без карты архитектуры
- модули, роли пользователей и права доступа
- интеграции, данные и процесс релизов
- документацию, оценки задач и технические зависимости
- восстановить карту модулей, ролей, данных и интеграций
- разделить доработки на обязательные, рискованные и отложенные
- ввести контрольные точки для подрядчика перед релизами
- появилась понятная причина технического тупика
- стало ясно, что стабилизировать до новых крупных функций
- проект можно было развивать без немедленного переписывания с нуля
Почему сценарий обезличен
Разбор описывает типовую ситуацию без названия компании, отраслевых деталей, логотипов и точных коммерческих показателей. Цель сценария - показать ход диагностики, а не имитировать публичный брендовый кейс.
Контекст
У компании был действующий B2B-портал для клиентов и партнёров. Первые версии запускались быстро: добавлялись новые разделы, интеграции и роли пользователей. Через несколько циклов доработок скорость развития начала падать.
На уровне бизнеса проект выглядел живым: задачи ставились, подрядчик работал, релизы выходили. Но каждая новая доработка становилась дороже, сроки росли, а после релизов появлялись ошибки в соседних сценариях.
Симптомы
- доработки регулярно цепляли модули, которые формально не должны были меняться;
- роли пользователей пересекались и усложняли права доступа;
- интеграции работали, но никто не держал единую карту обменов;
- документация не отражала фактическую систему;
- подрядчик оценивал задачи без анализа влияния на соседние модули;
- бизнес не понимал, можно ли развивать текущую архитектуру дальше.
Что проверяли
Диагностика была построена не вокруг поиска одного виноватого участка кода, а вокруг проверки всей связки “процессы, данные, архитектура, подрядчик”.
| Зона проверки | Что искали |
|---|---|
| Архитектура модулей | Где изменения в одном разделе ломают соседние сценарии |
| Интеграции | Какие обмены завязаны на неформальные договорённости |
| Роли и права | Где пересечения ролей создают нестабильность и ручные исключения |
| Документация | Какие решения не зафиксированы и теряются при передаче задач |
| Процесс релиза | Как проверяется влияние доработок перед выкладкой |
| Оценка задач | Учитывает ли подрядчик технические зависимости |
Что стало понятно
Проблема не сводилась к одному плохому модулю. Портал развивался рывками: новые требования добавлялись поверх старых решений, а архитектурная карта не обновлялась вместе с системой. Из-за этого подрядчик видел отдельные задачи, а бизнес видел растущую непредсказуемость.
Часть технического долга уже влияла на сроки и качество релизов. При этом полная остановка проекта и переписывание с нуля не были очевидно лучшим решением. Сначала нужно было стабилизировать критичные сценарии и восстановить управляемость.
Какие решения не принимались до аудита
До завершения диагностики не рекомендовалось:
- срочно переписывать весь портал без карты причин;
- переносить проект новой команде без документации и списка рисков;
- запускать крупные новые разделы поверх нестабильных модулей;
- считать проблему только слабостью подрядчика;
- добавлять AI-функции до проверки данных, ролей и интеграций.
План действий
- Зафиксировать критичные пользовательские сценарии, которые нельзя ломать в ближайших релизах.
- Восстановить карту модулей, ролей, данных и интеграций.
- Разделить доработки на обязательные, рискованные и отложенные.
- Выделить архитектурные решения, которые нужно принять до новых крупных функций.
- Ввести контрольные точки для подрядчика: что проверяется до релиза и какие риски фиксируются письменно.
- Подготовить roadmap стабилизации без полной остановки проекта.
Вывод для похожих проектов
Если портал стал плохо развиваться, причина редко находится в одном фрагменте кода. Чаще нужна независимая диагностика связки “процессы, данные, архитектура, подрядчик”.
Для похожих ситуаций полезны аудит проблемного проекта, восстановление web/AI-проекта и статья как понять, что web-проект зашёл в технический тупик.
