Главное уместить это всё в адекватную зону контекста, т.е. это малые или средние проекты, на которые выделено достаточно времени.
А вот когда начинается проект на 3+ команды и в объёме 3+ месяца, то такая фишка уже не прокатывает. Ибо разработчик отвечает только за свой кусок и не видит общего контекста (ехало ему болело его видеть, он должен понимать, что конкретно его сервис делает и для кого), а аналитик начинает коннектить команды, показывать общий контекст, выдавать нужные данные нужным людям в нужном объёме.

Много отдать разработчику - тоже плохо. Он начинает теряться.

Спорное замечание.

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

А как без "почему" впринципе валидировать требования?

Т.к. мы с @romanvt работали в одной компании, то у нас есть примеры такой работы.
Там и правда объём мыслетоплива тратится в разы меньше, скорость работы выше и результат более качественный.

Как показала практика, только в том случае, если тебе дают право управлять или корректировать поток создания бизнес ценности.
Если всё решает верхушка, а тебе приходят только приказы, что надо сделать, то никому эти документы даром не сдались.
У топов всё в голове и в их интересах иметь минимальную прозрачность.

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

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

не измеримо = не существует с точки зрения бизнеса

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

Можно статистику подбить, но я там уже не работаю. xD

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

Метрики умеют считать единицы.

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

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

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

Если начинаются формы подчинения участников команды, то сразу начинаются перекосы, разные темы кто тут главнее, я так сказал, KPI и прочее подобное

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

А бизнесовые метрики системный аналитик и не должен считать, на мой взгляд. Он должен их ТРЕБОВАТЬ.
Иначе он выходит за рамки своих компетенций и илезет в чужую роль.

И вот если метрик нет, то надо слать лесом по-хорошему. Грибы (метрики) собирать.

Иначе без тз (метрик) выходит хз.

А еще шикарно, когда это дополнено дополнено объяснениями, почему не сделано вот так-то

Я в тр сейчас, когда что-то меняю, тупо зачёркиваю и серым закрашиваю с пометкой о причине.
У меня люди спрашивают, зачем так? Четверть-треть тр перечёркано.
Вот для этого самого.

Но в целом для этого  надо смотреть в сторону ограничений. Технических и бизнесовых. И все не нативные решения выносить туда.

Мне в этом плане нравится арх практика с ADR, аналог такого очень полезно вести и аналитикам

У нас есть meeting notes - аналог ADR, который в себе содержит в т.ч. бизнесовые решения и назначения работ.