Неработающие KPI в ИТ: чем грозят и как выбрать правильные

В менеджменте есть постулат: невозможно успешно управлять тем, что нельзя измерить. KPI (Key Performance Indicators, ключевые показатели эффективности) — это тот самый инструментарий, который позволяет оценивать, контролировать и улучшать работу по достижению цели или оптимальности процесса. Причем KPI можно применять как к отдельным сотрудникам и командам, так к бизнесу в целом. ИТ-компании — не исключение.

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

Почему ИТ-компании важны KPI?

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

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

Когда у проекта появляются реальные пользователи, компания начинает расти. Её владельцы или инвесторы ожидают уже не просто выживания, а предсказуемого роста бизнеса. По мере развития появляются вопросы, на которые собственникам хочется знать ответы. Где находится компания? Что позволит бизнесу расти быстрее? Где теряются деньги? Как повысить качество продуктов или сервисов, а, следовательно, завоевать больший кусок рынка?

Момент осознания необходимости KPI — серьезный шаг к развитию компании. Если мы спустимся на уровень ниже и возьмем отдельно взятую команду, то увидим аналогичную историю. Два-три единомышленника, пишущих код по ночам, — это хобби. Команда из 5-10, а то и 50 человек, работающих по четкому графику, в едином проектном и процессном пространстве с учетом бизнес-приоритетов и ограничений, нуждается в активном внедрении и постоянном использовании метрик (KPI).

Как понять, что выбранные KPI не работают?

Пример из начала 1990-x. В те годы ряд мировых компаний придумали и стали применять метрику оценки скорости работы разработчика. Согласно ей, оплачивать работу таких специалистов предполагалось по количеству строк кода, написанных за день, неделю, месяц.

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

Другой пример из 2000-х. Руководство одной уважаемой ИТ-компании из Санкт-Петербурга ввело новую систему поощрения разработчиков. Звучало это примерно так: исправленный дефект в выходной день поощрялся в два раза больше, чем в рабочий день. Цель такой метрики очевидна: стимулировать сотрудников прилагать дополнительные усилия по повышению качества продуктов в выходные дни.

В первые пару недель всё работало, как и было задумано. Однако несколько умных сотрудников «взломали систему». Они готовили исправления в течение рабочих дней, а заливали в репозиторий в субботу. В итоге предприимчивые ребята подняли доход, не увеличив вклад в проект.

Далее пошла цепная реакция. В течение рабочей недели большая часть команды не исправляла дефекты, а ждала выходного дня. Они приходили в офис на 15 минут и заливали все накопившиеся изменения. По истечению трех месяцев от данной метрики пришлось отказаться и признать ее в таком виде неэффективной.

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

При внедрении KPI могут возникнуть несколько проблем:

1. Выбранные или созданные KPI не соответствуют стратегическим целям компании. Метрика «решает» какую-то локальную проблему, которая лежит вне вектора развития бизнеса или вовсе мешает его развитию;

2. Целевые показатели или пограничные пределы определены неверно. Если они слишком низкие и легко достижимые, это приведет к демотивации и деградации сотрудников. Абсолютно недостижимые — к отрицанию целей и нигилизму сотрудников, которые будут только делать вид, что работают над поставленными задачами. Вспомним термин «достижимость» в аббревиатуре SMART;

3. Сотрудники не поняли логику KPI. Команда должна понимать и разделять идею, стоящую за каждым показателем. Иначе получите либо игнорирование целей, либо неправильную расстановку приоритетов;

4. KPI избыточны. У сотрудников могут разбегаться глаза от обилия целей, их метрик и пороговых значений. Худшее, что может придумать руководитель, — назначить противоречивые KPI. Когда выполнение одного KPI сводит на нет работу по второму критерию или наоборот.

Поэтому набор показателей эффективности должен быть:

• простым,

• понятным,

• принимаемым всеми сотрудниками,

• достижимым,

• направленным на повышение эффективности процесса или на ускорение результата.

В итоге KPI должны стать частью стратегии компании и ни в коей мере ей не противоречить.

Алгоритм создания правильных KPI

Как я уже упоминал, KPI должны быть направлены на повышение одной или нескольких характеристик проекта, команды, процесса. Предлагаю следующий алгоритм создания правильных метрик:

1. Следование стратегической цели. Стратегия заключается в повышения удовлетворенности и лояльности клиентов к существующему ИТ-продукту. Его качество — один из ключевых факторов успеха. Поэтому, несмотря на добавление нового функционала, необходимо повышать степень покрытия unit-тестами;

2. Определение текущих и целевых значений. Пример: текущий уровень покрытий кода unit-тестами — 30%, тогда как целевой, признанный отраслевой стандарт — 80%;

3. Получение данных метрики. Значения метрик должны высчитываться максимально легко и желательно автоматически. В примере с unше-тестами это решается с помощью SonarQube, правильно настроенного и включенного в общий CI/CD-процесс проекта;

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

5. Частота обновлений. Целевые показатели и вес KPI в общем наборе разумно пересматривать с определенной периодичностью. В зависимости от бизнес-ситуации эти показатели имеет смысл уточнять раз в месяц или в квартал, не чаще. О таких изменениях сотрудников следует уведомлять заранее, а не постфактум. Тем более не следует скрывать эту информацию;

6. Время жизни. Если стратегическая цель компании достигнута или KPI перестал приносить ожидаемую пользу, а может просто была выбран неверно, от данной метрики следует отказаться и взять другую, которая будет отражать ситуацию в бизнесе с прогнозом на будущее.

Примеры правильных KPI для ИТ-сферы

Если мы говорим о приложениях, платформах и решениях, позволяющих компании или клиентам зарабатывать на их использовании, то одной из важных метрик будет Uptime — время работоспособности информационной системы или приложения.

Измеряется в процентах за квартал или за год. В зависимости от класса надежности приложения может иметь такие целевые показатели:

• 99.9% — за год (365 дней) приложение суммарно не работало чуть менее 9 часов;

• 99.5% — чуть менее двух дней;

• 99.0% — менее четырех дней.

Чтобы достичь такого KPI, ответственному за платформу менеджеру придется очень сильно потрудиться вместе со своей и соседними командами.

Есть еще несколько высокоуровневых KPI:

• сокращение финансовых расходов (в год) на поддержку приложения;

• выгода от перехода на новую платформу или технологию.

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

В KPI также включаются более технические или ИТ-процессные метрики.

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

Будем исходить из факта, что все айтишники умные и честолюбивые сотрудники. Следовательно, и метрики, помогающие компании и сотрудникам, тоже должны быть «умными».

Варианты таких KPI для разработчика (software developer):

Теперь приведу примеры KPI для тестировщика-автоматизатора (QA automation engineer):

И это только две роли из множества внутри ИТ-команды.

Если в проекте участвуют несколько подкоманд, для них можно применить дополнительную единую метрику: отзыв клиента/заказчика/конечных пользователей. Она позволит повысить общую заинтересованность в результате.

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

Итак, какие выводы можно сделать из всего вышесказанного.

Во-первых, без метрик можно стартовать, но выжить и развиваться сложно. Это малоэффективно и очень рискованно.

Во-вторых, правильно подобранные метрики несут пользу и улучшения, а неправильные — вред, отторжение и убытки.

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

В-четвертых, нет ничего постоянного. Нельзя цепляться за однажды сформированные KPI. Чтобы добиваться постоянной выгоды от их использования, их нужно регулярно «подкручивать».

Михаил Гедзберг, эксперт в области управления проектами Luxoft Training

Источник.