Очевидно, что дисциплина важна в любой профессии. Джеральд Вайнберг описывает эффект бумеранга, который возникает, когда люди не выполняют необходимые процедуры. Сначала они пропускают какой-либо элемент процесса контроля качества, что увеличивает количество дефектов в готовом продукте, и это приводит к росту жалоб со стороны клиентов, в результате чего возникает необходимость отрываться от других проектов, чтобы решить возникшие проблемы, что ведет к возрастанию давления на команду разработчиков, вследствие чего не выполняются еще какие-либо процедуры [Weinberg 1992: 278–282]. Мы все знаем из опыта, что нарушения производственной дисциплины не ускоряют, а замедляют процесс. Это поистине порочный круг.
Мэри и Том Поппендик говорят о том же, указывая, что высокая скорость разработки невозможна, если качеству не уделяется должного внимания [Poppendieck 2007: 190]. Когда мы не сверяемся с чек-листами и перескакиваем через необходимые этапы, поначалу действительно складывается впечатление, что процесс ускорился. Но вскоре нежелательные компромиссы с точки зрения качества продукта (известные также как технический долг) доконают вас окончательно.
Вайнберг описывает шесть уровней зрелости при исполнении процессов [Weinberg 1992: 23]:
• О процессах даже не вспоминают: «Мы и не знали, что выполняем какой-то процесс».
• Нестабильные процессы: «Мы делаем так, как нам в данный момент кажется необходимым».
• Рутина: «Мы просто следуем заведенному распорядку (если только не запаникуем)».
• Направляемый выбор: «При выборе правил мы руководствуемся своим представлением о том, какие результаты они позволят получить».
• Учет предыдущего опыта: «Мы устанавливаем правила работы в зависимости от того, насколько хорошо они работали в прошлом».
• Согласованность: «Все сотрудники вовлечены в процесс непрерывной оптимизации во всех областях»
[54].
Вайнберг использует эти шесть уровней для классификации организаций, но я предпочитаю оценивать только отдельных исполнителей и только за конкретную деятельность. Что в итоге произойдет с самой компанией, будет результатом взаимодействия между людьми, которым при выполнении разных видов деятельности свойственны весьма разные уровни дисциплины. Например, меня иногда хвалят за то, насколько дисциплинированно я подхожу к написанию книг. Возможно, в этом смысле с точки зрения приведенной классификации я нахожусь на пятом («учет предыдущего опыта») или шестом уровне («согласованность»). Но если вы вдруг услышите громкую ругань и проклятия, то не исключено, что это я возвращаюсь за забытым бумажником – в таких делах я все еще нахожусь на первом уровне (когда «о процессах даже не вспоминают»). (Ругань и проклятия могут также исходить от моего партнера. Потрясающе: когда я писал этот абзац, он как раз вернулся, потому что десять минут назад вышел из дома, забыв взять бумажник…)
Похожая классификация была предложена Россом Петтитом. У него уровни зрелости называются так: регрессивный, нейтральный, ориентированный на сотрудничество, операционный, адаптивный и инновационный
[55]. Содержание каждого немного отличается от описанных выше, но похоже, что, как и Вайнберг, Петтит также имеет в виду именно уровни зрелости выбора и применения процессов.
Вторая важная часть компетентности – профессиональные умения. Умелый разработчик может при этом быть недисциплинированным, в то время как дисциплинированный разработчик необязательно будет умелым. Поэтому мне кажется, что в качестве еще одного измерения зрелости можно использовать профессиональный уровень разработчиков.
Есть два подхода к описанию уровней профессионального мастерства. Система гильдий, распространенная в средневековой Европе, предусматривала три уровня: ученик, подмастерье и мастер. Практически ничем не отличается японская система сюхари, в которой выделяются три уровня владения боевыми искусствами: сю, ха и ри. И в той и в другой системе люди, находящиеся на первом уровне, изучают основные техники; на втором уровне акцент делается на исключениях и рефлексии; а на третьем уровне думать уже не надо, все дается легко и естественно.
Еще довольно известна дрейфусовская модель приобретения навыков, в которой предусмотрено не три, а пять ступеней: новичок, продолжающий, компетентный, специалист и эксперт. Но мне кажется, что обсуждать, сколько ступеней профессионального мастерства можно выделить – три, четыре, пять или семнадцать, – совершенно неинтересно. Гораздо более актуален тот факт, что умения и дисциплина – совершенно разные вещи, и развитием того и другого надо заниматься отдельно.
Если нарисовать две оси, соответствующие дисциплине и умениям, то мы получим матрицу (рис. 10.4). Она позволяет в удобном виде оценивать степень проектной зрелости. Умения можно утратить с возрастом, в результате травмы или отставания от технического прогресса, а дисциплину – в результате потери мотивации или из-за отвлекающих факторов. Компетентность подразумевает как профессиональные умения, так и дисциплину, а следовательно, менеджерам надо заниматься и тем и другим.
Разнообразие правил
В своей деятельности команды руководствуются определенными правилами: как документировать требования, как предварительно оценивать работу, как фиксировать исходный код, как писать тестовый код, как разворачивать готовые решения и так далее. Кроме того, у каждого члена команды есть свой личный набор правил. Один разработчик фиксирует тестовый код в виде ветви до того, как написан окончательный код, в то время как другой откладывает свой код, пока не убедится, что все работает безупречно. Одному дизайнеру нравится использовать Visio, а другой говорит, что лучше доски и маркеров пока еще ничего не придумано. Один тестировщик документирует результаты пользовательской приемки при помощи специально созданного для этой цели инструмента, а другой пользуется простой таблицей в Google Docs. Я предпочитаю, чтобы комментарии к исходному коду были предельно лаконичными, а другим нравятся огромные простыни с максимумом подробностей.
Хорошо ли, когда люди следуют собственным правилам?
Да. Скорее нет. Может быть. Все зависит от ситуации…
Для Scrum-мастера неудобно, если у каждого члена команды есть свой способ калибровки пользовательских историй. Всем приходится договариваться, применять ли единицы истории или часы, – в противном случае невозможно рассчитать скорость команды. Точно так же нуждаются в согласовании даты и время совещаний, длина спринтов и тому подобное.
