Юрген Аппело - Agile-менеджмент. Лидерство и управление командами

В главе 4 «Информационно-инновационная система» обсуждалась проблема измерения (и даже вознаграждения) контрпродуктивных элементов внутри системы, приводящих к отрицательным побочным эффектам. В главе 9 «Настройка ограничений» мы говорили о трагедии общих ресурсов, а также о том, что в процессе самоорганизации система способна оптимизироваться только в своих собственных интересах; отсюда вытекает необходимость накладывать внешние ограничения на саму систему и направление, в котором она движется. В теории систем эти идеи обобщены в принципе субоптимизации [59]:

Если каждая подсистема, рассматриваемая отдельно, функционирует максимально эффективно, то в результате система как целое не будет функционировать с максимальной эффективностью [60].

Решение этой проблемы (и один из постулатов Lean-методов разработки ПО) – оптимизация системы как единого целого [Poppendieck 2007: 38]. Питер Друкер однажды сказал: «Что можно измерить, тем и управляют». Альтернативная формулировка того же тезиса звучит так: «Что вы измеряете, то и получите на выходе». Отсюда логически вытекает, что, если мы хотим оптимизировать целое, надо измерять целое. Таким образом, необходимо измерять систему в целом с начала до конца сверху вниз (и накладывать ограничения тоже на систему в целом), в противном случае ее неизмеряемые и неограниченные части самоорганизуются и сделают результаты целого субоптимальными.

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

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

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

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

Мы даже могли бы добавить это к Agile-манифесту в виде пятой ценности:

Предпочтение глобальных метрик локальным.

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

В главе 9 было показано, как традиционный треугольник ограниченийможно преобразовать в квадрат, чтобы не забыть об ограничениях, вводимых с целью обеспечения качества. Но с моей точки зрения, ни треугольник, ни квадрат не могут в полном объеме передать динамику сложных проектов по разработке ПО. Реальность иногда больше напоминает невозможный куб Эшера (рис. 11.1).