#кейс_стади
Задача на подумать для менеджера

Распил монолита — это не просто технический рефакторинг, а стратегический проект. Как справедливо заметили в комментариях, разумно начинать с приоритизации функционала, который критичен для компании. Финансы, логистика, складской учет — в первую очередь. Остальное — по мере стабилизации первых сервисов и понимания архитектуры

После этого в ход идут принципы Disciplined Agile. Вместо жесткого roadmap — адаптивное планирование. Вместо жестких процессов — Way of Working . Стоит подходить к процессам не как к жестким рамкам, а как к пересматриваемому канвасу для удобства, чтобы не разбредаться. Из XP обязательно советую утащить 2 практики как костяк:

Small Releases - команда максимально часто выкатывает изменения, даже если это небольшие куски системы. Это позволяет избежать эффекта «мы три месяца копаемся и ничего не видно».

Planning Game - помогает на высоком уровне держать стратегическое видение, но без жесткого долгосрочного roadmap. Вместо этого есть набор ожидаемых изменений, который корректируется по мере изучения системы.

Но главный элемент этого подхода — обязательные демо. Без них CTO будет постоянно давить на скорость, а команда не будет получать внятную обратную связь.

Каждую неделю команда должна:
1. Показывать не просто код или записи, а работоспособные куски системы на стенде;
2. Получать обратную связь от тех, кто реально пользуется админкой;
3. Давать CTO возможность перепахивать бэклог, меняя приоритеты и набор задач;

Это критически важно. Без регулярной адаптации планов проект превратится в долгострой с фальшивой прозрачностью. CTO должен не просто смотреть отчеты, а быть вовлечен в пересборку стратегии раз в неделю.

Почему другие варианты не работают?
1. Классический WBS с процентами выполнения — дает ложное ощущение контроля. В реальности каждая новая неделя открывает столько неожиданностей, что «50% выполнено» не значит ничего;

2. Работа через списки рисков — CTO хочет не риски, а движение. Без привязки к реальным шагам риск-лог превращается в формальность;

3. Планирование по аналогии с прошлым опытом — у CTO может быть успешный бенчмарк, но если архитектура другая, этот опыт здесь не работает;

4. Прогнозирование через темп команды — пока команда занимается исследованием, темп разработки бесполезен;

5. Применить принцип набегающей волны — делать планирование по мере прояснения картины. На первый взгляд, это кажется разумным: фиксировать ближайшие задачи, а дальние уточнять позже. Проблема в том, что в условиях монолита даже ближайшие задачи — это гипотезы. Их выполнение открывает новые зависимости, что делает любое планирование на несколько итераций вперед практически бесполезным. Этот метод работает в проектах с прогнозируемой структурой, а здесь каждую неделю картина меняется настолько, что даже краткосрочный план нужно пересматривать

При таком подходе работа становится не хаотичной, а управляемой. Команда видит реальный прогресс, CTO получает динамику, а пользователи админки вовлекаются в процесс и помогают формировать продукт. Главное — не создавать иллюзию предсказуемости, а строить процесс так, чтобы он сам корректировал курс по мере движения

P.S. Конечно это невозможно без первичного кик-офа, общих договоренностей об архитектурном стиле и подготовки окружений. Если команда тратит более 5 минут в данном случае на развертывание - к распилу монолита на самом деле вы долго не продвинетесь