Метрики быстро становятся самым главным фактором измерения и управления производительностью в связи с целями организации. Однако организации вступают на опасный путь, если они не понимают до конца, что собой представляют и о чем действительно говорят метрики.

Управление производительностью и эффективностью процессов находится сегодня в фокусе внимания многих компаний. Независимо от того, как называть подобные практики - управлением производительностью предприятия, корпорации или же бизнеса (Business, Corporate или Enterprise Performance Management), - все они основаны на метриках, описывающих ход тех или иных процессов в компании. К сожалению, за массой используемых слов часто исчезает понимание того, что представляют собой метрики, каким образом они должны определяться и каким образом можно установить их уместность и полезность.

Метрики

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

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

Стандарты для точек отсчета бывают двух типов: внутренние и внешние. Внутренние точки отсчета устанавливают целевые значения, которые должны быть достигнуты в бизнес-процессах. Они представляют условия "как есть", но могут использоваться и для измерения прогресса в сторону желательного состояния "как должно быть".

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

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

Управление производительностью

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

Многие компании считают себя слишком занятыми текущими проблемами выживания, чтобы обращаться к "корневым" вопросам качества. "У нас нет времени для теоретических дискуссий", - заявляют они. Эти компании отказываются понять, что если они не сделают попытки вернуть себе контроль, то скоро не станет бизнеса, который нужно сохранять. Но внедрение подходов Six Sigma и других инициатив, связанных с качеством, просветили многие компании и позволили им снова контролировать свой бизнес. Основой их успеха явились метрики, обеспечивающие прозрачность течения бизнес-процессов. Метрики позволили обнаружить, идентифицировать и устранить основные причины: плохое качество, узкие места, дублирующие или конфликтующие процессы, ограничения и другие факторы. General Electric является примером того, какими экстраординарными могут быть результаты: компания получила почти 300%-ную прибыль от вложений благодаря инициативе Six Sigma, показавшей значение метрик для корпорации. Давление конкуренции, финансовой эффективности и усиливающегося регулирования заставляет компании выжимать все из своих процессов.

Соответствие и правильность

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

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

1. Соотнести метрику с теми целями, которых нужно достичь. Действительна ли связь? Имеет ли она смысл? Какие другие метрики соотносимы с данной целью?

2. Оценить каждый компонент составной метрики (функции, весовые значения, измерения) с точки зрения корректности и приемлемости. Если разложить составные метрики на компоненты, то будет видно, какие из них оказывают сильное влияние на данную метрику. Очень полезно проверить правильность компонентов во всех возможных сценариях. Если используются весовые значения, нужно проверить, нуждаются ли они со временем в корректировке. Если да, то когда в последний раз они корректировались, и какой процесс был использован, чтобы получить и подтвердить весовые значения? Документирован ли этот процесс?

3. Проверить качество и применимость всех входных данных для метрики . Так же, как анализ метрики, компонент за компонентом нужно оценить используемые входные данные. "Что посеешь - то и пожнешь" - эта пословица здесь актуальна как никогда. Несомненно, что это соображение должно также привести к анализу метрик, находящихся раньше по ходу процесса и генерирующих данные.

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

5. Выполнить анализы на чувствительность метрики. Оказывают ли входные данные линейное или экспоненциальное влияние на значение метрики? Влияют ли данные на весовые значения, присвоенные компонентам метрики? Повторяемы ли результаты?

Сначала может показаться, что некоторые из этих шагов повторяются. До какой-то степени это действительно так. Здесь важно понять, что качество метрики не ограничено одним шагом, оно важно на протяжении всего процесса. Анализ отдельной метрики должен осуществляться в контексте цепочки метрик для этого процесса.

Жизненный цикл метрик

Отдельно стоит сказать об изменениях метрик. Казалось бы, разработав и испытав метрику, зачем нужно постоянно подтверждать ее? Но ведь то, что справедливо сегодня, завтра может стать неуместным. Бизнес приспосабливается, а адаптация влияет на те предположения, на основе которых действует бизнес. Изменение в одной области будет иметь эффект на всем предприятии. Метрики, используемые в областях, в которых происходили изменения, окажут влияние на подчиненные метрики, используемые в других местах. Влияния могут чувствоваться либо не прямо - например, через метрику для процессов, находящихся ниже по течению, - либо непосредственно, когда результаты метрики служат ключевым компонентом в системе метрик.

Хорошая стратегия использования метрик - это использование концепции жизненного цикла метрик (MML - metrics management life-cycle). MML определяет процедуры и средства контроля в области анализа проектирования, разработки, мониторинга, корректировки/модификации и, наконец, отмены каждой метрики. Таким образом можно поддерживать соответствие и правильность метрики, быть уверенным, что индикаторы действительны и точны, а действия, предпринимаемые на основе метрик, правильны.

Выбор метрик

