Post #881

Я тут вместе с 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) — возможности развития (архитектор, разработчик) Вот такая раскладка, что думаете? Ну и это про роли, их можно совмещать, пока в одну голову влезает и друг друга не тормозит. А внедрять нужно не "в процессы" и не "передавая задачи", а назначая зоны ответственности за необратимость.