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

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

Ну тут проблема явная с командой.

Такое бывает, когда в команде бывалые люди, эксперты в предметке, а аналитик молодой. Свысока смотрят. Или команда никогда раньше не работала с действительно сложными проектами и не видит пользы от аналитика.

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

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

Стоит замерить техдолг и время на въезд в давно не трогавшийся компонент разработчиком - если и тот, и другой показатель в норме и басфактора продукт не очень боится по каким-то причинам, то не нужно увеличивать T2M и добавлять прокси из аналитика. Телега-то и так едет.

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

Иными словами, в продуктах можно выделить upstream - условные работы по выполнению DoR и наполнению беклога и downstream - фактическую имплементацию

Так вот в большинстве продуктов, где нет глубокого технического компонента по типу машинки или лютой математики для рассчета цен, например - системный аналитик не нужен и в целом, в downstream аналитик не нужен. А вот в upstream нужен некий суррогат аналитика и продакт менеджера, чтобы помогать PO, если тот очень важная шишка

Вот тут полностью поддержу Ярослава с единственной оговоркой, что разрабы из примера - не фантастика, а реальные кадры и 80% успеха продукта по гибким методологиям зависит именно от качества людей в командах. Ещё 20% - это в основном усилия СМ и PO

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

Тут можно их поинтервьюировать на предмет болей - им мб норм ДевОпс лучше зайдет или автотестер, чтобы закрыть рутины и от проблем плясать. А если проблем нет - нужно развивать ребят и поддерживать хорошие темпы

Ну это имхо, мой опыт. На абсолютную истину претендовать не буду, однако, много насмотрелся на "продуктовые" команды, которые просто нарезали вотерфольный SDLC на двухнедельные итерации и думают, что у них Scrum и они вообще очень даже Agile :)

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

Артефакты не толмуды и наоборот хочется их качественно и понятно писать, но для этого и фидбек нужен

Вот чет такое и напоминает😂 здесь проблема, что продакт пришел с задачей, ее обмусолили, кидают в спринт и все начинается сначала. Мы впервые все видим, ничего не знаем

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

Ну так подружитесь с разработчиком. Он обычный человек, хоть и странненький)

А как артефакты помогут избавится от костылей?

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

Есть такие, но их меньшинство

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

Подружиться и проговорить в чатике фичу проще, чем заставить прочитать статью в конфе, по обсуждаемому итогу)

Проще. Но все проговоренное в чатике благополучно забудется примерно в течении недели двух.