Просуммировав опыт нескольких проектов, можно привести некоторые универсальные рекомендации по выбору метрик внутри организации.

1. Стоимость метрики . Стоимость проекта выбора метрик часто игнорируется. Стоимость каждой метрики - это сумма издержек на постоянный сбор, компиляцию, хранение, обсуждение, анализ, управление и поддержку коллекции метрик и ее хранилища. Ожидаемая стоимость каждой метрики не только влияет на разработку первоначальной стратегии выбора метрик, но и остается важным фактором на протяжении всего цикла жизни метрик.

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

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

3. Поведенческие факторы . Задача метрик состоит в том, чтобы помочь найти ответы на вопросы типа "кто, что, где, когда (как часто), почему и как". Поэтому при определении системы измерений имеют большое значение конкретность и недвусмысленность, которые позволяют избежать манипулирования метриками с целью искажения результатов. Чем конкретнее будет указано, что является правильной и надежной метрикой, тем меньше гибкости будет для интерпретации результатов. Кроме того, эксперты дают ряд советов, как избежать поведенческих проблем.

Первый совет - использовать несколько метрик (две или более, комплиментарные по своему характеру) в отношении отдельного процесса. Это обеспечит контроль и баланс метрик. Примером может служить тройное ограничение по стоимости, времени и качеству в проектном управлении: нельзя воздействовать на одно из них, не задевая одновременно и два других.

Второй - применять метрики к процессу так, чтобы они отражали то, как воздействуют изменения подчиненных процессов на данный процесс. Например: "Процесс А нельзя повернуть назад во избежание затрат, не оказав отрицательного влияния на доступность материала в процессе В, находящемся ниже по течению. Это приведет к исключению процесса В".

Портфель метрик

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

Как правило, портфель метрик должен включать следующие атрибуты:

• имя метрики;
• контекст метрики, идентифицирующий группу, к которой относится данная метрика, - например, отдел, отделение или группу/рабочий центр (заметим, что некоторые метрики могут найти применение в нескольких контекстах);
• описание функциональности метрики;
• входная информация, процессы и данные, которые поступают непосредственно в метрику (включая те, что взяты из метрик, находящихся ранее по ходу процесса);
• формулы, описывающие внутренний процесс обработки, осуществляемый данной метрикой;
• выходные данные, информация, полученная в результате использования метрики, а также непосредственные нисходящие зависимости метрики.

Опыт показывает, что портфель метрик - это очень удобный способ работы с метриками. Когда предлагаются новые метрики, можно просмотреть портфель, чтобы проверить, не существует ли метрика в той же самой или подобной форме. Если она существует в идентичной форме, то понятно, что предлагаемая метрика - это всего лишь другое применение старой или другой контекст. И опять же необходимо гарантировать, чтобы метрики сохраняли свою независимость. Если предлагаемая метрика подобна уже существующей, то следует рассмотреть возможность объединения двух вариантов в одну метрику, которую впоследствии можно будет использовать в разных контекстах. Таким образом мы по возможности избежим появления дубликатов и близких вариантов. Бизнес приближается к тому, чтобы управление процессами и отчетность осуществлялись в реальном масштабе времени. По мере этого активная работа с портфелем метрик будет становиться все более важной для стандартизации, координирования и управления правильным использованием метрик на предприятии.

Проект по созданию метрик

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

1. Согласование определений . Без этого шага чрезвычайно трудно осуществлять связь между разными контекстами, используемыми на предприятии. Слово "определение" используется здесь в рамках бизнес-процессов и их атрибутов: метрика, измерение, объект (организационная единица, единица данных), деятельность, задача и т. п. Чтобы "согласовать" определение, необходимо идентифицировать контекст, в котором используется слово. Затем идентифицировать антонимы и синонимы и сделать эти определения совместными внутри контекста. Наконец, начать отражение в другие контексты. Таким образом, согласованными являются определения, данные словам или стандартизированным группам слов, которые делают их совместимыми или переводимыми из одного контекста в большое число других контекстов.

2. Разработка структуры и атрибутов портфеля или архива метрик . Это источник документации и определений метрик. Архив позволяет сохранять в базе данных историю измерений, что может оказаться важным впоследствии. Сохранение этой информации в центральном архиве, доступном для всех, позволяет обеспечить гарантии совместимости и достоверности метрик.

3. Моделирование бизнес-процессов . Это должно быть отдельным проектом, причем в нем метрикам уделяется мало внимания. Полученная модель будет критическим компонентом инфраструктуры, необходимой для идентификации и собирания соответствующих метрик. Независимо от того, будет ли использоваться методология IDEF1x, Business Process Management Initiative (BPMI) или что-то другое, процесс моделирования должен быть стандартным и формальным для всей организации. В противном случае - компанию ждет дорогостоящий трудный процесс отображения одной методологии в другую, и, скорее всего, провал усилий по созданию метрик.

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

