Вступление

Неделю назад ко мне обратились с просьбой подсказать по одному рабочему кейсу.

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

А некоторые уникумы еще разделяют зп на базовый оклад и премиальную составляющую. Которую естественно можно резать при любом удобном или неудобном случае.

????А что, вы думали шутки про IT-заводы - это все шутки?

Перейдем же к сути кейса: 

Как вы догадались уже из вступления, руководство компании X всем бизнес-аналитикам помимо базового оклада внедрило премию. 
Сумму премии завязали на KPI.
KPI же определили метрикой количества багов / change request’ов после внедрения проекта...

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

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

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

Но для начала все же стоит разобраться в терминах и ограничениях по нашей задаче.

Термины

• Метрики — это показатели, которые отображают фактические данные за выбранный период. Например, количество кликов по рекламе за неделю.

• KPI (Key Performance Indicators — ключевые показатели эффективности) — показатели, которые помогают задать цели и оценить эффективность достижения нужных метрик. Например, в качестве KPI может использоваться цель достижения «1000 кликов в неделю» или «CPA до 500 рублей».

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

P.S. Описание взято из этой статьи.

Главное ограничение

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

Но камон, кто будет слушать линейного специалиста - аналитика? 

Правильный ответ: хороший менеджер. 

Но если в компании есть такая идиотская KPI-культура, давайте в ограничение все же добавим, что менеджер у нас плохой.

Теперь давайте разбираться:

Почему культура идиотская, и бизнес-аналитик в этом не причем?

Да, на метрику по кол-ву багов и CR (change request) бизнес-аналитик может иметь влияние. Но давайте попробуем порассуждать с другой стороны.

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

Из важных моментов:

1. Баг - это всегд комадная ответственность. Потому что при неудачном деплое в пятницу вечер именно вся команда поднимется и будет анализировать, а что же там поломалось.

2. Никто никогда мне не докажет, что плохая работа аналитика - на 100% единственная причина возникновения багов или создания CR на проекте.Да, бизнес-аналитик может продолбаться с интервьюрованием заказчиков и некорретным описанием одной из ветки бизнес-процесса. Это будет очень больно для всего проекта.

Фишка в том, что точно также может ошибиться:

• И бизнес-заказчик, который накосячил при формировании нового тарифа услуги и ее целевой аудитории;

• И разработчик, который смерджил не те ветки, и его поделие с заглушками уехало на прод;

• И тестировщик, который поленился провести регресионное тестирование, и по итогу у смежных коллег отвалился их сервис;

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

Итого, мы получили ответ на вопрос коллеги из запроса:

А насколько вообще адекватная эта метрика по отношению к аналитику?

Ответ: метрика по кол-ву багов на проде может быть применима, но только при условии, что она также будет привязана ко ВСЕМ членам команды. И в том числе к бизнес-заказчику.

Бизнес-аналитик - это не тот человек в команде, кто единолично отвечает за нажатие кнопки "DEPLOY" и несет ответственность за все, что произойдет после.

За это отвечает и должна отвечать КОМАНДА.

Теперь плавно перейдем к следующему вопросу:

А какие метрики можно привязать к KPI бизнес-аналитика?

Я бы отталкивался от нескольких направлений. И к каждому направлению можно прикрутить свою метрику:

1. Аналитик и Бизнес-процессы

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

   • зарабатывание денег за счет развития или создания нового бизнес-процесса

   • увеличение эффективности бизнес-процесса

   • урезание костов на обслуживание бизнес-процесса

Обычно при реализации любого проекта или внедрения продукта мы получаем business value в каком-то из этих направлений. А может даже в нескольких.
И задача бизнес-аналитика помогать бизнес-заказчику формализовать подход к реализации этих проектов через сбор требований и бизнес-моделирование.

Соответственно так или иначе бизнес-аналитик влияет на то, сколько бизнес заработает денег, насколько эффективно сработает новый бизнес-процесс и так далее.

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

