RAPID, RACI, DACI, SPADE: Выберите структуру прав на принятие решений, а затем действительно применяйте её
RAPID, RACI, DACI и SPADE отвечают на один и тот же вопрос разными буквами: кто рекомендует, кто консультируется, кто должен согласовать, кто принимает решение, кто информирован. Выбор между ними имеет гораздо меньшее значение, чем их использование — применяемый рабочий процесс идентичен, независимо от выбранных букв, и только этап назначения ролей меняется. Чтобы запустить структуру прав на принятие решений в Argumentree: сформулируйте решение как корневое утверждение (его автор на практике является Рекомендателем); определите, кто участвует, используя уровни видимости (публичный, для всех арендаторов, для отдела, частный), чтобы набор Входных данных был проконсультирован по умолчанию; зафиксируйте назначение ролей как датированный, подлежащий атрибуции аргумент под корнем ДО начала дебатов — нет встроенного поля для роли в принятии решений, а роль RBAC является уровнем разрешений, а не правом на принятие решения, поэтому назначение является соглашением, которое вы поддерживаете; постройте дело как варианты с детьми «за» и «против»; проводите консультации в виде цепочек вопросов и ответов, где завершенная цепочка является подтверждением того, что консультация состоялась; обрабатывайте возражения держателя согласия как цепочку Обзора, а конфликты между держателями согласия как цепочки Компромисса; фиксируйте, на какой позиции находились все, с помощью оценок — которые являются доказательством, а не голосованием, без кворума или порога; пусть назначенный Решатель зафиксирует решение как аргумент с его обоснованием, особенно когда решение принимается против распределения в комнате; и информируйте, расширяя видимость решения, чтобы информированный набор прочитал решение и дебаты. Честные ограничения: нет поля для роли в принятии решений, оценки не являются взвешенными голосами, уровни видимости читаются, а не являются обязательными, завершенная цепочка не означает согласия, и ничто из этого не исправляет нежелающего Решателя.
RAPID, RACI, DACI и SPADE все отвечают на вопрос кто рекомендует, кто консультируется, кто принимает решение, кто информирован. Сравнение занимает одну таблицу; ценность в процессе:
- Назначьте роли перед дебатами — как устаревший, приписываемый аргумент в протоколе. Назначение их после — это просто повествование.
- Участие в объеме с уровнями видимости, чтобы входной набор консультировался по конструкции, а не по памяти
- Завершенная цепочка вопросов и ответов — это подтверждение того, что консультация состоялась — то, что всегда оспаривается позже
- Рейтинг — это не решение: названный человек называет это и объясняет, почему — особенно против комнаты
Решение, которое четверо человек думали, что они владеют.
Изменение цен было отправлено во вторник. В среду вице-президент по продажам спросила, почему она не подписала — она считала, что отвечает за ценообразование. Финансовый директор предполагал, что последнее слово за ним; он одобрил модель. На самом деле решение принял руководитель продукта, полагая, что это его право. А генеральный директор, читая об этом в документе для всех сотрудников, был под впечатлением, что такие решения приходят к нему. Четыре человека, одно решение, четыре искренних владельца — и теперь дебаты о возврате, которые на самом деле являются дебатами о праве собственности, замаскированные под обсуждение цен.
Вы уже видели версию этого. Это самая распространенная ошибка управления в развивающихся организациях, и у нее есть хорошо укомплектованная полка с решениями: RAPID, RACI, DACI, SPADE — рамки, содержание которых сводится к записать, кто какую роль играет до принятия решения. Буквы различаются; понимание идентично.
Что указывает на настоящую проблему. Команды тратят энергию на выбор между фреймворками — посты сравнения, дебаты на семинарах о том, отличается ли Консультируемый от Входа — а затем присваивают буквы после принятия решения, как документацию. Присвоение ролей после этого — это просто повествование. Этот учебник уделяет одну таблицу выбору и остальное — выполнению: применяемый рабочий процесс, который идентичен независимо от того, какие буквы вы выберете. (Для теории и истории фреймворков наш гид по фреймворкам принятия решений охватывает их наряду с остальным инструментарием — этот учебник намеренно не повторяет это.)
Четыре фрейма в одной таблице
В любом значимом решении существует шесть ролей. Рамки называют их по-разному:
RAPID (Бэйн)
Рекомендовать · Согласовать · Выполнить · Ввести · Решить. Единственный с явной ролью Согласования — стороны, чье одобрение может заблокировать. Лучше всего, когда юридический/финансовый отдел действительно имеет право вето.
RACI
Ответственный · Несущий ответственность · Консультируемый · Информированный. Наследие ответственности за задачу — Несущий ответственность является единственным владельцем. Лучше всего, когда решение связано с обязанностями по выполнению.
DACI (Intuit/Atlassian родословная)
Dрайвер · Aдминистратор · Cоавторы · Iнформированные. Драйвер управляет процессом; администратор принимает решение. Лучше всего для продуктовых команд, которые хотят, чтобы процесс-управляющий был назван.
ЛОПАТА (Гокул Раджарам)
Установка · Люди · Альтернативы · Решение · Объяснение. Меньше матрица ролей, чем контрольный список решений — его шаг Объяснение это дисциплина записывания причин, которую другие забыли предписать.
Выберите своих настоящих блокировщиков: реальные обладатели вето → RAPID; запутанность выполнения → RACI; культура процессного исполнителя → DACI; команда, которая пропускает запись причин → SPADE. Затем остановитесь. Шаги 2-10 ниже не изменяются в зависимости от вашего выбора — только буквы на шаге 3. Это предложение является самым полезным в учебном пособии: оно завершает выбор фреймворка и начинает выполнение, что является поведением, которое действительно улучшает принятие решений.
Настройка: объем, затем роли, затем дело
- 1Назовите решение как основное требование. "Мы перейдем на ценообразование на основе использования для уровня Team в первом квартале." Его автором, на практике, является Рекомендатель/Драйвер — авторство видно, поэтому Р записан с первой секунды. Контрольная точка: корень существует; его автор — человек, который строит дело.
- 2Область, кто участвует с уровнями видимости. Установите видимость обсуждения — публичная, для всего арендатора, для отдела или частная — в соответствии с предполагаемым набором входных данных. Решение, охватывающее отдел, может быть проконсультировано этим отделом по умолчанию; вы не полагаетесь на то, что кто-то вспомнит вовлечь юридический отдел. Контрольная точка: видимость соответствует набору входных данных, а не привычке.
- 3Запишите распределение ролей — перед первым аргументом. Как про-ребенок корня: "Решатель: A. Рекомендатель: B. Согласен: C, D. Входные данные: Eng, Legal. Информированы: все руки." Датировано, подлежит атрибуции и оспариванию, как и все остальное в дереве. Эта последовательность — основная цель рамок прав на принятие решений: роли, назначенные после дебатов, просто описывают то, что произошло. Контрольная точка: аргумент о распределении предшествует каждому аргументу дела.
- 4Постройте аргументацию. Варианты в качестве узлов-соседей, каждый со своими плюсами и минусами — та же структура, что и в учебнике по записям решений, включая отклоненные варианты, о которых читатель спросит позже. Контрольная точка: у каждой реальной альтернативы есть узел.
Роль RBAC не является правом на принятие решений.
Нет встроенного поля для роли принятия решений. Роль пользователя в аренде (администратор, модератор, участник) является уровнем разрешений — кто может администрировать пространство — а не правом на принятие решений — кто может решить этот вопрос. Буквы RAPID/RACI являются соглашением, которое вы фиксируете как аргумент (шаг 3) и поддерживаете самостоятельно: с датой и возможностью указания, но не контролируется продуктом. Не давайте иного понимания вашим заинтересованным сторонам.
Консультацию вы можете подтвердить.
«Вас консультировали?» — это вопрос, на котором в конечном итоге основывается каждое оспариваемое решение, и в большинстве организаций честный ответ — это пожимание плечами: была встреча, была переписка, воспоминания различаются. Рабочий процесс здесь делает консультацию документом, а не воспоминанием:
- 1Каждый держатель ввода открывает цепочку вопросов и ответов по рекомендации: их вопрос, ответ Рекомендателя, последующий вопрос, ответ — завершено. Завершенная цепочка является доказательством того, что консультация состоялась: кто спрашивал, что было отвечено, когда. Держатель ввода, которому нечего спросить, явно отказывается. Контрольная точка: у каждого держателя ввода есть ≥1 завершенная цепочка или явный отказ.
- 2Держатель согласия, который высказывает возражение, открывает цепочку обзора: их оценка, ответ Рекомендателя, последующие действия, ответ. Несколько держателей согласия означают несколько параллельных цепочек, каждая из которых разрешается на своих условиях — никаких нерешенных блокировок, скрывающихся в групповой переписке. Контрольная точка: вне цепочки не существует активного возражения.
- 3Два держателя соглашения в конфликте → Цепочка компромиссов. Один предлагает другому среднюю позицию, фиксируя это на записи. Разрешено или нет, попытка документируется — что превращает "Юридический и финансовый отделы никогда не соглашались" из обвинения в читаемый обмен. Контрольная точка: конфликты либо разрешены, либо явно продолжаются.
Аудиторский вопрос
Кто был консультирован по вашему последнему важному звонку — и могут ли они это подтвердить? Если консультация не может быть подтверждена консультированными, значит, её не было в том виде, который выдержит спор.
Решив отказаться от номера и записав, почему
Перед звонком каждый оценивает варианты — по одному обозначенному рейтингу на каждый. Читайте это как есть: доказательство того, какова была ситуация в комнате, а не голосование. Кворума нет, порога нет, нет решающего голоса; вся основа структуры заключается в том, что решение принимает названный человек.
Затем Решатель принимает решение — в качестве аргумента, написанного ими, под выбранным вариантом, излагая свои доводы. И вот самое ценное предложение, которое производит рабочий процесс: если решение противоречит рейтингам, узел Решателя — это то место, где это объясняется. "Комната склонялась к варианту B; я выбираю A, потому что риск обновления предприятия превышает предпочтение распределения" — одно предложение, которое отделяет лидерство с несогласием и обязательством от решения по указу, и именно из этого состоит устойчивая решение. Решатель, который не напишет это, не управляет рамками; он носит их.
- ✓Контрольная точка: распределение зафиксировано до звонка; решение записано как собственный аргумент Решателя, с обоснованием — обязательно, когда оно противоречит мнению группы.
Информирование без отдельного письма
Последнее письмо, самый дешевый шаг: расширить видимость решения после его принятия. Информированная группа открывает обсуждение и читает не только результат, но и дебаты — варианты, цепочки консультаций, причины решения. "Почему изменились цены?" никогда не требует отдельной цепочки писем, потому что ответ — это само сообщение. Сделав это таким образом, информирование также становится началом привлечения заинтересованных сторон: люди привязываются к решениям, чью логику они могут проверить.
- ✓Контрольная точка: видимость расширена до набора Информированных; объявление связывает запись вместо того, чтобы перефразировать её.
Честные ограничения
- ✗Нет поля для роли решения. Буквы являются зафиксированной конвенцией — датированной и подлежащей атрибуции, но продукт не назначает и не проверяет их. Роль RBAC — это уровень разрешений, а не право на принятие решений.
- ✗Рейтинги не являются взвешенными голосами. Один балл и метка на человека, без кворума, без порога, без тай-брейка. Решение является тай-брейком.
- ✗Чтение областей видимости, а не обязательство. Область отдела означает, что Юридический может это видеть — завершенная цепочка вопросов и ответов, а не настройка видимости, является доказательством их участия.
- ✗Цепочка состоит из четырех оборотов, затем завершена — и завершено ≠ согласовано. Несогласный держатель согласия, который все равно действует, зафиксирован как услышанный, а не как преобразованный.
- ✗Ничто из этого не исправляет неохотного Решателя. Структура быстрее выявляет незавершенное решение — пустой узел, где должен быть вызов, очень заметен — но она не может сделать вызов.
Практические занятия
- ✓Напишите аргумент роли на стартовой встрече, вживую, прежде чем кто-либо начнет спорить о достоинствах. Тридцать секунд сейчас против археологии среды после.
- ✓Держите список согласий максимально коротким. Каждый держатель согласия — это потенциальный блок с цепочкой для разрешения; большинство "утверждающих" на самом деле являются Входом. Дисциплина RAPID заключается в том, чтобы говорить об этом вслух.
- ✓Отказ от консультации тоже является записью. Держатель ввода, который явно передал, не может позже требовать исключения — защитите их и себя, сделав передачу видимой.
- ✓Повторное использование задания. Повторяющиеся типы решений (ценообразование, набор сотрудников, выбор поставщика) сохраняют одни и те же буквы — вставьте аргумент роли в качестве шаблона и обновите имена.
Среда, пересмотренная
Повторите изменение цен через рабочий процесс. Вице-президент по продажам является согласующим — её возражение — это завершённая цепочка обзоров, на которую ответили дважды, и она дала согласие. Финансовый директор является входом — его консультация — это квитанция. Руководитель продукта является решающим на основании аргумента с датой, написанного до дебатов, и её обоснование против мнения зала состоит из одного абзаца, который может прочитать каждый. Генеральный директор проинформирован — документ для всех сотрудников связывает дерево. То же самое решение, возможно, тот же результат. Но в среду нечего пересматривать, потому что единственный вопрос, который когда-либо подогревает эти споры — кто имел право это решать? — был задан до того, как кто-либо начал спорить.
Источники и дополнительная литература
- Роджерс, П., и Бленко, М. (2006). У кого есть D? Как четкие роли в принятии решений улучшают организационную эффективность. Harvard Business Review, январь 2006.Фреймворк RAPID от Bain, от его авторов — включая случай, когда неясные права на принятие решений, а не плохой анализ, тормозят организации.
- Раджарам, Г. — инструментальный комплект SPADE (Установка, Люди, Альтернативы, Решение, Объяснение).Член семьи в форме контрольного списка, чья стадия Объяснения требует письменного объяснения, почему этот учебник строит узел Решателя вокруг.
- Atlassian Team Playbook — DACI: рамка для принятия решений.Вариант Участник/Утверждающий/Вкладчики/Информированные, как это практикуется в продуктовых организациях.
Часто задаваемые вопросы
В чем разница между RAPID, RACI, DACI и SPADE?
Они отвечают на один и тот же вопрос — кто рекомендует, кто консультируется, кто должен согласовать, кто принимает решение, кто информирован — с разными акцентами. RAPID (Bain) является единственным, у кого есть явная роль Согласования для настоящих обладателей вето. RACI исходит из ответственности за задачу, где Ответственный является единственным владельцем — полезно, когда решение связано с выполнением. DACI называет Водителя, который управляет процессом отдельно от Утверждающего, который принимает решение. SPADE ближе к контрольному списку, и его шаг Объяснения требует записать обоснование. Выбирайте по вашим реальным блокировщикам — вето, исполнению, управлению процессом или привычке пропускать «почему» — и затем отметьте, что применяемый рабочий процесс идентичен для всех четырех: меняются только буквы, обозначающие роли.
Когда следует назначать роли принятия решений?
Перед дебатами — в этом и заключается вся суть семейства рамок. Роли, назначенные задним числом, являются нарративом: они описывают, кто оказался доминирующим, а не кто имел на это право. Практически: зафиксируйте назначение в виде датированного, атрибутируемого заявления (в этом рабочем процессе, аргумента под корнем решения) до того, как будет сделан первый аргумент по делу. Это занимает тридцать секунд в начале и устраняет класс споров — 'кто имел право решить это?' — который подогревает большинство повторных разбирательств по решениям.
Как вы докажете, что заинтересованные стороны действительно были проконсультированы?
С чеком, а не с воспоминанием. В этом рабочем процессе каждая сторона, участвующая в консультации, открывает цепочку вопросов и ответов по рекомендации — их вопрос, ответ Рекомендателя, последующий вопрос, ответ — и завершенная цепочка получает временную метку, что является подтверждением того, что консультация состоялась и что она охватывала. Заинтересованная сторона, у которой нет вопросов, явно отказывается, что также является записью. Обратите внимание на честную границу: ограничение видимости решения для отдела означает, что они могут его видеть; только завершенная цепочка подтверждает, что они участвовали.
Оценка вариантов — это то же самое, что и голосование по решению?
Нет, и сохранение различия — это то, что делает эти структуры работающими. Рейтинги — одно значение и ярлык на человека — фиксируют, где находилась комната: база доказательств. Нет кворума, порога или правила решающего голоса, потому что предпосылка структуры заключается в том, что решение принимает названный человек. Реальная ценность распределения проявляется, когда Решающий идет против него: зафиксированное обоснование ('комната наклонилась к B; я выбрал A, потому что…') — это единственное самое ценное предложение, которое производит процесс, превращая отмену из указа в подотчетное, проверяемое суждение.
Можно ли реализовать права на принятие решений в программном обеспечении?
В основном нет, и будьте осторожны с инструментами, которые подразумевают иное. В частности, в Argumentree: роль арендатора RBAC (администратор, модератор, участник) — это уровень разрешений, определяющий, кто может управлять пространством, а не право на принятие решения, определяющее, кто может решать конкретный вопрос. Буквы RAPID/RACI фиксируются как датированный аргумент по решению — подлежащий атрибуции и оспариванию, но поддерживаемый по соглашению. То, что программное обеспечение действительно обеспечивает полезно, находится рядом: ограничение видимости делает набор консультаций структурным, а цепочки превращают консультации и возражения в завершенные, подлежащие атрибуции записи.
Что если Решающий не примет решение?
Никакая структура не исправит неохотного Решателя — но структура выявляет задержку быстрее и точнее, чем ритм встреч. В этом рабочем процессе разрыв виден: дело построено, консультации завершены, оценки получены, а узел Решателя пуст. Это превращает неопределенное организационное отклонение в конкретный, датированный факт ('решение ожидается от A с 12 числа'), на который может повлиять путь эскалации. Если тот же узел остается пустым многократно, честное решение — это перераспределение роли Решателя, что делает зафиксированное назначение роли явным действием, а не тихим.
Перестаньте искать фреймворки. Запустите один на этой неделе.
Роли в записи до дебатов, консультации с квитанциями и названное лицо, принимающее решение с записанным обоснованием.
Начать бесплатную 14-дневную пробную версию