Бывает, заговоришь с человеком, мол, с требованиями надо работать аккуратно, а он такой: да, да! Хорошо так на душе становится: разговариваешь с умным человеком.

А потом: а давай поговорим об этом. Что вы делаете?

И оказывается, что потолок мечтаний - это 1-2 странички с рисунками интерфейсов и описания визуального поведения системы.

Карл, этого мало! Карл! Сейчас поясню, о каких проблемах я говорю.

- Требования - они порождаются аналитиками. А в это слово в нашей стране слиты две профессии: UX-аналитик и бизнес-аналитик. К сожалению, некоторые люди не видят разницы, и нанимают первых (они вроде что-то понятное говорят - про дизайн и вот это всё). Функция бизнес-аналитики тем не менее должна быть в команде, и если вы не разместите её самостотельно где-то рано в процессах - она окажется на исполнителях или вообще на QA (видел и такое!). Что гарантирует вам постоянную переделку продукта.

- Бизнес-аналитиков нельзя в неподготовленном виде вставлять в современную команду. Они обычно зарождаются в недрах энтерпрайза и пишут многостраничные требования, не пригодные, к сожалению, для гибких и невнимательных эджайл сотрудников. Этап передачи бизнес-требований исполнителям - одно из самых чувствительных к сбоям мест для сколь-нибудь сложоных (с бизнесовой точки зрения) систем.
Бизнес-аналитика - это ответ на вопрос "нахуа так было сделано?", самый важный вопрос при модификации системы.

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

- Разработчикам нужна внутренняя дока. Так или иначе. И эта дока - должна быть связана с требованиями. Думаю, не надо объяснять почему.

- Ну и, наконец, то, чего все очень хотят, но я не слышал, чтобы у кого-то было. ТРАССИРОВКА. Чуть ли не от кода: каждая строчка в системе контроля версий так или иначе промаркирована номером тикета, породившего её. А от номера тикета должна быть возможность взойти к ответу на вопрос "нахуа так было сделано?".

Конечно, это влажные мечты, а жизнь вносит свои коррективы. Но вообще говоря, всё это можно сделать без сильного проседания производительности.