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

Дон Маркис, американский юморист,

журналист и писатель (1878–1937)

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

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

Но разве эти модели не ориентированы на результат? Да, утверждается, что модели зрелости управления проектами нейтральны с процессной точки зрения, и это хорошо. Но основная идея таких моделей состоит в том, что способность систематически достигать необходимого уровня качества базируется именно на применяемых процессах (независимо от характера этих процессов). Объектом измерения при этом будет способность организации внедрять и применять эффективные процессы — а не ее способность проявлять инновационность и адаптивность в сложной среде.

Хотя в основе таких моделей лежат благие намерения, многие из них механистичны и… неизменно игнорируют тот факт, что единственной убедительной причиной, почему компании вообще совершенствуют производственные процессы, будет стремление повысить свою способность создавать ценность для клиентов и акционеров. Соответственно, многие из таких «процессно-ориентированных моделей зрелости проектов» не принимают во внимание в явном виде следующие две фундаментальные реалии: 1) организации — это одновременно не только сложные бизнес-системы, но и сложные социальные системы; 2) образцовое управление бизнес-процессами требует от лидеров способности сотрудничать друг с другом, в том числе и с точки зрения кросс-функциональности.

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

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

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

Если перефразировать Роберта Мартина, «рассуждают о своей зрелости подростки, а не взрослые».

Семь методов развития компетенций

Работая над составлением плана своих выступлений на различных конференциях, я однажды решил воспользоваться услугами профессионального агента. Я отправил ему по электронной почте описание своей квалификации, историю моих уже состоявшихся выступлений на конференциях в Европе и США, информацию о книге, которую писал, а также возможности взаимодействия. Я прождал три недели, но ответа так и не получил. Затем я отправил напоминание и моментально получил ответ с извинениями и с обещанием позвонить на следующий же день. Я продолжал ждать… Через три дня я отказался от своего намерения нанять этого человека в качестве своего агента.

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

• Самодисциплина. Самодисциплина и самосовершенствование опираются на личную инициативу и желание сделать свое поведение продуктивным. Меня не надо убеждать, что на звонки и электронную почту следует отвечать в разумные сроки. Это тип поведения, которому я следую сейчас и намереваюсь следовать в будущем.
• Коучинг. Метод обучения с целью развить конкретные умения и типы поведения. Коуч может помочь овладеть правильными навыками работы с электронной почтой, и в результате полученные вами электронные сообщения не будут оставаться без ответа.
• Тестирование. Результаты тестирования подтверждают (или должны подтверждать), что кто-то проверил наличие у данного сотрудника необходимых умений и желания выполнять определенные функции — например, что данный сотрудник в состоянии поднять телефонную трубку и правильно набрать номер.
• Инструменты. Извещения и напоминания — это способ ориентировать людей на выполнение необходимых действий, удостоверяясь, что они знают, что именно им надо сделать. За час до того, как я сел писать этот раздел, я позвонил клиенту и отметил в своем ежедневнике это дело как выполненное. Я настроил систему, чтобы она напоминала мне о подобных важных делах.
• Коллеги. Давление со стороны коллег может заставить сотрудника изменить свое поведение в соответствии с нормами, принятыми в данной группе. Первый раз, когда кто-то заставляет меня ждать, я стараюсь войти в его положение и мягко напоминаю этому человеку, что все еще жду ответа. Во второй раз в тоне моего напоминания сквозит раздражение. Ну а в третий раз я просто скажу все, что я о нем думаю.
• Проверки. Задача проверок от лица менеджмента организации — убедиться, что люди должным образом выполняют свою работу. Например, в некоторых организациях было бы неплохо время от времени проверять, насколько своевременно и профессионально сотрудники реагируют на звонки и электронную почту.
• Менеджеры. Задачи менеджера — лидерство и управление. Менеджер должен подавать положительный пример, а также применять санкции в случае, если кто-то повел себя во вред интересам компании — например, полностью проигнорировал запрос от потенциального клиента, чем навредил репутации компании.

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

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

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

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

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

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

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

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

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

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

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

Предпочтение глобальных метрик локальным.

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

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

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

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

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

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

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

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

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

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

Советы при выборе операционных показателей

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

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