5. Запуск пилотного проекта . Пилотный проект должен быть небольшим, но оказывать заметное влияние. Этот проект начнет формальный процесс разработки и использования метрик на предприятии и продемонстрирует их преимущества. Первым шагом пилотного проекта должно быть измерение текущего состояния характеристики процесса, с тем чтобы можно было показать эффективность программы использования метрик.

6. Разработка BI-политики . Портфель метрик может облегчить анализ данных на всем предприятии. Частью проекта по разработке метрик, как правило, является выявление наиболее эффективных методов, процессов и форматов для представления метрик пользователям всей организации. Именно поэтому разработка метрик обычно инициирует последующие BI-проекты.

CIO и метрики предприятия

Ясно, что получение метрики - это прямая функция информационных технологий. CIO хорошо осведомлены о том давлении, которое оказывается на их бизнес. Они понимают, что если ИТ-отдел не может удовлетворить потребность в создании метрик или слишком медленно принимает новые технологии, то CIO несдобровать. Вместе с тем создание метрик оказывает влияние на ИТ-инфраструктуру предприятия. Основных направлений два: время и ресурсы; квалификация.

1. Время и ресурсы . Прежде всего речь идет о затратах времени, связанных с созданием инфраструктуры и образованием портфеля метрик. ИТ-ресурсы играют важную роль в решении задач, связанных с метриками. Потребуются средства, а также персонал, чтобы собрать, объединить и представить информацию по метрикам для своей организации. Кроме того, как только метрики начнут вычисляться, пойдет поток запросов к базам данных предприятия. По мере накопления запросов возникают модели, указывающие на сходство типов запросов и поставляющих их групп. CIO должны будут организовать анализ этих запросов в рамках предприятия. Один из результатов - разработка повторно используемых компонентов для множества метрик с перекрещивающимися функциями.

2. Квалификация . Несмотря на то что IT-профессионалы должны неплохо разбираться в бизнесе компании, их основной интерес находится в сфере технологии. Они имеют общее представление о бизнесе и его экосистеме, но, как правило, их знания в области финансов, операций и в других специфических областях бизнеса недостаточно глубоки. Однако опыт показывает, что проект по созданию метрик предприятия ведет к повышению бизнес-квалификации CIO. Компании, которые реализовали в своих организациях принципы Six Sigma, повсеместно включали ИТ-менеджеров в проектные команды. И это вполне оправданно, ведь работа с метриками требует еще более тесной связи между ИТ и бизнесом. Это важно для достижения не только довольно общей цели - облегчения понимания ИТ-специалистами задач и стратегий бизнеса. Преследуется и более специфическая цель: более тесная привязка к задачам бизнеса поможет ИТ-специалистам приобрести основательные знания KPI-метрик (key performance indicator- ключевые показатели эффективности).

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

Очень часто во многих стартапах складывается такая ситуация: все работают, процесс создания идет успешно, а потом оказывается, что пользователей мало, и те, которые есть, недовольны Вашим продуктом. Эту ситуацию проходит много стартапов, и немаловажное значение для выхода из кризиса имеет настойчивость и упорство основателей, а также умение влиять на команду, поддерживая "боевой настрой". Но до такой ситуации можно и не доводить, если воспользоваться опытом предыдущих команд.

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

В английском языке есть слово "traction ". В переводе оно означает:

• тяга; тяговое усилие;
• поддержка, шансы на успех; ситуация, когда кто-то или что-то имеет своих сторонников.

Заметьте, что второе значение по смыслу связано с первым. Лидеру проекта нужно отслеживать "traction ". Его описывают, как значимую обратную связь от ваших клиентов. Одним из классических определений понятия "traction " в бизнесе является следующее: "quantitative evidence of market demand ", т.е. явное количественное доказательство того, что продукт или услуга, которые предлагает ваш стартап, на самом деле имеет спрос на рынке.

Проще говоря, это фактическое, притом массовое, а не единичное, подтверждение нужности конечному (целевому) потребителю создаваемого вами проекта.

Как измерять "traction "? Существуют разные метрики. Начнём с неправильных. Вот несколько примеров:

Чем плохи эти метрики? Это так называемые, "метрики тщеславия" - термин, введённый Эриком Райсом. Они хорошо влияют на наше самолюбие, но, по сути, ничем не отличаются от "лайков" в социальных сетях. Обратите внимание:

• эти метрики будут расти в любом случае;
• они не позволяют понять, что привело к изменению показателей, а, следовательно, не могут помочь стартаперам в принятии решений.

Правильные метрики должны быть точными. Они могут быть сравнительными (сравниваем показатель X1 с показателем X2) и/или относительными, т.е. выраженными в процентах. Ещё они должны быть понятны широкому кругу людей, по крайней мере - вашей команде. Исходя из методологии CDM ( Customer Development Methodology ) и Lean Startup, метрики должны влиять на поведение основателей стартапа, служить призывом к действию.