P.S. Да, можно поспорить со мной на тему, что деньги это же больше про финансового аналитика / консалтинг. И вы будете правы!
Но все же мы знаем, насколько бывает широка роль аналитика на проекте.
И я видел такие случаи, когда бизнес-аналитика во всю погружали не только в построение бизнес-процессов, но и в экономику продукта, расчет тарифов услуг и так далее.
Поэтому и метрики нужно подбирать и тестировать под гипотезу, а не наоборот. Тем самым натягивая сову на глобус.

2. Аналитик и Люди

Тут метрика довольно простенькая, но не менее эффективная.
И это CSI.

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

После ознакомления со статьей вы скажите - но там же была речь про метрику продукта? Причем тут аналитик?

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

Задавая правильные вопросы можно определить impact аналитика в проект, а также его эффективность. И далее включить эту оценку в KPI сотрудника.

3.. Аналитик и Цикл разработки ПО

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

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

Дисклеймер: описывая каждую метрику, я специально не указываю ее удельный вес в KPI. Такую модель должен строить руководитель, и она от проекта к проекту может меняться и эволюционировать.
Поэтому вся эта история с метриками работает ТОЛЬКО через построение гипотез и их проверку.

Вернемся к метрикам:

• Оценка проекта: Всегда есть оценка этапа проекта аналитиком ДО старта проекта, есть сроки реализации по факту.Качество прогноза и оценки аналитиком своих работа можно включить как метрику эффективности в KPI

• Баги: Да, данная метрика является сейчас базовой в ситуации у коллеги, но как мы разобрались выше, она не идеальна.Причину каждого бага нужно четко проговаривать в команде. Ибо ответственность за продукт - она, командная, да. Но ответственность за личные косяки должна быть всегда персональная.Кол-во багов с целевым типом причины "Недочет в анализе" можно использовать уже как метрику.

  Фиксировать же первопричину бага - это нормально. И реализовать это можно через отдельное поле в тикете в Jira.
  Обозвать его "Причина сбоя" и далее сделать список возможных значений в виде "Недочет в анализе", "Недочет при разработке", "Сбой инфраструктуры" и так далее.
  При этом не нужно бить никого по рукам! Баги нужно анализировать, исправлять и учиться на них. Причем учиться не персонально одному человеку, а ВСЕЙ команде.

Best practise

Когда я был стажером в Альфа-банке, мне всегда говорили: критикуешь - предлагай. Поэтому ниже поделюсь с вами той пратикой по KPI, которая мне показалась годной и рабочей. Она применялась в ядровой команде Альфа-банка 4 года назад, сейчас возможно все уже по-другому.

Формулу точно я уже не вспомню, но концепция была следующая:

• У тебя есть 3-4 квартальных целей. Каждая цель - твоя задача/проект/side activity. Каждая цель также имеет определенный вес в %.

• Если ты достигаешь всех целей, то твой KPI условно 100.

• Дальше этот KPI умножался на коэффициент твоего управления (насколько хорошо отработало все управление). В цифрах это было что-то вроде 0.9 - 1.1. 

• Затем происходило перемножение на коэффициент «ценности» (1-1.1), который устанавливал сам руководитель команды (в команде 20 человек было). Таким образом распределение премии регулировалось не только % выполнения твоих проектов, а реальной (ака субъективной) ценностью того, что ты вообще делаешь в команде. И экспертное мнение руководителя в нашем случае было всегда обоснованным и справедливым, и никто не жаловался.

• То есть такого ограничение как в статье (про плохого менеджера) у нас не было.

Соответственно ты получал премию в зависимости от своего грейда, умноженную на показатель KPI. Который мог быть и 0, а мог быть и 1.2.

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

Заключение

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

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

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

Успехов!

P.S. Больше жизненных историй про аналитиков всех мастей вы сможете найти на моем ТГ-канале https://t.me/godnolytika.