• Делайте различие между профессиональными умениями и дисциплиной. В предыдущей главе мы обсуждали два критерия зрелости: профессиональные умения и дисциплину. Возможно, при оценке людей и команд вам стоит пользоваться этими критериями по отдельности. Это поможет наиболее квалифицированным сотрудникам (которые порой думают, что застрахованы от ошибок) не забывать о дисциплине. А людям, у которых с дисциплиной все хорошо, это поможет избежать самоуверенности («я прекрасно работаю, потому что выполняю все процедуры»). Несколько примеров показателей, позволяющих оценить состояние дисциплины: доска задач поддерживается в актуальном состоянии, совещания начинаются вовремя, покрытие кода тестами всегда превышает 95%. И показатели, связанные с профессиональными умениями: отсутствие ошибок при сборке, в коде мало ошибок, демо всегда принимаются клиентом.
• Не составляйте рейтингов знаний или опыта. В моем представлении знания и опыт — необходимые условия профессионализма и дисциплины, но измерять их было бы странно. Знания и опыт описывают состояние человека. Профессионализм и дисциплина напрямую связаны с результатами. Писатель попадает в рейтинги не потому, что он писатель. В рейтинги он попадает благодаря изданным книгам. В вашей компании никто не должен получать высокие рейтинги за знания и опыт, ведь такой человек вполне может проводить свое рабочее время за компьютерными играми.
• Выставляйте одновременно рейтинги по нескольким видам деятельности. У каждого из нас есть дела, с которыми ему удается справляться лучше, чем с другими. Гораздо легче пережить унижение, получив низкий рейтинг по одному виду деятельности, если одновременно получен высокий рейтинг по другому. Точно так же сотрудники легче воспринимают критику, если ее компенсировать похвалой за какие-либо достижения в другой области. Одновременные рейтинги по нескольким видам деятельности дают возможность быть более справедливым к людям. Должны быть рейтинги, отражающие качество релиза и его своевременность, степень удовлетворенности клиента и экономию затрат при реализации проекта, соблюдение принятых в компании стандартов и проявленную командой гибкость.
• Оценивайте несколько попыток. Один из моих учителей в средней школе практиковал систему, при которой он ставил ученику не менее десяти оценок в год. Но выводя итоговую, не принимал во внимание самые низкие из них, потому что «у всех нас бывают неудачные дни». Люди в целом предпочитают иметь возможность быть оцененными за какой-либо вид деятельности несколько раз. Нужно давать им шанс в следующий раз сделать лучше. Поэтому должны быть рейтинги за каждый завершенный проект и за каждый релиз продукта.
• По возможности всегда используйте относительные рейтинги. Сравнивайте актуальные результаты команды с предыдущими («в этот раз на 15% лучше, чем было»); с результатами других команд в вашей организации («на 20% хуже, чем у коллег, которые занимаются проектом X») либо с другими компаниями («наши дела обстоят на 32% лучше, чем в компании B»). Относительные показатели стимулируют команды от раза к разу повышать свою производительность, вместо того чтобы однократно достичь цели и застыть в этой точке [Highsmith 2009: 353].
• Цикл обратной связи должен быть предельно быстрым. Не должно быть большого разрыва во времени между действием и получением обратной связи в виде рейтинга или другого показателя. Это одна из причин, почему я стал вести блог до того, как начал писать эту книгу. Мне нужна была моментальная обратная связь от читателей, чтобы научиться писать лучше. Только через полтора года я почувствовал достаточную уверенность, чтобы начать писать книгу — как известно, у книг цикл обратной связи занимает гораздо больше времени.
• Используйте как опережающие, так и запаздывающие параметры. Изменения в опережающих параметрах позволяют понять, какова вероятность, что вы достигнете поставленной цели. (Пример: увеличение покрытия кода тестами может свидетельствовать о более высоком качестве продукта.) Запаздывающие параметры показывают (уже после завершения проекта), удалось ли вам достичь своих целей. (Пример: низкое количество жалоб от клиентов на ошибки уже после релиза подтверждает качество продукта.) В целом рекомендуется пользоваться обоими типами параметров [Cohn 2009: 440].
• Никогда не составляйте рейтинги сами. Ценность вашего мнения как менеджера для членов команды очень и очень низка. Пусть все и любые рейтинги — не важно, количественные или качественные — составляются не вами. Вы можете приносить благую весть, но не быть ее автором. Будьте судьей, а не прокурором.

Говоря о судьях… Признаю себя виновным (в который раз). Как и многие другие наивные менеджеры в этом мире, я виновен в том, что раз в год лично составлял индивидуальные и командные рейтинги по пятибалльной шкале. Сейчас я об этом жалею. Я считаю, что рейтинги должны составляться многократно, по разным видам деятельности и как можно оперативнее. И не мной. Пусть мир знает, что я раскаиваюсь. Больше этого не повторится.

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

Четыре ингредиента саморазвития

Мне нужно писать книгу. Но иногда совершенно нет настроения. Я бы с бóльшим удовольствием почитал свои любимые романы. Но все равно я сажусь и пишу.

Почему?

Это называется самодисциплиной.

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

Исследования говорят о том, что у студентов самодисциплина в два раза сильнее влияет на результаты выпускных экзаменов, чем IQ. Есть основания полагать, что количество прилагаемых усилий при овладении компетенциями важнее, чем талант [Jensen 2006].

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

