... количественным методам оценки эффективности:
- работы аналитика, как конкретного сотрудника;
[/quote]
Кто-нибудь на практике  этим занимается?

Я бы посетила семинар, посвященный количественным методам оценки эффективности:

- работы аналитика, как конкретного сотрудника;
- процессов, связанных с требованиями (разработка, управление, и подпроцессы, входящие в разработку).

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

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

Измерить эффективность тестировщиков, например, намного проще.

А вот в этом я сомневаюсь. Можно услышать аргументы? (т.к. это оффтоп, то можно в личку )

Измерить эффективность тестировщиков, например, намного проще.

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

Пардон, меня опередили

А давайте отдельную ветку создадим с соответствующей темой ?

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

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

P.S. Что касается оценки эффективности тестировщиков по сравнению с аналитиками, аргументы приведу позже. Может, имеет смысл это обсуждение перенести в отдельную тему, коль уж есть подозрения на оффтоп?  

Перенес

А вот в этом я сомневаюсь. Можно услышать аргументы?

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

Так что прошу прощения за то, что ввела вас (да и себя) в заблуждение. Получается, что тема по-прежнему остается открытой...

Вопрос действительно очень интересный. Кстати, Александр Байкин должен был докладывать по Оценке качества требований на конференции Req Labs 2009, но эту тему заменили. Жаль... Это был один из двух докладов, из-за которых я вообще иду на эту конференцию...

Вигерс в своём профиле профессии аналитика требований:
http://www.processimpact.com/process_assets/RA_job_description.doc
приводит следующие (перевод Д.Олеванова, см. связанную тему: http://www.uml2.ru/forum/index.php?topic=202.0)
Показатели качества работы
1.   Оценка требований продукт-менеджером и менеджером проекта относительно общего качества и эффективности продукта на рынке после разработки продукта.
2.   Отзывы ключевых клиентов о реализации процесса управления требованиями
3.   Показатели удовлетворенности клиентов
4.   Соблюдение или превышение планов разработки требований, ограничений по ресурсам и качественных целей
5.   Контроль расползания требований, связанный с пропущенными требованиями и просачиванием "неформальных" требований в проект

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

NB: Субъективные оценки важны и нужны, потому что качество — это соответствие ожиданиям ключевых ЗЛ, а ожидания всегда субъективны.

Самой простой шкалой для показателей в этом случае будет
0 - не соответствует ожиданиям
1 - соответствует ожиданиям
2 - превосходит ожидания
Расширенная шкала будет включать оттенки градаций.
Но субъективность - подлая штука, никогда не знаешь, что за ней стоит - межличностные проблемы, крепкая дружба, политические и карьерные интересы, глубина понимания ситуации или честный профессионализм. Поэтому оценке в довесок нужно обоснование. Это не панацея, но если возникнут полярные оценки, то будет хотя бы понятно, что за ними стоит.

Можно еще помечтать о более систематизированном подходе, когда прежде чем собирать отзывы, с ЗЛ собирают их ожидания...

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

Можно опираться на этот список для проверки качества требований.

Список хороший. Только он основан исключительно на экспертных оценках людей, проверяющих требования.
Основной риск в этом случае - насколько "эксперт" является экспертом
Можно посадить заказчика Васю и попросить его оценить полноту. Думаю вы мало чего полезного добьетесь
Каждый пункт этого списка к тому же проверяется отдельными людьми - экспертами предметной области, тестировщиками, разработчиками и сильно зависит от поставленного процесса (попробуйте например в ТЗ на 200 страниц, которая параллельно разрабатывается несколькими людьми, определить согласованность и трассируемость)
У меня был такой опыт, когда в НИИ ТЗ по частям писали несколько человек и потом склеивали в один документ.

И напоследок следует наверное заметить, что такое согласование займет не меньше нескольких недель (причем качество все равно никто не гарантирует), что в большинстве случаев не приемлемо для проектов

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

Хорошим показателем качества требований является количество запросов на изменения после начала реализации и поставки системы заказчику.
Можно даже строить различные графики, показывающие отношение запросов на изменение к общему набору требований
Делая различные срезы можно оценивать эффективность работы аналитика
Пример из практики. По каждой функциональной области системы был назначен ответственный аналитик. После фиксации требований (читай бейзлайн) все изменения в документацию вносились по запросам на изменение. Так вот, аналитика по документу которого было больше всего запросов на изменение и вопросов от разработчиков, можно считать менее эффективным. Но это статистика, а в жизни еще бывают факторы которые нужно учитывать : опыт, работоспособность, умение коммуницировать с заказчиком, аналитический склад ума и умение видеть альтернативы.

Хорошим показателем качества требований является количество запросов на изменения после начала реализации и поставки системы заказчику.
Можно даже строить различные графики, показывающие отношение запросов на изменение к общему набору требований
Делая различные срезы можно оценивать эффективность работы аналитика
Пример из практики. По каждой функциональной области системы был назначен ответственный аналитик. После фиксации требований (читай бейзлайн) все изменения в документацию вносились по запросам на изменение. Так вот, аналитика по документу которого было больше всего запросов на изменение и вопросов от разработчиков, можно считать менее эффективным. Но это статистика, а в жизни еще бывают факторы которые нужно учитывать : опыт, работоспособность, умение коммуницировать с заказчиком, аналитический склад ума и умение видеть альтернативы.

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

NB: Субъективные оценки важны и нужны, потому что качество — это соответствие ожиданиям ключевых ЗЛ, а ожидания всегда субъективны.

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

Короче вывод получается такой - что оценка аналитика (персоны, работника) есть действительно субьективная штука, только наверное не внешними (по отношению к проекту/процессу) личностями, а самой командой

Хорошим показателем качества требований является количество запросов на изменения после начала реализации и поставки системы заказчику.

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