4) Текст или диаграмма — это представление модели и способ фиксации решений. Все очень заморочены тем, как правильно написать требования или как правильно нарисовать диаграмму. А дело вообще не в этом. Это результат. А деятельность аналитка — указать, какая точка требует принятия решения, и обеспечить принятие этого решения. Подготовить варианты, возможно. Обозначить последствия. Установить связи, зависимости и ограничения. Но в итоге — добиться принятия решения и зафиксировать его. А потом учесть все последствия и влияния, и задать новые вопросы. Это и есть основная задача, а не "требования писать". Поэтому требования (и другие артефакты) пусть вам ИИ пишет, вы главное решения принимайте. ИИ в этом случае должен про эти решения спрашивать, подгонять вам поводы для принятия решений.

И центральным документом, по которому можно отслеживать ход проекта, становится документ с записями о решениях. Не только ADR, но и BDR (Business), и CDR (Client), и DDR (Design), и так далее.

Требования и любые другие представления вам чат напишет. А вот решения должен принимать только человек! И чтобы их принять, нужно будет разобраться с этой частью системы. А через это как раз и сформируется карта системы в голове.

Ну а ведение документа с зафиксированными решениями, подготовку обоснований, анализ tradeoffs и рассмотрение последствий можно тоже поручить ИИ.

Знаете ли вы про кризис воспроизводимости психологических исследований? Практически ничего из знакомых нам понятий и моделей из психологии ХХ века не воспроизводится при повторных экспериментах. Либо вообще, либо с гораздо меньшим эффектом, либо не учтены какие-то важные параметры (как в "зефирном тесте"), либо просто выдуманы от начала до конца ("Стэнфордский тюремный эксперимент", или вот недавнее расследование про "когнитивный диссонанс").

Преподавателям в этих условиях приходится трудно. Настоящие психологи постоянно оговариваются "у этой теории вообще нет эмпирической базы", "данные для подтверждения этой очень сомнительны". А бизнес-тренеры этим в основном вообще не заморачиваются. Так получилось, что я в последнее время наблюдал несколько курсов по лидерству, и там лепят вообще всё подряд — и что проверено, и что нет, а для иллюстрации любят ещё и фрагмент из какого-нибудь кино поставить. Жизнь — не кино! Документальные съёмки не такие гладкие и интересные, как постановочные.

Ну и часто проскакивают отсылки к поведению животных — этологии. Там тоже не всё гладко — например, с вожаками в стае волков. Стая вообще оказалась не стаей, а просто семьей. И впереди идёт не альфа-самец (которого нет, есть просто отец семейства), а самый бодрый и любопытный волк. Автор главной книги про альфа-лидерство уже и опровержение написал, и прекратить переиздание неправильной книги пытался, но не особо получается.

С лидерством вообще всё плохо — многие путают его с доминированием. Этология как раз дает определение: доминирование — это кто первым ест и размножается, это про силовое удержание статуса и ресурсов. А лидерство — это за кем группа идет в поисках пищи или спасаясь от угрозы.

И во многих ситуациях это вообще не доминант. Раньше считалось, что доминирование = лидерство, а сейчас присмотрелись — нет, часто не связанные вещи. Доминант знает, как защищать свой статус и ресурс, а вот повести за собой не всегда может. Да и рискованно — вдруг там кто-то подвергнет сомнению его положение? И члены группы за ним не так охотно идут — от него вообще лучше подальше держаться, для безопасности. Гораздо чаще лидером становится кто-то более безопасный и близкий по статусу.

И вот это прямо инсайт для меня: лидер — тот, кто знает, куда идти, а не тот, кто всех застращал. И тут, кажется, у аналитика есть большое преимущество — уж он-то знает, куда идти. Или нет? Вот это один из принципиальных вопросов для роли — знаем ли мы, куда идти, или мы только можем в деталях описать, как идти, когда кто-то другой уже выбрал цель?

Мы как будто ставим задачи — делает ли нас это лидерами? Или это сугубо техническая задача, просто удобный сервис?

Кажется тут есть 4 варианта по двум осям: Цель — Детали и Описание — Движение. Детали/описание — аналитик, детали/движение — менеджер, цель/движение — лидер, цель/описание — не знаю, кто, стратег?