1. Все начинается с осознания важности задачи. Если вы не понимаете, в чем состоит ценность того, что надо сделать, вы никогда не сможете приступить к конкретному делу (и продолжить им заниматься). (Я знаю, что очень важно заниматься спортом, не запускать свои финансовые дела и готовить еду, поэтому с этим у меня нет никаких проблем.)
2. Требуются базовые навыки тайм-менеджмента. Если вам не удается найти в своем графике время для важных дел, то вы их не сделаете. (Мне трудно находить время на занятия спортом. Всегда кажется, что чтение и работа над книгой важнее.)
3. Если с пониманием важности задачи и тайм-менеджментом все в порядке, необходимо не забыть конкретное дело. (Я могу очень легко найти время в своем графике, чтобы разобраться с личными финансами, но часто просто забываю об этом. А через месяц уже очень трудно понять, куда же подевались все деньги.)
4. И самое трудное — люди должны быть мотивированы. Нет мотивации, нет и дисциплины. (К счастью, я никогда не забываю, что мне, например, надо поесть. Но когда я один, отсутствует мотивация готовить. Я просто не мотивирован готовить еду только для себя. Поэтому благодаря мне несколько ресторанов с доставкой еды на дом хорошо зарабатывают. И тут мне становится понятно, на что уходят все мои деньги…)

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

1. Помогайте людям осознать важность решаемых задач. Объясните им, что рефакторинг очень важен. Что важен правильно поставленный контроль версий кода. Что важно личное общение. Если вы хорошо справитесь с этим, то решите первые 20% проблем с дисциплиной.
2. Обучите сотрудников базовым навыкам тайм-менеджмента. Объясните им, чем важность отличается от срочности. Покажите им, как резервировать время для повторяющихся действий и как составлять расписание. Если они в состоянии каждый день чистить зубы, чтобы избавляться от микробов, то почему не могут каждый день проводить проверку написанного ими кода на предмет ошибок? Научив их тайм-менеджменту, вы решите вторые 20% проблем с дисциплиной.
3. Обучите сотрудников приемам, которые позволяют не забывать важные дела. Покажите им, как создавать напоминания и превратить составление плана на каждый день в привычку. Также могут помочь методы повышения личной эффективности, описанные в книгах «Как привести дела в порядок» Дэвида Аллена [Allen 2003] и «Личный канбан» Джима Бенсона. Так вы решите еще 20% проблем с дисциплиной.
4. Покажите людям, как сделать их работу более интересной. Крис Спануоло отмечает, что удовольствие от работы — критически важный компонент мотивации [Spagnuolo 2008]. Это также одна из основных тем бестселлера «Ловись, рыбка!» [Lundin 2000]. Люди лучше мотивированы, если они в состоянии получать удовольствие даже при выполнении рутинных задач. Этим способом можно решить очередные 20% проблем с дисциплиной.

Все это в сумме дает 80%. А что с остальными 20%?

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

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

Вот так мне и удалось завершить эту главу, хотя очень хотелось почитать книгу Стивена Эриксона. Но для меня было важно качественно написать очередную главу. Поэтому организовал свои дела так, чтобы у меня было на это время. Я меня есть чек-лист, который гарантирует, что я не забуду сделать автоматическую проверку правописания, перепроверить примечания и ссылки, вставить уведомления об авторских правах и создать версию в PDF. Размещая посты в Twitter о своих усилиях в качестве автора, рисуя иллюстрации и форматируя главы, чтобы текст выглядел привлекательно, я мотивирую себя, поскольку все это позволяет получать от работы удовольствие.

Я также надеюсь, что мне удалось кого-нибудь вдохновить своим примером.

Менеджмент, коучинг, менторинг

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

Похоже, что руководители должны стать еще и персональными коучами:

Часть обязанностей менеджера — коучинг своих подчиненных. Это повышает их квалификацию и эффективность. Коучинг может фокусироваться на развитии либо навыков межличностного общения, либо чисто технических умений, необходимых в работе. <…> Вы можете провести коучинг сотрудника, у которого есть определенные проблемы с эффективностью, или же поработать над развитием у него новых умений и навыков.

Но есть и другие варианты…

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

В качестве линейного менеджера вы действительно обязаны обеспечить коучинг тем, кто в этом нуждается. Но совсем необязательно заниматься этим лично! Вы можете делегировать эту обязанность наиболее опытным сотрудникам, поручив им коучинг более молодых коллег с целью развить их профессиональные умения. В предыдущие столетия мастера в каком-нибудь ремесле поручали учеников своим подмастерьям. Зачастую подмастерья справлялись с коучингом лучше самих мастеров [Snowden 2010a]. На этом основании иногда возникают рекомендации использовать коучинг в основном при работе на начальных уровнях компетенций, например со стажерами [Hunt 2008: 31].

