Слайды выступления на конференции и табличное представление см. здесь.
Тренинги по фасилитации сложных встреч, по решению бизнес-проблем, по целеполаганию и OKR. Проведение стратсессий.
Круги влияния и контроля
Сокращение спискаЭтап I–II
Когда применять На старте — при генерации длинного списка проблем/идей, чтобы отделить то, что команда реально контролирует.
Вид действия Сокращение списка вариантов.
Вход Длинный, неструктурированный список проблем/запросов.
Инструкция Нарисуйте 3 круга: «контроль», «влияние», «вне контроля». Разнесите элементы по зонам, отложите «вне контроля». Если спор — зафиксируйте аргументы и вернитесь позже.
Выход Отфильтрованный список задач, по которым команда может реально действовать.
Этап процесса I — Генерация → II — Фильтрация/группировка.
Плюсы и выгоды Быстрый фокус, снижение фрустрации, экономия времени команды.
Минусы и ограничения Не даёт приоритизации внутри круга; возможно разногласие о границах влияния.
Скорость Высокая (10–20 мин).
Проработанность Низкая (фильтрация, не анализ).
Цена ошибочного решения Низкая (ошибка ведёт к незначительной переработке списка).
Сила и масштаб влияния решения Средний (внутри команды/проектов).
Срочность Нет.
Исполнители слаженные? Подходит и для слаженных, и для менее слаженных команд.
5 примеров для ИТ (показать)
- Определить, какие задержки релизов команда контролирует (CI, тесты) и что — внешние подрядчики.
- Решить, попадает ли поддержка 24/7 в компетенцию команды или вендора.
- Классифицировать проблемы интеграции с внешним API.
- Отобрать кандидаты на обновление CI/CD-инструментов, которые команда может внедрить.
- Выяснить, какие бюджетные решения можно принять локально, а какие — эскалировать.
Категории
ГруппировкаЭтап II
Когда применять Когда длинный список идей/проблем нужно разбить по смысловым группам.
Вид действия Группировка/упорядочивание.
Вход Сырый неструктурированный список идей/боли.
Инструкция Согласуйте набор категорий (напр., продукт, техдолг, процессы, безопасность). Разнесите элементы и уточните определения категорий.
Выход Разбитый по категориям список для дальнейшей приоритизации.
Этап процесса II — группировка/фильтрация.
Плюсы и выгоды Упорядочивает хаос, облегчает параллельную работу разных команд.
Минусы и ограничения Категории могут быть субъективными; иногда нужен фасилитатор.
Скорость Высокая (15–30 мин).
Проработанность Низкая–средняя.
Цена ошибочного решения Низкая (переклассификация простая).
Сила и масштаб влияния решения Низкий–средний.
Срочность Нет.
Исполнители слаженные? Подходит всем командам.
5 примеров для ИТ (показать)
- Разделение элементов backlog на фичи/баги/техдолг.
- Классификация запросов от бизнеса по приоритетности.
- Сортировка потенциальных улучшений UX vs инфраструктура.
- Группировка проблем безопасности по уровню критичности.
- Разделение кейсов онбординга по типам пользователей.
Матрицы 2×2
ПриоритизацияЭтап II
Когда применять Когда нужно быстро распределить варианты по двум ключевым осям (например, срочность/влияние).
Вид действия Сортировка/фильтрация.
Вход Набор идей (обычно 8–20 элементов).
Инструкция Выберите оси (напр., влияние vs усилия). Поставьте каждый вариант в квадрант; верхний-правый — первоочередной.
Выход Короткий список приоритетов (топ-3/5) для дальнейшей проработки.
Этап процесса II — первичная приоритизация.
Плюсы и выгоды Наглядно, быстро отделяет «важное и простое» от «маловажного и дорогого».
Минусы и ограничения Выбор осей субъективен; требует минимальной дисциплины в оценке.
Скорость Средняя (15–40 мин).
Проработанность Средняя.
Цена ошибочного решения Средняя (может временно сместить фокус).
Сила и масштаб влияния решения Средний.
Срочность Иногда (в зависимости от контекста).
Исполнители слаженные? Предпочтительно слаженные команды.
5 примеров для ИТ (показать)
- Определить, какие баги фиксировать в критическом релизе.
- Выбрать, какие автоматизации запускают сначала.
- Приоритизировать техдолг vs новые фичи.
- Определить MVP-фичи для следующего релиза.
- Сортировать оптимизации CI по влиянию/усилиям.
Голосование точками (топ-5 из 10+)
ФильтрацияЭтап II
Когда применять Когда много идей и нужно быстро отфильтровать несколько фаворитов для последующей проработки.
Вид действия Сокращение списка.
Вход 10+ вариантов после первичной категоризации.
Инструкция Дайте каждому N точек (напр., 5). Участники распределяют точки. Подсчитайте и возьмите топ-5 для дальнейшего анализа.
Выход Топ-5 приоритетных вариантов.
Этап процесса II — сокращение/фильтрация.
Плюсы и выгоды Быстро вовлекает всю группу, видно коллективные приоритеты.
Минусы и ограничения Популярность ≠ качество; эффект «громких» участников.
Скорость Высокая (10–20 мин).
Проработанность Низкая (требуется дальнейшая обработка).
Цена ошибочного решения Средняя (не лучшие идеи могут подняться вверх).
Сила и масштаб влияния решения Средний.
Срочность Да (когда нужно быстро сузить список).
Исполнители слаженные? Подходит для любых команд.
5 примеров для ИТ (показать)
- Выбрать 5 тем для следующего спринта/ретро.
- Отобрать идеи для A/B-тестов.
- Сузить список потенциальных внешних инструментов.
- Выбрать набор UX-экспериментов.
- Определить 5 кандидатов на исправление техдолга.
Scoring-таблица (простая)
ОценкаЭтап II
Когда применять Когда нужно сравнительно оценить несколько вариантов по набору критериев.
Вид действия Фильтрация / ранжирование.
Вход 5–15 идей, определённые критерии оценки.
Инструкция Выберите 3–5 критериев (ценность, риск, усилия). Оцените каждый вариант по шкале 1–5, умножьте/сложите по весам, отсортируйте.
Выход Ранжированный список с аргументами для лидеров.
Этап процесса II — структурированная фильтрация.
Плюсы и выгоды Более объективно, чем простое голосование; даёт видимые критерии.
Минусы и ограничения Требует согласования критериев; веса вводят субъективность.
Скорость Средняя (30–60 мин).
Проработанность Средняя–высокая.
Цена ошибочного решения Средняя–высокая (если данные неверны).
Сила и масштаб влияния решения Средний–высокий.
Срочность Нет (если нужны данные).
Исполнители слаженные? Желательно слаженные команды.
5 примеров для ИТ (показать)
- Приоритизация backlog-фич с учётом ценности/усилий.
- Выбор внешней библиотеки или сервиса.
- Оценка задач рефакторинга.
- Распределение ресурсов между инициативами.
- Сравнение поставщиков DevOps-услуг.
Scoring RICE / WSJF
ПриоритизацияЭтап II
Когда применять Для продуктовой приоритизации, когда важна прозрачная экономическая логика (reach/impact/confidence/effort или cost of delay).
Вид действия Фильтрация / ранжирование.
Вход Список фич/инициатив + оценки (reach, impact, effort и т.д.).
Инструкция RICE: рассчитайте Reach × Impact × Confidence ÷ Effort; WSJF: Cost of Delay ÷ Job Size. Отсортируйте по результатам.
Выход Приоритизированный список инициатив с пояснениями.
Этап процесса II — приоритет по ценности.
Плюсы и выгоды Прозрачная методика, связывает решения с отдачей.
Минусы и ограничения Зависит от точности оценок; требует данных/оценок; может быть сложной для новичков.
Скорость Средняя (30–90 мин в зависимости от объёма).
Проработанность Высокая.
Цена ошибочного решения Средняя–высокая.
Сила и масштаб влияния решения Высокий (продуктовые/бизнес-решения).
Срочность Нет (предпочтительно время для расчётов).
Исполнители слаженные? Да, желательно продукт + инженерия.
5 примеров для ИТ (показать)
- Выбор фичи, влияющей на активацию/ретеншн.
- Решение о приоритизации техдолга против фич.
- A/B-идеи для масштабного теста.
- Интеграции, где важна скорость вывода на рынок.
- Оптимизация очереди задач для PI-планирования.
Scoring по метрикам продукта
МетрикиЭтап II–IV
Когда применять Когда критично связать решение с KPI/OKR (активация, ретеншн, revenue и т.д.).
Вид действия Фильтрация / доработка / финальное решение (в связке с данными).
Вход Кандидаты + доступные метрики/аналитика.
Инструкция Для каждого варианта оцените ожидаемое влияние на ключевые метрики, учтите усилия и риски; составьте взвешенную таблицу и ранжируйте.
Выход Список инициатив, ранжированных по ожидаемому влиянию на продуктовые метрики.
Этап процесса II–IV (зависит от зрелости данных).
Плюсы и выгоды Прямая связь с бизнес-результатом; хорошо для обоснования инвестиций.
Минусы и ограничения Требует аналитики; риск переоценки эффектов; влияет на короткий горизонт.
Скорость Средняя–низкая (нужна аналитика).
Проработанность Высокая.
Цена ошибочного решения Высокая (может увести продукт в неверном направлении).
Сила и масштаб влияния решения Высокая (продукт/бизнес).
Срочность Иногда (когда метрики критичны).
Исполнители слаженные? Да — продукт + аналитика + инженерия.
5 примеров для ИТ (показать)
- Выбор изменений онбординга для улучшения конверсии.
- Оптимизация цепочки платежей для роста ARPU.
- Приоритизация фич по влиянию на удержание.
- Выбор экспериментов для снижения оттока.
- Инвестиции в производительность ради увеличения транзакций/мин.
Квадраты Декарта
АнализЭтап III
Когда применять Когда команда «зависла» из-за риска/сомнений и нужно увидеть последствия «сделать/не сделать».
Вид действия Детальная проработка формулировки и последствий.
Вход 1–2 варианта, вызывающие сомнения (финалисты).
Инструкция Заполните 4 квадранта: что будет, если сделаем; что будет, если не сделаем; чего не будет, если сделаем; чего не будет, если не сделаем. Сопоставьте риски и упущенные возможности.
Выход Осознанная карта последствий, понятные аргументы «за» и «против».
Этап процесса III — глубокая проработка перед утверждением.
Плюсы и выгоды Простой, но мощный способ вскрыть скрытые эффекты и упущенные возможности.
Минусы и ограничения Не даёт количественных оценок; может требовать времени на обсуждение.
Скорость Средняя (20–40 мин).
Проработанность Высокая (качественный анализ).
Цена ошибочного решения Высокая (если проигнорировать важные последствия).
Сила и масштаб влияния решения Высокий.
Срочность Нет (лучше проводить без спешки).
Исполнители слаженные? Лучше слаженные команды.
5 примеров для ИТ (показать)
- Принятие решения о миграции базы данных (стоимость, downtime, выгоды).
- Переход с монолита на микросервисы (риски, затраты, долгосрочные выгоды).
- Удаление legacy-компонента.
- Внедрение SSO/SSO провайдера.
- Полный переход на Kubernetes vs держать VM.
Определение уровня поддержки (шкала 1–5)
Финальное уточнениеЭтап IV
Когда применять Перед запуском/реализацией, чтобы измерить готовность команды и выявить скрытое несогласие.
Вид действия Финальное уточнение/проверка buy-in.
Вход Чётко сформулированный вариант решения.
Инструкция Каждый показывает 1–5 (1 — против/блок, 5 — полностью поддерживаю). Для низких оценок — короткое уточнение причин и условия для старта.
Выход Порог готовности к запуску и список условий/ограничений.
Этап процесса IV — утверждение/готовность.
Плюсы и выгоды Быстрая проверка готовности; выявляет скрытые риски в команде.
Минусы и ограничения Не заменяет глубокое обсуждение причин низких оценок.
Скорость Очень высокая (5–10 мин).
Проработанность Средняя.
Цена ошибочного решения Средняя.
Сила и масштаб влияния решения Средний.
Срочность Да (к моменту Go/No-Go).
Исполнители слаженные? Подходит любым, но полезнее в слаженных.
5 примеров для ИТ (показать)
- Go/No-Go перед релизом.
- Запуск новой политики код-ревью.
- Внедрение нового CI-процесса.
- Изменение формата стендапов/ретро.
- Подготовка к миграции баз данных.
Единоличное решение (лидер/эксперт)
Финальное утверждениеЭтап IV
Когда применять В кризисных ситуациях, при срочной необходимости или когда есть очевидный эксперт/владелец.
Вид действия Финальное утверждение.
Вход Короткий набор вариантов или критическая ситуация требующая немедленного решения.
Инструкция Владелец/лидер принимает решение, кратко объясняет обоснование и границы, фиксирует план и RACI для исполнения и проверки результатов.
Выход Решение с назначенными ответственными и планом действий.
Этап процесса IV — утверждение и немедленный запуск.
Плюсы и выгоды Максимальная скорость и ясность ответственности.
Минусы и ограничения Низкий buy-in, риск «ошибки одного»; требует последующего ретро.
Скорость Максимальная (мгновенно — до 30 мин).
Проработанность Низкая–средняя (зависит от эксперта).
Цена ошибочного решения Высокая (особенно при стратегических последствиях).
Сила и масштаб влияния решения Высокий.
Срочность Да.
Исполнители слаженные? Подходит и для неслаженных, но требует контрольных точек.
5 примеров для ИТ (показать)
- Hotfix в продакшене — лидер принимает решение о rollback.
- Срочные меры при инциденте безопасности.
- Выбор временного обхода при отказе внешнего сервиса.
- Решение о срочном найме подрядчика для критичной задачи.
- Принятие меры по ограничению нагрузки (rate limiting) в пике.
Consent (консент)
Финальное утверждениеЭтап IV
Когда применять Когда нужно принять рабочее решение быстро, но с проверкой на содержательные возражения.
Вид действия Финальное утверждение (если нет веских возражений).
Вход Чётко сформулированный вариант решения.
Инструкция Фасилитатор задаёт: «Есть ли у кого веское возражение (риск/вред) против этого решения?» Используйте go-round: каждый по очереди отвечает; если существенных возражений нет → решение принято; если есть — доработка.
Выход Либо решение принято (нет возражений), либо список возражений для доработки.
Этап процесса IV — утверждение/корректировка.
Плюсы и выгоды Быстрее, чем консенсус; учитывает содержательные риски; сохраняет вовлечённость.
Минусы и ограничения Молчание ≠ согласие — требует культивирования культуры выражения аргументированных возражений.
Скорость Высокая (10–20 мин).
Проработанность Средняя.
Цена ошибочного решения Средняя.
Сила и масштаб влияния решения Средний.
Срочность Да.
Исполнители слаженные? Лучше слаженные, но можно и с менее зрелыми при правильной фасилитации.
5 примеров для ИТ (показать)
- Утвердить новую политику код-ревью, если нет существенных возражений.
- Принять мелкие изменения в CI-настройках.
- Согласовать использование нового чат-плагина для команды.
- Утвердить формат стендапов/ретро.
- Запустить пилот фичи при отсутствии критических рисков.
Консенсус (и право вето)
Финальное утверждениеЭтап IV
Когда применять Для очень важных, долгосрочных или чувствительных решений, где нужна поддержка всей группы.
Вид действия Финальное утверждение (по согласию всех или с возможным вето у ключевых стейкхолдеров).
Вход Глубоко проработанные варианты, аргументы, возможно отчёты/анализ.
Инструкция Проводится обсуждение до тех пор, пока не будет достигнута формулировка, с которой каждый может жить; вето может быть использовано только для содержательных и аргументированных опасений, и требует предложения альтернативы.
Выход Широко поддерживаемое коллективное решение (или фиксация точки разногласия и путь эскалации).
Этап процесса IV — окончательное утверждение (стратегическое).
Плюсы и выгоды Максимальная вовлечённость, долгосрочный buy-in, снижение сопротивления при реализации.
Минусы и ограничения Очень длительный процесс; риск блокировки одним человеком/группой.
Скорость Низкая (часы/дни/несколько встреч).
Проработанность Очень высокая.
Цена ошибочного решения Очень высокая (стратегические последствия).
Сила и масштаб влияния решения Очень высокий.
Срочность Нет (требует времени).
Исполнители слаженные? Да — требуется зрелая команда.
5 примеров для ИТ (показать)
- Принятие архитектурных стандартов на уровне компании.
- Определение DevOps-стратегии для нескольких команд.
- Слияние команд/перераспределение ответственности.
- Утверждение политики безопасности и доступа.
- Выбор основополагающей платформы (например, облако провайдера).
RACI
МетаспособЭтап V
Когда применять Когда размыты роли и ответственные по проектам/решениям.
Вид действия Для доработки формулировки и распределения ответственности (мета-уровень).
Вход Проект/инициатива с множеством стейкхолдеров.
Инструкция Для каждой ключевой активности укажите: Responsible (R), Accountable (A), Consulted (C), Informed (I). Опубликуйте матрицу и согласуйте с участниками.
Выход Чёткая матрица ответственности и ожиданий.
Этап процесса V — решение о способе принятия/распределение ролей.
Плюсы и выгоды Устраняет «перекидывание ответственности», делает процесс прозрачным.
Минусы и ограничения Требует времени на согласование; бывает перегружает документами.
Скорость Средняя (30–90 мин в зависимости от масштаба).
Проработанность Высокая.
Цена ошибочного решения Высокая (неправильное распределение ведёт к срывам).
Сила и масштаб влияния решения Высокий (кросс-функционально).
Срочность Нет.
Исполнители слаженные? Требует согласования между командами.
5 примеров для ИТ (показать)
- Матрица RACI для релиз-процесса (who deploys, who QA, кто информирован).
- RACI при миграции в облако (кто отвечает за миграцию, за вендора, за тесты).
- Распределение ответственности за безопасность и инциденты.
- Управление backlog между продуктом и платформой.
- Координация интеграций с партнёрами.
Покер делегирования
МетаспособЭтап V
Когда применять Когда нужно согласовать уровень делегирования (кто решает и насколько автономно).
Вид действия Доработка формулировки/мета-решение о правилах принятия.
Вход Ситуации с неясными полномочиями или неоднозначными ожиданиями.
Инструкция Каждый участник выбирает карту (уровень делегирования, напр. 1—лидер решает, 7—полная автономия). Открывают карты, обсуждают расхождения и фиксируют согласованный уровень.
Выход Зафиксированный уровень делегирования и рамки ответственности.
Этап процесса V — мета-решение о способе принятия/делегировании.
Плюсы и выгоды Снижает разночтения ожиданий; повышает доверие и прозрачность.
Минусы и ограничения Требует зрелости команды и честности; может выявить системные проблемы доверия.
Скорость Средняя (15–30 мин).
Проработанность Средняя.
Цена ошибочного решения Средняя (нечёткое делегирование ведёт к провалам).
Сила и масштаб влияния решения Средний.
Срочность Нет.
Исполнители слаженные? Лучше — да.
5 примеров для ИТ (показать)
- Согласовать, кто утверждает релизный план.
- Решить, кто выбирает приоритеты техдолга.
- Определить уровень автономии для команды разработки при выборе стека.
- Установить границы для принятия бюджетных решений.
- Договориться, кто принимает решение о найме/удалении подрядчиков.