Саша, я лишь процитировал Вигерса. Ща всё проверим в бою

Если вы планируете производить количественную оценку эффективности с целью понять, кто из аналитиков лучше, то, полагаю, нет смысла заморачиваться, так как лучше при любом раскладе тот, кого больше любит начальство. И так оно бывает даже вопреки всем объективным показателям.

Если же задача более глубокая, а именно - оценить реальное положение дел с анализом на определенном проекте, то целесообразно пойти по классическому пути: проводим измерения и накапливаем статистику, а потом анализируем отклонения метрик проекта от средних по компании. Сразу оговорюсь, что для воплощения в жизнь идеи проектных измерений необходима добрая воля руководства компании (те самые 85% качества по Демингу в действии).
Измеряем объем кода, объем требований (в каких "попугаях" - надо придумать, например, отдельно количество страниц и количество бизнес-правил), трудозатраты  (для этого в компании должна быть хотя бы примитивная система учета рабочего времени). Предварительно фиксируем оценочные значения для всего перечисленного, чтобы потом оценить точность нашего прогноза.

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

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

Если много дефектов закрыли путем корректировки требований, вероятно, аналитики плохо поработали на начальном этапе проекта, небрежно относились к своим обязанностям. А если таких дефектов намного меньше среднего или их вообще нет, то очень вероятно, что требования не актуализировались и расходятся с реализацией. А может быть и так, что аналитик тщательно продумал все до мелочей и аккуратно задокументировал.
Слишком высокая производительность документирования требований (единиц требований в час) чаще всего свидетельствует о низком качестве требований (много copy-paste). Кстати, при измерении производительности  программирования не учитывают автоматически сгенерированный код.

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

Саша, спасибо +1 Очень важные вещи подметил.

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

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

+100, о чем я и пытался сказать в самом начале. А народ хочет все свести к автоматизму, это невозможно! Нужно  еще мозгами и руками потом поработать.

Возникает резонный вопрос: а есть ли идеал, пусть недостижимый, но к которому реально стремиться? Или аналитик обречен ощущать всеобщее недовольство?

Хороший вопрос! Правда, когда мы говорим о "всеобщем недовольстве", мы должны понимать, что здесь мы как раз говорим об ожиданиях тех или иных лиц: представителей заказчика, менеджера проекта, разработчиков, тестировщиков... Можно ли по субъективным ожиданиям давать оценку эффективности? Исходя из определения эффективности (например, вот такого: "ЭФФЕКТИВНОСТЬ — относительный эффект, результативность процесса, операции, проекта, определяемые как отношение эффекта, результата к затратам, расходам, обусловившим, обеспечившим его получение", http://slovari.yandex.ru/dict/economic), скорее всего, нет.

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

Вот хороший показательный пример. Задача моей коллеги заключалась в том, чтобы обеспечить формирование отчета, содержащего около 100 столбцов. Ей необходимо было сказать разработчикам, какая информация, по какому алгоритму и из какого места системы должна была браться в каждый из столбцов. У нее была инструкция, полученная от заказчика, в которой было описано, что должно содержаться в каком столбце отчета. При этом, согласно этой инструкции, часть столбцов отчета заполняться не должна была. Логично, что прорабатывала она в итоге оставшуюся часть, т.е. те столбцы, которые заполнять было нужно. В результате, спустя несколько месяцев выяснилось, что один из столбцов, которые по инструкции заполняться не должны были, заполнять было нужно. Коллега получила нагоняй за то, что "не подумала" об этом заранее. Правильно ли это? На мой взгляд, нет. Потому что тогда, получается, она должна была отдельно проанализировать каждый из не подлежащих заполнению столбцов (согласно инструкции) на предмет необходимости его заполнения. (А нагоняй она получила именно за этот конкретный столбец, что именно про него она не подумала.) Но такой задачи перед ней никто не ставил. Более того, в виду очень ограниченного количества времени, отведенного на реализацию, у нее просто даже физически не было возможности этим заниматься.

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

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

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

Никуда мы не денемся от субъективности. Даже если мы вводим показатели, шкалы, каталоги компетенций, их КТО-ТО вводит, КТО-ТО отбирает исходные данные для оценки. Даже для оценки 360 КТО-ТО отбирает людей, которые будут оценивать специалиста. Всем хочется, чтобы этим КТО-ТО был либо он сам, либо тот, кому он доверяет и очень страшно, что оценивать будет какой-то не понятно откуда взявшийся человек по непонятным никому правилам.
Где-то это было у Дилберта "Забавно, что ВЫ оцениваете меня, потому что я могу выполнять Вашу работу, а Вы мою - нет". Согласитесь, что такая ситуация неприятна всем.

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

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

InfinitI,

Кстати, когда начал читать про незаполненные столбцы, у меня сразу возник вопрос (кот я бы наверное задал Заказчику) - а почему они пустые

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

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

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

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

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

Вывод получается что оценивать все таки надо не аналитиков, а целиком команду или решение/продукт полученный этой командой

Согласны?

Хороший вопрос! Правда, когда мы говорим о "всеобщем недовольстве", мы должны понимать, что здесь мы как раз говорим об ожиданиях тех или иных лиц: представителей заказчика, менеджера проекта, разработчиков, тестировщиков... Можно ли по субъективным ожиданиям давать оценку эффективности? Исходя из определения эффективности (например, вот такого: "ЭФФЕКТИВНОСТЬ — относительный эффект, результативность процесса, операции, проекта, определяемые как отношение эффекта, результата к затратам, расходам, обусловившим, обеспечившим его получение", http://slovari.yandex.ru/dict/economic), скорее всего, нет.

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

Готов согласиться с Галиной.
Хочу немного дополнить.
1. Кто оценивает эффективность и цель оценки?
   Руководитель отдела СА для принятия решений в управлении деятельности по выполнению отделом своих функций в рамках обозначенных компетенции, а именно:
-   планирование деятельности (включая планирование требований);
-   организацию деятельности (включая распределение ресурсов);
-   контроль;
Скорее всего, так же руководитель проекта.

2. GLITBA Competency Model предусматривает несколько видов деятельностей аналитика:
а) анализ коммерческой деятельности предприятия и подготовка проекта;
б) планирование и управление требованиями;
в) сбор требований;
г) анализ и документирование требований;
д) реализация требований;
е) коммуникации с заинтересованными лицами и визуализация информации о проекте;
ж) обеспечение качества;
з) инженерия требований к удобству использования системы.

