Поддерживаю такой подход, когда описаны все use cases и edge cases, можно смело отдавать в разработку. Только в некоторых случаях бывает сложно определить, что описаны все возможные use cases и edge cases. А как вы определяете что фича полностью покрыта use cases и edge cases?

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

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

Если на проекте нет аналитика, то его работу делает кто то другой. Не факт что лучше. Бесплатно ни чего не бывает. )

Контракт + описание внутренней логики контракта (для быстрого понимания последовательности действий внутренней логики sequence)

Всё так

Я ни когда не говорил, что аналитик должен знать детали реализации — классы, репозитории, паттерны и т.д. Это зона ответственности разработки.

Но спроектировать контракты API, описать последовательность вызовов сервисов и основные сценарии взаимодействия компонентов системы, как мне кажется, это как раз задача системного аналитика.

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

Конечно, это мой практический опыт, а не универсальная истина, но именно поэтому я придерживаюсь такой позиции.

Я ни слова не говорил про классы м паттерны. И по моему печальному опыту все-таки лучше это делать в составе разработчиков чем потом ругаться на на пуско-наладочном этапе. Лучше самим.

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

В этом случае не придется ни с кем ругаться на пуско-наладочных работах.

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

Работал в такой схеме последние 5 лет, высоконагруженное мобильное приложение ДБО физ лиц, впечатления позитивные. Ни какой грызни, только аргументы и контр агрументы)

Хорошо если так) я такого за последние 5 лет работы в разных командах не видал)

Спасибо за развернутый комментарий. Думаю, у нас немного разное понимание роли системного аналитика.

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

Но мне кажется, что есть принципиальная разница между вопросами «что именно должно происходить?» и «можно ли сделать это лучше?».

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

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

А вот когда разработчик говорит: «Здесь лучше использовать другой подход», «Этот API можно упростить», «Давайте объединим два вызова» или «Такое решение будет масштабироваться лучше» — это уже инженерная экспертиза, и именно за это я ценю сильных разработчиков.

Что касается ИИ, то я не разделяю идею «написали ТЗ — отдали ИИ», без верификации разработчиком - путь в никуда. Хорошая спецификация не заменяет инженера. Она лишь избавляет его от необходимости гадать о замысле аналитика и позволяет сосредоточиться на том, в чем его ценность действительно максимальна: выборе технического решения, качестве реализации и проверке результата.

Коллеги, о чём спор. В каждой организации разделение аналитик/разработчик проходит в своем уникальном месте. Где то вообще нет выделенных аналитиков)

Все так) вопрос только в том, что чем подробнее описано решение(без перегибов, разумеется), тем проще жить команде после его релиза)

А где то и сама документация отсутствует как класс)