Есть ли KPI?
Ключевые показатели эффективности (англ. Key Performance Indicators, KPI) — это числовые показатели деятельности, которые помогают измерить степень достижения целей или оптимальности процесса, а именно: результативность и эффективность.
Почему это важно?
KPI довольно спорная и сложная тема. Прежде чем взвалить на свои плечи работу с KPI разработки и команды в целом, подумайте о следующем:
- Зачем вам нужен KPI?
- Какие метрики войдут в KPI?
- На сбор и интерпретацию метрик будет уходить много времени. Где вы возьмете это время?
- Когда вы поймете, что времени уходит очень много, вы задумаетесь об автоматизации. Подумайте заранее, каким образом вы настроите автоматический сбор и визуализацию метрик?
- Что вы будете делать, когда какие-то метрики будут проседать? Для исправления и улучшения показателей потребуется придумывать какой-то комплекс мероприятий и последующую оценку влияния.
Какие метрики могут быть у команды?
Советы
Возьмём типичную проблему — допустим есть бизнес, у которого разработка периодически ломает прод. Если решать эту проблему классическим способом, как решали раньше на заводах, то вы просто построите ОТК: отдельный этап тестирования, жёсткие правила для код-ревью, чтобы без одобрения двух коллег нельзя было выкатывать. Как настоящий кризисный менеджер, вы придумаете какой-нибудь солидно звучащий KPI для программистов, вроде количества автотестов. Только вот прод реже ломаться не начнёт.
Проблема этого способа в том, что вы не доверяете своей команде, и строите систему, которая каждый день это недоверие демонстрирует, буквально повторяет: «ты дебил, делай что сказали, соблюдай правила».
Даже если отбросить то, что за месяц любая команда научится обходить ваши барьеры, такая практика выглядит глупо хотя бы потому, что вы нанимаете весьма дорогих творческих людей, и при этом пытаетесь сами же за них делать их работу. Уверенные в себе люди, которым эти рамки мешают, просто не приживутся в вашей команде. Подумайте сами, кто останется?
Бирюзовый подход работает совсем по другому. В основе лежит простое правило, что все люди — хорошие: если доверять на 100%, то вас никогда осознанно не обманут. А если обманут случайно, то приложат все силы для исправления проблемы. Парадоксально: если давать новичкам с самого начала полный доступ на прод, они пользуются им с большей осторожностью, чем доступом, честно заслуженным за испытательный срок.
Сфокусируйтесь не на преградах, а на помощниках. Пусть программист сам решает, когда привлекать QA, сколько и каких писать автотестов, в какой момент приглашать в задачу представителей бизнеса. Ваша задача как лидера — создать для этого инфраструктуру: быстрый деплой/откат, нужное количество QA, а самое главное — климат, в котором люди не боятся ошибаться.
Давайте представим, что вы поставили своим программистам KPI — количество ошибок. Первый вопрос, с которым вы столкнётесь — а что именно считать критической ошибкой? Достаточно ли десяти сообщений в Сентри или нужно что‑то более серьёзное, к примеру упавшая конверсия?
Допустим, вы решили эту проблему, и теперь все стороны понимают под словом «ошибка» одно и то же. Теперь давайте представим, как поменяется образ мыслей программиста, который оценивает свою работу по количеству ошибок.
Вот, к примеру, на проекте стоит очень старая версия Django, скажем 1.8. Это сильно замедляет разработку — сложно разворачивать окружение, нельзя подключать современные инструменты, трудно искать документацию. Обновить Django в принципе можно, и работа после этого пойдёт гораздо приятнее и быстрее. Но ошибок при смене версии не избежать, а за эти ошибки потом придётся отвечать — если и не вычтут из зарплаты, то как минимум посчитают.
Или есть у вас на проекте очень старый код, который достался в наследство от предыдущей команды, скажем управление правами доступа. Прилетает задача — добавить новую роль в эту систему. Вроде бы можно написать ещё парочку if, скорее всего ничего не сломается. А можно посидеть пару дней и сделать управляемую систему контроля доступа на основе ролей, с которой приятно будет работать. Как думаете, какое решение примет программист с KPI на количество ошибок? А будет ли он счастлив на работе, когда весь код в системе превратится в бесконечную череду вложенных if?
Мне кажется, команду разработки лучше строить и з людей, которым не нужен KPI, чтобы делать свою работу хорошо. Чтобы просто подойти к коллегам и вместе придумать меры по исправлению проблем, не нужна никакая система мотивации. Скорее всего, их эти проблемы беспокоят не меньше вашего.