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

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

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

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

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

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

Но анализ проектов можно продолжить и далее. То, что некоторые называют «ресурсы», представляет собой комбинацию людей и инструментов, а люди и инструменты требуют разных менеджерских подходов. Более того, Алистер Коберн утверждает, что процесс – это дополнительное измерение и в первоначальной версии треугольника оно отсутствовало [Cockburn 2003]. А Джим Хайсмит модифицировал этот треугольник, добавив в качестве дополнительного измерения (бизнес-)ценность (и поменяв остальные ограничения местами) [Highsmith 2009: 21].

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

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

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

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

Роберт Каплан и Дэвид Нортон более десяти лет назад создали знаменитую методику управления параметрами системы, известную как сбалансированная система показателей [Kaplan, Norton 1996]. Я бы просто предложил менеджерам команд разработчиков заменить предложенный Капланом и Нортоном стандартный набор из пяти параметров (финансы, клиенты, бизнес-процессы, инновации и обучение) нашими семью, которые, с моей точки зрения, полезнее в проектах по разработке ПО.

Правильный выбор операционных показателей очень важен. Обучаясь в школе, занимаясь спортом или искусством, люди хотят знать, каковы их успехи. Они получают оценки за свои знания в математике, языках и географии; успехи в футболе, баскетболе и теннисе находят отражение в рейтингах; точно так же существуют рейтинги книг, пьес и телевизионных шоу. Если вы не знаете, чего вам уже удалось достичь, то невозможно проверить, улучшаются ли ваши результаты. Именно поэтому, сдав квалификационные экзамены Microsoft, люди хотят узнать, чем все закончилось. Именно поэтому они ставят сенсоры на кроссовки Nike и с помощью iPod отслеживают свои результаты в беге. По этой же причине я с нетерпением жду появления ваших оценок моей книги на Amazon.com.

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

• Делайте различие между профессиональными умениями и дисциплиной. В предыдущей главе мы обсуждали два критерия зрелости: профессиональные умения и дисциплину. Возможно, при оценке людей и команд вам стоит пользоваться этими критериями по отдельности. Это поможет наиболее квалифицированным сотрудникам (которые порой думают, что застрахованы от ошибок) не забывать о дисциплине. А людям, у которых с дисциплиной все хорошо, это поможет избежать самоуверенности («я прекрасно работаю, потому что выполняю все процедуры»). Несколько примеров показателей, позволяющих оценить состояние дисциплины: доска задач поддерживается в актуальном состоянии, совещания начинаются вовремя, покрытие кода тестами всегда превышает 95 %. И показатели, связанные с профессиональными умениями: отсутствие ошибок при сборке, в коде мало ошибок, демо всегда принимаются клиентом.