В каждой крупной компании рано или поздно наступает момент «тотального измерения», а точнее, попытка побороть растущую неэффективность (расходы растут, а перфоманс как-то не очень), научиться измерять производительность и экономическую эффективность любого, кто принимает участие в разработке продукта или сервиса: от уборщицы до целых бизнес-блоков. И чем крупнее компания, тем, как правило, выше упор на разного рода KPI и метрики.
Однако, нужно ли это делать, и если да, то как? Насколько реально метрики помогают достичь конечных бизнес-целей? Не уходит ли за счёт внедрения сотен KPI и падения мотивации персонала больше денег, чем приходит онных за счёт усиления контроля / повышения той самой эфемерной «эффективности»? Ответить на все эти вопросы в рамках одного диалога нереально, но мы хотя бы начнём этот нетривиальный процесс.
Вообще, планирую посвятить данной теме ряд статей:
- На сколько метрики реально полезны на практике, и каков идеальный баланс между получаемым за счёт их внедрения приростом качества и их минусами?
- Какой набор метрик стоит использовать в ИТ, чтоб их
невозможнотрудно было обойти (спойлер: обойти можно любые KPI, но можно сделать это максимально сложным делом ;)).
Как сделать так, чтоб система KPI объективно отражала эффективность вашей команды? - Как комбинировать бизнес-метрики (аля OKR) и тех. метрики, не убив при этом мотивацию и инициативность команды?
Начнём с пункта №1. Итак,
Зачем нужны метрики (KPI) в ИТ?
1. Объективная оценка производительности команды и помощь в принятии управленческих решений. Позволяет понять, насколько хорошо вся ИТ-команда, конкретная подкоманда (BA, Dev, Front, QA, DevOps) или её участник справляется с задачами. Выявляет их сильные и слабые стороны, помогает понять, где именно нужна поддержка, обучение, доп ресурсы, перераспределение задач и т.д.
2. Детерминированность и формализация оценки работы команды (её участника). Особенно полезно при проведении ретро всей команды и Performance review конкретного инженера, в т.ч. в аргументации повышения / неповышения грейда или ЗП.
2.1. Вся команда одинаково и чётко понимает свои цели в цифрах и то, как оценивается её работа (в т.ч. для повышения грейда / ЗП). Это повышает мотивацию и снижает число конфликтов и вопросов.
2.2. Хорошая визуализация динамики эффективности работы команды (её участников) во времени, что позволяет видеть эффективность применения тех или иных подходов в работе (тех., орг) для повышения результативности.
3. Рост мотивации. Справедливая оценка, её чёткое понимание и online-доступ к текущим показателям вдохновляет команду на улучшение результатов и позволяет легко проверять гипотезы (см. пп. 2, 2.1, 2.2).
4. Инструмент для быстрой и эффективной оптимизации менеджмент и тех. процессов команды. Вся команда, включая руководство, может использовать данные метрик в динамике для проверки гипотез (разных подходов повышения результативности) или в перераспределения задач.
5. Online-режим выявления проблем (мониторинг и алертинг).
Вы легко построите систему мониторингов и алертингов, которая будет показывать Вам проблемы раньше клиентов (буквально в режиме online).
Пример: метрика отклонение от скользящего среднего по выдачам кредитов в час больше 5%. Обычно спрос прыгает до 30% от дня к ночи, но это всегда происходит медленно. Потому, если у Вас начнёт лагать одна из 2 интеграций с СМС-агрегаторами для подтверждения подачи заявки, то Вы не увидите резкого падения спроса ниже какой-то нормы, но изменение произойдёт очень резко, что Вы и заметите в течение 5-60 минут.
5.1. Быстрое и системное исследование первопричин проблем.
При грамотно построенной иерархической системе метрик Вы легко научитесь находить и устранять первопричины этих проблем. Для понимания, про что я, приведу примеры цепочек выявления проблем от бизнес уровня до первопричин.
Пример 1 (тех): упали выдачи кредитных карт клиентам => упала конверсия шага X в заполнении заявки => повысилось ср. время доставки SMS-кода клиенту => увеличилось число HTTP errors в интеграции с SMS-агрегатором Y.
Вывод: интеграция одного из агрегаторов начала давать нерегулярные сбои, и надо либо переключить балансировщик на второй агрегатор, либо оперативно внедрить retry-и.
Пример 2 (орг): повысилось недовольство бизнеса Time-To-Market (Lead time) по их фичам => Delivery lag по 80% задач в спринтах с 0-3 дней (доставляем 80% задач не позже 3 дн после даты окончания спринта + 7дн) => метрика соотношения QA / Dev выросла с 0.8 до 1.2 (при неизменном составе команды) => QA Cycle time (время на этапе QA) выросло с 16h до 30h при неизменном Dev Cycle time.
Вывод: либо ленятся QA, либо разработчики пихают в QA фиговый непроверенный код.
А теперь…
Почему метрики (KPI) в ИТ — это плохо?
1. Не всегда понятно, как объективно измерить вклад команды (её участника).
Пример: релиз выпущен вовремя и без прод багов, в нём было обычное по объёму спринт-квоты мн-во задач, но задачи затрагивали потенциально все части монолита, и команде QA пришлось консультировать BA-команду для учёта всех кейсов изначально и провести полный регресс перед релизом, из-за чего они нехило по-овертаймили, дабы всё вовремя и без рисков зарелизить. Однако QA / Dev метрика стала хуже, и судя по цифрам, QA поработали хуже других подкоманд, хотя на самом деле QA — самые молодцы.
Это классическая проблема бессистемно организованных метрик.
2. Оценка может демотивировать команду (участника), если не учитывать контекст, другими словами — при неполноте системы KPI.
Пример: нагибаем раком джуна за овертаймы по оценке от сениора (превысил своими работами оценку сениора). Классическая проблема неучёта грейда в ресурсном планировании (или просто отсутствие ресурсного планирования как такового :)).
3. Необъективность системы KPI. Погоня за цифрами может снизить фактическое качество работы в тех областях, где метриками что-либо ещё не покрыто или где система метрик неполна. Это часто случается с низкоуровневыми (узкими или техническими) метриками типа Downtime по компонентам или REST Errors: порой, их соблюдение обходится намного дороже сэкономленных на их соблюдении денег.
В этом случае команда может начать работать на красивые цифры вместо реальной пользы проекта / реальность заинтересованности развитием проекта.
4. Сосредоточенность на индивидуальных результатах может подорвать дух сотрудничества, командой работы.
Пример: QA / Dev растёт, а дело не в том, что QA стали дольше тестировать, а в том, что Dev стремится сохранить свои метрики по оверэстимейтам (превышение оценки) и по Dev Cycle Time (время на этапе Dev) в норме, и им абсолютно забить на работу QA, DevOps, SRE и тем более на бизнес.
Классическая проблема отсутствия у подкоманд (участников) завязки на верхнеуровневые KPI (говоря проще, — общекомандных и бизнес-метрик).
5. Разработка и поддержка системы KPI требуют времени и ресурсов.
Особенно, если мы говорим об общедоступной BI-системе, в которой всё автоматизировано собирается. Для этого нам наверняка понадобится свой DWH, навёрнутый на него BI (аля Superset) и его интеграция с условной Jira-ой, Zabbix-ом, ELK, loki и всем таким прочим. Понадобятся доп ресурсы (люди / деньги) на поддержку всего этого непростого дела.
Как снизить риски и недостатки метрик?
- Использовать комплексный подход к оценке, комбинируя количественные и качественные метрики.
- Учитывать контекст выполнения задач (сложность, грейды, уровень погруженности в домены, приоритеты, внешние факторы).
- Делать акцент на командных результатах и бизнес-метриках, а не только на индивидуальных и технических.
- Вовлекать разработчиков в процесс формирования метрик, чтобы они воспринимались, как справедливые и объективные.
- Регулярно пересматривать и адаптировать метрики в зависимости от изменения целей и приоритетов проекта.
Ну и просто нужно быть осознанным: не надо измерять ради измерения, пытаться заткнуть все дырки сотнями KPI, не смотря на качественные показатели и людей: поверьте, закрыть все кейсы чистыми цифрами не получится, а вот мотивацию и желание команды (сотрудника) сделать бизнес-продукт угробить этим можно. Таки мотивация команды и ориентация на бизнес, даже если придется овертаймить и выходить из своей зоны ответственности (читай, комфорта), принесет самый лучший результат.
Напомню ещё раз: самое ценный актив любой компании — это люди. И они важнее цифр. 😉
Лысяк Александр
