원클릭으로 Manus에서 모든 스킬 실행

planning-prep

스타39

포크13

업데이트2026년 4월 7일 10:34

Скилл BABOK Глава 3 — Планирование и мониторинг бизнес-анализа. Используй этот скилл всегда, когда бизнес-аналитик начинает новый проект или инициативу и нужно спланировать подход к работе. Триггеры: "как мне подойти к этому проекту", "какую методологию выбрать", "кто мои стейкхолдеры", "как организовать работу с требованиями", "планирование БА", "governance", "как хранить требования", "оценить эффективность аналитики", "начать бизнес-анализ", "спланировать анализ". Скилл ведёт BA по пяти задачам Главы 3: подход → стейкхолдеры → governance → хранение информации → оценка эффективности.

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

Manus에서 실행

출처

chaussky

chaussky/ainalyst

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Manus에서 실행

관련 직업SOC

SOC 직업 분류 기준

경영 분석가비즈니스 및 금융 운영직·SOC 13-1111

SKILL.md

readonly

이 저장소의 다른 Skills

같은 저장소

change-strategy

chaussky/ainalyst

Скилл BABOK 6.4 — Определение стратегии изменения. Используй этот скилл когда BA завершил анализ текущего/будущего состояния и оценку рисков и готов определить стратегию: выбрать вариант изменения (big_bang/phased/pilot_first), оценить готовность организации, сравнить варианты по взвешенным критериям и зафиксировать скоуп решения. Триггеры: «стратегия изменения», «варианты решения», «скоуп», «готовность организации», «compare options», «change strategy», «define solution scope», «transition states».

2026-04-0739

current-state

chaussky/ainalyst

Скилл BABOK 6.1 — Анализ текущего состояния (as-is). Используй этот скилл когда BA хочет понять текущее состояние бизнеса, сформулировать бизнес-потребности, провести RCA (Root Cause Analysis) или описать проблемы организации. Триггеры: «текущее состояние», «as-is», «проблема», «бизнес-потребность», «корневая причина», «current state», «analyze current state», «почему так происходит».

2026-04-0739

design-options

chaussky/ainalyst

Скилл BABOK 7.5 — Определение вариантов дизайна. Используй этот скилл когда BA переходит от требований к вариантам реализации: выбирает build/buy/hybrid подход, оценивает технические альтернативы, описывает компромиссы и готовит рекомендацию. Триггеры: «варианты дизайна», «design options», «build vs buy», «варианты реализации», «как реализовать», «технические альтернативы», «solution options».

2026-04-0739

elicitation-collaborate

chaussky/ainalyst

Скилл BABOK 4.5 — Управление сотрудничеством с заинтересованными сторонами. Используй этот скилл когда BA хочет понять что происходит со стейкхолдером, зафиксировать решение или протокол встречи, разобраться с конфликтом. Триггеры: "стейкхолдер перестал отвечать", "кто-то против", "есть конфликт интересов", "нужно зафиксировать решение", "запиши протокол встречи", "стейкхолдер стал Blocker", "не могу договориться", "кто принял это решение", "нужен decision log", "стейкхолдер соглашается но ничего не делает", "обходит меня и идёт к разработчикам", "зафиксируй вовлечённость", "attitude изменился", "как работать с сопротивлением". Скилл поддерживает четыре режима: диагностика вовлечённости, decision log, протокол встречи, анализ конфликта.

2026-04-0739

elicitation-communicate

chaussky/ainalyst

Скилл BABOK 4.4 — Предоставление информации бизнес-анализа. Используй этот скилл когда BA хочет адаптировать артефакт под конкретную аудиторию или зафиксировать факт коммуникации. Триггеры: "адаптируй под разработчиков", "перепиши для руководства", "как передать требования тестировщику", "сделай executive summary", "подготовь пакет для архитектора", "в каком формате отправить", "как лучше донести до бизнеса", "зафикс что отправил требования", "запиши что провели встречу", "нужен follow-up", "стейкхолдер не понял", "выбери канал коммуникации", "подготовь письмо", "сделай презентационное резюме". Скилл поддерживает три режима: адаптация под аудиторию, выбор формата и канала, фиксация факта коммуникации.

2026-04-0739

elicitation-conduct

chaussky/ainalyst

Скилл BABOK 4.2 — Проведение выявления требований. Используй этот скилл всегда, когда бизнес-аналитик передаёт результаты интервью, воркшопа или анкетирования для анализа. Триггеры: "вот транскрипт интервью", "вот заметки с воркшопа", "проанализируй интервью", "что мы упустили", "где пробелы", "сравни два интервью", "стейкхолдер что-то скрывает", "прилетел change request — кого довыявить", "сформируй отчёт по интервью", "выяви требования из интервью". Скилл поддерживает три сценария: обработка одного интервью, сравнение нескольких, анализ в контексте Change Request. Итеративный процесс — каждое новое интервью сравнивается с предыдущими.

2026-04-0739

name	planning_prep
description	Скилл BABOK Глава 3 — Планирование и мониторинг бизнес-анализа. Используй этот скилл всегда, когда бизнес-аналитик начинает новый проект или инициативу и нужно спланировать подход к работе. Триггеры: "как мне подойти к этому проекту", "какую методологию выбрать", "кто мои стейкхолдеры", "как организовать работу с требованиями", "планирование БА", "governance", "как хранить требования", "оценить эффективность аналитики", "начать бизнес-анализ", "спланировать анализ". Скилл ведёт BA по пяти задачам Главы 3: подход → стейкхолдеры → governance → хранение информации → оценка эффективности.
project	AI-powered Platform AInalyst (AI Платформа AIналитик)
copyright	Copyright (c) 2026 Anatoly Chaussky. Licensed under AGPL v3. Commercial licensing: chaussky@gmail.com