С другой стороны, можно же в эту сторону не ходить? И только подавать анализ, когда требуется, а вперед уже пусть лидер ведет. Мы ему скажем, куда.

Рискну поднять холиварную тему: где границы ролей BA и SA?

На тренинге опять возник этот вопрос. И, кажется, есть немалое число компаний, в которых есть принятое разделение между этими ролями. Принятое, но, однако, недостаточно чёткое.

И я, честно говоря, не видел чёткого и признанного определения.

У нас есть профессиональные стандарты, в которых весьма конкретно определена разница: BA — специалист по организационным изменениям и оптимизации;
SA — специалист по проектированию и координации создания информационных систем.

Это чёткие определения, но они мало признаны. Обычная реакция — а, профстандарты! Разве они имеют какое-то отношение к жизни? Вот BABoK! (В этом своде знаний, кстати, системные аналитики упоминаются лишь один раз вскользь. Но и для BA работа с ИТ-системой там описана как частный случай)

В реальной жизни я чаще вижу другой подход (видимо, сложившийся естественным путем): BA — тот, кто может поговорить с пользователями и записать их требования(!), проанализровать и описать их деятельность, и сформулировать концепцию ИТ-решения, а иногда и достаточно детальные постановки (BRD), но всё ещё понятные бизнес-заказчикам.

А SA в такой конфигурации — эксперт по устройству систем. Он осуществляет распределение требований и задач на системы и их элементы, переводит концептуальные и логические модели в физические, проектирует схемы данных, API и брокеры, описывает технические моменты типа журналирования, метаданных, ретраев и т.п. То есть, смотрит на систему не как на черный ящик, а уже хорошо разбирается в её устройстве. И останавливается только перед непосредственным прораммированием.

И тут я у вас хочу спросить -- где, по-вашему, граница ролей и деятельности? До чего в пределе может дойти BA, а что для него уже перебор? Чтобы структурировать обсуждение, предложу рассматривать следующие аспекты:

1. Цели бизнеса / создания системы
2. Модель деятельности (процессы, юзкейсы, сценарии)
3. Модель данных, состояний
4. Пользовательские, функциональные и системные требования
5. Интерфейсы пользователя и API
6. Отчеты, метрики, дэшборды
7. Нефункциональные требования
8. Архитектура системы

Насколько далеко в каждом направлении может/должен продвинуться BA, а где ему придется остановиться?

Короче, я психанул и создал канал про цифровизацию образования: https://t.iss.one/nodxhere

Это две вещи, которые меня особенно волнуют:
* Как наиболее эффективно создавать программные системы (отсюда — системный анализ, проектирование и управление продуктом, весь канал, который вы читаете);
* Как наиболее эффективно учить людей.

И вот в последнем, мне кажется, глупо не использовать цифровые технологии — уж если они радикально меняют и перестраивают другие области жизни, то уж образование тоже должны! Но мы видим странное — вроде, и технологии внедряются, и деньги выделяются, и рынок растет — а принципиальных изменений как не было, так и нет. Не происходит подрыва, как в других отраслях. Даже на горизонте не видно. Уже автономные автомобили по улицам ездят, а мы всё так же слушаем лекции, как в Древней Греции, и пишем эссе, как в XVI веке.

В общем, кажется, что-то где-то идёт не так, и интересно — что именно.

И многие исследования показывают, что цифровизация-то образования происходит, а какой-то принципиальной трансформации — нет. Поэтому и канал я так и назвал: "Цифровизация без трансформации"

В общем, если вам интересна тема образования и технологий, милости прошу:

https://t.iss.one/nodxhere

Там будет много ссылок на разные исследования, в основном школьного и вузовского образования — просто потому, что их больше исследуют и они образуют системы, в отличие от профессионального и неформального ("наплодились всякие курсы"). Ну и мои наблюдения — всё-таки, я уже почти 20 лет преподаю, 10 лет занимаюсь проектированием и созданием систем в этой области, кое-что видел и, смею надеяться, понял.

Сергей Баранов написал про DDD — Domain Driven Design. Предметно-ориентированное проектирование, как его по-русски называют.

