Разные версии продукта
Бизнес, продукт и подрядчик вкладывают разный смысл в одни и те же требования.
Архитектура цифрового продукта
Проектирую системудо дорогойразработки.
Собираю сценарии, роли, данные, интеграции и требования в целостную модель. На её основе можно принять ключевые решения, оценить бюджет и уверенно начинать реализацию.
До кодапроверяются решения, которые дорого менять после старта
Одна модельдля бизнеса, продукта, команды и подрядчика
20+ летархитектурной и продуктовой практики
Планпонятное основание для оценки и реализации
До начала разработки
Список требований не даёт общей картины будущей системы.
Архитектурный проект помогает договориться о продукте, сравнить варианты и увидеть влияние каждого решения на бюджет, сроки и развитие.
Плавающая оценка
Бюджет меняется, потому что роли, сценарии, данные и интеграции остаются неопределёнными.
Ранний выбор технологии
Команда обсуждает инструменты до того, как согласованы границы и реальные требования системы.
Дорогие изменения
Каждая новая функция затрагивает непредсказуемые части продукта и требует всё больше согласований.
Зависимость от подрядчика
Ключевые решения не объяснены и не могут быть независимо оценены или переданы другой команде.
Нет критерия готовности
Нельзя заранее определить, когда этап завершён и соответствует бизнес-сценарию.
Два слоя одной системы
Продуктовая и техническая части проектируются вместе.
Сценарии определяют, какие данные и состояния нужны системе. Архитектура задаёт способ реализовать их надёжно и без лишней сложности.
01Продукт
Пользователи и роли
Кто участвует, какие решения принимает и какую информацию видит на каждом шаге.
02Продукт
Сценарии
Ключевые пути, правила, исключения и границы первой версии продукта.
03Система
Данные
Основные сущности, владельцы, источники, связи и правила изменения состояния.
04Система
Интеграции
Какие внешние системы участвуют, что передаётся и как обрабатываются задержки и ошибки.
05Эксплуатация
Надёжность и доступ
Требования к безопасности, нагрузке, восстановлению и работе критических сценариев.
06Управление
План и приёмка
Поэтапная реализация, зависимости и критерии, по которым результат можно проверить.
Логика решения
Связываю бизнес-цель, сценарии и устройство системы.
Каждый следующий слой отвечает на предыдущий. Поэтому команда понимает не только что реализовать, но и почему это решение существует.
0101
Бизнес-цель
Какой процесс или показатель должен измениться.
0202
Сценарии
Как пользователи получают ценность и где возникают исключения.
0303
Роли и данные
Кто принимает решения и какая информация для этого нужна.
0404
Интеграции
С какими системами связан процесс и где находятся источники данных.
0505
Архитектурный выбор
Как реализовать сценарий с учётом стоимости, риска и развития.
0606
Критерий готовности
Как бизнес и команда проверят, что решение действительно работает.
Архитектурный проект
Столько детализации, сколько нужно для решения и старта.
Глубина проработки определяется тем, кто и какое решение должен принять на основании материалов.
Контекст
Цели, ограничения, участники, текущее состояние и решения, которые уже приняты.
Границы задачиСценарии
Роли, процессы, правила, исключения и состав будущей системы.
Продуктовая модельДанные и связи
Что система хранит, получает, передаёт и с чем должна согласовывать состояние.
Карта данныхВарианты
Сравниваем подходы по стоимости, рискам, срокам и влиянию на развитие.
Обоснованный выборПередача
Формируем этапы, критерии и материалы, разбираем решения с командой.
Основание для стартаКомплект результата
Результат, понятный собственнику, команде и подрядчику.
Каждый материал отвечает на конкретный вопрос: что строим, почему выбран этот вариант, сколько этапов потребуется и как принять результат.
Контекст и границы
Цели, пользователи, ограничения, допущения и состав ближайшего этапа.
Сценарии и роли
Ключевые пользовательские пути, бизнес-правила, права и исключения.
Модель системы
Данные, внешние системы, интеграции и критические состояния.
Варианты решений
Сравнение подходов и причины принятого архитектурного выбора.
План и оценка
Этапы, зависимости и состав работ, достаточные для расчёта бюджета реализации.
Критерии готовности
Проверяемые условия приёмки и встреча-передача с бизнесом и командой.
Архитектурный контекст
Опыт продуктов с ролями, данными, интеграциями и высокой ценой решения.
Проекты показывают практику решений, где пользовательские сценарии, роли, данные и интеграции образуют единую систему.
01 / B2B-банкинг · ДБОLIVE
Совкомбанк Бизнес
Цифровой банк для компаний: продукт с большим числом финансовых сценариев и высокой ценой каждого решения.
Открыть продукт
02 / Mobile banking · УзбекистанAPP STORE
Ipoteka Mobile
Мобильный банк, который объединяет ежедневные операции, переводы, кредиты, валюту и контроль счетов.
Открыть продукт
03 / ЖКХ · цифровая платформаNDA
МГС
Приложение управления ЖКХ, которое связывает жителей, управляющие компании, обращения и объекты.
Детали проекта закрыты NDA
04 / Собственный AI-продуктLIVE
Vi-Code
AI-платформа, в которой web-чат, Desktop и Linux Agent работают как единая среда для проектов и серверных задач.
Открыть продукт
Стоимость проектирования
Глубина проектирования зависит от следующего решения бизнеса.
Для MVP фиксируем ключевой сценарий и решения, которые дорого менять. Для платформы дополнительно прорабатываем роли, данные, интеграции и этапы развития.
Рекомендуемый первый этапот 300 000 ₽Обсудить формат
Архитектурная консультация
80 000–150 000 ₽Разбор конкретного решения, вариантов и ключевых рисков.
Архитектурный аудит
300 000–600 000 ₽Проверка существующей модели и решений перед развитием или сменой команды.
Архитектура MVP
500 000–900 000 ₽Сценарии, роли, данные, интеграции, границы и критерии первой версии.
Архитектура платформы
900 000–2 000 000 ₽Продуктовая и системная модель с несколькими процессами и поэтапным планом реализации.
Сопровождение
300 000–600 000 ₽ / месяцКлючевые решения, ревью и контроль соответствия реализации архитектуре.
Как формируется бюджет
Стоимость зависит от числа сценариев и ролей, интеграций, состояния текущей системы, требований к безопасности и надёжности, а также глубины материалов, необходимых команде.
Вопросы об архитектуре
Что архитектура даёт проекту на практике.
01Нужна ли архитектура небольшому MVP?+
Нужна не максимальная документация, а достаточная ясность: ключевой сценарий, роли, данные, интеграции и решения, которые дорого менять после начала разработки.
02Что останется после проекта?+
Целостная модель системы, принятые решения, план реализации, критерии готовности и материалы, по которым команда сможет оценить и реализовать продукт.
03Можно проверить архитектуру подрядчика?+
Да. Независимый аудит покажет, где решения соответствуют задаче, а где создают лишнюю стоимость, зависимость или риски.
04Сможет ли наша команда работать с результатом?+
Материалы проектируются под конкретных получателей. Итог передаётся на совместной встрече, где решения разбираются с бизнесом и разработкой.
05Можно продолжить сопровождение реализации?+
Да. Я могу участвовать в ключевых решениях, ревью, работе с подрядчиком и контроле соответствия продукта принятой архитектуре.
До начала разработки
Какое решение нужно спроектировать?
Опишите бизнес-задачу, стадию продукта и главную неопределённость. Я предложу глубину архитектурной работы, достаточную для вашего следующего шага.