AARRR - Startup Metrics for Pirates

Теперь о правильных метриках. Дейв Маклюр, один из основателей акселератора-инкубатора (в портфолио около 450 компаний) стартапов "500 Startups", предложил систему метрик AARRR - Startup Metrics for Pirates.

AARRR - это аббревиатура, сформированная из названий стадий, через которые проходит пользователь в вашей воронке продаж:

• Acquisition (приобретение пользователей, их привлечение на ресурс). Это посетители вашего сайта, которые пришли из разных мест. Кто-то по рекламным каналам, кто-то через поиск, кто-то через ссылку в твиттере.
• Activation (активация). Посетителям понравился их первый визит. Они не закрыли сразу ваш сайт, они что-то на нем прочитали, поняли, в чем суть и совершили необходимое действие - подписались на рассылку, зарегистрировались, заказали обратный звонок и т.д.
• Retention (удержание). Ваши посетители возвращаются на ваш сайт, потому что он им чем-то нравится, и совершают там какие-либо действия.
• Referral (передача). Посетителям нравится ваш сайт настолько, что они рассказывают о нем, привлекая новых пользователей, которые в свою очередь тоже проходят стадию активации (это важно).
• Revenue (доход). Ваши посетители превратились в клиентов, которые платят вам деньги.

В разных источниках 4-ый и 5-ый этапы часто меняются местами. Это логично, т.к. в классической схеме продаж пользователи сначала становятся клиентами, а потом начинают говорить о продукте.

Теперь поговорим о каждом этапе более подробно.

Привлечение (Acquisition)

Первый этап. Люди приходят к вам из разных каналов: социальные сети, SEO (поисковая оптимизация, от англ. search engine optimization), SEM (поисковый маркетинг, от англ. search engine marketing), E-mail, блоги, контекстная реклама, офлайн (события не в онлайне), партнерские программы и прочие. Основной показатель - соотношение переходов на сайт и затраченных денег/просмотров рекламы.

Активация (Activation)

Пользователи попали на ваш сайт. Как понять, что произошла активация?

Пользователь:

• провел на сайте 10-30 и более секунд.
• посмотрел 2-3 и более страниц.
• сделал 3-5 кликов.
• воспользовался одной ключевой функцией.

Что может быть ключевой функцией или действием, которое считается активацией?

Для того, чтобы активация была успешна, требуется создавать множество "landing page" ("посадочных" страниц). В стартапах обычно используют от 4 до 16 "landing page", но можно и больше. После этого необходимо проводить A/B тестирование, т.е. делать разные страницы и отслеживать конверсию. Делать это нужно быстро.

Ключевые метрики данного этапа:

• Количество просмотренных страниц за визит.
• Время на сайте.
• Конверсия.

Невозможно управлять тем, что нельзя измерить. Эта фраза встречается во многих руководствах по управлению ИТ, да и по любому менеджменту. Невозможно управлять производством без измерительных приборов, позволяющих вовремя принимать правильные решения и реагировать на изменяющуюся ситуацию. Подразделение ИТ - то же производство, сравнимое по сложности со средним заводом, и для управления им нужны соответствующие инструменты. Метрики процессов - инструменты управления. От того, как будет выстроена система метрик, зависит, насколько эффективно руководитель сможет управлять организацией.

Разница между метриками и показателями

Прежде, чем двигаться дальше, договоримся о терминах. Метрика - измеримый параметр.Показатель - измеримый параметр достижения определенной цели. Для показателя должно быть определено целевое значение и желательная тенденция.

Классификация метрик

Деятельность любой ИТ организации можно разделить на три сегмента

• Сервисы
• Процессы
• Инфраструктура

Каждым из этих сегментов следует управлять и, следовательно, измерять.

Сервисные метрики

Показывают, как предоставляются наши сервисы. Эти метрики соответствуют параметрам сервисов согласованным в SLA. Именно изменение этих метрик в первую очередь чувствует на себе заказчик. Они формулируются в терминах, понятных заказчику, и должны коррелировать с субъективным восприятием заказчика.Примеры таких метрик: время формирования отчета, количество клиентов, обслуженных в единицу времени и т.д.Именно за значения сервисных метрик ИТ организация отвечает перед заказчиком.Очевидно, что значение сервисных метрик зависит как от работы процессов, так и инфраструктуры. Большое время простоя (сервисная метрика) может быть вызвано как избыточной загрузкой канала связи (технологическая метрика) так и недостаточной скоростью устранения инцидентов (процессная метрика).

Технологические метрики

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

Процессные метрики и их классификация

Процессные метрики показывают эффективность работы внутренних процессов ИТ организации.У любого процесса есть вход и выход, кроме того, процесс использует ресурсы и подвергается управляющим воздействиям.