У меня есть по поводу DDD несколько инсайтов, накопилось материала на отдельный пост.

1) Аналитики не особо знают DDD, потому что DDD придумано как раз для ситуаций, когда разработчики работают без аналитиков. И нужно как-то понять, что там эти пользователи вообще хотят. А ничего нет — ни моделей процессов, ни требований, ни модели данных. Интересно тут то, что, в принципе, подошла бы любая техника выявления требований и описания предметной области: хоть модели БП, хоть Use Cases, хоть User Story Mapping. Было бы желание. Но желания в этом разбираться у программистов как раз обычно и нет, интереснее же писать код. То, что написанный код очень отдаленно соответствует предметной области, решает локальные проблемы и закрывает возможности для развития — выясняется сильно позже и больно бьет. Поэтому программисты придумали свой метод — запишем ровно то, что говорят пользователи (ubiquitous language), и будем делать в программе классы именно с такими именами — тогда произойдет магия и нас не заругают.

2) Программистам больше всего интересен слой логики. Вопрос хранения данных решает ORM, вопрос проектирования интерфейсов вообще оскорбителен — это дело дизайнеров же. Поэтому юскейсы и user story не заходят — они слишком много говорят о пользователях и сценариях их работы. Нам бы что-нибудь поближе к классам и их взаимодействию. То есть, это всё то же решение задачи — какие именно классы создать в объектно-ориентированной программе. Есть паттерны GoF, но они слишком низкоуровневые. Есть юскейсы — но они слишком высокуровневые, и непонятно, как перейти от них к классам. Знания предков, типа подхода Якобсона к отображению юскейсов на классы через Entity Object - Control Object - Boundary Object, оказались прочно забыты.

Кроме того, программисты склонны упрощать юскейсы до операций CRUD, начисто отбрасывая всё рассмотрение деятельности пользователей (какая ещё деятельность, нипанятна). В Clean Architecture каждый use case — это отдельный класс, и они все живут в своем отдельном слое юскейсов. Вроде бы это как раз пересказ идей Якобсона про Control Object, но понятый не всеми. При этом часть логики живет в этом слое, а часть в Entity — опять непонятно, несмотря на название. DDD вводит свою терминологию (агрегаты, инварианты), и мы попадаем в ситуацию, когда несколько подходов говорят об одном и том же, но разными словами.

3) DDD упирает на generic domains: типовые домены, для которых вообще не нужно ничего разрабатывать, а взять готовое. Называются оценки 80/20 или даже 95/5 — мол, в вашем решении уникального-то всего 5%, на них и сосредоточьтесь, а остальное возьмите готовое.

Здесь нужно быть втройне аккуратными, т.к. есть большой риск "выплеснуть с водой ребенка". Generic могут быть только низкоуровневые компоненты, типа аутентификации, хранения файлов, отрисовки интерфейсов и математических операций, или стандартизованные бизнес-функции, типа платежей, электронной подписи или обмена сообщениями.

Всё, что несет чуть больше бизнесового контекста, попадает под два закона:

1. "Парадокс переиспользования": степень эффективности выполнения задачи компонентом в конкретном контексте обратно пропорциональна возможности переиспользования этого компонента (чем лучше работает, тем хуже возможность переиспользовать);

2. "Эффект фастфуда": чуть хуже + чуть хуже + чуть хуже + ... = полный провал. Если мы возьмем "95% не уникальных Generic функций", которые всего лишь чуть хуже, чем специализированные — на выходе получим неудобоваримое нечто.

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

Итого, три инсайта про DDD: это для программистов без аналитиков, это для слоя логики, и со склонностью применять упрощенные решения там. А так-то дело хорошее.

Продолжение про «похожие процессы» и про важность DDD.

(кажется, получился очень глубокий и важный пост про важность DDD)

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

Взять сферу туризма – это отдельная профессия, ей учатся по пять лет, чтобы нормально разбираться в маршрутах, сезонах, рисках, партнерах и ожиданиях клиентов. И взять разработчика – тоже лет пять только чтобы уверенно писать код, понимать архитектуру, паттерны, инфраструктуру.

И вот спец по туризму открывает турфирму. Нанимает сотрудников, поднимает продажи, строит партнерства – бизнес как‑то работает.

