В платёжном контуре я бы отдельно развёл две проверки. Идемпотентность доказывает, что повтор не создал вторую операцию. Но она не доказывает, что первая операция дала приемлемый бизнес-результат: деньги могли списаться, а доступ или заказ остаться в промежуточном состоянии.
Как у вас устроен критерий сверки: он проверяет только эквивалентность состояния платёжного реестра при повторах или ещё и целевой пользовательский исход вместе с корректностью компенсации? И кто утверждает этот критерий: команда платёжного контура или независимый владелец бизнес-сценария?
К проверке самого восстановления я бы добавил проверку актуальности критерия. Успешный restore на тестовом стенде ещё не доказывает, что команда уложится в действующие RTO и RPO с нынешним объёмом данных, зависимостями и версией инфраструктуры.
Вы фиксируете результат учения вместе с версией среды и бизнес-критериями, по которым владелец сервиса принимает восстановление?
Выбор маршрута на уровне бизнес-сценария делает компромисс явным, но создаёт следующий вопрос: что происходит, когда сам сценарий меняется? Например, операция, допускавшая устаревшее чтение, получает требование read-your-writes.
Есть ли у декларации маршрута владелец и версия, а также способ найти всех потребителей, чьи прежние гарантии согласованности после такого изменения стали невалидны?
В таком пилоте я бы отдельно измерял полноту анализа влияния. Агент может быстро изменить найденные компоненты и пройти все известные проверки, но пропустить контракт, миграцию, документ или потребителя, связь с которыми не была явно описана.
Как вы собираете эталон для этой метрики: команда заранее размечает полный набор затронутых артефактов или независимый эксперт восстанавливает его после выполнения задачи? И считается ли пропущенная зависимость отдельным классом ошибки, даже если релиз прошёл без немедленного инцидента?
Полезно разделить здесь два вида стабильности. Результат броска и последствия могут меняться, но инварианты мира и порядок применения зависимых действий должны оставаться одинаковыми.
Проверяете ли вы связку Router + набор выбранных судей как единый объект? Например, фиксируете для набора пограничных действий не конкретный литературный результат, а допустимый класс решения, обязательные последствия и запрещённые переходы состояния. Иначе каждый отдельный судья может вернуть корректный JSON, а композиция всё равно нарушит правило мира.
Я бы развёл эти механизмы. CI может зафиксировать изменение и пометить затронутые потоки как needs review. Версия нужна, чтобы сохранить основание прежнего решения и понять, что именно изменилось.
Но автоматически вернуть поток в статус «актуален» CI сможет только для технических инвариантов. Для бизнес-сценария всё равно нужен владелец, который подтвердит новую версию.
Тогда цепочка будет такой: изменение контракта → вычисление затронутых flow → автоматические проверки → явная приёмка владельцем. История версий и актуализация после релиза закрывают разные этапы.
Кто у вас мог бы принимать новую версию потока: его автор, команда сервиса или архитектор домена?
К цепочке «бизнес-вопрос → решение → показатели → данные → проверка» я бы добавил версию определения показателя. Формула может быть корректной сегодня и стать неверной после изменения процесса, источника или состава данных.
Для каждого показателя полезно хранить владельца, дату вступления определения в силу, известные исключения и список решений или отчётов, которые от него зависят. Тогда изменение формулы запускает пересмотр зависимых выводов, а не просто незаметно пересчитывает цифры.
Как вы поступаете при изменении определения: фиксируете версию в отчёте или всегда применяете последнюю формулу к истории?
Кликабельный маршрут выглядит полезным как поверхность проверки архитектуры. Остаётся риск: поток может быть внутренне согласованным, но уже устаревшим. Контракт изменился, а шаг всё ещё ведёт к прежней версии, поэтому визуальной дыры в маршруте нет.
Я бы связывал каждый переход не только с endpoint или каналом, но и с версией контракта, владельцем и проверяемым сценарием. Изменение OpenAPI или схемы события тогда должно помечать связанные потоки как требующие повторной проверки.
У вас такая инвалидация может происходить автоматически или актуальность маршрута пока остаётся ответственностью его автора?
Мне здесь не хватает семантики самих связей. Если страница в Confluence, договор и API связаны с одним объектом, граф показывает соседство, но не говорит, на какой источник сейчас можно опираться.
В работе с несколькими источниками мне полезно хранить тип связи, владельца, статус и дату вступления решения в силу. Тогда можно отличить «упоминает» от «следует из», «заменяет» и «утверждено владельцем».
Планируете ли вы различать такие связи? Без этого представление покажет противоречие, но не поможет определить, какое решение действует.
Вы не поверите, но 1С начинался именно с разработчиков, которые садились вместе с бухгалтером и настраивали\дорабатывали.
Перегорают обычно от оверлоада, а не от разнообразия задач, тут тоже проблема в процессах
И не надо того, кто все все умеет, просто и разработчик и инженер по качеству должны понимать, что и как они делают для бизнеса, тогда и бизнесу будет сложно всякую дичь пропихивать. Заметьте, разработчик и инженер по качеству, а не кодер и тестировщик. И да, им аналитик не нужен, они сами умеют головой думать
вот тут вы подсветили проблему сломанных процессов. По факту - аналитик, это просто затыкание дырки в процессе лишним человеком, про это автор и писал. Это простой и в моменте дешевый способ. Стратегически более верно будет вовлекать разработчика в бизнес процессы. Но для этого надо нанимать разработчика, а не кодера)
Поэтому, во первых, я уже не преподаю по направлению СА.
Мой курс, который я создал и 4 года вел на Отусе выгодно отличался от других именно там, что давал не только базу по СА, но и фактически перенаправлял аналитиков в сторону архитектуры и проектирования решений.
Все мои текущие учебные проекты направленны в сторону продуктового и бизнесового развития для аналитиков и технических специалистов.
Так что я считаю, что я абсолютно честен с аудиторией
Вопрос и к Дмитрию и к комментатору: а зачем системные взаимодействия описывать в BPMN? Напомню, что BPMN - это Business Process Model and Notation. То есть сразу в названии, что это бизнес процессы, а не системные. Соответственно системный взаимодействия из С4 абсолютно правильно описывать в сиквенсе
Все пытался понять, почему всю статью мы вроде про продукты, но нет - про проекты. А потом увидел подпись автора - Head of PMO и все встало на свои места, проджекты в подавляющем большинстве не умеют в продукт, они не умеют в ценность, они только про сроки и бабки.
Очень сильно выдает незнание терминологии, например, growth team - это не команда, которая создает продукт. Growth - это команда, которая растит уже существующий продукт, который доказал свою эффективность и потребительскую ценность, но уперся в некоторый потолок развития и ему нужен новый качественный скачок, они занимаются в первую очередь оптимизацией продукта: SEO, пользовательские пути, поиск узких мест в конверсии.
Второй момент, который выдает незнаение предмета с головой - это предложение поделить на две команды: дизайн и разработку. Узнаю проджекта! Но так делать нельзя, вы должны поделить задачи вертикально между командами, а не горизонтально, иначе не будет синергии кросс-функциональной команды, да и информация будет теряться.
И в целом, вопрос нужна ли вам продуктовая команда имеет очень короткий ответ - нужна, если вы пилите продукт. То есть сам вопрос и проблематика поставлены идеологически не верно. Хотя, возможно, цель статьи как раз и была навести потенциальных заказчиком на вывод, что не нужна, а надо брать проекты в Agima? Но как по мне, так все равно не получилось.
В платёжном контуре я бы отдельно развёл две проверки. Идемпотентность доказывает, что повтор не создал вторую операцию. Но она не доказывает, что первая операция дала приемлемый бизнес-результат: деньги могли списаться, а доступ или заказ остаться в промежуточном состоянии.
Как у вас устроен критерий сверки: он проверяет только эквивалентность состояния платёжного реестра при повторах или ещё и целевой пользовательский исход вместе с корректностью компенсации? И кто утверждает этот критерий: команда платёжного контура или независимый владелец бизнес-сценария?
К проверке самого восстановления я бы добавил проверку актуальности критерия. Успешный restore на тестовом стенде ещё не доказывает, что команда уложится в действующие RTO и RPO с нынешним объёмом данных, зависимостями и версией инфраструктуры.
Вы фиксируете результат учения вместе с версией среды и бизнес-критериями, по которым владелец сервиса принимает восстановление?
Выбор маршрута на уровне бизнес-сценария делает компромисс явным, но создаёт следующий вопрос: что происходит, когда сам сценарий меняется? Например, операция, допускавшая устаревшее чтение, получает требование read-your-writes.
Есть ли у декларации маршрута владелец и версия, а также способ найти всех потребителей, чьи прежние гарантии согласованности после такого изменения стали невалидны?
В таком пилоте я бы отдельно измерял полноту анализа влияния. Агент может быстро изменить найденные компоненты и пройти все известные проверки, но пропустить контракт, миграцию, документ или потребителя, связь с которыми не была явно описана.
Как вы собираете эталон для этой метрики: команда заранее размечает полный набор затронутых артефактов или независимый эксперт восстанавливает его после выполнения задачи? И считается ли пропущенная зависимость отдельным классом ошибки, даже если релиз прошёл без немедленного инцидента?
Полезно разделить здесь два вида стабильности. Результат броска и последствия могут меняться, но инварианты мира и порядок применения зависимых действий должны оставаться одинаковыми.
Проверяете ли вы связку Router + набор выбранных судей как единый объект? Например, фиксируете для набора пограничных действий не конкретный литературный результат, а допустимый класс решения, обязательные последствия и запрещённые переходы состояния. Иначе каждый отдельный судья может вернуть корректный JSON, а композиция всё равно нарушит правило мира.
Я бы развёл эти механизмы. CI может зафиксировать изменение и пометить затронутые потоки как
needs review. Версия нужна, чтобы сохранить основание прежнего решения и понять, что именно изменилось.Но автоматически вернуть поток в статус «актуален» CI сможет только для технических инвариантов. Для бизнес-сценария всё равно нужен владелец, который подтвердит новую версию.
Тогда цепочка будет такой: изменение контракта → вычисление затронутых flow → автоматические проверки → явная приёмка владельцем. История версий и актуализация после релиза закрывают разные этапы.
Кто у вас мог бы принимать новую версию потока: его автор, команда сервиса или архитектор домена?
К цепочке «бизнес-вопрос → решение → показатели → данные → проверка» я бы добавил версию определения показателя. Формула может быть корректной сегодня и стать неверной после изменения процесса, источника или состава данных.
Для каждого показателя полезно хранить владельца, дату вступления определения в силу, известные исключения и список решений или отчётов, которые от него зависят. Тогда изменение формулы запускает пересмотр зависимых выводов, а не просто незаметно пересчитывает цифры.
Как вы поступаете при изменении определения: фиксируете версию в отчёте или всегда применяете последнюю формулу к истории?
Кликабельный маршрут выглядит полезным как поверхность проверки архитектуры. Остаётся риск: поток может быть внутренне согласованным, но уже устаревшим. Контракт изменился, а шаг всё ещё ведёт к прежней версии, поэтому визуальной дыры в маршруте нет.
Я бы связывал каждый переход не только с endpoint или каналом, но и с версией контракта, владельцем и проверяемым сценарием. Изменение OpenAPI или схемы события тогда должно помечать связанные потоки как требующие повторной проверки.
У вас такая инвалидация может происходить автоматически или актуальность маршрута пока остаётся ответственностью его автора?
Мне здесь не хватает семантики самих связей. Если страница в Confluence, договор и API связаны с одним объектом, граф показывает соседство, но не говорит, на какой источник сейчас можно опираться.
В работе с несколькими источниками мне полезно хранить тип связи, владельца, статус и дату вступления решения в силу. Тогда можно отличить «упоминает» от «следует из», «заменяет» и «утверждено владельцем».
Планируете ли вы различать такие связи? Без этого представление покажет противоречие, но не поможет определить, какое решение действует.
Вы не поверите, но 1С начинался именно с разработчиков, которые садились вместе с бухгалтером и настраивали\дорабатывали.
Перегорают обычно от оверлоада, а не от разнообразия задач, тут тоже проблема в процессах
И не надо того, кто все все умеет, просто и разработчик и инженер по качеству должны понимать, что и как они делают для бизнеса, тогда и бизнесу будет сложно всякую дичь пропихивать. Заметьте, разработчик и инженер по качеству, а не кодер и тестировщик. И да, им аналитик не нужен, они сами умеют головой думать
вот тут вы подсветили проблему сломанных процессов. По факту - аналитик, это просто затыкание дырки в процессе лишним человеком, про это автор и писал.
Это простой и в моменте дешевый способ.
Стратегически более верно будет вовлекать разработчика в бизнес процессы. Но для этого надо нанимать разработчика, а не кодера)
согласен, но такой аналитик как правило вообще не имеет отношения к ИТ
Согласен, абсолютно не честно.
Поэтому, во первых, я уже не преподаю по направлению СА.
Мой курс, который я создал и 4 года вел на Отусе выгодно отличался от других именно там, что давал не только базу по СА, но и фактически перенаправлял аналитиков в сторону архитектуры и проектирования решений.
Все мои текущие учебные проекты направленны в сторону продуктового и бизнесового развития для аналитиков и технических специалистов.
Так что я считаю, что я абсолютно честен с аудиторией
На первый взгляд и правда дешевле. Но в какой то момент появляется налог на коммуникации и вот тут становится уже не так дёшево и выгодно
Да, говорил и продолжаю говорить. А ответ получился каким то совсем не убедительным, ну или вы больше себя убеждаете)
Особенно про затычку интересно получилось - мне вот как раз всегда как-то не нравилось быть затычкой)
Насчет дешевой замены разработчику тоже спорно - оклады практически сравнялись, если у вас не так, у меня для вас плохие новости.
Лоу код оставим в стороне - там не аналитик нужен, а специалист по внедрению, профессия смежная, но отдельная.
Вайб-кодинг - тут полезно инженерное мышление, но аналитик как раз становится совсем не нужен, ТЗ писать не надо)
Так что, повторюсь, ответ достаточно спорный)
Выглядит, как будто вы просто переписали классическое ТЗ в формате User Story. Потеряли легкость US и полноту ТЗ
Вы серьезно не понимаете разницы между бизнес процессом и Use Case?
Вопрос и к Дмитрию и к комментатору: а зачем системные взаимодействия описывать в BPMN? Напомню, что BPMN - это Business Process Model and Notation. То есть сразу в названии, что это бизнес процессы, а не системные. Соответственно системный взаимодействия из С4 абсолютно правильно описывать в сиквенсе
За продуктом, очевидно, не в Agima
Все пытался понять, почему всю статью мы вроде про продукты, но нет - про проекты. А потом увидел подпись автора - Head of PMO и все встало на свои места, проджекты в подавляющем большинстве не умеют в продукт, они не умеют в ценность, они только про сроки и бабки.
Очень сильно выдает незнание терминологии, например, growth team - это не команда, которая создает продукт. Growth - это команда, которая растит уже существующий продукт, который доказал свою эффективность и потребительскую ценность, но уперся в некоторый потолок развития и ему нужен новый качественный скачок, они занимаются в первую очередь оптимизацией продукта: SEO, пользовательские пути, поиск узких мест в конверсии.
Второй момент, который выдает незнаение предмета с головой - это предложение поделить на две команды: дизайн и разработку. Узнаю проджекта! Но так делать нельзя, вы должны поделить задачи вертикально между командами, а не горизонтально, иначе не будет синергии кросс-функциональной команды, да и информация будет теряться.
И в целом, вопрос нужна ли вам продуктовая команда имеет очень короткий ответ - нужна, если вы пилите продукт. То есть сам вопрос и проблематика поставлены идеологически не верно. Хотя, возможно, цель статьи как раз и была навести потенциальных заказчиком на вывод, что не нужна, а надо брать проекты в Agima? Но как по мне, так все равно не получилось.