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

Похожая классификация была предложена Россом Петтитом. У него уровни зрелости называются так: регрессивный, нейтральный, ориентированный на сотрудничество, операционный, адаптивный и инновационный [55]. Содержание каждого немного отличается от описанных выше, но похоже, что, как и Вайнберг, Петтит также имеет в виду именно уровни зрелости выбора и применения процессов.

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

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

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

Если нарисовать две оси, соответствующие дисциплине и умениям, то мы получим матрицу (рис. 10.4). Она позволяет в удобном виде оценивать степень проектной зрелости. Умения можно утратить с возрастом, в результате травмы или отставания от технического прогресса, а дисциплину – в результате потери мотивации или из-за отвлекающих факторов. Компетентность подразумевает как профессиональные умения, так и дисциплину, а следовательно, менеджерам надо заниматься и тем и другим.

В своей деятельности команды руководствуются определенными правилами: как документировать требования, как предварительно оценивать работу, как фиксировать исходный код, как писать тестовый код, как разворачивать готовые решения и так далее. Кроме того, у каждого члена команды есть свой личный набор правил. Один разработчик фиксирует тестовый код в виде ветви до того, как написан окончательный код, в то время как другой откладывает свой код, пока не убедится, что все работает безупречно. Одному дизайнеру нравится использовать Visio, а другой говорит, что лучше доски и маркеров пока еще ничего не придумано. Один тестировщик документирует результаты пользовательской приемки при помощи специально созданного для этой цели инструмента, а другой пользуется простой таблицей в Google Docs. Я предпочитаю, чтобы комментарии к исходному коду были предельно лаконичными, а другим нравятся огромные простыни с максимумом подробностей.

Хорошо ли, когда люди следуют собственным правилам?

Да. Скорее нет. Может быть. Все зависит от ситуации…

Для Scrum-мастера неудобно, если у каждого члена команды есть свой способ калибровки пользовательских историй. Всем приходится договариваться, применять ли единицы истории или часы, – в противном случае невозможно рассчитать скорость команды. Точно так же нуждаются в согласовании даты и время совещаний, длина спринтов и тому подобное.

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

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

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

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

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

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