В какой‑то момент становится тесно в Excel и мессенджерах и он нанимает разработчиков: «пора автоматизировать».
Что разработчик, который 5 лет учился на разработчика, знает о туризме? Ну… есть Турция, Египет, самолетом можно долететь, отели бывают с завтраком и без….

У него нет такого же целостного и глубокого представления о процессе, как у эксперта в туризме. Прилетает задача: «сделай бронь места в гостинице, вот тут предоплата, вот тут подтверждение». Он честно реализует эту отдельную фичу.

Потом еще одну.
Потом «быструю доработку к сезону».
Потом срочный костыль «потому что партнер меняет правила».

Со временем разработчик, конечно, начинает лучше понимать процесс, картинка становится целостнее…. но к этому моменту система уже обросла заплатками так, что ее страшно трогать. «Сначала требования определяют архитектуру, а затем живут в ней» (c) мой

И вот в системе сотня мест, где бизнес-жвачка намотана на технический долг и любая попытка рефакторинга превращается в операцию на сердце.

С должным усилием, упорством и желанием этот разработчик вырастает до архитектора.
Он наконец смотрит на весь процесс целиком и понимает, что 90% кода можно выбросить и заменить несколькими коробочными продуктами, одним внешним сервисом и небольшим слоем кастома. Потому что реально уникальное – вот эти самые 5%, где и прячется конкурентное преимущество бизнеса, а все остальное – типовой, стандартный Generic.

Вот эту проблему во многом и решает DDD вместе с практиками вроде Event Storming.
Они как раз про то, как вытащить знание экспертов (в нашем примере – гуру в туризме), перевести его в общий язык и донести до разработчиков и архитекторов так, чтобы все видели одну и ту же цельную картину.

Пока этого понимания нет, «в прод идут лишь предположения разработчиков о предметной области» (c) Альберто Брандолини
Как только оно появляется – архитектура начинает работать на бизнес, а не наоборот.

Ну и завершая тему DDD (готов уворачиваться от помидоров) — ни в одной рекламной статье вам не расскажут про "DDD трилемму" — аналог CAP-теоремы для моделирования доменов.

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

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

В реальной жизни у вас либо бизнес-логика оказывается размазана по уровням (что-то контролируется в модели, что-то — в контроллере, что-то вообще в БД), либо модель должна ходить в базу / в глубинные слои инфраструктуры, соответственно — начинает зависеть от реализации, либо всё красиво и абстрактно, но нещадно тормозит.

Вот ключевая статья на эту тему от Владимира Хорикова https://enterprisecraftsmanship.com/posts/domain-model-purity-completeness/ + преза на русском.

Там простой пример: проверка уникальности email'а при регистрации пользователя. Как его делать? То ли передать с уровня домена в контроллер (и там сначала проверить существование пользователя с таким email), то ли прямо из модели пользователя сходить в хранилище поискать email'ы, то ли поднимать всех пользователей из хранилища на уровень домена, и отдавать модели пользователя (сожрет всю память).

Ну и вот, выбирайте, как хотите. И так, и так, и так будет криво, вопрос — с какой кривизной вы готовы столкнуться?

Это, в общем, следствие старого Закона дырявых абстракций Джоела Спольски: все нетривиальные абстракции дырявы.

И DDD тут тоже не является серебряной пулей. Собственно, претензии к адептам примерно те же, что и к инфобизнесменам — не в том дело, что приемы какие-то неправильные, дело в том, что нельзя создавать впечатление, что DDD решит все проблемы с целостностью и изолированностью изменений. Не решит. Всё равно придётся выбирать плохое из худшего.

"Назови три"

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

Но у всех них, однако, можно чему-то научиться. Вот, например, попалась мне статья с LessWrong, а потом и вторая. LessWrong — это главный ресурс движения рационалистов. Ну, теорема Байеса, борьба с когнитивными искажениями, "Гарри Поттер и методы рационального мышления", вот это всё.

Статья про конкретику (в английском, как обычно, есть два отдельных слова: specific и concreteness). Я думаю, мы все с этим сталкиваемся, когда говорим с заказчиками. Да и когда между собой спорим, что уж тут.

