Коллеги, как вы собираете обратную связь от ЗЛ по качеству требований? Опрос для всех? Интервью с каждым? Или только личное ощущение?

Коллеги, как вы собираете обратную связь от ЗЛ по качеству требований? Опрос для всех? Интервью с каждым? Или только личное ощущение?

Уточните, в каких целях в данном случае собирается "обратная связь". Измерять качество можно из различных соображений, и подходы будут разными.

Также, о каких ЗЛ идет речь? Функциональный заказчик, менеджер проекта, менеджер продукта, программист и тестировщик - все они заинтересованы в требованиях по-своему, устроены по-разному, оценивают разное и, соответственно, "как собирать" для них нужно разное.

Обратная связь собирается с целью оценить качество требований. На основании чего оценить работу аналитиков и повысить качество будущих требований.

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

Коли так, то для ответа нужен фундаментальный труд. Или сферические тезисы из оного. Навроде:

(про заказчика)
1. В течение какого времени согласуются требования? Отклонение от среднего по проектам?
2. Сколько проведено итераций их изменения, инициированных заказчиком?
3. Есть ли претензии к формулировкам у смежных (помимо функциональной) служб заказчика?
4. Какая часть требований на итоговых испытаниях вызывает вопрос заказчика "а нафига нам это надо?"
...

или (немного с другой стороны):
1. Соответствуют ли требования политической ситуации у заказчика? (не вызывают ли локальные очаги агрессии в давних терках между его подразделениями).
2. Соответствуют ли формулировки финансово-экономической политике заказчика? (т.е. если он проводит контракт по статье бюджета "доработка", никакой "разработки" в требованиях фигурироваьт не должно)
3. Соответствует ли общий объем требований ожиданиям заказчика (заплатил он 100500 млн рублей, и через 2 месяца работы получил 10 страниц требований).
4. и т.д.

И это мы еще не дошли до смысловой нагрузки требований.

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

На основании чего оценить работу аналитиков

Корреляция есть не всегда. Хороший аналитик может запросто разрабатывать отвратительные требования по 9 из 10 разделам оценки. Зато в десятом разделе есть тот самый единственный критерий, который требуется задрать в данной конкретной ситуации. Гм... Зато наоборот гораздо реже. У плохих аналитиков хороших требований почти не получается.

Собственно хотелось узнать делал ли кто такой фундаментальный труд и какой результат.

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

Конечно, результат такой оценки - это не истина в последней инстанции. Стоит учитывать не только вес каждого из 10 параметров, но и ситуацию в целом. Заказчика, сроки, команду, ограничения бюджета и т. д. Пусть такая оценка не точна, но она измерима и не субъективна - в этом ценность. Веса, приоритеты и параметры оценки можно редактировать по мере внедрения. А в результате следить за изменением оценки для каждого аналитика от проекта к проекту, от команды к команде. Выводы будут полезны как руководителю (в каких проектах и командах человек эффективен) так и аналитику (ясность в слабых сторонах).

Я тут немного затрагивал этот вопрос:
http://www.slideshare.net/alexgolder/requirements-quality-cmcons2010

Я собираю обратную связь от коллег лично в разговоре и комментариях к документу/текстам требований/постановок задач

Может быть поможет: "Приоритизация методов верификации требований" http://sqadays.com/ru/talk/11180

Спасибо за ответы! В личном разговоре и я собираю, но не регулярно и за динамикой не слежу. К тому же мало кто в личной беседе может по-честному сказать о плохом.

Не морочить голову - не вариант. Даешь KPI!)

"Когда я слышу слово KPI, рука тянется к предохранителю браунинга" почти (с).
Вообще, KPI - самый надежный из всех известных мне способов убить естественную мотивацию. В теории подходкрасивый. Но вот с практикой, особенно в творческих областях, как-то не складывается. 

Но Вы пробуйте, вдруг получится.

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

Зачем, если этот человек видит не только результат, но и весь путь к нему? И может на лету править тот или иной момент? Кстати, вот эти вот "последовательны", "недвусмысленны" очень зависят не только от разработчика, но и от потребителя. Особенно последнее.

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

Гм. Я вот, в роли аналитика, за последние 4 года не припомню разработанный мной лично или командой идеальных требований. За все стыдно, где больше, где меньше. Ибо, как сказал т.Сталин еще в 34 году, "Ведь инженер, организатор производства работает не так, как он хотел бы, а так, как ему прикажут, как велит интерес хозяина."

Конечно, результат такой оценки - это не истина в последней инстанции. Стоит учитывать не только вес каждого из 10 параметров, но и ситуацию в целом.

То есть, поправить ручками, если КПИ начинают показывать что-то не то?

Пусть такая оценка не точна, но она измерима и не субъективна - в этом ценность.

Чем неточная несубъективная оценка ценнее неточной субъективной? А вот стоит она неизмеримо дороже.
И, скажу по секрету, в творческих областях несубъективных оценок быть не может. Не верите - попробуйте самостоятельно разделить 100 условных рублей премии между программистом, аналитиком и тестировщиком проекта. Соразмерно вкладу. Да хоть между тремя программистами. Можно пользоваться любыми КэПэАйями, БээСЦами и прочими "системами".

Веса, приоритеты и параметры оценки можно редактировать по мере внедрения.

Да. Это очень понравится тем, кто уже успел соптимизировать свою работу под предыдущую версию КПИ.

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

O sancta simplicitas!
Впрочем, как говаривали в пору моего студенчества, "Если седой профессор говорит, что что-то возможно - это точно возможно. А если он говорит, что что-то невозможно - вполне может быть, что он заблуждается".

Леонид, спасибо! Вы чудо как мотивируете)

Леонид, спасибо! Вы чудо как мотивируете)

Рад стараться!

"Когда я слышу слово KPI, рука тянется к предохранителю браунинга" почти (с).
Вообще, KPI - самый надежный из всех известных мне способов убить естественную мотивацию. В теории подходкрасивый. Но вот с практикой, особенно в творческих областях, как-то не складывается. 

По поводу мотивации согласен. Но черт даже с ней, с мотивацией.
KPI - самый надежный из всех известных мне способов убить производственный поток. Голдратт в книге "Критическая цепь" наглядно показал, что отмена KPI необходимый и достаточный способ превратить безнадежно убыточную фирму в золотую жилу.
http://software-testing.ru/forum/index.php?/topic/29619-performance-evaluation-ili-ezhegodnye-razgovory-o-glavnom/page-2#entry135399

В нетворческих областях "совсем не складывается".

Одно из очень распространенных заблуждений: "Все сотрудники должны быть заняты работой на 100%". Это заблуждение приводит к огромным финансовым потерям, а иногда и к банкротству.
 
Несколько лет назад я имел честь беседовать с директором  одной из наших аутсорсинговых компаний. В свое время они провели исследование, с целью выяснить, сколько процентов должно находиться на "скамейке запасных" для максимизации прибыли фирмы. Результат, который они получили, в точности соответствовал теории массового обслуживания. Оптимальная цифра для их бизнеса - 25% простаивающего персонала.

...Выводы будут полезны как руководителю (в каких проектах и командах человек эффективен) так и аналитику (ясность в слабых сторонах).

Зачем такие сложности? Все проще.

"Если аналитик не умеет верифицировать требования, то он не умеет их писать. Не надо учить писать требования, учите их верифицировать."

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

Be happy.