Вступление
Неделю назад ко мне обратились с просьбой подсказать по одному рабочему кейсу.
В некоторых компаниях менеджерам (особенно тем, кто из руководителей отделов продаж перешли в бизнес-руководители 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 одной из твоих первых задач должно стоять определение того, что/кто стало причиной его возникновения.
Из важных моментов:
Баг - это всегд комадная ответственность. Потому что при неудачном деплое в пятницу вечер именно вся команда поднимется и будет анализировать, а что же там поломалось.
Никто никогда мне не докажет, что плохая работа аналитика - на 100% единственная причина возникновения багов или создания CR на проекте.Да, бизнес-аналитик может продолбаться с интервьюрованием заказчиков и некорретным описанием одной из ветки бизнес-процесса. Это будет очень больно для всего проекта.
Фишка в том, что точно также может ошибиться:
И бизнес-заказчик, который накосячил при формировании нового тарифа услуги и ее целевой аудитории;
И разработчик, который смерджил не те ветки, и его поделие с заглушками уехало на прод;
И тестировщик, который поленился провести регресионное тестирование, и по итогу у смежных коллег отвалился их сервис;
И менеджер проекта, который нормально не договорился со смежниками и сопровождением о последовательности внедрения поставок. По итогу кто-то поставился раньше времени, кто-то позже, и никто не понимает, в чем проблема.
Итого, мы получили ответ на вопрос коллеги из запроса:
А насколько вообще адекватная эта метрика по отношению к аналитику?
Ответ: метрика по кол-ву багов на проде может быть применима, но только при условии, что она также будет привязана ко ВСЕМ членам команды. И в том числе к бизнес-заказчику.
Бизнес-аналитик - это не тот человек в команде, кто единолично отвечает за нажатие кнопки "DEPLOY" и несет ответственность за все, что произойдет после.
За это отвечает и должна отвечать КОМАНДА.
Теперь плавно перейдем к следующему вопросу:
А какие метрики можно привязать к KPI бизнес-аналитика?
Я бы отталкивался от нескольких направлений. И к каждому направлению можно прикрутить свою метрику:
Аналитик и Бизнес-процессы
У бизнес-заказчика также есть несколько ключевых направлений, где он должен проявить себя, а именно:
зарабатывание денег за счет развития или создания нового бизнес-процесса
увеличение эффективности бизнес-процесса
урезание костов на обслуживание бизнес-процесса
Обычно при реализации любого проекта или внедрения продукта мы получаем 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.
