Чем опасны метрики?
Эта статья — продолжение разговора о метриках, который был начат в прошлом номере, о силе метрик, связи метрик и SLA, а также о потребителе метрик. А сейчас поговорим о том, какими вообще бывают метрики, об эскалации и связанных с этим сложностях, и конечно, об автоматизации.
Метрики проекта, продукта и процесса
Вечная тема: проект, продукт и процесс. Не вдаваясь в теорию, важно помнить, что это три хоть и связанных, но разных по сути своей сущности. И метрики у них тоже будут разными. Очень важно помнить это, особенно при разработке и внедрении метрик. Потому что иначе есть риск не просто терминологической путаницы, а путаницы принципиальной, при которой параметр процесса, например, будет оцениваться на основании данных продукта, и т. д. Понятно, что оценка при помощи подобной системы будет мало того что далека от совершенства, она окажется недостоверной. Разумеется, могут возникать косвенные связи: качество продукта зависит от скорости процесса; контроль артефактов проекта оказывает влияние на скорость процесса и т. п. Но, как правило, такие взаимосвязи либо отсутствуют, либо строго индивидуальны.
Рассмотрим пример: есть некое ПО, выполняющее полезную функцию. Есть процесс разработки ПО в компании. И есть проект разработки именно этого ПО. Что мы оцениваем в проекте? В первую очередь соответствие фактических результатов планируемым. Если в плане стоит, что к 10 ноября должен выйти релиз с заявленной функциональностью, то в указанной дате контролируется наличие именно такого артефакта (а до этой даты, возможно, скорость приближения к цели; но о ней чуть позже). Причем метрики процесса разработки (наличие требований, соблюдение методики, постановка ПО в производство, собственно производство ПО, тестирование и т. д.) лишь косвенно пересекаются с метриками проекта. Точнее, они пересекаются в одном-единственном: надо начать процесс так, чтобы 10 ноября был гарантирован выпуск дистрибутива ПО. Что же касается метрик продукта, они также могут зависеть от метрик проекта и процесса, но не быть привязанными к ним. В частности, обеспечение определенных потребительских характеристик продукта закладывается в roadmap процесса, план проекта, но контроль этих характеристик выполняется при оценке продукта.
Про пороги и эскалацию
Вообще, метрики — это достаточно универсальный инструмент, который служит не только для статистики и управления процессом в целом, но и для «спрямления» движения процесса «здесь и сейчас», для каждой его итерации. Предположим, в ходе некоего процесса в одном из узлов возник сбой. Он может быть либо вычислен «в моменте» (не было реакции в течение определенного времени), либо фигурировать в статистике (скажем, в течение суток не было реакции в определенных узлах процесса). Такие сигналы — повод для организации воздействия, перевода процесса на альтернативную ветку, например для эскалации. Причем эскалация эскалации рознь. В том смысле, что единичное отклонение можно эскалировать на начальника отдела, а систематическое — на руководителя более высокого ранга. Но это как пример, на самом деле эскалация по пороговым условиям может быть и многоступенчатой: при единичном событии — на начальника отдела, при повторении — на его начальника, при систематическом повторении — на заместителя директора и т. д. Вообще, выстраивание такой системы может потенциально принести достаточно большие дивиденды с точки зрения как организации процесса, так и упорядочивания деятельности в целом. Но как и всё, что связано с метриками, организация подобных «мостов» требует времени, статистики и тренировок. Ну и конечно же, софта, «заточенного» под меняющиеся условия.
Еще один момент, который нужно обязательно упомянуть, говоря о метриках, — динамика изменений во времени. Метрика сама по себе — это фиксация некоего состояния во времени. Зачастую много полезной информации можно получить, анализируя тренды, — к примеру, на определенном узле процесса значение метрики растет в течение часа. И хотя пороговое значение не наступило ни в одном случае, это повод для того, чтобы применить эскалацию: возможно, через какое-то время рост показателя перейдет в активную фазу и тогда простые решения, которые можно было бы использовать при возникновении тренда, просто не сработают.
Слабости и сложности
Слабость метрик в какой-то степени противоположна их силе и проявляется в основном в недостаточном их «тюнинге», провоцирующем «работу ради работы». Всё просто: достаточно изменить отношение к метрикам (рассматривать их не как организационный инструмент, а как возможность для решения личных вопросов) и они становятся тормозом на пути развития. «Если говорить с формальной точки зрения, показатели были выполнены», — не знаю, как вас, коллеги, а меня подобные фразы всегда заставляют внутренне напрячься.
Типичная ошибка при разработке метрик — недостаточный анализ или выбор такого среза, при котором анализируются неосновные параметры рассматриваемого процесса. Скажем, в процессе технической поддержки пользователю гарантируется, что решение его вопроса будет выдано в течение 24 часов. При этом метрики настроены именно на данный показатель — без промежуточных фаз. В итоге получается, что внешне вроде бы метрика перекрывает SLA, а по факту (в случае массового нарушения SLA) информации о причинах такого нарушения не будет. Потребуется «деятельность в ручном режиме», то есть не на предвосхищение, а по факту, что перечеркивает весь смысл работы с метриками.
Еще одна ошибка — слишком много метрик на объект. На первый взгляд «ничего такого» тут нет, есть и есть. Ловушка в том, что анализ по многочисленным параметрам, во-первых, гораздо сложнее, а во-вторых, далеко не всегда оправдан: возникает риск не увидеть главного. Кроме того, многопараметрический анализ требует в том числе больше ресурсов, что, в свою очередь, приводит к увеличению стоимости работы с метриками и в целом — как это ни парадоксально — к снижению эффективности. Таким образом, получается, что при больших затратах может «на выходе» получиться меньшая эффективность.
Теперь о сложностях. Основная из них — пресловутый человеческий фактор. Метрики могут быть сколь угодно эффективны, но дружное бойкотирование или намеренное искажение информации запросто поставит крест на любом начинании. Соответственно, этот фактор нужно учитывать как при проектировании, так и при эксплуатации метрик. Далее, система работы с метриками должна быть выстроена так, чтобы по возможности исключить манипуляции показателями. Не секрет, что при получении любых измеримых параметров большинство сотрудников постарается сделать всё, чтобы «соответствовать любой ценой», в том числе и в ущерб процессу, уровню сервиса и т. д. Соответственно, при проектировании метрик необходимо проводить их стресс-тестирование, то есть постараться поставить себя на место сотрудников, которые будут вовлечены в процесс, и представить себе механизмы обхода. И проводить проектирование так, чтобы выявленными уязвимостями было либо невозможно, либо чрезвычайно сложно воспользоваться. Или как вариант — чтобы информация об «особо отличившихся» сразу бы доводилась до руководства.
Остальные сложности менее заметны и, как правило, не имеют столь серьезных последствий. Потому что, как говорит один мой коллега, «починить можно любой сервер, настроить любой софт, а вот с человеческим мозгом всё гораздо сложнее: его настройки формируются годами и прошиваются намертво».
Про автоматизацию
Последнее, о чем нужно сказать, рассуждая о метриках, о ПО - про автоматизацию работы с ними. Я не стану называть конкретных вендоров и конкретное ПО, перечислю лишь существенные, с моей точки зрения, требования, которые должны быть реализованы в хорошем ПО управления метриками:
- ПО должно поддерживать работу с метриками различных объектов (процесса, проекта, продукта);
- ПО должно иметь возможность анализировать как метрики, так и тренды по их изменению;
- ПО должно иметь возможность работы с гибко настраиваемыми оповещениями;
- ПО должно иметь возможность онлайн-импорта метрик;
- ПО должно иметь возможность как выводить заранее определенные отчеты, так и строить и сохранять новые, по запросу пользователя;
- В идеальном варианте — ПО должно уметь экспортировать задачи эскалации в систему управления задачами.
По сути, если разобраться, никакого специализированного ПО по работе с метриками может и не быть: достаточно поставить мощный генератор отчетов (таких на рынке довольно много), с расширенными возможностями, определить состав метрик, роли... И, как говорится, поехали.
В финале
Работа с метриками — это всего лишь один из инструментов контроля и управления. И проектируя метрики, важно не упускать суть самой работы — того, что производилось и производится каждый день. Метрики — вспомогательный по отношению к основной деятельности инструмент, тонкий тюнинг деятельности. Не стоит ставить их во главу угла — иначе в один прекрасный момент может оказаться, что показатели важнее реального эффекта.
Опубликовано 27.04.2016