Если у вас есть аналитик, то он должен этим заниматься

Так и есть. Меня смутило слово разработчик, лучше общепринятые термины в контексте их привычного использования употреблять)

Ссылку в этом чате разместите?

да, конечно, но проще подписаться на мой гитхаб, там каждый день почти что-то новое

Ожидания заказчика - решение его бизнес  задачь с помощью вашего софта. Понимание того , что ему нужно в качестве софта, формулирует ваш аналитик и укладывает это в ТЗ. Заказчику не нужен софт ради софта. Вы пишите софт- продукт, который является решением для задач заказчика. И вы должны написать софт, который будет отвечать его ожиданиям. Сам заказчик не может вам написать ТЗ на софт, потому, что это ваша задача - разработать решение

Это все понятно, да. Спасибо. Хотя ответ в чем же для вас разница чего хочет заказчик и его ожидания - я не услышал) Но это отдельная интересная тема - как быть когда ожидания заказчика отличаются от того что ему нужно, как он думает.

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

Я в этой теме вообще не силен, просто знаю что такая проблема есть.

Так я вам пытаюсь ответит, уже не в первый раз, а вы меня не можете понять)

А, сорри. Понял

Ответ нашел)

Эх бро. Ты, видимо, сам не работал так? )
Что "разжевал" аналитик - прогеру надо собрать обратно в торт. И без коммуникаций тут всё равно никак.

Что значит собрать в торт?

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

Всмысле не Senior такой разраб)

Не служил не мужик

Другое дело что разраб не должен заниматься самодеятельностью) Если видит как улучшить может. А донести до аналитика.

Прод не подымал не сеньор

Ну там речь шла про связки аналитик +так себе разраб против хорошего разраба