У каждого сотрудника в компании только один руководитель, но у него может быть ноль, один или даже несколько коучей для личного развития в разных областях. Вам даже не нужно быть коучем для самых опытных сотрудников. Можно делегировать и это, наняв консультанта со стороны. Вы все еще будете руководителем для всех своих подчиненных, сэкономите кучу времени, да еще и расширите полномочия некоторых сотрудников, назначив их коучами (если у них есть для этого данные) — и все это одновременно! А если в компании нет хороших коучей, вам следует их либо нанять, либо обучить [Adkins 2010].

Тема ответственности руководителей за коучинг сотрудников часто поднимается в литературе по менеджменту. Мне кажется, это заблуждение, возникшее из традиционного иерархического мышления, где подразумевается, что руководители по определению компетентнее своих подчиненных (часто это становится основной причиной продвижения по служебной лестнице). Но с точки зрения сложных систем это ерунда. Топ-менеджеры не могут быть супергероями. Руководителям так же свойственно ошибаться, как и их подчиненным. (Или даже еще сильнее, поскольку ставки выше.) Единственное, в чем вам надо хорошо разбираться, это какие именно люди внутри или вне организации могут стать хорошими коучами, способными обучить ваших сотрудников необходимым компетенциям. Мэри и Том Поппендик называют их лидерами компетенций, чья функция — устанавливать стандарты и обучать людей:

Что делают лидеры компетенций? Их первостепенная задача — совершенствование технологий, применяемых организацией. Они начинают с того, что устанавливают критерии качественной разработки ПО с точки зрения архитектуры, внедрения защищенных от ошибок ревью кода, поэтапной эволюции и технической компетентности. <…> Они устанавливают стандарты, настаивают на ясности кода, требуют, чтобы кроме задачи выявления ошибок обзоры кода ставили перед собой цели обучения <…> Вероятно, самая важная роль лидера компетенций — роль учителя, который целенаправленно развивает практики, приводящие к высокому уровню технической компетентности. <…> Лидеры компетенций часто бывают линейными менеджерами, но линейные менеджеры не всегда становятся лидерами компетенций.

Здесь уместно дать один совет тем, кто ищет для себя ментора. Ментор — это нечто совершенно иное, чем коуч, хотя эти слова часто используют как синонимы. Ментор помогает человеку управлять своей жизнью или строить карьеру, при этом у него нет личной повестки дня, кроме интересов своего подопечного. Напротив, коуч имеет дело с задачами и обязанностями конкретного сотрудника, у него своя программа или методы обучения, и он сосредоточен на повышении эффективности своего подопечного [Starcevich 2009]. Будучи менеджером, вы можете назначить коуча кому-либо из сотрудников, но никакого отношения к выбору ментора вы иметь не можете. Менторы похожи на любовников и любовниц. Всегда очень интересно узнать, есть ли они у ваших сотрудников, но в целом вас это совершенно не касается.

Подумайте о сертификации сотрудников

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

Кажется, что сертификаты мало влияют на способности человека. Мой друг Руди, специалист по организации дорожного движения, полагает, что выдача голландских водительских удостоверений — наименее важный фактор в обеспечении безопасности движения, причем Голландия — одна из самых безопасных в этом отношении стран. Главный фактор, влияющий на (относительную) безопасность дорожного движения в Голландии, — культура населения, а не наличие водительских прав.

Точно такая же проблема у нас и с разработкой ПО, и с управлением проектами.

Сертификация Project Management Professional (PMP), проводимая Институтом управления проектами, вроде бы предъявляет очень серьезные требования — от претендентов требуется изучить обширный материал, иметь определенный практический опыт и тому подобное. Однако вынужден констатировать, что, хотя мне и приходилось встречать хороших сертифицированных проектных менеджеров, диплом PMP также имели и худшие сотрудники, которых мне когда-либо приходилось видеть. Им вообще нельзя было поручать никаких проектов. Именно они больше всех кичились своей сертификацией, при этом меньше других осознавали ограниченность своих возможностей. Аббревиатура PMP точно не означает «минимально приемлемый уровень компетентности».

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

Кевин Келли отмечает, что знания распределяются крайне неравномерно и в нашем мозгу небольшие участки знаний перемежаются огромными пустырями невежества [Kelly 1994: 454]. Сертификат может быть способом заставить эти пустыри плодоносить. В сочетании с личным коучем, давлением со стороны группы, правильно подобранными инструментами, некоторой степенью контроля и компетентным менеджментом сертификат окупится многократно.

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

Используйте силу социального давления

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

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

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

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