Вы спрашиваете про функции будущей системы, а заказчик вам начинает говорить что-то про "эффективное решение для организации коммуникации между подразделениями" или "оптимальное распределение состава финансовых инструментов в портфеле". И вроде всё понятно, но что конкретно делать-то?

В статье приводят в пример разбор дейтинг-стартапа на школе YCombinator: на вопрос, а что конкретно лучше он делает по сравнению с обычными способами общения, автор отвечает нечто вроде "конкретно наш продукт предоставляет более лучший способ коммуникации для людей, они много что делают в реальной жизни, и пытаются это делать онлайн, и мы даем им онлайн-инструмент, чтобы делать это". Понятно, в чем фишка стартапа?

То же самое постоянно делают участники тренингов: вместо того, чтобы быть конкретными, стараются наоборот обобщать. Так в документах и на диаграммах появляются "данные клиента", "информация о товаре", "контент курса" и "управление скидками".

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

В изучении иностранных языков есть такая игра: "назови три". Тебе дают общее понятие, и нужно назвать три конкретных. Три предмета одежды, три кухонных прибора, три водоплавающих птицы и т.д. Очень полезное упражнение, им можно и собеседников на интервью возвращать к конкретике. Приведите пример, пожалуйста. Ладно, не три, хотя бы один. Хотя лучше несколько — для разных ситуаций.

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

Я раньше не мог понять, что заставляет людей возноситься к абстрактным понятиям. LessWrong утверждает, что это когнитивное искажение, связанное с экономией мыслетоплива и подстановкой атрибута — назвать абстрактное (всё объясняющее) понятие проще, чем подумать над конкретным примером. LW предлагают ловить это у себя: как только заметили слишком абстрактные слова или мысли — остановитесь и придумайте конкретный пример. Но для нас, как аналитиков, очень важно вытаскивать конкретику из других людей, поэтому и на собеседниках нужно использовать этот прием, просить привести примеры — типичные и исключительные.

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

— У нас протечка.
— Протечка чего?
— У меня всё сиденье мокрое.
— Должно быть, это абстракции протекли.

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

В институте нас очень аккуратно провели по всем уровням абстракций при создании электронной аппаратуры:

Сначала ты анализируешь задачу — твоё устройство вообще зачем? Какие функции оно будет выполнять?

Потом строишь алгоритм, или, например, карту Карно. Или целую функциональную схему (для цифровых схем — логическую), где только нолики и единички бегают.

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

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

Кое-что из этого можно и нужно решать программно — например, нагрев. Опять протечка!

И эти протечки нам могут подсказать границы ролей. Если в бизнес-процессе участвует смежная система — какое у аналитика предположение о её ответе? Она всегда доступна и отвечает мгновенно? Это бизнес-анализ. Ответ занимает столько-то миллисекунд в 95% случаев? При получении ответа 500 мы ждем 3 секунды и пытаемся выполнить запрос повторно? Это системный анализ/проектирование. Что мы показываем пользователю во время этого ожидания, чтобы он не нажал ещё несколько раз, не видя отклика? Это протечка абстракции: мы должны учесть детали реализации. В устранении протечки должны участвовать две роли. Перекладывать на бизнес-аналитика задачу "представить себе, как это будет реализовано" — это с больной головы на здоровую, не его зона ответственности, не его уровень абстракции. Мы же стараемся, чтобы более верхний уровень не знал о деталях реализации нижележащего.

Можно попробовать ещё накидать типовых точек протечек:
— Поиск/фильтрация по большому объему данных. А вы об индексах подумали? А может, запретим выдачу без фильтров, а то слишком много результатов, это full scan — протечка! Мы не должны думать об устройстве базы. Нужна совместная работа двух ролей. Сюда же — пагинация, поэтому её так часто БА забывают.
— Форматы данных при передаче. JSON? XML? Avro?
— Парадигма хранилища (реляционное, колоночное, документарное)
— Домены данных в хранилище (типы + ограничения на формат/диапазон, а вот бизнес-правила — это уже уровень выше)
— Кэширование, управление кэшированием (это и для системного аналитика часто вне рассмотрения)
— Распределение обращений по однотипным узлам, балансировка нагрузки
— Стратегии обеспечения согласованности, CAP/PACELC, уровни согласованности данных
— Развертывание, обновление
— Поддержка разных окружений (браузеры, ОС, оборудование, подключение к сети)

