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

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

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

• Тестирование.Результаты тестирования подтверждают (или должны подтверждать), что кто-то проверил наличие у данного сотрудника необходимых умений и желания выполнять определенные функции – например, что данный сотрудник в состоянии поднять телефонную трубку и правильно набрать номер.

• Инструменты.Извещения и напоминания – это способ ориентировать людей на выполнение необходимых действий, удостоверяясь, что они знают, что именно им надо сделать. За час до того, как я сел писать этот раздел, я позвонил клиенту и отметил в своем ежедневнике это дело как выполненное. Я настроил систему, чтобы она напоминала мне о подобных важных делах.

• Коллеги.Давление со стороны коллег может заставить сотрудника изменить свое поведение в соответствии с нормами, принятыми в данной группе. Первый раз, когда кто-то заставляет меня ждать, я стараюсь войти в его положение и мягко напоминаю этому человеку, что все еще жду ответа. Во второй раз в тоне моего напоминания сквозит раздражение. Ну а в третий раз я просто скажу все, что я о нем думаю.

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

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

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

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

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

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

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

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

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

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

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

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