Введение: почему метрики важны
Бизнес, как правило, не гонится за красивыми словами про "выявление скрытых требований" и "улучшение user experience". Бизнесу нужны цифры. Нужны рубли, копейки, проценты, которые можно посчитать и по которым можно оценить эффективность. Но как измерить эффективность работы системного аналитика? Ведь он не кодит и не продает, он... что-то делает, чтобы все работало лучше.
Косвенно в деньгах можно выразить:
Сокращение времени на задачу
Сокращение трудозатрат на задачу
Количество новых клиентов
Напрямую в деньгах:
Увеличение среднего депозита
Увеличение суммы чека
Увеличение оборота
Давайте разберемся, какие метрики можно использовать, чтобы доказать руководству, что системный аналитик – это не тот, кого страшно приглашать на встречи, а ценный актив компании.
Базовый набор «денежных» метрик: с чего начать
Чтобы не метаться между «всем подряд» и «ничем», имеет смысл опереться на небольшой набор метрик, которые реально можно посчитать и которые понятны бизнесу. Ниже – рабочий минимум: что мерить, зачем и откуда брать цифры.
| Метрика | Формула (пример) | Что показывает? | Как собрать данные |
1 | Сокращение трудозатрат на требования | ΔT_req = T_withoutSA – T_withSA (чел‑часы) | Сэкономленное время разработки | Jira (учёт времени), Confluence (история версий) |
2 | Меньше доработок после релиза | ΔD = D_withoutSA – D_withSA (шт.) | Насколько ТЗ «доживает» до релиза без костылей | Jira → типы «Bug», «Improvement» |
3 | Рост конверсии пользовательского потока | ΔConv = Conv_withSA – Conv_withoutSA (‰) | Прямой вклад в выручку | Аналитика продукта (GA, Amplitude и т.п.) |
4 | Рост среднего чека / депозита | ΔRev = Rev_withSA – Rev_withoutSA (₽) | Финансовый эффект в рублях | BI‑дашборд, CRM |
5 | Сокращение «времени на отклик» бизнеса | ΔT_resp = T_resp_withoutSA – T_resp_withSA (ч) | Как быстрее принимаются решения | e‑mail, мессенджеры |
6 | ROI аналитической деятельности | ROI = (ΔRev – Cost_SA) / Cost_SA | Общая отдача: сколько вложили в аналитика и инструменты – и сколько получили | Суммируем все Δ‑метрики, вычитаем затраты (зарплата, инструменты) |
7 | Покрытие требований трассировкой | Trace% = (Требований, покрытых ТЗ) / (Всего требований) | Насколько полно ТЗ отражает запрос бизнеса | Требования в Jira ↔ ТЗ в Confluence |
8 | Скорость выявления скрытых требований | ΔHidden = сколько скрытых нашли на этапе SA / сколько всего всплыло | Насколько аналитик «ловит» риски заранее | История change‑requests после релиза |
9 | Индекс переиспользования знаний | KRI = (Ссылок на прошлые ТЗ) / (Количество новых ТЗ) | Насколько аналитик накапливает и переиспользует знания | Confluence, анализ ссылок |
10 | Удовлетворённость стейкхолдеров (NPS) | NPS = % промоутеров – % критиков (опрос после сдачи) | Как воспринимают качество работы | Google Forms, SurveyMonkey |
Совет. Если возможности собирать всё сразу нет – начните с двух-трёх самых простых: трудозатраты, количество багов/доработок, конверсия. Остальное можно добавить позже, когда базовая аналитика уже крутится.
Метрики в историческом контексте: сравниваем "было" и "стало"
Метрики хороши только в историческом контексте. Например, прирост клиентской базы за неделю на 5% – это хорошо или плохо? Вроде как хорошо. Но если неделю назад было 10%? Уже вроде не так хорошо, а даже катастрофично. Падение на 50%!
Поэтому важно сравнивать метрики в периоде, а не смотреть среднюю температуру по больнице. Одна и та же цифра может означать успех или провал в зависимости от того, что было до этого.
Главная проблема: как сравнивать несравнимое?
Вот есть задача, сделанная без системного аналитика. На нее потратили X. А вот другая задача – с системным аналитиком, на нее потратили Y. Как их сравнить, если это совершенно разные задачи? Разные сервисы, разные технологии, разные разработчики с разными компетенциями?
Да даже если сервисы, технологии и разработчики будут одни и те же, глупо делать одну и ту же задачу по разным рельсам (с системным аналитиком и без) только для того, чтобы оценить эффективность. Это как строить два одинаковых дома, чтобы понять, нужен ли архитектор. Абсурд.
Как же быть? Как доказать руководству, что системный аналитик не просто так штаны протирает? И не мешает процессу разработки, а наоборот помогает?
Да, конечно, можно говорить кучу умных слов, что системный аналитик на раннем этапе выявит все требования, даже скрытые, что поможет их учесть еще на этапе разработки и не дорабатывать задачу уже после релиза, что системный аналитик учтет негативные и альтернативные сценарии, до которых не додумается ни разработчик, ни тестировщик.
Но все это – лишь слова, на которые руководство может резонно возразить, что у нас крутые кадры. Они сами до всего додумаются и учтут, или что время, потраченное на системный анализ, будет равно времени на устранение недочетов, выявленных в ходе эксплуатации. Короче, что овчинка выделки не стоит.
Хорошо бы найти какие-то метрики и способы измерения выхлопа от работы системного аналитика, которые будут убедительными для руководства.
Решение: сравнение при переделке функционала
Один из вариантов измерения эффективности системного аналитика – это ситуация, когда у вас есть некий функционал, который был сделан без системного аналитика и сейчас работает на бою. И вот приходит задача по его переделке в связи с, например, переходом на новый API поставщика. И вам так повезло, что эта задача попала к вам, как к системному аналитику.
Задача проходит по всему циклу разработки, начиная с изучения системным аналитиком API поставщика, сбора требований к интеграции (что проще, т.к. интеграция уже существует и в каком-то виде удовлетворяет). Уже на этом этапе можно выявить те недочеты, которые не были учтены в предыдущей интеграции (это те «хотелки», без которых вроде как работает, но было бы лучше с ними).
А потом, после выпуска новой интеграции можно замерить эффект от их реализации.
Пример из практики
У нас в старой интеграции была реализована идентификация клиентов не по всем типам документов (не все способы идентификации клиентов), предоставляемые API. В новой реализовали (т.к. системный аналитик ознакомился с API и учел еще и этот сценарий). На выходе замерили кол-во клиентов, пришедших именно с данным типом документов. Т.е. раньше их было 0, а теперь Х% от всех. Прирост? Прирост! В деньгах выражается? Еще как.
Кроме того, системный аналитик проанализировал API поставщика и смог предложить вариант, существенно сокращавший клиентский путь. Это напрямую повлияло на конверсию.
Получается, это ситуация, когда есть аналогичная задача, но сделанная без системного аналитика. И можно посчитать выхлоп от того, что не было учтено в предыдущей реализации.
Далее, когда данная задача выйдет целиком, можно посчитать в принципе общий прирост клиентов/денег (в общем, того, для чего она делалась) по сравнению с ситуацией до. Например: кол-во новых клиентов в день/неделю при старой реализации и при новой.
И тут прирост может быть обоснован кучей факторов:
Более продуманным/удобным/коротким (системный аналитик!) пользовательским путем
Альтернативными сценариями достижения цели
Отсутствием багов
И пр.
Вот это можно померить в деньгах и прийти к руководству: «Смотрите, без системного аналитика у вас был реализован этот функционал, который работал как-то вот с такими показателями (клиенты, деньги и пр.). Теперь этот же функционал реализован с системным аналитиком. И посмотрите на эти показатели!»
Возвращаясь к предыдущему примеру из моей практики
Когда я пришла в компанию системный анализ не был внедрен от слова совсем. И конкретно функционал по регистрации и идентификации клиентов был реализована силами разработчика «ну, как я ее понял». Да, в целом оно работало, были какие-то показатели прироста клиентской базы. Но после выпуска новой регистрации и идентификации (уже по моему ТЗ и под моим авторским надзором) эти показатели увеличились на 20%! Я замерила и представила руководству: количество клиентов, прошедших идентификацию с помощью новых типов документов (до было 0), количество клиентов, прошедших идентификацию со старыми типами документов (имевшихся в прошлой реализации) за неделю – в старой реализации и в новой.
И тут дело не в некомпетентности разработчика, �� в отсутствии процесса системного анализа в принципе, понимания его важности в голове у руководства. Когда я продемонстрировала эти цифры, произвели эффект взорвавшейся бомбы.
Таким образом, можно сравнить продуктовые метрики реализованной фичи без системного анализа с фичей с системным аналитиком при вынужденной необходимости ее переделки (как в примере выше с переходом на новую версию API поставщика) без существенных переработок функционала, когда не добавляются дополнительные возможности (либо их можно отсечь при измерении).
Как превратить «случайный рост» в убедительный аргумент
Чтобы руководство не отмахнулось фразой «ну подумаешь, один раз повезло», рост нужно оформить как осмысленное сравнение, а не как разовую цифру. Вот пошагово, как это сделать.
Выберите «базовый» период – например, квартал до внедрения аналитика (или до переделки с аналитиком). Это ваше «было».
Соберите по тем же KPI данные за этот период – трудозатраты, количество багов, конверсия. Без этого «стало» ни с чем не сравнить.
Нормализуйте цифры. Делите на количество релизов, размер команды, сложность фич (Story Points). Иначе сравнение «в лоб» легко раскритикуют: «раньше было меньше задач», «команда другая» и т.д.
Постройте график. По одной оси – время, по другой – метрика. Покажите тренд до и после, при желании добавьте линейную регрессию. Наглядно видно: не просто «цифра выросла», а «тренд изменился».
Посчитайте доверительный интервал (если точек несколько). Тогда можно сказать: «с такой-то вероятностью эффект не случайность». Возражения в духе «это случайность» отпадают.
Переведите в деньги. Процентный рост конверсии умножьте на средний чек. Снижение багов – на среднюю стоимость исправления (чел‑час×ставка). Руководство мыслит рублями – дайте им рубль.
Метрика производительности: влияние инструментов
Если вопрос необходимости этапа системного анализа у вас не стоит, то можно измерить повышение производительности аналитика при применении тех или иных новых инструментов. Например, ИИ.
Пример из практики
У нас (я писала в своей статье) внедрение ИИ позволило сократить путь от собранных бизнес-требований до готового ТЗ в некоторых проектах до 50%! Мы научили ИИ не только работать с документами в Confluence и задачами в Jira, но и бегать по гиту и предлагать решения в текущей конфигурации сервисов.
Это конкретная метрика, которую можно измерить: время от начала сбора требований до готового ТЗ. До внедрения ИИ – X часов, после – Y часов. Разница – экономия, которую можно перевести в деньги через стоимость часа работы системного аналитика.
Пример.
«После внедрения ИИ‑помощника аналитика путь от бизнес‑требования до готового ТЗ сократился с 12 ч до 6 ч (–50 %). При среднем тарифе разработчика 4 000 ₽/ч экономия составила 24 000 ₽ на одну фичу. При 30 фичах в квартал — 720 000 ₽.»
Подставьте свои цифры – и у вас уже не «мы поработали хорошо», а конкретный финансовый эффект.
Плюс-минус «чистых» экспериментов: как не попасть в ловушку
Когда вы сравниваете «до» и «после», всегда найдутся скептики: «задачи разные», «сезон другой», «команда поменялась». Чтобы ваше сравнение было устойчивым к таким возражениям, стоит заранее учесть типичные подводные камни.
Проблема | Что сделать |
Разные сервисы / технологии | Сравнивайте задачи с одной технологической базой – например, ре‑интеграцию того же API, тот же стек. |
Разный уровень компетенций разработчиков | Фиксируйте «командный фактор»: сколько в среднем Story Points за спринт было до и сколько после. Иначе припишут всё сильной команде, а не аналитику. |
Сезонность и бизнес-циклы | Сравнивайте периоды одной длины и одного типа: Q1 с Q1, не Q1 с Q4. Иначе «рост» может оказаться просто сезонным пиком. |
Нельзя сделать две одинаковые задачи параллельно | Делайте ретроспективное сравнение: берёте задачу, сделанную без аналитика, и сравниваете с похожей задачей, уже выполненной с аналитиком (как в примере с переделкой интеграции). |
«Слишком хорошее» ТЗ = мало изменений в коде | Чтобы не терять эффект из вида: выделяйте отдельно change requests (доп. требования после релиза) и считайте их количество и стоимость. Так видно и качество ТЗ, и экономию на доработках. |
Чем аккуратнее вы учтёте эти моменты, тем сложнее будет списать ваши метрики на «совпадение» или «другие факторы».
Расширенный набор метрик: когда базовых мало
Когда базового набора (трудозатраты, баги, конверсия, чек) уже не хватает или хочется показать влияние аналитика с разных сторон – можно добавить метрики «второго эшелона». Они не всегда напрямую в рублях, но хорошо дополняют картину.
Категория | Метрика | Что измеряется |
Требования | Volatility of requirements – доля изменённых требований от общего числа | Насколько аналитик умеет держать курс при изменении запросов |
Риски | Risk mitigation index – доля рисков, описанных в ТЗ и закрытых до релиза | Превентивная работа: сколько «пожаров» потушили до выката |
Коммуникация | Mean time to clarification – среднее время ответа на запрос бизнеса | Как быстро аналитик снимает неясности |
Документация | Documentation completeness – доля обязательных разделов ТЗ, которые реально заполнены | Качество артефактов, а не «галочка что ТЗ есть» |
Скорость разработки | Sprint velocity delta – изменение Velocity (Story Points) после появления аналитика | Влияние на темп команды |
Поддержка | Support cost per feature – затраты поддержки на одну функцию | Долгосрочная экономия: меньше костылей – меньше вопросов в саппорт |
Решения | Decision latency – время от появления вопроса до принятия решения | Насколько аналитик ускоряет принятие решений в продукте |
Качество решений | Solution success rate – доля реализованных решений, достигших KPI | Не просто «сделали», а «сделали и выстрелило» |
Автоматизация | Automation coverage – доля требований, покрытых автотестами | Связка качества ТЗ и качества кода |
Клиенты | CSAT after release – средняя оценка удовлетворённости по новой функции | Прямое влияние на то, что чувствует пользователь |
Откуда брать данные?
Jira – требования и баги; Confluence – ТЗ и их версии; BI – финансовые KPI; мессенджеры или почта – время реакции; Google Forms (или аналог) – NPS и CSAT. Постепенно подключайте источники, не обязательно всё сразу.
Заключение
Измерять работу системного аналитика можно и нужно. Главное – выбрать правильные метрики и правильно их интерпретировать. Не все метрики можно выразить напрямую в рублях, но все они в конечном итоге влияют на бизнес-результаты.
Важно помнить:
Метрики нужно сравнивать в историческом контексте
Лучше всего сравнивать похожие проекты или один проект до и после переделки
Не все метрики работают в одиночку – лучше использовать комплекс метрик
Метрики – это инструмент, а не цель. Цель – улучшение процессов и результатов
И самое главное: метрики – это не способ оправдаться перед руководством, а способ понять, как работать лучше и приносить больше пользы бизнесу.