1. Социальное давление работает только в тех случаях, когда люди хотят ощущать принадлежность к данной группе. Это значит, что как менеджер вы должны способствовать формированию (или развитию) команд. Не создавайте один большой пул разработчиков, где никто не знает друг друга по имени, а разбейте его на команды. Не позволяйте никому разделять уже сформировавшиеся команды или заставлять людей переходить в другие команды. Разрешайте людям переходить из команды в команду, только если они сами этого захотят. И поддерживайте любые инициативы, направленные на поиск командами своей идентичности. Только когда люди ощущают себя частью уникальной команды, они готовы изменить свое поведение и соблюдать принятые в команде правила.
2. Придайте социальному давлению направление, сделав группу в целом ответственной за достижение разделенной цели. Спортивные команды выигрывают или проигрывают — и тут важен каждый человек. То же самое относится к командам разработчиков. Ответственность команды — ответственность, разделяемая всеми ее членами.
3. Отойдите в сторону. Дайте самоорганизации шанс выполнить свою работу и подождите, пока социальное давление не изменит поведение людей. Высока вероятность, что наступит переходный момент, после которого все начнут применять один и тот же подход и пользоваться одними и теми же процедурами.

В этом состоит теория вопроса. В реальности процесс иногда приходится подталкивать, но все равно базовый алгоритм управления социальным давлением остается неизменным: сформировать команду, поставить цели и отойти в сторону.

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

А что если люди все равно ничему не учатся? Если сотрудник не развивают свои компетенции путем самообразования, а коучинг, сертификация и давление со стороны коллег не помогают, у вас в запасе остаются следующие три действия: Поговорите с ним. Поговорите с ним в последний раз. Избавьтесь от него.

Используйте адаптируемые инструменты

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

Я имею в виду инструменты.

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

Инструменты могут играть важную роль в повышении дисциплины в компании. Приверженцы Lean-методологий настаивают, что инструменты должны быть сконфигурированы таким образом, чтобы это позволяло максимально защитить процессы от ошибок (метод также известен как «защита от дурака») и тем самым затруднить выпуск программного обеспечения, содержащего дефекты [Poppendieck 2007: 196]. Меры по превентивному исключению ошибок можно считать техническим эквивалентом коучинга, который также помогает повысить дисциплину разработки.

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

Люди и процессы — сердце вашей компании, к этой же категории относятся и инструменты. Это значит, что, подобно людям и процессам, инструменты должны быть тщательно подобраны и адаптированы под потребности вашего бизнеса. Никогда не меняйте свой бизнес под свои инструменты. Как однажды написал Джоэл Спольски:

Если речь идет о критически важной для вашего бизнеса функции — выполните ее сами, чего бы это ни стоило.

Я думаю, этот тезис с небольшими оговорками может быть распространен и на используемые инструменты:

Если инструмент очень важен для вашего бизнеса — разработайте его сами, чего бы это ни стоило.

Не поймите меня превратно. Я никого не призываю создавать свой личный Visual Studio или Eclipse. Но вы должны выбирать для себя столь же адаптируемые программные продукты, какими являются Visual Studio и Eclipse. Не выбирайте настраиваемые инструменты. Чаще всего под настраиваемостью понимается возможность изменить набор пунктов меню, поменять их местами и выбрать ваш любимый цвет. Это не то, что я имею в виду под адаптируемостью. Точно так же не думайте, что вы в порядке, если пользуетесь инструментами, в названии которых есть слово Agile. Его обычно применяют с маркетинговыми целями, и его присутствие в названии продукта совсем не означает, что он имеет соответствующую архитектуру. Мне приходилось видеть так называемые гибкие инструменты, в которых было столько же гибкости, сколько в Ким Чен Ире, помещенном в ледник.

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

Подумайте о супервайзере

Я где-то читал, что «управлять людьми труднее, чем программировать, поскольку добиться нужного от людей труднее, чем от компьютера». (Не обрушивайтесь на меня с критикой, если вы не согласны. Это просто цитата из неизвестного источника.)

Эта фраза никак не выходила у меня из головы, когда я недавно столкнулся с рядом проблем… назовем их проблемами с дисциплиной…

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

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

И все же проблемы остаются проблемами. Если бы мой компьютер был настолько ненадежным, я выбросил бы его в окно. (Я бы даже затащил его на седьмой этаж нашего офиса и выбросил его оттуда.) Но в наши дни проделывать то же самое с проштрафившимися сотрудниками как-то не принято. Менеджеры научились проявлять человеческое сострадание. Они с пониманием относятся к причинам, которые вынуждают людей проявлять недисциплинированность, — вроде следующих: я не знал, что есть такое правило; прошу прощения, я забыл; у меня голова была занята другими важными рабочими делами; возникла очень срочная проблема; я заболел; у меня заболела собака; собака съела мой ежедневник; у меня убежала собака; ну и конечно, моя собака умерла.

То есть мы поняли, что такое быть людьми. Но как быть с проблемами?

Одно из часто предлагаемых решений — назначение супервайзера, в зону ответственности которого входило бы проведение инспекций. Такая мера выглядит как первый шаг к бюрократии, против которой так страстно выступают поклонники методологий Agile и Lean.

