трудоемкость проектов, например по методологии COCOMO II, рассчитывают исходя, в том числе, из количества логических строк кода :)

вот присоединюсь, как вариант. хотя если сложность проектов разная то и количество утончений тоже разное

Имхо, никак нельзя формально оценить.

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

А в некоторых случаях чем менее лаконичен документ, тем он сложнее для восприятия.

Спасибо большое за ваши ответы!

Деньги. Любая эффективность работы выражается в деньгах.
Работать в IT можно и без аналитика. И тут не важен тип аналитика.
Системный аналитик в большей части времени экономит деньги.
Бизнес аналитик способен как экономить деньги, так и искать новые возможности, тем самым зарабатывая их.
Есть аналитики, которые мониторят рынки, конкурентов, производят исследования новых направлений - они зарабатывают деньги.

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

У меня, как системного аналитика, можно выделить несколько направлений оптимизации процесса разработки ПО (конечно это отдельная работа на аналитику и структурирование для понимания метрик, а также отдельная работа по её подсчёту, в т.ч. с контрольной и экспериментальной группой). Но уже сейчас можно прикинуть, что основной доход будет приходить от работы со стейкхолдерами (уменьшение работы разработчиков за счёт правильной постановки), экономия их работы за счёт разделения труда разработчика и системного аналитика. Это самые явные и первые мысли, что пришли в голову. Есть также косвенные доходы - формирование документации (тут можно считать объёмы багфиксов или переделывания систем с и без документации), уменьшение количество ошибок разработчиков на уровне архитектуры, доход от формирования общего концепта архитектуры и соблюдения правил...
Да, это похоже на формулу, описанную выше. Но вам она вся и не нужна. Исследуете основные направления (этим сможет заняться начальник отдела аналитики, если у него голова на плечах), составляете перечень метрик и исследуете группы с/без аналитика.

Зачастую польза от конкретного системного аналитика ощущается: 1. с опытом, 2. на понимании, насколько он ускорил работу разработчика и защитил его от ошибок или неверных суждений. Опытные начальники отделов, тимлиды и  менеджеры проектов с техническим образованием вполне способны через 3-6 месяцев работы с аналитиком, прикинуть его КПД за счёт сравнения с эталонными/среднестатистическими экземплярами. Аналитики уровня сеньёров могут даже ппробовать вычислять КПД по метрикам. Но прикручивание аналитика к метрикам - плохая и дорогая практика. лучше нанять нормального лида, чтобы он формировал представление: 1. нужен ли аналитик вообще, 2. кто и как работает.

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

Аналитик не производящая роль. Как ты эти деньги посчитаешь, особенно если нет в компании опыта "без аналитика"?

в моём случае это оптимизация. если нет опыта "без аналитика", то надо не деньги считать, а качество контролировать

вообще небольшим проектам аналитик не нужен, они могут быть выполнены силами команды + ревью архитектора и человека, отвечающего за бизнес

Это как раз тот самый "опыт без аналитика". Везде впихивать аналитика - глупо.

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

Ок. Качество. Какие метрики есть чтобы чисто аналитика померить и другие роли не примешивались?

к сожалению небольшие проекты зачастую делаются командой РП+разрабы, архитектор (про толкового даже и не говорим) встречается реже аналитика

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

А вообще, конечно, продуктивность отдельной роли мерять - это какие-то надуманные метрики. Тем более, что никто сейчас не работает в одной роли

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

Для каждой компании они свои. И для каждой роли они свои. Я работал в 4-х компаниях системным аналитиком и у них всех были разные метрики успеха. Кому-то было важно проект запустить, кому-то отчитаться перед начальством. Где-то важно было уложиться в сроки.
Конкретные метрики: качество создаваемой документации (понятность для конечных пользователей, законченность, учёт необходимых данных), работа со стейкхолдерами (объём покрытия, % выявления на разных стадиях), качество данных (количество данных, которые пришлось за аналитиком переделывать), прочие.
У аналитика всегда есть чётко определённая роль. Он делает конкретную работу для достижения конкретного результата. Как только аналитик начинает размываться по ролям, возможность что-то считать исчезает. Потому, что аналитик перестаёт быть аналитиком.

А как количественно измеряете понятность документации для пользователя?

На моём опыте часто были случаи, когда работали именно РП + разработчики + архитектор (грамотный). Может быть мне везло на архитекторов. =)
И всё-таки к счастью, что там не было аналитика, в ином случае разработчики начинают со временем отключать мозги.

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