Выстраивая систему метрик необходимо помнить об этих четырех составляющих и измерять каждую из них.Метрики входа - измеряют нагрузку на процесс. Например, для процесса управления инцидентами количество инцидентов - метрика входа. Важно, что для менеджера процесса метрики входа - показатель исключительно информационный, на них нельзя влиять, а можно только реагировать.Метрики выхода, или метрики результативности - показывают, насколько процесс достигает своей цели.Метрики ресурсов показывают загрузку и достаточность ресурсов, используемых процессом.Метрики управления показывают, насколько процесс управляем, эффективны управляющие воздействия.В CobiT предложена своя классификация метрик: показатели результативности, показатели управляемости. Кроме того, для каждого процесса предложена модель зрелости.Разложение метрик по четырем составляющим сопоставимо с классификацией метрик, предложенной в CobiT. Показатели результативности - метрики выхода, показатели рациональности - метрики ресурсов, зрелость процесса - метрика управляемости.Очевидно, что, планируя целевые значения для различных метрик, следует балансировать их между собой. Потому что процесс может быть очень результативен и совсем нерационален и наоборот. Например, мы можем устранять все инциденты за полчаса, силами тысячи человек, или же справляться десятком человек, но устранять инциденты за месяц.

Отчетность корректирующие меры

Показатели не интересны сами по себе, они нужны для осуществления управленческих воздействий на процесс. Следовательно, ответственность за достижение целевых показателей должна быть возложена на руководство процесса и на сотрудников, назначенных на роли в процесс.Должна быть выстроена система отчетности по показателям. Важно, чтобы на каждом уровне управления были представлены соответствующие показатели. Вряд ли директору по ИТ будет интересно анализировать статистику сбоев одного из дисковых массивов. Система отчетности должна быть выстроена таким образом, чтобы на каждом уровне, каждый менеджер контролировал и отвечал за 3-9 показателей. Большее количество трудно удерживать под постоянным контролем.

Вопросы мотивации

Зачастую показатели эффективности процесса используют для постановки личных целей и мотивации сотрудников. На первый взгляд, это логичное и правильное решение. Однако у человека, зарплата которого зависит от выполнения целевых значений, будет слишком велико искушение "подправить" показатели в свою пользу. Такая "правка" приводит к нарушению главного принципа использования показателей - объективности и достоверности, как если бы врач ставил диагноз и назначал лечение на основании неправильной информации о температуре пациента.Как этого избежать? Можно создать развитую службу внутреннего аудита, которая гарантировала бы актуальность показателей. Но, зачастую, затраты на содержание такой службы неоправданны. Однозначного рецепта тут нет. Приходится искать разумный баланс между доверием и контролем.

Выстраивание системы показателей ИТ

Процессы работают не в вакууме. Каждый процесс направлен на достижение определенной цели, связан с другими процессами и вносит свой вклад в предоставление сервисов. Цель каждому процессу должна ставиться исходя из того, какой аспект сервиса им поддерживается.Таким образом, первичны цели сервисов, параметры, зафиксированные в SLA. Цели процессов и показатели, их измеряющие, должны определяться путем декомпозиции этих параметров. Например, в SLA может быть зафиксирована целевая доступность сервиса. Очевидно, что на доступность сервиса влияют такие показатели как время устранения инцидентов, количество инцидентов, успешность проведения изменений и пр. Целевые значения этих показателей должны определяться из целевого значения доступности сервиса. Также понятно, что значимость каждого из этих показателей неодинакова и может меняться в зависимости от условий.Исходя из значимости каждого показателя ему должен быть присвоен соответствующий вес.Проведя декомпозицию на несколько ступеней, можно выстроить систему целей и показателей организации. Такая система предоставляет руководству организации инструмент оперативного контроля и быстрой диагностики, основу для принятия решений как на операционном, так и на тактическом и, даже, стратегическом уровне.

На основании чего строить систему показателей?

Чем же руководствоваться при построении системы измерений для ИТ процессов?В первую очередь, конечно, CobiT . В этой методологии предлагается процессная модель, состоящая из тридцати четырех процессов. Считается, что любая деятельности внутри организации ИТ может быть отнесена к одному из этих процессов. Для каждого процесса приведен набор показателей результативности и рациональности. Проблема в поверхностном и общем описании метрик. При использовании рекомендаций CobiT способы измерения целевые значения и алгоритмы расчета показателей придется продумывать самостоятельно.Что касается ITIL®, то он более конкретен. В нем можно найти достаточно подробный перечень показателей для каждого процесса со способами их измерения и желательными тенденциями. Однако, в ITIL®, как известно, описаны не все возможные процессы ИТ. Например, за показателями процесса Разработки ПО придется обращаться к другим источникам.В теме про измерения процессов невозможно не затронуть Карту Сбалансированных Показателей (BSC). Этот инструмент, изначально разработанный для управления предприятием, с успехом может быть применен для системы управления ИТ. Основной постулат BSC в том, что, выстраивая систему целей организации, опасно допустить перекос в ту или другую сторону. Например, уделять все внимание финансовой эффективности, не обращая внимания на лояльность клиентов или организацию внутренних процессов.То же верно и для ИТ. Например, перекос в сторону технологического аспекта инфраструктуры может привести к нарушению внутренних процессов или ухудшению взаимоотношений с заказчика. Вреден также и перекос в сервисный аспект. Таким образом, выстраивая систему целей и измерения ИТ, необходимо выделить несколько перспектив, которым уделять взвешенное внимание. Например, можно предложить такие перспективы:

• Сервисы
• Внутренние процессы
• Инфраструктура
• Финансы
• Персонал.

В каждом конкретном случае вес целей по этим перспективам может меняться. Можно также использовать другую систему перспектив.

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

Группа 1 - Требования к разрабатываемому ПО

Эта группа метрик позволит оценить, насколько мы проработали требования (user story) к ПО, определить уязвимые места и наиболее сложные, потенциально проблемные фичи ПО, понять, где требуется особый контроль:

1. Тестовое покрытие требования

Иными словами, это количество тестов на 1 требование.

Назначение метрики: выявить слабые места в тестовом покрытии, подсветить риски.

• Конечно, данная метрика будет работать, только если требования хорошо декомпозированы и более или менее равнозначные. Разумеется это не всегда возможно, но если получается сделать требования достаточно атомарными, то данная метрика покажет отклонение покрытия каждого требования от среднего уровня. Чем больше значение отличается от 1, тем меньше\больше тестов написано для одного требования, чем обычно.
• Важнее всего обратить внимание на требования, для которых коэффициент будет равен или близок к 0. Для них нужно рассмотреть возможность добавления тестов.
• Если требования не атомарные, то данная метрика позволит убедиться только в том, что для каждого требования есть хотя бы 1 тест. Для этого коэффициент всегда должен быть больше 1.

2. Степень взаимосвязанности требований

Метрика вычисляется как среднее количество связей каждого требования с остальными требованиями.

Назначение метрики: дать основание для оценки сроков тестирования и учета возможных рисков. Зная степень взаимного влияния требований друг на друга можно, например, запланировать дополнительное время и кейсы для сквозного тестирования, проработать регрессионные проверки, посмотреть в сторону интеграции и т.п.

• Значение этой метрики будет находиться от 0 до 1. 1 означает, что каждое требование связано с каждым, а 0 – что взаимосвязей нет.
• Тут сложно вводить какие-то ограничения для значений данного коэффициента, многое зависит от специфики функционала, архитектуры, технологий. Однако, по своему опыту могу сказать, что хорошо, когда степень связанности не превышает 0,2-0,3. В противном случае доработка в рамках одного из требований будет вести к цепочке изменений, а значит и возможных ошибок, в значительной части продукта.

3. Коэффициент стабильности требований

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

• Разумеется, полностью изолированного функционала не существует, но количество новых требований должно преобладать над изменяемыми а коэффициент желательно должен быть меньше 0,5. В этом случае мы внедряем новых фич в 2 раза больше, чем переделываем существующих.
• Если коэффициент выше 0,5, особенно если больше 1, то это скорее всего значит, что ранее мы сделали то, что оказалось ненужным. Команда фокусируется не на создании новых ценностей для бизнеса, а на переделывании ранее выпущенных фич.
• Также метрика дает представление о том, насколько легко масштабируется функционал системы, добавляются новые возможности.

Группа 2 - Качество разрабатываемого продукта

Как следует из названия, эта группа метрик демонстрирует качество ПО, а также и качество самой разработки.

1. Плотность дефектов

Вычисляется доля дефектов, приходящаяся на отдельный модуль в течение итерации или релиза.

Назначение метрики: подсветить, какая часть ПО является наиболее проблемной. Эта информация поможет при оценке и планировании работ с данным модулем а также при анализе рисков.

• Причины большого количества дефектов к каком-то одном конкретном модуле (коэффициент больше 0,3) могут быть различны: некачественные требования, квалификация разработчика, техническая сложность и т.д. В любом случае данная метрика сразу обратит наше внимание на проблемную зону.

2. Коэффициент регрессии

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

• Чем ближе коэффициент к 0, тем меньше было внесено ошибок в существующий функционал при реализации новых требований. Если значение больше 0,5, то мы больше половины времени тратим на восстановление работавших ранее функций ПО

3. Коэффициент повторно открытых дефектов

Назначение метрики: дать оценку качеству разработки и исправления дефектов, а также сложности продукта или отдельного модуля

• Эту метрику можно рассчитывать для всего ПО, отдельного модуля или функциональности. Чем полученное значение ближе к 0, тем меньше при разработке повторяются старые ошибки.
• Если коэффициент получился больше 0,2-0,3, это может говорить либо о технической сложности модуля и высокой связанности требований в нем, либо о корявой архитектуре, либо о том, что предыдущий фикс был сделан некачественно.