Например, Мэри и Том Поппендик считают, что инспекции, чья цель — обнаружение дефектов, это пустая трата времени. Они призывают вообще отказаться от инспекций. И утверждают, что ресурсы необходимо направлять на профилактику дефектов, а не на их исправление, потому что профилактика дешевле [Poppendieck 2007: 7].

В то же время Том и Кэй Гилб, прославившиеся именно своими работами по организации инспекций [Gilb 2003], проводят формальное обучение методам проверки проектной документации, направленным на выявление и измерение дефектов. Они даже вручают сертификаты с названиями вроде Inspection Leader и Inspection Process Owner!

Что вообще происходит? Как примирить эти точки зрения? Могу ли я получить сертификат за полный отказ от инспекций? Или мы стали свидетелями серьезной разборки между двумя самыми известными семейными парами, специализирующимися в области разработки ПО?

Я бы сказал, что их точки зрения — не более чем две стороны одной медали. Да, профилактика проблем дешевле, чем их исправление, но только в 98% случаев. К тому же, как отмечалось многими, добиться полного отсутствия дефектов невозможно, поскольку превентивные меры с целью исключить последние 2% дефектов стоят слишком дорого.

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

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

Одна из типичных форм инспекций — ассессмент. Существуют разнообразные инструменты, помогающие организациям проверить, насколько эффективно работают их Agile-команды [Cohn 2009: 430–438]. По существу, ассессменты будут инспекциями, поскольку они оценивают эффективность команд разработчиков после принятия ими Agile-практик. К сожалению, не существует способа внедрить Agile-методологии и не допустить при этом никаких ошибок, и это плохая новость для разработчиков, но хорошая для растущей индустрии консалтинга, включая семьи Гилб и Поппендик.

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

Проводите встречи с глазу на глаз

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

В своей книге «За закрытыми дверями» Джоанна Ротман и Эстер Дерби описывают, как нужно проводить индивидуальные встречи с сотрудниками [Rothman, Derby 11, 150]. C системной точки зрения регулярные встречи с глазу на глаз полностью оправданны. Они стимулируют обмен информацией в системе и ускоряют получение обратной связи.

Я не считаю нужным повторять здесь великолепные рекомендации, которые дают Ротман и Дерби. Просто советую прочитать их книгу. Но хотелось бы отметить, что многим менеджерам, включая меня, соблюдение графика встреч с сотрудниками дается с трудом. Как и в случае с другими важными видами деятельности, которые трудно поддерживать, есть только одно решение — воспользоваться четырьмя приемами самодисциплины:

1. Осознайте важность проведения встреч с глазу на глаз. Именно поэтому я выделяю для них специальный раздел в этой главе, а вы его читаете.
2. Решите проблему управления своим временем, зарезервировав в своем графике фиксированное время для этих встреч, например по полчаса на одного сотрудника. Проводите индивидуальные встречи в один и тот же день раз в две недели. По моему опыту, так легче не дать другим срочным делам вмешаться в ваши планы.
3. Мой опыт говорит, что о проведении таких встреч практически невозможно забыть. В тех редких случаях, когда со мной это происходило, сотрудники приходили ко мне в кабинет сами.
4. Мотивируйте себя, организуя индивидуальные встречи в разных интересных форматах. Например, можно сходить вместе с сотрудником в кафетерий во время обеденного перерыва, заняться с ним парным программированием и даже обмениваться текстовыми сообщениями, если вам вдруг приходится участвовать в безумно скучном совещании.

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

Встречи для обсуждения оценок 360°

Из упоминаемого в главе 4 закона требуемого разнообразия следует, что простые метрики никогда не смогут правильно оценить сложную систему. А принцип непрозрачности системы, описанный в главе 6 «Базовые принципы самоорганизации», объясняет, почему менеджер никогда не в состоянии точно оценивать сотрудников. Но тогда как же это делать?

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

В моей последней компании процедуру оценки персонала всегда оставляли на декабрь. Менеджеры, обреченные ее проводить, оказываются между молотом и наковальней: для них участие в этом — самый простой способ нарваться на неприятности. Поскольку в процедуре оценки участвует как старший менеджмент, так и рядовые сотрудники и все показывают пальцами в разные стороны, менеджеры среднего звена оказываются ровно посередине. Для них заниматься оценкой персонала такое же увлекательное занятие, как сидеть на границе между Израилем и Палестинской автономией, держа в руках плакат: «Я не поддерживаю ни ту, ни другую сторону. Может, просто обсудим ситуацию?»

Ежегодная процедура оценки персонала никуда не годится по целому ряду причин:

• Людей нельзя оценивать с помощью стандартизированных критериев вроде «пунктуальность», «коммуникационные навыки» или «энтузиазм». Сам характер таких критериев унизителен для оцениваемых и не в состоянии отразить присущую людям индивидуальность и разнообразие выполняемой ими работы [Bobinski 2010].
• Процесс оценки персонала один раз в год сильно запаздывает и поэтому теряет всякий смысл. Невозможно запомнить все, что происходило в течение двенадцати месяцев. А необходимость корректировать поведение людей возникает гораздо чаще [Derby 2010].
• При проведении ежегодной оценки персонала и менеджмент, и сотрудники имеют свои «тайные планы», что делает весь процесс «нечестным и мошенническим» [Culbert 2010].
• И наконец, «от него отдает старомодным, патерналистским и авторитарным управленческим подходом, который рассматривает сотрудников как собственность компании» [Heathfield 2010c].

К счастью, существует правильный метод оценки персонала. Для начала надо внутренне согласиться с принципами, лежащими в основе оценки 360° [Heathfield 2010b]. В первую очередь это утверждение, что ни одна отдельно взятая точка зрения не может объективно оценить работу сотрудника. Следовательно, для того, чтобы точнее измерить его вклад в работу организации, необходимо учитывать множественные оценки, вынесенные разными людьми [Dent 1999: 16].

К сожалению, многие руководители злоупотребляют оценкой 360° именно с точки зрения старомодности, патернализма и авторитарности (рис. 11.2). А это совсем не то, что нужно Agile-менеджеру.

Вот альтернатива получше.

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

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

Попросите кого-либо из сотрудников задать всем остальным вопросы о вашей эффективности и при этом вести запись ответов. Когда ваша личная оценка 360° будет завершена, переходите к сотруднику, сидящему рядом с вами. Вести записи в этом случае можно попросить еще одного сотрудника.

Зачем вам вообще проводить совещания для обсуждения оценок 360°? Чем этот способ лучше, чем традиционные методы?

• Люди получают возможность обсудить проблемы с чьим-либо поведением, при этом становится очевидно, действительно ли большинство членов команды считают это проблемой. Не имеет смысла документировать «проблемы», которых большинство не видит.
• Если ситуация неясна, сотрудник имеет возможность задать вопросы и прояснить ситуацию, чтобы лучше понять, в чем состоит проблема. Иногда стоит попросить привести конкретные примеры, если критика кажется слишком абстрактной. Или же потребуется всего лишь ответить и прояснить обстоятельства, вызвавшие то или иное его поведение, в результате чего ситуация предстанет совершенно в ином свете. Иногда между воспринимаемой и реальной проблемой имеется существенная разница.
• При личном общении люди вынуждены быть более справедливыми и проявлять больше понимания. Слишком легко критиковать других за их спиной. Гораздо правильнее и цивилизованнее привлечь внимание человека к его проблемам лицом к лицу. Присутствие других членов команды помогает составить более объективное представление, которое не будет искажено в результате предубежденности или из соображений мести.
• Высока вероятность, что в ходе обсуждения участники начнут оценивать друг друга по одинаковому набору параметров. Никто не совершенен, и всем полезно больше узнать о себе. Члены команды увидят несправедливость в том, что на кого-то обрушивается больше критики, чем на остальных. Поэтому, скорее всего, люди захотят, чтобы количество критики было сбалансированным.
• Вы можете проводить совещания для обсуждения оценок 360° несколько раз в год, чтобы людям не приходилось мучительно вспоминать, что именно происходило во время предыдущего обсуждения. А раз в год вы можете попросить сотрудников заполнить официальные формы и отдать их вам, чтобы вы могли их подписать и передать в отдел HR. Это будут действительно оценки 360°, а не ваши личные оценки каждого сотрудника.

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

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

Повышайте стандарты

Каждый раз, когда я приезжаю в Соединенные Штаты, мне приходится тратить время, а также физические и интеллектуальные усилия на перевод одних стандартов в другие. Я конвертирую доллары в евро и наоборот, мили в километры, галлоны в литры, а часы до и после полудня в 24-часовой формат. У меня скопилось уже по меньшей мере четыре электрических адаптера, потому что иногда я забываю взять их с собой в поездки. И это несмотря на то, что они указаны в чек-листе вещей, которые нужно взять с собой. (Возможно, вы задаете себе вопрос, зачем вам советы такого человека, когда речь идет о компетентности…)

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

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

Когда мы оцениваем свою эффективность, мы также сравниваем ее с определенными стандартами. В прошлом такие стандарты устанавливались менеджерами, которые фиксировали их на определенном уровне. Но самоорганизующиеся команды могут самостоятельно этим управлять. Их стандарты более динамичны, поскольку по мере развития компетенций люди могут сами пересматривать эти стандарты в сторону повышения [Thomas 2000: 31].

