Рамки принятия решений
Назначение
Документ задаёт, кто и на каком уровне принимает решения в ИИ-конвейере: по переходам инициатив, приоритетам портфеля, ресурсам, исключениям, рискам и подтверждению эффекта.
Цель рамок — убрать ручное «договоримся в чате» и заменить его понятной системой: решение имеет владельца, критерии, след в карточке инициативы и последствия для портфеля.
Основные идеи
- Решение должно быть привязано к этапу. На новой инициативе достаточно решения ИИ-офиса, а перед деливери нужен более строгий контроль.
- Переходы должны быть проверяемыми. Если правило можно выразить через обязательное поле, проверку похожих инициатив или выбранный продукт, оно должно быть настроено в платформе.
- Комитет не должен заменять критерии. Коллегиальный орган нужен для спорных и дорогих решений, а не для каждого движения карточки.
- Отклонение — нормальный результат. Конвейер должен отсекать слабые, дублирующие и рискованные инициативы до того, как они заберут ресурс команды.
- Исключения допустимы, но должны оставлять след. Если инициативу пропускают вопреки правилу, причина и владелец исключения фиксируются.
Как это работает
Решения принимаются на трёх уровнях:
| Уровень | Какие решения принимает | Где отражается |
|---|---|---|
| Операционный | создание инициативы, уточнение карточки, назначение задач, возврат на доработку | карточка инициативы, задачи, история изменений |
| Портфельный | приоритет, допуск к деливери, распределение ресурса, отложенные инициативы | бизнес-воронка, матрица приоритизации, аналитика |
| Контрольный | риск, безопасность, данные, архитектура, исключения, подтверждение эффекта | контрольные точки, артефакты, заключения, отчёт эффекта |
Связанные разделы: модель контрольных точек, подтверждение эффекта.
Матрица решений
| Решение | Кто готовит | Кто утверждает | Минимальные условия |
|---|---|---|---|
| Создать инициативу | Инициатор или ИИ-помощник | Инициатор / ИИ-офис | Есть проблема, описание и ожидаемый тип эффекта |
| Перевести в оценку | ИИ-офис | ИИ-офис или руководитель направления | Карточка достаточно заполнена, нет очевидного дубля |
| Выбрать продукт | ИИ-офис, владелец продукта | Владелец продукта или ИИ-офис | Продукт подходит по классу задачи и имеет маршрут деливери |
| Допустить к деливери | ИИ-офис, руководитель проекта | Портфельный комитет или назначенный ответственный | Есть продукт, проверка похожих инициатив, гипотеза эффекта, нет отрицательного решения безопасности |
| Изменить приоритет | ИИ-офис | Портфельный комитет / спонсор | Есть обоснование ценности, срочности и ресурса |
| Отклонить инициативу | Ответственный за этап | ИИ-офис или владелец решения | Указана причина отклонения |
| Перевести в ожидание эффекта | Руководитель проекта | Бизнес-владелец и ИИ-офис | Решение внедрено, метрики и дата проверки эффекта определены |
| Закрыть инициативу | Бизнес-владелец | ИИ-офис / финансы при значимом эффекте | Эффект рассчитан или причина закрытия зафиксирована |
| Принять исключение | Инициатор исключения | Руководящий орган или спонсор | Есть риск, причина, срок действия и ответственный |
Связь с платформой
В платформе решения поддерживаются через:
- бизнес-воронку инициатив;
- допустимые переходы между этапами;
- обязательные поля по этапам;
- проверки похожих инициатив;
- предварительную проверку безопасности;
- выбор продукта и продуктовый деливери-трек;
- задачи инициативы;
- роли и права доступа;
- аналитику портфеля и рисковых инициатив.
Смена этапа не должна происходить простым редактированием поля карточки. Она должна идти через управляемый переход, чтобы система могла применить правила и сохранить историю.
Права и ответственность
Минимальная модель ответственности:
- инициатор отвечает за первичное описание проблемы;
- бизнес-владелец отвечает за значимость проблемы и подтверждение эффекта;
- ИИ-офис отвечает за качество карточки, правила воронки, приоритеты и методологию;
- руководитель проекта отвечает за продвижение инициативы и задачи;
- владелец продукта отвечает за реализуемость в рамках продукта;
- безопасность отвечает за ограничения обработки данных и применения решения;
- архитектор отвечает за интеграцию, надёжность и соответствие целевой архитектуре;
- финансы подтверждают значимый экономический эффект;
- портфельный комитет решает конфликты приоритетов, ресурсов и исключений.
Правила исключений
Исключение — это разрешение двигать инициативу дальше, несмотря на невыполненное стандартное правило.
Исключение допустимо только если:
- указан владелец исключения;
- описана причина;
- определён срок действия;
- понятен риск;
- есть компенсирующее действие;
- решение сохранено в истории инициативы.
Примеры допустимых исключений:
- стратегическая инициатива идёт в оценку при неполной финансовой модели;
- деливери начинается до финального архитектурного заключения, но только в изолированном контуре;
- эффект проверяется позже из-за сезонности процесса.
Недопустимое исключение:
- пропустить инициативу в деливери без продукта, владельца, проверки похожих инициатив и понимания данных.
Анти-паттерны
Плохая модель решений выглядит так:
- все решения принимает один человек без критериев;
- комитет собирается по каждой мелкой карточке;
- переходы делаются вручную без истории;
- причины отклонения не фиксируются;
- инициативы получают высокий приоритет из-за статуса инициатора;
- безопасность и архитектура подключаются только перед запуском;
- эффект подтверждается словами «пользователям понравилось».
Хорошая модель решений делает обратное: заранее задаёт критерии, автоматизирует простые проверки и оставляет человеческое решение там, где действительно есть неопределённость.