Оптимизируйте систему в целом — в разных измерениях

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

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

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

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

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

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

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

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