Может ли быть слишком много прозрачности в работе Agile-команд?

Прозрачность часто называют одним из трёх столпов Agile, наряду со способностью к проверке и адаптации. Но может ли команде быть нанесён вред от излишней прозрачности? Майк Кон (Mike Kohn), один из соавторов и основателей Scrum и Scrum Alliance, считает, что это возможно, и предлагает свой подход по снижению возможного урона.

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

• скорость работы
• отработанные часы
• количество story points на одного сотрудника команды
• диаграммы выгорания
• количество исправленных дефектов за один спринт и проч.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Facebook

Twitter

Linkedin

VK

Также по теме:

• itSMF 2011: «Всё это — люди». Александр Тараторин
• Удовлетворённость: измерять или нет?
• Книга «RealITSM: проверено временем» поступила в продажу