В главе 10 «Искусство создавать правила» мы обсудили семь возможных подходов к организации дорожного движения. Перенеся их на разработку ПО (и бизнес в целом) и расширив понятие дисциплины, включив в него компетенции, мы получаем семь методов развития компетенций в организациях. Первый из них будет исходным, а все остальные могут рассматриваться как резервные по отношению к каждому предыдущему методу в этом списке:
• Самодисциплина. Самодисциплина и самосовершенствование опираются на личную инициативу и желание сделать свое поведение продуктивным. Меня не надо убеждать, что на звонки и электронную почту следует отвечать в разумные сроки. Это тип поведения, которому я следую сейчас и намереваюсь следовать в будущем.
• Коучинг. Метод обучения с целью развить конкретные умения и типы поведения. Коуч может помочь овладеть правильными навыками работы с электронной почтой, и в результате полученные вами электронные сообщения не будут оставаться без ответа.
• Тестирование. Результаты тестирования подтверждают (или должны подтверждать), что кто-то проверил наличие у данного сотрудника необходимых умений и желания выполнять определенные функции – например, что данный сотрудник в состоянии поднять телефонную трубку и правильно набрать номер.
• Инструменты. Извещения и напоминания – это способ ориентировать людей на выполнение необходимых действий, удостоверяясь, что они знают, что именно им надо сделать. За час до того, как я сел писать этот раздел, я позвонил клиенту и отметил в своем ежедневнике это дело как выполненное. Я настроил систему, чтобы она напоминала мне о подобных важных делах.
• Коллеги. Давление со стороны коллег может заставить сотрудника изменить свое поведение в соответствии с нормами, принятыми в данной группе. Первый раз, когда кто-то заставляет меня ждать, я стараюсь войти в его положение и мягко напоминаю этому человеку, что все еще жду ответа. Во второй раз в тоне моего напоминания сквозит раздражение. Ну а в третий раз я просто скажу все, что я о нем думаю.
• Проверки. Задача проверок от лица менеджмента организации – убедиться, что люди должным образом выполняют свою работу. Например, в некоторых организациях было бы неплохо время от времени проверять, насколько своевременно и профессионально сотрудники реагируют на звонки и электронную почту.
• Менеджеры. Задачи менеджера – лидерство и управление. Менеджер должен подавать положительный пример, а также применять санкции в случае, если кто-то повел себя во вред интересам компании – например, полностью проигнорировал запрос от потенциального клиента, чем навредил репутации компании.
В организациях лучше всего применять все эти методы. Безусловно, в первую очередь развитие компетенций будет личной ответственностью сотрудников. Но, если сами они на это не способны, следует призвать на помощь соответствующий случаю коучинг. Если у вас нет коучей или они тоже некомпетентны, можно попробовать решить вопрос, применив комбинацию из тестирования, правильно настроенных инструментов и давления со стороны коллег. Наконец, если и это не работает, а в организации нет людей, способных профессионально проводить соответствующие проверки, или они тоже некомпетентны, в запасе всегда остается менеджер, который и будет (вполне оправданно) нести ответственность за непривлеченных клиентов.
А что если у менеджера тоже ничего не получается?
Если проблемы с компетентностью не решаются даже после того, как испробованы все эти методы, пострадают либо клиенты, либо топ-менеджмент (либо и те и другие).
Какое непосредственное отношение это имеет к профессиональному мастерству разработчиков?
Agile-манифест сам по себе – пример осознания, что одних манифестов недостаточно, чтобы решить проблемы с компетенциями в организациях, которые специализируются на разработке программного обеспечения.
Достижение профессионального мастерства разработчиками ПО – высокая цель, и с точки зрения программных документов движения за мастерство программирования она должна достигаться с помощью двух основных из перечисленных здесь подходов (самодисциплина и коучинг). В моем представлении профессиональное мастерство – это уже результат и свойство организаций, достигших компетентности.
Оптимизируйте систему в целом – на разных уровнях
В главе 4 «Информационно-инновационная система» обсуждалась проблема измерения (и даже вознаграждения) контрпродуктивных элементов внутри системы, приводящих к отрицательным побочным эффектам. В главе 9 «Настройка ограничений» мы говорили о трагедии общих ресурсов, а также о том, что в процессе самоорганизации система способна оптимизироваться только в своих собственных интересах; отсюда вытекает необходимость накладывать внешние ограничения на саму систему и направление, в котором она движется. В теории систем эти идеи обобщены в принципе субоптимизации
[59]:
Если каждая подсистема, рассматриваемая отдельно, функционирует максимально эффективно, то в результате система как целое не будет функционировать с максимальной эффективностью
[60].
Решение этой проблемы (и один из постулатов Lean-методов разработки ПО) – оптимизация системы как единого целого [Poppendieck 2007: 38]. Питер Друкер однажды сказал: «Что можно измерить, тем и управляют». Альтернативная формулировка того же тезиса звучит так: «Что вы измеряете, то и получите на выходе». Отсюда логически вытекает, что, если мы хотим оптимизировать целое, надо измерять целое. Таким образом, необходимо измерять систему в целом с начала до конца сверху вниз (и накладывать ограничения тоже на систему в целом), в противном случае ее неизмеряемые и неограниченные части самоорганизуются и сделают результаты целого субоптимальными.
Мне много раз на практике приходилось сталкиваться с проблемами, вызванными принципом субоптимизации. Начинаешь измерять превышение бюджета в рамках одной команды, а в результате получаешь жалобы от некоторых из ее членов, что они не виноваты в перерасходовании бюджета, потому что присоединились к проекту позже. Стоит заняться измерением некоторых профессиональных умений членов команды, как тут же поступают жалобы, что именно эти умения в данном случае не имеют никакого отношения к своевременной передаче продукта клиенту. Иногда начинало казаться, что единственным надежным показателем было количество жалоб на показатели, которые измерялись.
Эксперты по гибким методологиям уверены, что члены команд должны самоорганизовываться с целью оптимизировать результаты команды как единого целого, а не ее отдельных членов. Я с этим согласен. Но те же эксперты затем говорят, что измерять надо только эффективность команд в целом. Вот тут у меня другое мнение.
