Перевод статьи Fernando Cuenca, размещённой на www.agileadvice.com.
Оригинал можно прочитать здесь.
Когда вас попросят предоставить показатели для оценки того, «насколько хорошо» идёт Agile-трансформация, сосредоточьте обсуждение вокруг измерения изменений в то, какое влияние IT-организация оказывает (или нет) на её бизнес-среду, и определите небольшой набор метрик «соответствия предназначению».
Неизбежный вопрос о показателях Agile-трансформации
Рано или поздно, когда IT-организация начнёт движение в сторону Agile-мышления и практик, кого-то попросят предоставить «веские доказательства» того, что усилия окупаются. Вывод будет заключаться в том, что метрики — это средство для удовлетворения этого запроса. Каковы же ваши метрики Agile-трансформации?
По моему опыту, такой запрос обычно приводит к обсуждению оценки конкретных Agile-инициатив, запущенных IT-организацией. В организациях, где упор идёт на инженерные дисциплины, такими метриками могут быть покрытие кода модульными тестами или время сборки интеграции. Если фокус был на командах и процессе, то в качестве выбора может появиться подсчёт количества команд, «преобразованных» в Scrum, или людей, отправленных на обучение Scrum Master.
Хоть эти измерения и могут быть полезными индикаторами в определённом контексте, но у них есть две проблемы. Во-первых, они сродни измерению производительности автомобильного двигателя, не глядя в окно: двигатель может работать хорошо, но если у машины нет колёс, то мы никуда не поедем. Что ещё более важно — эти цифры обычно бессмысленны для заинтересованных сторон бизнеса, которые обычно и просят их в первую очередь. Метрики Agile-трансформации должны быть значимыми для бизнеса.
Переосмысление вопроса о метриках Agile-трансформации
Усилия по Agile-трансформации могут быть очень дорогостоящими, поэтому законно спросить о результатах таких усилий. Однако, важно понимать, что этот вопрос на самом деле эквивалентен другому: «Увеличивает ли IT-организация влияние на свою бизнес-среду». Другими словами, заимствуя терминологию, используемую Канбан-сообществом: «становится ли IT-организация всё более и более соответствующей предназначению?» Ответ на этот вопрос, конечно, требует чёткого понимания того, чего бизнес ожидает от взаимодействия с IT.
IT-организацию можно рассматривать как организацию, предоставляющую клиентам различные сервисы. Возможно, если IT-специалисты решили каким-то образом «трансформироваться» (возможно, путём перехода к Agile-мышлению), они делают это, чтобы усилить своё влияние на этих клиентов. Поэтому это именно то, что нужно измерить, чтобы знать как происходит трансформация.
Некоторые из этих клиентов относятся к разным сферам деятельности организации (например, финансы или HR). Но это ещё не всё, потому что взаимодействие бизнеса с IT не имеет ценности само по себе. В конечном итоге бизнес использует IT, как способ оптимизации своей деятельности, чтобы предоставлять внешним клиентам более эффективные продукты и услуги. Более того, в наши дни IT — это прямой канал, через который эти продукты и услуги доставляются внешним клиентам (например, через веб-сайты и мобильные приложения). Таким образом, концепция «соответствия предназначению» IT-организации может быть расширена, чтобы учитывать соответствие предназначению бизнеса в отношении внешних клиентов, которых он намерен обслуживать.
Определение метрик «Agile» трансформации
Измерение «успеха Agile-трансформации» на самом деле означает измерение успеха взаимодействия между IT и бизнесом, а также между бизнесом и его внешними клиентами. Измерение внутренних процессов и практик, которые IT-компании внедряют в рамках этой «трансформации», не имеет значения. Это подразумевает, что начинать нужно с тщательного определения границ, которые покажут очертания этого взаимодействия (который мы хотим измерить). К примеру, соответствие предназначению внешнего клиента может иметь большее значение, чем IT-операции. Это необходимо учитывать при определении метрик Agile-трансформации, особенно, если позже мы будем делать выводы о причинно-следственных связях.
Определение метрик Agile-трансформации, конечно же, будет всегда лежать в неком контексте, потому что каждая бизнес-организация индивидуальна. Но тем не менее, мы можем снова позаимствовать у Канбан-сообщества некоторые общие рекомендации о том, что искать. Их идейные лидеры говорят о классификации показателей на 3 категории: показатели соответствия предназначению, показатели здоровья и драйверы улучшения. Используя эту структуру, когда мы говорим о «показателях Agile-трансформации», мы имеем в виду в основном первую категорию и, возможно, немного вторую. На их основе могут быть реализованы инициативы по улучшению, которые, возможно, будут управляться с помощью показателей, относящихся к третьей категории.
Показатель соответствия предназначению (также известный как KPI) — это показатель того, что нужно клиенту. Это ключевое различие: если показатель не является легко узнаваемым и значимым для клиента, то это не ключевой показатель эффективности. Другой ключевой характеристикой является то, что можно определить минимальный порог для его значения: если показатель опускается ниже порогового значения, бизнес ставит под угрозу отношения со своими клиентами (возможно, они уйдут, инициируют судебные иски и т. д.). Другими словами, бизнес больше не «соответствует предназначению». Затем мы можем измерить эффективность «Agile-трансформации», проанализировав, как значения KPI с течением времени сравниваются с соответствующими пороговыми значениями. Типичный KPI — это время доставки, которое измеряется с момента принятия и выполнения запроса клиента до момента его поставки в производство. Обычно, это хорошая метрика Agile-трансформации.
Индикаторы здоровья — это метрики, обращенные вовнутрь. На самом деле, клиенты не заботятся о них (или даже не понимают), но они показывают, как работает тот или иной аспект системы. Ключевой особенностью является то, что они не имеют прямого действия; они только предоставляют информацию, которую необходимо проанализировать и поместить в контекст. По мере изменения значения индикатора работоспособности мы можем сделать некоторые выводы о том, как работает система, или объяснить, почему что-то происходит (или нет), но это не обязательно ведёт к конкретным действиям. Яркий пример этого — подсчёт дефектов. Клиенты, безусловно, будут заботиться о качестве продукта, и мы можем сделать выводы об этом качестве, посмотрев, сколько у нас дефектов, но абсолютное количество дефектов не обязательно сделает продукт более или менее пригодным для использования. Может случиться так, что покупатели сочтут текущее качество «достаточно хорошим» независимо от количества дефектов.
Наконец, метрики драйвера улучшения — это показатели, которые используются для влияния на поведение по отношению к конкретному изменению. Их ключевая особенность в том, что они временные: мы устанавливаем для них цель, и как только цель достигнута, метрика больше не нужна. Причина этого связана с непреднамеренным поведением, которое метрика может стимулировать у людей, что может привести к локальной оптимизации метрики за счёт других аспектов, что приведёт к глобальной субоптимизации системы. Здесь примером может служить покрытие кода модульными тестами: если мы определили, что данный сервис не соответствует предназначению, и причина связана с плохим покрытием модульными тестами, то установка целевого показателя минимального покрытия может повлиять на разработчиков, чтобы они работали над добавлением тестов для изменения ситуации.