При разработке ПО предметом обсуждения между лидерами компетенций и сотрудниками в этом случае становятся их собственные стандарты, а не те, что навязаны менеджерами. К числу стандартов, устанавливаемых командами самостоятельно, могут относиться протоколы взаимодействия с пользователями, система именования файлов, требования, предъявляемые к коду, структура файлов, используемые инструменты, протоколы регистрации ошибок, правила безопасности [Poppendieck 2007: 193]. Исчезает необходимость в стандартизации сверху вниз, проводимой менеджментом. Но стандартизация снизу вверх произойдет только в том случае, если цели и контрольные показатели не оставляют у сотрудников никаких сомнений, что оптимальнее будет внести изменения в процесс своей работы.

Управляйте системой, а не правилами или людьми

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

• Дайте стандартам компетентности возможность и время сформироваться под влиянием положительной обратной связи. Например, практикам Agile-методологий хорошо известно, что размещение команды в одном помещении и вывешивание на всеобщее обозрение результатов измерения операционных показателей поощряют людей копировать друг у друга лучшие практики.
• Чтобы ускорить принятие лучших практик, вводите их в виде целостных мемплексов, а не по отдельности. Например, большинство идей, использованных Дэвидом Алленом в книге «Как привести дела в порядок» (Getting things done), существовало задолго до появления этого труда. Но в книге все идеи собраны в единый «пакет» под легко запоминающимся брендом, что облегчает задачу применения рекомендуемых автором практик.
• Разрешите людям фокусироваться на том, в чем они сильны, и не требуйте от них большего, чем «минимально необходимый уровень компетентности», в других областях. C точки зрения организации гораздо полезнее разрешить людям заниматься тем, что им нравится, и не заставлять их развивать свои компетенции в областях, к которым они безразличны. Не имеет никакого смысла превращать своих сотрудников в однородную массу. Гораздо лучше дать людям возможность проявлять свои индивидуальные таланты, тем самым компенсируя недостатки друг друга в прочих областях. Например, сотрудник со слабыми навыками вербальной коммуникации и межличностных взаимодействий может быть супергероем во всем, что касается системной архитектуры. Время, которое он проведет на тренингах по развитию «навыков коммуникации», можно использовать гораздо продуктивнее, отправив его на семинар, где будут обсуждаться «вопросы улучшения масштабируемости программных продуктов».
• Большие проблемы начинаются с маленьких. Нельзя фокусироваться только на крупных проблемах, поскольку за это время небольшие превращаются в огромные. Например, с самого начала установите требования, предъявляемые к качеству кода, чтобы под воздействием эффекта разбитых окон ваш проект не стал похож на местность, где похозяйничали сомалийские пираты [Hunt, Thomas 2000: 5].

Профессионально выстроенная организация представляет собой систему, которая подталкивает людей становиться все более компетентными в своей профессиональной области. Развитие компетенций — один из компонентов Менеджмента 3.0. Мне представляется, что самоорганизующаяся система развития компетенций — это и есть тот единственный уровень зрелости, который вам когда-либо понадобится.

Резюме

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

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

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

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

Подумать и сделать

Посмотрим, как можно применить некоторые идеи этой главы в вашей компании:

• Пройдитесь еще раз по семи проектным измерениям (функциональность, качество, инструменты, люди, время, процессы, ценность) и для каждого из них предложите минимум по одному показателю, важному с точки зрения организации. Начните применять эти показатели на практике.
• Подумайте о своем подходе к поддержанию дисциплины. Вас самого можно назвать примером самодисциплины? Смогут ли сотрудники понять, что такое дисциплина, просто понаблюдав за тем, как вы работаете?
• Испытывает ли ваша организация потребность в коучах? Все ли сотрудники, кому это нужно, получают соответствующий коучинг? Если нет, то почему?
• Подумайте, не стоит ли сертифицировать некоторых сотрудников. Кто из них нуждается в приобретении систематических знаний, которые станут катализатором дальнейшего развития их компетенций?
• Как формируются команды в вашей организации? Обладают ли они достаточной идентичностью, чтобы сотрудники ощущали к ним принадлежность и чтобы давление группы выполняло свою положительную роль?
• Обсудите вместе с командой инструменты, которыми вы пользуетесь в работе. Будут ли основные инструменты, применяемые вами при разработке ПО, достаточно адаптируемыми?
• Нужны ли вашей организации супервайзеры? Находятся ли компетенции команд на достаточно высоком уровне, чтобы обходиться без супервайзеров и инспекций? Или все же есть смысл, чтобы супервайзеры на выборочной основе проверяли работу команд?
• Проводите встречи с сотрудниками один на один. Запланируйте их в своем календаре в качестве регулярного события. Настройте напоминания, чтобы не забывать об этом.
• Несколько раз в год проводите встречи для обсуждения оценок 360°. Разрешите членам команды самим документировать результаты, но не забывайте, что ответственность за результаты оценки лежит на вас.
• Сделайте обзор стандартов, принятых в вашей организации. Удостоверьтесь, что все сотрудники знают и применяют их в своей работе. Как вариант, просто научитесь обходиться без них (без стандартов, а не без сотрудников!).

Отправить