Стратегия развития 2-я половина 2025: бизнес-клуб, отдел заботы и инженерия требований

Стратегия – это искусство отказа, искусство фокусировки. Стратегия развития Альянса во второй половине 2025 года такая:

1. называем альянс понятным словом, описывающим процесс работы – бизнес-клуб
2. в рамках клуба создаем регулярные программы развития партнерских отношений, например, Хакатон для марок и мультибрендов, где учимся с трекерами работать по Своду знаний и Набору документов для совместной работы
3. создаем отдел заботы, который собирает боли/потребности с каждым индивидуально и фиксирует боль/потребность в Битриксе (Алина Цуцу этот процесс курирует)
4. вместе со сбором болей отдел заботы их решает: назначает встречи с теми игроками экосистемы, которые могут помочь участнику клуба. И типизирует эти решения. Таким образом в уже существующих партнерских цепочках Альянса с проверенными партнерами идет настройка взаимодействия. Вероятнее всего, можно масштабировать уже существующие продукты, вот они: производственный модуль, услуги агентства по работе с ритейлерами, d2c продажи, менторинг от сертифицированных экспертов, сертификация экспертов, сетевые проекты с сообществом (спонсорство клуба ради партнерских лидов и продвижения новых продуктов)
5. в MBSE этот наш этап описывается так "преобразовать боли/потребности участников клуба в требования заинтересованных сторон, создав участвующим ролям свой интерфейс и путь использования"

Ниже цитата из учебника MBSE. Мне кажется, надо глянуть эти схемки, чтобы просто понимать, как эти инженерные задачи решают другие.

Глава 6: Инженерия требований

ПАРАГРАФ 6.2. ТРЕБОВАНИЯ В ЖИЗНЕННОМ ЦИКЛЕ СИСТЕМ

Жизненный цикл системы начинается со стадии «определения концепции». На первых шагах этой стадии заказчик (или предприятие) идентифицирует новые желательные возможности системы в виде потребностей (needs) заинтересованных сторон. Такие потребности еще не являются требованиями, так как они недостаточно про-работаны.

Затем проводится бизнес-анализ или анализ миссии, результатом которого являются высокоуровневый набор стратегий и потребностей, выраженные в виде бизнес-требований, отражающих миссию проекта.

Далее проводится анализ возможных решений, направленных на удовлетворение потребности заинтересованных сторон, с целью уточнений потребностей и их трансформации в требования заинтересованных сторон (представление системы с точки зрения пользователя).

Следующей стадией жизненного цикла систем является стадия «определения системы». На этой стадии требования заинтересованных сторон преобразуются в системные требования.

Описанные выше процессы и составляют основу инженерии требований, место которой в жизненном цикле систем иллюстрируется на рис. 6.1

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

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

Рекурсивный и итеративный характер процессов разработки требований иллюстрируется на рис. 6.2 .

Рекурсивное применение описанных выше процессов позволяет создать требования к системным элементам более низкого уровня.

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

Цитата по: ВВЕДЕНИЕ В МОДЕЛЬНО-ОРИЕНТИРОВАННУЮ СИСТЕМНУЮ И ПРОГРАММНУЮ ИНЖЕНЕРИЮ (MBSSE) (Сухомилин, Романов, Гапанович)