4. Средняя стоимость исправления дефекта

Отношение суммы затрат понесенных командой при работе со всеми дефектами (например, в рамках релиза) к общему числу дефектов.

Назначение метрики: показать как дорого нам обходиться обнаружение и исправление каждого дефекта. Это даст возможность посчитать выгоду от сокращения числа допускаемых ошибок, оценить целесообразность соответствующих техник.

• Каких-либо правильных значений тут конечно нет, все будет определяться спецификой конкретной ситуации

5. Количество дефектов в коде конкретного разработчика

Назначение метрики: подсветить возможные сложности в команде разработки, кому из специалистов не хватает опыта, знаний или времени, нужна помощь.

• Если, например, 50% всех дефектов приходиться на 1 разработчика, а всего в команде их 5, то тут явно есть проблема. Из этого не следует, что данный программист плохо работает, но сигнализирует обязательно разобраться в причинах подобной ситуации.
• Метрика помимо прочего может быть индикатором особенно сложного для разработки и поддержки модуля\функционала\системы.

Группа 3 – Возможности и эффективность команды QA

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

1. Скорость работы (velocity) команды QA

Рассчитывается как отношение реализованных story points (или требований, или user stories) за несколько, например, 4-5 итераций (Sprint) к количеству выбранных итераций.

Назначение метрики: численно выразить возможности, скорость работы команды для дальнейшего планирования объема работ и анализа трендов развития

• Метрика позволяет следить за скоростью работы QA, наблюдать за тем, какие внутренние процессы или внешние воздействия на команду могут на эту скорость повлиять.

2. Среднее время жизни дефекта

Общее время, в течение которого были открытыми дефекты, найденные в рамках итерации или релиза к сумме дефектов.

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

• Обычно время жизни дефекта, это все время от его создания (статус Created) до закрытия (Closed) за вычетом всех возможных Postponed и Hold. Любой баг-трекер позволяет рассчитать и выгрузить данную информацию для отдельного спринта или релиза.
• Также среднее время жизни дефекта можно рассчитывать для различных модулей и функций ПО, или, что самое интересное, отдельно для каждого из тестировщиков и разработчиков из команды. Так есть шанс выявить особенно сложные модули или слабое звено в команде ПО.

Группа 4 - Качество работы команды тестирования

Задача этого набора метрик оценить насколько качественно тестировщики выполняют свои задачи, определить уровень компетенций и зрелости команды QA. Обладая таким набором показателей можно сравнивать команду с ней же самой в разные моменты времени или с другими, внешними группами тестирования.

1. Эффективность тестов и тестовых наборов

Назначение метрики: показать как много ошибок в среднем позволяют обнаружить наши кейсы. Эта метрика отражает качество тест дизайна и помогает следить за тенденцией его изменения.

• Лучше всего рассчитывать данную метрику для всех наборов тестов: для отдельных групп функциональных проверок, регрессионного набора, Smoke тестирования и т.д.
• Данный показатель «убойности» тестов позволяет мониторить эффективность каждого из наборов, как она меняется с течением времени и дополнять их «свежими» тестами.

2. Коэффициент ошибок, пропущенных на продуктив

Кол-во ошибок обнаруженных после выпуска релиза \ общее кол-во ошибок в ПО обнаруженных в процессе тестирования и после выпуска

Назначение метрики: продемонстрировать качество тестирования и эффективность обнаружения ошибок - какая доля дефектов была отфильтрована, а какая прошла на продуктив.

• Допустимый процент ошибок, которые были пропущены на продуктив, конечно же будет зависеть от многих факторов. Однако, если коэффициент получился >0,1 – это плохо. Это значит, что каждый десятый дефект не был обнаружен во время тестирования и привел к проблемам в ПО, уже переданном пользователям.

3. Реальное время работы команды QA

Отношение времени потраченного командой непосредственно на QA активности к общему кололичеству часов.

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

• Целевые активности, это анализ, дизайн, оценки, тестирование, рабочие встречи и многое другое. Возможные побочные вещи - это простой из-за блокеров, проблемы в коммуникациях, недоступность ресурсов и т.п.
• Естественно, данный коэффициент никогда не будет равен 1. Практика показывает, что для эффективных команд он может составлять 0,5-0,6.

4. Точность оценки времени по областям\видам\типам работ

Назначение метрики: позволяет использовать поправочный коэффициент для последующих оценок.

• Степень точности оценки можно определить для всей команды или отдельных тестировщиков, для всей системы или отдельных модулей ПО.

5. Доля неподтвержденных (отклоненных) дефектов

Назначение метрики: показать сколько дефектов были заведены «вхолостую».

