Menü
Use when: 技术方案确定后涉及多部门协作、需要明确协作流程与职责分工、跨团队沟通困难 Do NOT use when: 单一团队独立完成、协作关系已明确无需梳理
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
Product Manager Skills Pack - Full lifecycle support from demand to delivery 让一个产品经理拥有一个产品团队的能力 Use when: Starting a new product, planning features, analyzing market, designing solutions, managing growth, strategic decision
Use when starting any product management task - automatically detects task type and invokes appropriate PM skill using intelligent routing
Use when: 需要检查super-pm skills健康状态、定期维护审计、验证元数据完整性 Do NOT use when: 正在使用某个功能skill、仅需执行产品管理任务
Use when: 有初步需求清单需要细化细节、需明确需求场景和边界条件、需求描述模糊需要结构化 Do NOT use when: 需求已足够详细可直达开发、仅需快速立项无需深入
Use when: 需要理解用户体验全链路、发现用户痛点与机会点、优化用户转化流程 Do NOT use when: 用户流程已非常清晰、仅需单一功能分析而非全局体验
Use when: 需要了解市场格局与竞争态势、收集行业数据、分析竞品优劣势、评估市场机会 Do NOT use when: 市场已有充分内部调研数据、仅需简单规模估算无需深度分析
| name | pm-cross |
| description | Use when: 技术方案确定后涉及多部门协作、需要明确协作流程与职责分工、跨团队沟通困难 Do NOT use when: 单一团队独立完成、协作关系已明确无需梳理 |
| allowed-tools | ["Agent","Read","Write","AskUserQuestion","Bash"] |
bash "$(dirname "${BASH_SOURCE[0]}")"/check-update.sh 2>/dev/null || true
# 读取技能包版本号
SKILL_ROOT="$(cd "$(dirname "${BASH_SOURCE[0]}")" 2>/dev/null && pwd)" || true
if [ -f "$SKILL_ROOT/VERSION" ]; then echo "📦 super-pm $(cat "$SKILL_ROOT/VERSION")"; fi
mkdir -p docs/04-风控管理
echo "🤝 跨部门协作方案制定工具已启动"
当流程要求与用户交互时：
使用 AskUserQuestion:
🏢 参与部门识别
本次项目涉及哪些部门？（可多选）
A) 产品部门（需求定义、验收） B) 研发部门（技术实现） C) 设计部门（UI/UX设计） D) 测试部门（质量保障） E) 运营部门（推广、用户反馈） F) 市场部门（品牌、宣传） G) 客服部门（用户支持） H) 法务部门（合规审查） I) 财务部门（预算审批） J) 其他部门（请手动输入）
使用 AskUserQuestion:
🔗 协作场景识别
主要的跨部门协作场景：
A) 需求确认与评审 B) 设计稿评审 C) 技术方案评审 D) 测试用例评审 E) 上线发布评审 F) 问题排查与解决 G) 多项组合
使用 AskUserQuestion:
📋 协作流程模式
选择协作流程的严格程度：
A) 正式流程（多级审批、文档完备） B) 标准流程（关键节点评审） C) 灵活流程（快速沟通、轻量文档）
继续询问：
🔄 协作依赖关系
部门间是否存在强依赖关系？
A) 串行依赖（部门A完成 → 部门B开始） B) 并行协作（多部门同时进行） C) 混合模式（部分串行、部分并行）
使用 AskUserQuestion:
💬 沟通会议频率
跨部门沟通会议的频率：
A) 每日（快速同步） B) 每周（周会） C) 每迭代（迭代评审） D) 按需（有重要事项时召开）
继续询问：
📢 信息同步方式
项目信息同步的主要方式：
A) 文档协作（Notion/飞书文档） B) 群组沟通（微信群/飞书群） C) 邮件通报 D) 项目管理工具（Jira/Trello） E) 多种方式组合
使用 AskUserQuestion:
🎯 决策权归属
关键决策由谁负责：
A) 产品负责人（PO）决策 B) 项目经理（PM）协调决策 C) 委员会决策（多部门负责人） D) 分层决策（按决策类型划分）
使用 Write 工具生成 docs/04-风控管理/跨部门协作方案.md。
利用 Agent 工具并行执行独立子任务，大幅缩短总执行时间。
当步骤1-2的用户信息收集完成后，以下两个任务可以并行执行：
| 子任务 | 说明 |
|---|---|
| RACI矩阵生成 | 基于参与部门和协作场景，自动生成职责分配矩阵 |
| 沟通机制设计 | 根据部门关系和协作模式，输出沟通会议和信息同步方案 |
在步骤6生成文档前，使用 Agent 工具激活子任务并行执行。
| 维度 | V1.1.0（串行） | V2.0.0（Subagent并行） | 节省 |
|---|---|---|---|
| 职责分配 | 用户逐一回答决策权问题 | Agent并行生成RACI矩阵 | 约3轮交互 |
| 沟通设计 | 依次询问会议和信息方式 | Agent并行输出沟通方案 | 约2轮交互 |
| 总交互轮次 | 约8-10轮 | 约4-6轮 | 减少45%+ |
| 耗时估算 | 8-12分钟 | 5-7分钟 | 节省约5分钟 |
跨部门协作方案 → docs/04-风控管理/跨部门协作方案.md
# 跨部门协作方案
## 一、协作概况
- **参与部门**: [从步骤1提取]
- **协作场景**: [从步骤2提取]
- **协作模式**: [从步骤3提取]
- **生成时间**: [当前时间]
---
## 二、部门职责矩阵（RACI）
| 活动 | 产品 | 研发 | 设计 | 测试 | 运营 | 市场 |
|------|------|------|------|------|------|------|
| 需求定义 | R/A | C | C | C | C | I |
| 技术方案 | C | R/A | I | C | I | I |
| UI设计 | A | C | R | C | C | I |
| 开发实现 | I | R | C | C | I | I |
| 测试验收 | A | C | I | R | C | I |
| 上线发布 | A | R | I | C | R | C |
**图例**:
- **R (Responsible)**: 执行者
- **A (Accountable)**: 负责人（决策者）
- **C (Consulted)**: 被咨询者
- **I (Informed)**: 被告知者
---
## 三、协作流程设计
### 3.1 需求确认流程
产品部门 → 输出PRD ↓ 技术评审会 → 研发、测试、设计参与 ↓ 需求确认 → 各部门签字 ↓ 进入开发
**关键节点**:
- 需求评审通过
- 技术方案确认
- 测试用例确认
- 设计稿确认
### 3.2 设计评审流程
设计部门 → 输出设计稿 ↓ 设计评审会 → 产品、研发、测试参与 ↓ 修改完善 ↓ 设计稿定稿 → 产品签字确认
### 3.3 上线发布流程
测试完成 → 测试报告 ↓ 上线评审会 → 全部门参与 ↓ 发布计划确认 ↓ 执行上线 → 各部门配合
---
## 四、沟通机制
### 4.1 会议安排
| 会议类型 | 频率 | 参与者 | 时长 | 目的 |
|---------|------|--------|------|------|
| 项目启动会 | 项目开始时 | 全员 | 1小时 | 对齐目标、明确职责 |
| 周例会 | 每周五 | 各部门负责人 | 1小时 | 同步进度、协调问题 |
| 需求评审会 | 按需 | 产品+研发+测试+设计 | 2小时 | 确认需求细节 |
| 上线评审会 | 上线前 | 全员 | 1小时 | 上线前检查 |
### 4.2 信息同步渠道
**主要渠道**: [从步骤4提取]
**文档协作**:
- 产品需求文档: `docs/02-方案设计/PRD产品需求文档.md`
- 技术方案: `docs/02-方案设计/技术对接方案.md`
- 测试用例: `docs/02-方案设计/用户故事清单.md`
- 项目进度: `docs/03-增长迭代/迭代计划.md`
**沟通群组**:
- 项目总群: 全员（重要通知）
- 研发群: 技术讨论
- 需求群: 需求澄清
**定期报告**:
- 周报: 每周五发送
- 月报: 每月最后一周
- 里程碑报告: 关键节点
---
## 五、资源协调机制
### 5.1 资源申请流程
需求部门 → 提交资源申请单 ↓ 项目经理评估 → 影响范围、时间成本 ↓ 协调会议 → 双方部门负责人参与 ↓ 资源调配 → 明确时间、产出
### 5.2 冲突解决机制
**资源冲突场景**:
- 多项目竞争同一资源
- 时间冲突（不同项目档期重叠）
- 优先级冲突
**解决流程**:
1. 项目经理协调
2. 升级至部门负责人
3. 提交指导委员会决策
---
## 六、决策机制
### 6.1 决策类型
| 决策类型 | 决策者 | 评审者 | 咨询者 |
|---------|--------|--------|--------|
| 需求变更 | 产品负责人 | 研发负责人 | 测试、设计 |
| 技术选型 | 研发负责人 | 架构师 | 产品、测试 |
| 上线时间 | 项目经理 | 全部门 | - |
| 资源调配 | 部门负责人 | 项目经理 | 相关部门 |
### 6.2 决策记录
所有重大决策需记录在 `docs/04-风控管理/需求变更记录.md`:
- 决策内容
- 决策原因
- 决策者
- 决策时间
- 影响范围
---
## 七、协作工具推荐
### 7.1 文档协作
- **飞书文档**: 国内团队，实时协作
- **Notion**: 功能强大，模板丰富
- **语雀**: 阿里出品，知识库管理
### 7.2 项目管理
- **Jira**: 功能完善，适合大型项目
- **飞书项目**: 轻量级，集成度高
- **Trello**: 看板式，简单易用
### 7.3 沟通工具
- **飞书**: 一站式协作
- **企业微信**: 微信生态
- **钉钉**: 阿里生态
---
## 八、常见问题处理
### 8.1 需求变更频繁
**问题**: 产品频繁变更需求，研发疲于应付
**解决方案**:
- 建立需求冻结期（每个迭代前2天）
- 变更评审机制（评估影响与成本）
- 变更申请单（书面记录）
### 8.2 信息不同步
**问题**: 部门间信息不对称，重复沟通
**解决方案**:
- 单一信息源（统一文档平台）
- 定期同步会议（周会）
- 自动化通知（工具集成）
### 8.3 责任推诿
**问题**: 出现问题时互相推卸责任
**解决方案**:
- RACI矩阵明确职责
- 决策记录可追溯
- 复盘机制（而非追责）
---
## 九、协作质量评估
### 9.1 协作满意度
每迭代收集反馈：
- 沟通效率（1-5分）
- 信息同步及时性（1-5分）
- 决策效率（1-5分）
- 整体满意度（1-5分）
### 9.2 协作效率指标
- 会议时长占比
- 需求澄清次数
- 决策响应时间
- 跨部门问题数
---
## 十、下一步建议
建议执行：
1. /pm-risk（识别项目风险）
2. /pm-release（规划上线方案）
3. /pm-change（建立变更管理机制）
---
## 输出质量对比
**✅ Good 示例**：
**❌ Bad 示例**：
---
## 常见误区 / Red Flags — STOP
出现以下情况立即停止并回溯：
| 误区 | 正确做法 |
|------|---------|
| 使用"应该"、"大概"、"看起来"做结论 | 必须基于实际数据和验证 |
| 未运行检查就声称已完成 | 先验证，再陈述 |
| 因时间紧迫跳过关键步骤 | 没有例外，时间紧更要严格 |
| "这次应该没问题"的想法 | 每次都要重新验证 |
---
## 产出质量检查 / Verification Checklist
- [ ] 前置依赖已满足（输入文档/数据已收集）
- [ ] 核心步骤已全部执行
- [ ] 输出文档已生成到 `docs/` 目录
- [ ] 每个判断都有数据/证据支撑
- [ ] 已推荐 2-3 个后续 skill
> ⚠️ 任何一项未通过 → 补全后再标记完成。
---
**项目状态**: 跨部门协作方案已制定
**生成时间**: [时间戳]
**生成工具**: super-pm
执行完成后，输出：
✅ 跨部门协作方案已生成！
🎯 建议下一步：