3. Какие затраты осуществляются?
Как сказала Галина, что эффект  м.б. охарактеризован, как отношение полученного результата к затратам. А затрачивают обычно, да и принято оценивать: время, деньги, ресурсы. Исходя из пропорции, при сокращении их (время, деньги, ресурсы) и получении одинакового результата мы повышаем эффективность.
Думаю всем понятно, для чего нам нужно изменять затраты и варьировать ими. Возьмем, к примеру, проблему которую пытаются решить с помощью аналитика «убрать риски непонимания заказчика и недобора требований», при нехватке аналитических ресурсов проблему нужно решать комплексно и возможно другими методами, за счет других ресурсов.

4. Методы оценки эффективности.
На основе примеров из других отраслей (например, «МЕТОДИКА оценки эффективности деятельности органов исполнительной власти субъектов Российской Федерации»), к методам оценки можно отнести совокупность операций по измерению некоторых показателей деятельности.
Показатели можно объединять в группы, например:
-   общие;
-   коммуникации;
-   выявления;
-   анализа и документированная и т.п.

5. Немного о самих показателях.
Скорее всего, можно говорить о качественных и количественных показателях. Показатели можно разделить на: показатели, динамика роста которых отражает эффективность деятельности; показатели, динамика снижения которых отражает эффективность деятельности.
Примеры (подготовлены на скорую руку, прошу отнестись с пониманием).
Общие:
а) количество видов деятельностей, в которых аналитик компетентен.
Если, например, знания и опыт, синтезированные в навыки позволяют ему эффективно выполнять все вышеобозначенные виды деятельностей, значит он по этому показателю эффективен – насколько, можно определить пропорцией «x/8».

Выявления (для задачи «идентификация и описание заинтересованных в проекте лиц»):
а) знание всех областей в которых осуществляется идентификация;
б) знание принципов и методов идентификации ЗЛ из каждой области;
в) время затраченное на выделение;
г) время затраченное на описание;

Вывод получается что оценивать все таки надо не аналитиков, а целиком команду или решение/продукт полученный этой командой
Согласны?

Да. Так оно и есть.

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

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

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

Если аналитик выходит на "нерасчищенную территорию" - кто будет виноват в его плохих результатах? Как оценивать - он сам виноват в том, что не смог договориться с заказчиком или это вина ПМ (или сейлза), который имел конфликт с этим заказчиком на предварительных переговорах (и ничего ему не сказал об этом, или даже сказал)?

5. Немного о самих показателях.
Скорее всего, можно говорить о качественных и количественных показателях. Показатели можно разделить на: показатели, динамика роста которых отражает эффективность деятельности; показатели, динамика снижения которых отражает эффективность деятельности.
Примеры (подготовлены на скорую руку, прошу отнестись с пониманием).
Общие:
а) количество видов деятельностей, в которых аналитик компетентен.
Если, например, знания и опыт, синтезированные в навыки позволяют ему эффективно выполнять все вышеобозначенные виды деятельностей, значит он по этому показателю эффективен – насколько, можно определить пропорцией «x/8».

Выявления (для задачи «идентификация и описание заинтересованных в проекте лиц»):
а) знание всех областей в которых осуществляется идентификация;
б) знание принципов и методов идентификации ЗЛ из каждой области;
в) время затраченное на выделение;
г) время затраченное на описание;

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

Метрики, которые целесообразно использовать для оценки качества анализа, следующие:

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

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

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

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

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

2cintyao
Можно конечно обсуждать все написанные метрики дополнять их и т.д., только в общем случае все перечисленное относится именно к процессу анализа. В котором участвует как команда (причем местами не только аналитик) так и заказчик

То есть это не качество/эффективность Аналитика