Когда компании создают новый ИТ-продукт, они почти всегда начинают одинаково: собирают требования, формируют backlog продукта, начинают разработку.
Для простых продуктов такой подход может сработать. Но чем сложнее продукт, тем быстрее начинается хаос:
- требования противоречат друг другу
- команды делают «свою часть», но система как готовый продукт не получается
- внесение изменений ломает ранее сделанное
- архитектура продукта расползается
Проблема в том, что проект управляется через задачи, а не через понимание системы.
Именно в таком контексте становится критически важным использование подхода MBSE.
Что такое MBSE в контексте ИТ-продукта
Model-Based Systems Engineering (MBSE) — это подход, при котором продукт сначала описывается как система, а уже потом разбивается на задачи разработки.
Это значит, что вы работаете не только с backlog продукта, но и с моделью, которая отвечает на вопросы:
- кто пользователи и какие у них работы (Jobs)
- какие функции должен выполнять продукт
- какие данные используются и как они связаны
- какие сервисы и компоненты участвуют
- какие есть ограничения и риски
- как всё это связано между собой
Проект начинается не со списка задач, а с создания согласованной картины продукта как системы.
Где MBSE даёт максимальный эффект
1. На старте создания продукта
Позволяет чётко определить границы системы: что входит в продукт, а что остаётся снаружи, убирает размытость границ проекта и лишние ожидания.
2. При работе с требованиями
Связывает в одной модели бизнес-цели, пользовательские сценарии и технические ограничения. Требования перестают жить отдельно от реализации.
3. При проектировании архитектуры
Даёт целостную картину: модули, API, данные, интеграции, нефункциональные требования. Архитектура продукта становится управляемой, а не «собранной по кускам».
4. При управлении изменениями
Позволяет сразу видеть последствия: что сломается, если меняется один элемент системы. Снижается стоимость изменений.
5. При работе с рисками
Помогает заранее выявить узкие места, конфликты между командами, нестыковки в логике. Проблемы находятся до того, как становятся дорогими.
Как применять MBSE на практике
Для нового ИТ-продукта это можно выстроить как последовательный процесс:
Шаг 1. Описать систему
Зафиксировать: работы (Jobs), на которые нанимается продукт, пользователей, потребности, которые возникают у пользователей при выполнении работы, внешние системы, каналы, ограничения.
Шаг 2. Построить сценарии
Определить: что делает пользователь, какой результат ожидает получить, какие компоненты участвуют в реализации.
Шаг 3. Связать требования с архитектурой
Каждое требование должно иметь описание конкретного элемента системы, который его реализует.
Шаг 4. Управлять изменениями через модель
Любое изменение автоматически показывает влияние на данные, API, процессы и тесты.
Шаг 5. Сделать модель единым источником правды
Её используют все: продукт, аналитика, архитектура, разработка, QA.
Чем это отличается от классического управления проектом
В классическом подходе PM управляет задачами, сроками, статусами.
В MBSE PM получает дополнительный уровень — системную модель продукта. То есть управляет не только «что делаем», но и тем, «как устроен продукт как целое».
Когда без MBSE уже не обойтись
Подход особенно важен, если:
- продукт быстро растёт
- много команд
- много интеграций
- высокая цена ошибки
- сложная бизнес-логика
- есть риск, что команды «разъедутся» по разным направлениям
Если этого не делать, возникает классическая ситуация: каждая команда делает свою часть правильно, но продукт в целом не работает.
Главный эффект
MBSE переводит разработку из режима «управляем задачами» в режим «управляем системой».
Что это даёт бизнесу
- Прозрачность архитектуры
- Снижение потерь на согласованиях
- Контроль зависимостей
- Быструю реакцию на изменения
- Повышение качества решений
И главное — продукт начинает работать как единое целое, а не как набор отдельных решений.
В сухом остатке
MBSE — это не про документацию и не про усложнение процессов. Это про переход на другой уровень управления — от локальных задач к целостному управлению системой продукта. И чем сложнее продукт, тем быстрее этот подход начинает окупаться.