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

А что если у менеджера тоже ничего не получается?

Если проблемы с компетентностью не решаются даже после того, как испробованы все эти методы, пострадают либо клиенты, либо топ-менеджмент (либо и те и другие).

Какое непосредственное отношение это имеет к профессиональному мастерству разработчиков?

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

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

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

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

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

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

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

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