Заказчик хочет фичу, с кем не бывает.

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

У разработчиков глаза по 5 копеек.
Потом аналитика подключили, описали как это еще работать будет. Снова показали разработчикам.
Глаза уже по 5 рублей.

У вас так было?
Если не было, то кажется вы живете в розовой ИТ сказке. Возьмите меня к себе.

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

1) Надо приоритизировать котов.
2) Надо жертвовать котами.

Мы сейчас с командой вот так «боремся» с заказчиком и пытаемся отсечь мишуру. Есть функционал-блестяшки, с которым удобнее, приятнее, но он не хило так расширяет нам scope. Мы с аналитиком путаемся приоритизировать с заказчиком эти блестяшки, но, разумеется, все важно.

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

Если бизнес «плывет» в своих ответах, то используем это как рычаг для пункта 2. Непонятная ценность должна быть отложена, пока ее не поймут.

Если же не чем жертвовать и бизнес нормально отвечает «зачем» и вы понимаете (!), а не продавливаетесь под гнетом непонимания и неуверенности, то у меня плохие новости. Мы где-то зафакапились на старте.