Разборки со всеми этими уровнями требуют двух точек зрения:
1. Взгляд на устройство системы: а почему я не могу сделать систему такой, чтобы об этом не нужно было думать?

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

В конечном итоге, кажется, всё это укладывается в проверочный вопрос "если системы нет, то как это будет исполняться?" Пока нет конкретной реализации системы — это бизнес-анализ, нужно учитывать особенности реализации — системный.

Я тут вместе с ChatGPT немного подумал про разделение ролей и протечку абстракций, и вот что у нас получилось, полюбопытствуйте:

Абстракции есть не только в архитектуре. Роли на уровне организации распределены тоже по слоям абстракций, с обещанием "вам на этом уровне не нужно об этом думать". Это [само]обман — абстракции всегда дырявы. С этим не нужно бороться, это нужно учитывать.

Частая ошибка — проводить границы ролей по артефактам ("кто описывает процессы, кто требования, а кто API"). Артефакт — след деятельности, а не её смысл. А граница проходит по языку, точнее — по модальностям. Сергей Нужненко любит упоминать логику, ну вот всё проектирование — это набор модальных логик, своих для каждой роли. По сути, описание разных миров с операторами достижимости: □ "во всех достижимых мирах" / ◊ "в некотором достижимом мире".

По ролям эти логики раскладываются так:

Продакт (владелец ценности). Модальность пользы: "желательно/целесообразно/вероятно окупится | во всех мирах/в отдельном мире". Это логика предпочтений и неопределённости. "В большинстве релевантных сценариев это даёт пользу [и это лучше, чем другой вариант], мы твердо уверены в этом".

BA (владелец политик). Деонтическая модальность, логика норм и обязательств: обязательно/разрешено/запрещено. "Во всех допустимых (нормативно корректных) вариантах поведения бизнеса это должно быть так".

SA (владелец модели). Динамическая и темпоральная модальность: "после события X", "всегда", "в состоянии системы S1 | допустимо/обязательно". Сюда же модальность последовательности ("после выполнения действия A допустимо/обязательно B"). В общем, это про целостность, "во всех достижимых состояниях модели инварианты сохраняются".

Архитектор, владелец качества. Мультимодальность достижимости гарантий во всех режимах/при сбоях/нагрузке. Это гарантии, но не логические/бизнесовые, а технические, низкоуровневые. "В реальных условиях запрошенный уровень гарантий требует пересмотра".

Разработчик, владелец реализации. В теории, должен действовать в логике формальных методов (TLA+, лямбда-исчисление, конечные автоматы и т.п.), но в реальности всё это слишком сложно, поэтому никакой логике действия разработчика не поддаются.

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

ИИ предлагает регулярные ритуалы для выявления взаимовлияний — по-моему, он их просто на ходу придумал, цитирую без правки:
Feature framing (PM ведёт): гипотеза ценности + ограничения + метрика + допустимые компромиссы по качеству.
Policy workshop (BA ведёт): правила + исключения + спорные кейсы + "кто имеет право решать исключения в рантайме".
Model review (SA ведёт): сущности/состояния/события + инварианты + контракты интеграций + миграции.
Quality attribute workshop (архитектор ведёт): сценарии качества (нагрузка, отказ, атака) + бюджеты (latency/cost) + деградации.
Design/operability review (dev ведёт): стратегия тестирования + наблюдаемость + откаты + SLO-реальность.

А роли, в конечном итоге — это предохранители необратимых потерь. Вот смотрите, что можно необратимо потерять:
— данные, если не собирали, то уже и не соберем; если необратимо испортили — обратно не восстановим (SA)
— деньги — из-за атак или сбоев (архитектор, ИБ) или неверного расчета экономики (продакт)
— доверие рынка / право на деятельность (продакт, BA)
— возможности развития (архитектор, разработчик)

Вот такая раскладка, что думаете?

Ну и это про роли, их можно совмещать, пока в одну голову влезает и друг друга не тормозит. А внедрять нужно не "в процессы" и не "передавая задачи", а назначая зоны ответственности за необратимость.