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