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

Если работаете через ТЗ, то новая версия ТЗ, чтобы не плодить лишние документы. Попробуйте так, а потом решите нужны ли дополнительные звенья вроде CR

Это зависит от того, что написано в ТЗ.
Если написано "нужно три поля и кнопка, по которой сумма первых двух будет выводиться в третье", а потом выяснилось, что нужно 5 полей и кнопки "минус" и "умножить" - то я думаю, что это уже новый объем работ.
Если в ТЗ написано "нужен калькулятор", а решение - три поля и кнопка плюс, то это несомненно нуждается в доработке в рамках данного ТЗ

Но мы вроде не совсем про это разговариваем.
Change Request должен содержать требования того же уровня, что раньше были в ТЗ. Чаще всего, это требования технического уровня. Вот что я хотел сказать, говоря о хотелках)

Буду переваривать! Спасибо всем за информацию

На полке лежит учебник Вигерса, никак не доберусь до изучения)

может я пропустил что-то из ветки.
а поговорить с разрабами/архитекторами как им удобно и к чему они привыкли.

если все на одном стеке, то возможно команда привыкла к какому-то формату.

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

Но пытаясь быть аналитиком я прекрасно понимаю, что привыкли не значит удобно/эффективно. В конце концов, после написания мною первой в компании технической спецификации мне был объявлен респект))

Я заметил, что в этой группе часто всплывают "вопросы первого аналитика за всю историю команды". Это радует; видимо, все больше компаний сталкиваются с пределом сложности (или просто следуют моде) и нанимают аналитиков. У @beskov в его Школе Системного Анализа был crash-course для аналитиков, где он из того же Виггерса и других популярных книжек отобрал практики, необходимые именно на начальном этапе. Цель там была, насколько я понимаю, познакомить новичков с системным анализом; но также можно использовать наверное как вводную для компаний-новичков
(я надеюсь, это не воспринимается как реклама)

Почему была? Она есть https://systems.education/tz-online
И не только для новичков, но и тех кто хочет понять методология проектирования требований и систематизировать свои знания

Хорошо прокачиваются навыки, когда одновременно выполняешь функции БА и СА, но вопрос: сколько времени/практики необходимо, чтобы стать уверенным ведущим специалистом? Ведь помимо практики нужно обладать массой знаний. При чем крайние зоны компетентности довольно рознятся: у БА  больше уклона в бизнес, а у СА - в технологии, включая архитектуры, БД и даже код

Говорят, чтобы стать экспертом в чем угодно, нужно заниматься этим чем угодно 10 тыс часов)

у меня есть наблюдение что экспертность повышается скачкообразно, но каждый следующий скачок на порядок затратнее, т.е. 1 час - 10 часов - 100 часов - 1000 часов - 10к часов - ...

Тут быстрее шизофрению разовьёшь, если одновременно и то, и то

Расскажите. Мне казалось, что изучая что-то, со временем наоборот поглощаешь и впитываешь знания быстрее, так как понимаешь тему все лучше и лучше. Или тут вопрос объема?

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

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

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

я вот еще 1000 часов наиграю, и, полагаю, понимание как смотреть на мяч опять качественно прыгнет на другой уровень

А что делать? Я в компании работаю один. Мне приходится проводить анализ, описывать требования, собирать прототипы, писать ТЗ, тестировать (тут участвуют стейкхолдеры), обучать (материал с меня, обучение 50/50 с отделом кадров), писать регламент и так далее.