Зачем нам нужны правила.
Очень простой вопрос: «Какие у вашей команды правила принятия решения?» часто ставит в тупик некоторых Скрам Мастеров и Менеджеров. И хорошо, если вы с легкостью можете на него ответить. Попробую объяснить, почему этот вопрос так важен.
Все гибкие методологии и фреймворки (Scrum, XP, DSDM, Crystal etc.), которые комфортно ютятся под зонтиком Agile, предполагают, что большинство решений должны приниматься в процессе командного обсуждения, коллаборативно. Хороший пример такой встречи – Ретроспектива Спринта в Скраме, на которой присутствует вся Скрам Команда – Владелец Продукта, Скрам Мастер и Команда Разработки. Мы оглядываемся назад на прошедший Спринт и проводим ревизию наших инструментов, процессов, человеческих взаимоотношений, рабочих договоренностей, различных техник, Критериев Готовности и принимаем корректирующие решения.
Существует точка, через которую должны проходить все групповые обсуждения. Точка, которая отделяет мир идей от мира действий. Назовем ее точкой «Принятия решения». ДО прохождения этой точки мы можем ломать копья или конструктивно спорить (лучше, конечно, последнее J), настаивать на своей точке зрения, соглашаться или нет с предложениями наших коллег и так далее. ПОСЛЕ прохождении этой точки мы попадаем в иной мир - мир действий, где принятие решения осталось уже позади. Тут нет места спорам. Мы занимаемся лишь внедрением ранее принятых решений.
.
На практике же точка принятия решения «плывет» или вообще отсутствует. Как результат, кто-то начинает воплощать, по его мнению, уже принятое решение в жизнь, в то время как другие члены команды с недоумением смотрят и думают «а я ведь не подписывался на это». Случается и другое – то, что я называю «молчаливым согласием». В конце встречи менеджер встает и говорит: «Ну, насколько я понял, все согласны с этим предложением и возражений больше нет. Так ведь?». В ответ раздается лишь невнятное бормотание. «Все, решение принято». Встреча подошла к концу.
Часто команды при решении любых возникающих в работе вопросов пользуются лишь одним правилом «по умолчанию» - правилом большинства, даже не задумываясь над тем, что это правило может принести больше вреда, чем пользы при рассмотрении некоторых вопросов, где нужна поддержка большей части команды.
Итак, правила принятия решений важны. Они дают прозрачность и явно отделают мир принятия решений от мира обсуждения. Давайте попробуем разобраться и понять, как их можно правильно использовать.
Какие бывают правила.
Правило большинства (Majority). Правило, которое по умолчанию используется не только во многих командах, но и повсеместно в обычной жизни.
- Плюсы: очень просто в использовании, позволяет быстро принять необходимое решение.
- Минусы: набрав 51% голосов (контрольный пакет акций), вы можете дальше просто пренебрегать позицией меньшинства. С другой стороны, не ждите от уступившей стороны большого энтузиазма (если вообще он будет) в реализации принятого решения. Большая вероятность того, что решение будет саботироваться. Правило большинства разделяет группу.
Делегирование. Иногда возникает ситуация, когда команда может передать окончательное принятие решения группе людей или одному человеку как домашнюю работу. После выполнения группой домашнего задания команда может ратифицировать или отменить принятое решение.
- Плюсы: делегирование позволяет команде быстро двигаться дальше, особенно когда команда доверяет человеку-группе людей, которым «выдано» домашнее задание.
- Минусы: команда может не ратифицировать принятое группой решение после.
Правило супер большинства (Super Majority). Решение принимается большинством, как и в предыдущем правиле, но планка прохождения решения повышается. Это может быть 60%, 70%, 80%.
- Плюсы: чем выше процентный порог, тем больше мы получаем поддержки и тем менее команда разделена, тем меньше возможного сопротивления.
- Минусы: время на принятие решения значительно увеличивается.
Мультиголосование (Multivoting). Часто используется в том случае, если нам необходимо приоритезировать длинный список на флип-чарте из возможных проблем или решений. Часто при этом используется голосование точками. Другой вариант мультиголосования – сетки принятия решений(Decision Grid). Мультиголосование нейтрально. Оно не делит команду на победителей и проигравших. Ведь каждый отдает несколько голосов и непосредственно вовлечен в процесс принятия решения.
Консенсус (Consensus). Определение консенсуса следующее: “Я готов жить с этим решением и поддерживать его”. Многие ошибочно думают, что консенсус обязательно предполагает наличие лучшего или наиболее оптимального решения. Это не так. Консенсус также не обязывает интегрировать все точки зрения (хотя это, бесспорно, хорошо). Дл я консенсуса необходимо и достаточно того, чтобы вся команда готова была жить и поддерживать принятое решение.
- Плюсы: решение, принятое консенсусом, не встретит сопротивления и будет всячески поддерживаться командой.
- Минусы: поиск консенсуса может занять много времени и требует наличия опытного фасилитатора.
Как и какими решениями стоит пользоваться на практике?
Хочу привести один пример из личного опыта.
Скрам Команда всего несколько дней как работала вместе. Ребята только познакомились с друг другом. Обсуждались рабочие договоренности, и, наконец, они подошел вопрос выработки Критериев Готовности (Definition of Done). Уходило время, а команда никак не могла сойтись в едином мнении относительно того, какой же должен быть процент покрытия кода интеграционными тестами. Некоторые члены команды начали торопить Скрам Мастера с принятием решения. В итоге оно было принято с использованием правила «по умолчанию» - правилом большинства. Стоит ли говорить о том, какие были последствия? В команде еще несколько Спринтов не утихали жаркие споры и назревал серьезный конфликт. Разработчики разбились на два лагеря. Те, кто поддержал принятое решение, настаивали на четком его соблюдении (ведь решение было уже принято), и тех, кто всячески продолжал саботировал выработанные Критерии Готовности.
Типичный пример того, как правило было использовано неудачно. Я убежден, что следующие критические вопросы, которые требуют поддержки всей команды, должны решаться исключительно с применением правила консенсуса:
- Определение Критериев Готовности (Definition of Done)
- Рабочие договоренности (Working Agreements)
- Определение времени Ежедневного Скрама.
Для менее важных вопросов можно использовать правила мультиголосования или супер большинства. Наконец, тривиальные вопросы можно решать простым поднятием рук (правило простого большинства) или делегированием.
Договариваемся о правилах.
Людям и особенно командам нужны четкие правила, по которым будут приниматься решения, поэтому я рекомендую провести с командой воркшоп. Описываю примерные шаги:
- Обсуждаем с командой важность существования четких правил принятия решений.
- Обсуждаем все типы принятия решений, которые могут быть использованы.
- Рисуем на флип-чарте таблицу (см. на фотографии ниже) и заполняем ее примерами (тут может понадобится мозговой штурм).
- Вешаем флип-чарт в комнате команды и используем его как подсказку в тех случаях, когда от нас требуется принять согласованное решение.
- Дополнительно вы можете выработать критерий (или несколько), по которым каждое решение будет относиться к одному из перечисленных правил. Это может быть Важность (Importance) или уровень Воздействия (Impact). Как это работает? Допустим, команда изначально договорилась о том, что все важные решения (больше ШЕСТИ по десятибалльной шкале) должны приниматься правилом консенсуса, ЧЕТЫРЕ-ШЕСТЬ мультиголосованием, а все что меньше правилом большинства. В этом случае при необходимости принять какое либо решение Скрам Мастер рисует на флип-чарте шкалу и команда голосует, отмечая на шкале важность . Затем высчитываем среднее арифметическое между оценками и «попадаем» на одно из оговоренных ранее правил решений.
И в заключение.
Надеюсь, что мне удалось донести до вас важность и необходимость выработки культуры принятия решений. Конечно, у каждой команды будет свой контекст, корпоративная культура и окружение, поэтому правила могут существенно отличаться. Буду рад, если вы поделитесь своими мыслями в комментариях. Удачного вам принятия решений!
Подробнее о правилах принятия решения мы рассказываем на наших тренингах:
Scrum ON