• Если доля дефектов, которые были отклонены превышает 20%, то в команде может наблюдаться рассинхронизация в понимании, что является дефектом, а что нет

Группа 5 - Обратная связь и удовлетворенность пользователей

И в заключение, группа метрик, показывающая, как продукт был принят конечными пользователями, насколько он соответствовал их ожиданиям. Но важна не только обратная связь о ПО: еще одна важная задача этой группы метрик - показать, удовлетворены ли пользователи процессом взаимодействия с командой ИТ в целом и QA в частности.

1. Удовлетворенность пользователей ИТ сервисом

Регулярный опрос удовлетворенности пользователей сервисом ИТ с выставлением баллов.

Назначение метрики: показать, доверяют ли пользователи команде ИТ, понимают ли, как и почему организована ее работа, насколько эта работа оправдывает ожидания.

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

2. Удовлетворенность пользователей продуктом

Регулярный опрос пользователей о том, насколько они удовлетворены продуктом.

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

• Для расчета этой метрики также проводим опрос пользователей и вычисляем средний балл. Рассчитывая такой показатель на регулярной основе (например, после каждого релиза) можно следить за трендом удовлетворенности пользователей.

3. Вовлеченность стейкхолдеров

Количество инициатив и предложений по улучшению процесса и продукта, поступивших в течение итерации (релиза) со стороны стейкхолдеров

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

У любого стартапа есть показатели, к которым стоит стремиться. Но метрики — только половина дела. Главное — достичь реального роста, а это, по словам Пола Грэма (Paul Graham), знаменитого эксперта по инвестициям и соучредителя Y Combinator, поразительно разносторонняя задача. К сожалению, многие компании, большие и малые, зачастую вовсе не отслеживают свой прогресс. В то время как выбор единого четкого ориентира и следование ему — один из важнейших аспектов успешного развития бизнеса.

К примеру, компания Shopify (которая, к слову, недавно вышла на IPO и была оценена в миллиард долларов) использует для этого настолько простую тактику, что удивительно, почему остальные компании не следуют её примеру. Каждую неделю они: а) рассылают членам команды электронные письма, позволяющие отследить ключевую метрику, и б) проводят совещание, чтобы обсудить результаты. Вот и все.

Тем не менее, за этими простыми действиями — целая философия, как управлять компанией, как распределять права и обязанности внутри команды, чтобы сплотить ее для достижения цели. Генеральный директор Shopify Тоби Литке (Tobi Lutke) называет это «мотором быстрорастущего многомиллионного бизнеса».

Выбор ключевых метрик

Современные инструменты оптимизации позволяют отслеживать и регулировать буквально сотни различных показателей. И многие бизнес-аналитики собирают массу данных, анализируют их, превращая в таблицы, диаграммы, графики. Это распространенная ошибка. Без четкого ориентира вы распыляете силы, тратите время в том числе на маловажные, а то и бесполезные метрики. А время в SaaS-бизнесе всегда играет против вас.

Сосредотачивая внимание на одном показателе, вы задаете своей команде единую цель, на достижение которой она и бросает все силы. Главное — выбрать правильную метрику, тогда и все остальное встанет на свои места.

Какой же должна быть эта правильная метрика?

Она должна отражать вашу основную задачу и усилия по ее достижению, а также иметь оптимальный интервал измерения.

1. Выбор стратегии

Это может показаться простым этапом, однако выбор направления часто сопряжен с необходимостью идти на компромиссы. К примеру, если вы решили делать ставку на удержание клиентов, то вынужденно «просядете» по части привлечения новых лидов, и наоборот. Так что выбор стратегии требует очень взвешенного подхода.

Как правило, на ранних этапах развития владельцы компании сосредотачиваются на росте (количества активных пользователей или ежемесячного дохода — MRR, Monthly Recurring Revenue).

Позднее фокус на развитие сохраняется, но при этом вы можете начать уделять все больше внимания увеличению пожизненной ценности клиентов (LTV, Lifetime Value), а также отслеживанию (MRR Churn). Однако, как правило, эти аспекты находятся в компетенции конкретных подразделений компании, поэтому сплотить вокруг них всю команду гораздо сложнее.

2. Постановка цели

Итак, вы определились, на какой конкретно показатель будете ориентироваться. Второй шаг — установить конкретные измеримые цели. К примеру, на ранней стадии стартапа это вполне может быть рост 5-7% в неделю, в то время как на более поздних этапах более разумно будет установить планку 3% в месяц. Здесь важно сохранять баланс: чтобы по-настоящему воодушевлять команду, цель должна быть достаточно амбициозной, но при этом достижимой.

3. Выбор интервала измерений

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

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

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

В недавнем исследовании, проведенном ProfitWell среди SaaS-клиентов, обнаружилось, что компании, которые делились информацией о своем финансовом росте с командой, росли на 34% быстрее, чем те, кто этого не делал.

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

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