Мой менти столкнулся с проблемой, которую не знаю, как быстро решить. Возможно, вы тоже с таким встречались. По-английски называется "Игра принеси-мне-камень" (Bring me a rock), прием психологического насилия, когда человек просит принести камень, вы ему приносите, а он говорит — нет, это не такой камень. А какой нужен? Не знаю, ты принеси, посмотрю — скажу.

Раньше в такую игру любили поиграть заказчики — "ой, ну тут что-то не то... а что не то, мы не знаем..." — но теперь мы столкнулись с игрой со стороны разработчиков. Выглядит так: ну, вы тут напридумывали, здорово, но мы так сделать не можем. Давайте как-нибудь по-другому. А как по-другому? Не знаем, вы же с пользователями общаетесь. Так мы точно не сможем сделать. Принесите камень, который нам подойдет.

Есть множество статей на эту тему, с общим посылом: это игра, в которой единственный способ выиграть — не играть вообще. К сожалению, мы не можем выйти из игры и перестать работать с этой командой (ну, или можем — выход есть всегда, в том числе из компании). Остается что: 1) пытаться договориться с разработчиками и 2) эскалировать на руководителя. Эскалация сработает, если у вас в принципе выстроен механизм медиации, если руководители уделяют внимание психологической обстановке, пресекают буллинг и работают с установками работников.

Вариант "договориться" — это если разработчики готовы договариваться. Исходим из того, что у всех нас одна общая цель, нет конкуренции между аналитиками и разработчиками, нет каких-то политических игр и подстав. Тут может быть всякое — аналитики и разработчики могут вообще подчиняться разным руководителям (я видел варианты, что даже разным C-level: аналитики — директору по технологиям, а разработчики — техническому, и их конкуренция транслируется до рядовых исполнителей), аналитики могут постоянно меняться и команде не понравился конкретный аналитик и т.д. Тут проблема не техническая, но парадоксальным образом иногда решение оптимальнее искать вне координат проблемы: если проблема политическая, то решение должно быть техническим, и наоборот. Это вообще полезное правило — неразрешимое противоречие в одной системе координат нужно решать в другом измерении.

Допустим, у всех одна искренняя цель, но сделать мы так не можем. А как можем, мы сами не знаем. Тут нужно заметить, что фраза "мы так сделать не можем" очень часто означает "мы так делать не хотим, потому что..." и вот тут возможны варианты:
* сделать можно, очень много переделывать, но на задачу отведено мало времени и есть риск что-то упустить
* сделать можно, но это будет очередной костыль (архитектура уже давно не соответствует потребностям бизнеса, но времени и ресурсов на рефакторинг так же давно не выделялись)
* сделать можно, но придется отказаться от готового компонента (и нести в дальнейшем риски и тратить ресурсы на развитие)
* сделать можно, но это выглядит, как ультра-локальное изменение и частный случай, который больше нигде и никогда не получится использовать
* сделать можно, но очевидное решение будет сильно нагружать бэк/фронт, или будет слишком медленным. Возможно, тут чисто математическая сложность.

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

Я бы пробовал просто потыкать палочкой все эти места. Это принципиально невозможно, или просто слишком много переделывать? В чем основная сложность? (Тут бы нужно локализовать проблемную зону, ну примените те же методы анализа, то есть рассечения на части, только уже системы. Проблема с фронтом, бэком или базой? Что сложнее всего поменять?). Это будет костыль? Чисто теоретически, можно это сделать костылем? У вас этот компонент самописный или готовый? Это прямо сейчас сложно сделать, или вы про будущую поддержку переживаете? Сколько по времени обойдется, если нормально сделать? А если закостылить?

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