BABOK Глава 3 — Планирование и мониторинг бизнес-анализа

Твоя роль — помочь бизнес-аналитику выстроить фундамент работы на проекте: выбрать подход, определить стейкхолдеров, установить правила принятия решений и организовать хранение информации. Без этого фундамента остальные задачи BABOK выполняются хаотично.

Веди пользователя пошагово. Каждая задача — отдельный шаг. Не перегружай вопросами.

Пять задач Главы 3

Задача 3.1 — Выбор подхода к бизнес-анализу

Помоги BA выбрать методологию работы исходя из контекста проекта.

Задай уточняющие вопросы, если контекст не указан:

Как часто меняются требования?
Насколько высока неопределённость в проекте?
Есть ли строгие регуляторные требования (compliance)?

Логика выбора:

Ситуация	Подход
Требования стабильны, неопределённость низкая	Predictive (Waterfall)
Высокая динамика или неопределённость	Adaptive (Agile)
Нужен баланс гибкости и контроля	Hybrid
Agile + строгий compliance	Hybrid с compliance-gates

После выбора подхода — предложи сохранить решение через MCP-инструмент suggest_ba_approach.

Задача 3.2 — Планирование вовлечения стейкхолдеров

Помоги составить карту стейкхолдеров и выбрать стратегию работы с каждым.

Важно: реестр стейкхолдеров — это живой документ. В начале проекта известны 1–2 человека (обычно спонсор). Каждое интервью добавляет новых. Реестр никогда не бывает "закрыт" — он растёт на протяжении всего проекта.

Типичная цепочка роста:

Спонсор → называет руководителей → те называют экспертов →
эксперты называют смежные отделы → и так далее

После каждой сессии выявления реестр обновляется через update_stakeholder_registry (MCP задачи 4.2).

Для каждого стейкхолдера определи:

Влияние (High / Medium / Low) — способность влиять на проект
Интерес (High / Medium / Low) — заинтересованность в результате
Отношение (Champion / Neutral / Blocker)
Статус охвата: Выявлен / В плане / Не охвачен
Частота коммуникации — как часто получает информацию
Триггер коммуникации — при каком событии обязательно уведомить

Расписание коммуникаций — шаблон по матрице:

Квадрант	Частота	Типичные триггеры
High influence / High interest	После каждого значимого шага	Любое решение, изменение требований, риски
High influence / Low interest	По milestone или по запросу	Только критичные решения и блокеры
Low influence / High interest	После сессий выявления с участием	Follow-up после интервью, статус-апдейт
Low influence / Low interest	Редко, по необходимости	Только если напрямую затронуты

Расписание фиксируется в профайле стейкхолдера и используется задачей 4.4 (check_communication_schedule) для контроля — кому давно не писали и у кого сработал триггер.

Матрица Power/Interest:

Влияние ↑ / Интерес →	Low	High
High	Keep Satisfied — информировать о вехах	Manage Closely — вовлекать в каждое решение
Low	Monitor — общая рассылка	Keep Informed — демо, статус-апдейты

Вопросы для расширения реестра (задавай на каждом интервью):

"С кем вы согласовываете изменения в этом процессе?"
"Кто ещё использует результаты этой работы?"
"Чья работа изменится, если мы реализуем это?"
"Кто может заблокировать или замедлить проект?"

Используй MCP-инструмент plan_stakeholder_engagement для формирования матрицы.

Задача 3.3 — Планирование Governance

Помоги установить правила принятия решений и контроля изменений.

Ключевые вопросы:

Кто принимает финальные решения по требованиям?
Как обрабатываются изменения — формально (CR + CAB) или гибко (через PO)?
Как эскалируются конфликты?

Шаблон ответа по критичности:

Критичность	Контроль изменений	Согласование
High	Формальный CR → CAB	Sponsor + PO
Medium	PO одобряет через Backlog	PO + Lead BA
Low	Фиксация в Jira, устно	Lead BA

Используй MCP-инструмент plan_ba_governance.

Задача 3.4 — Управление информацией

Помоги спланировать где и как хранятся требования и артефакты.

Вопросы для обсуждения:

Какие инструменты уже используются в команде?
Нужна ли трассировка требований и насколько детальная?
Кто имеет доступ к артефактам — только BA или вся команда?

Уровни трассировки:

Уровень	Что означает
High	Бизнес-цели → FR → Тест-кейсы → Код
Medium	FR связаны с задачами Jira
Low	Базовая нумерация требований

Используй MCP-инструмент plan_information_management.

Задача 3.5 — Оценка эффективности БА

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

Признаки проблем, на которые стоит обратить внимание:

Требования часто меняются уже в разработке
Разработчики жалуются на непонятные или противоречивые требования
Нет единого места хранения требований
Onboarding новых BA занимает больше месяца
Нет метрик качества требований

Используй MCP-инструмент evaluate_ba_performance для формирования плана улучшений.

Когда использовать MCP-инструменты

Все пять задач поддержаны MCP-сервером (skills/planning_mcp.py). Вызывай инструменты когда нужно сохранить артефакт или получить структурированный вывод:

Задача	MCP-инструмент
3.1 Выбор подхода	`suggest_ba_approach`
3.2 Стейкхолдеры	`plan_stakeholder_engagement`
3.3 Governance	`plan_ba_governance`
3.4 Хранение информации	`plan_information_management`
3.5 Оценка эффективности	`evaluate_ba_performance`
Финализация	`save_ba_plan`

Все инструменты принимают project_id первым параметром. Артефакты сохраняются в governance_plans/data/{project}_ba_plan.json и governance_plans/reports/.