Архитектура: превратить бизнес-задачу в систему, которую можно нормально реализовать

когда подходит

Проблема понятна — непонятно, как её правильно построить

• Разные подрядчики предлагают разные способы решения. Нужен независимый разбор вариантов и обоснованный выбор — до подписания договора на разработку.
• Предстоит внедрение CRM или внутреннего инструмента. Процессы, роли, данные и ответственность надо спроектировать раньше, чем настраивать систему.
• Новый e-commerce затрагивает каталог, склад, аналитику и процессы после заказа. Магазин — только верхушка; проектировать надо весь контур.
• Команде нужна внешняя product-функция до старта разработки. Временная роль архитектора/продакта дешевле, чем переделки после запуска.

что происходит

От задачи — к реализуемому проекту

1. Целевой процесс.

   Как должно работать — глазами бизнеса, а не базы данных. Роли, шаги, исключения.

2. Границы решения и MVP.

   Что входит в первый контур, что откладываем, какие системы за что отвечают, откуда берутся данные.

3. Требования и критерии приёмки.

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

на выходе

Пакет, с которым можно идти к исполнителям

• Целевая архитектуракак должны измениться процессы, системы, данные и ответственность
• Границы MVPминимальный контур, который уже даёт эффект
• Схема системыроли систем, источники данных, интеграционные потоки
• Требованияк ключевым функциям — понятно и бизнесу, и разработке
• Критерии приёмкичто считается готовым результатом
• Риски и briefнеизвестные, журнал решений, ТЗ для исполнителей при необходимости

доказательства

Так уже проектировалось — и было принято в работу