pm-cross

Preamble

echo "🤝 跨部门协作方案制定工具已启动"

---

Boundaries when writing

When only discussing, do not write files; during startup checks, do not create directories. When the user requests to save artifacts, first confirm the current product, the exact output path, and the overwrite/append choice for existing files; after confirmation,only immediately before the actual Writecreate the parent directory of that output file. For complete installation, see skills/_shared/artifact-policy.md, and installing this skill separately also follows this paragraph.

---

Cross-Agent interaction rules

When the process requires interaction with the user:

1. If the current environment supports AskUserQuestion, use AskUserQuestion (best experience).
2. If the current environment does not support AskUserQuestion, you must ask the same question using a normal chat message.
3. Ask only one question at a time.
4. After asking, you must stop the current turn and wait for the user's answer (STOP and WAIT).
5. Do not generate documents or write to docs before the user answers.
6. Existing docs files cannot replace the user's answer in this round.

---

Execution process

Step 1: Identify participating departments

Use AskUserQuestion:

🏢 Participating department identification

Which departments are involved in this project? (multiple choice)

A) Product department (requirements definition, acceptance) B) R&D department (technical implementation) C) Design department (UI/UX design) D) Testing department (quality assurance) E) Operations department (promotion, user feedback) F) Marketing department (brand, publicity) G) Customer service department (user support) H) Legal department (compliance review) I) Finance department (budget approval) J) Other departments (please enter manually)

Step 2: Clarify collaboration scenarios

Use AskUserQuestion:

🔗 Collaboration scenario identification

Main cross-department collaboration scenarios:

A) Requirements confirmation and review B) Design draft review C) Technical solution review D) Test case review E) Release review F) Problem investigation and resolution G) Multiple combinations

Step 3: Design the collaboration process

Use AskUserQuestion:

📋 Collaboration process mode

Choose the strictness level of the collaboration process:

A) Formal process (multi-level approval, complete documentation) B) Standard process (review at key nodes) C) Flexible process (fast communication, lightweight documentation)

Continue asking:

🔄 Collaboration dependencies

Are there strong dependencies between departments?

A) Serial dependency (Department A completes → Department B starts) B) Parallel collaboration (multiple departments proceed simultaneously) C) Hybrid mode (partly serial, partly parallel)

Step 4: Design the communication mechanism

Use AskUserQuestion:

💬 Communication meeting frequency

Frequency of cross-department communication meetings:

A) Daily (quick sync) B) Weekly (weekly meeting) C) Every iteration (iteration review) D) On demand (held when there are important matters)

Continue asking:

📢 Information synchronization method

Main methods for project information synchronization:

A) Document collaboration (Notion/Feishu Docs) B) Group communication (WeChat group/Feishu group) C) Email notification D) Project management tools (Jira/Trello) E) A combination of multiple methods

Step 5: Clarify the division of responsibilities

Use AskUserQuestion:

🎯 Decision-Making Authority

Who is responsible for key decisions:

A) Product Owner (PO) decides B) Project Manager (PM) coordinates decisions C) Committee decision-making (multiple department heads) D) Tiered decision-making (divided by decision type)

Step 6: Generate Cross-Department Collaboration Plan

Use the Write tool to generate docs/04-风控管理/跨部门协作方案.md。

---

Subagent Parallel Acceleration (New in v2.0.0)

Use the Agent tool to execute independent subtasks in parallel, greatly shortening total execution time.

Parallelizable Subtasks

Once the user information collection in Steps 1-2 is complete, the following two tasks can be executed in parallel:

Subtask	Description
RACI Matrix Generation	Automatically generate a responsibility assignment matrix based on participating departments and collaboration scenarios
Communication Mechanism Design	Output communication meeting and information synchronization plans based on department relationships and collaboration modes

Trigger Method

Before generating the document in Step 6, use the Agent tool to activate parallel execution of subtasks.

V1 vs V2 Comparison

Dimension	V1.1.0 (Serial)	V2.0.0 (Subagent Parallel)	Savings
Responsibility Assignment	User answers decision-making authority questions one by one	Agent generates RACI matrix in parallel	About 3 rounds of interaction
Communication Design	Ask about meetings and information methods sequentially	Agent outputs communication plan in parallel	About 2 rounds of interaction
Total Interaction Rounds	About 8-10 rounds	About 4-6 rounds	Reduced by 45%+
Estimated Time	8-12 minutes	5-7 minutes	Saves about 5 minutes

---

Output File

Cross-Department Collaboration Plan → docs/04-风控管理/跨部门协作方案.md

---

Output Document Template

# 跨部门协作方案

## 一、协作概况

- **参与部门**: [从步骤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 需求确认流程

Product Department → Output PRD ↓ Technical Review Meeting → R&D, Testing, Design participate ↓ Requirements Confirmation → Sign-off by each department ↓ Enter Development

**关键节点**:
- 需求评审通过
- 技术方案确认
- 测试用例确认
- 设计稿确认

### 3.2 设计评审流程

Design Department → Output Design Draft ↓ Design Review Meeting → Product, R&D, Testing participate ↓ Revision and Improvement ↓ Design Draft Finalized → Product sign-off confirmation

### 3.3 上线发布流程

Testing Complete → Test Report ↓ Launch Review Meeting → All departments participate ↓ Release Plan Confirmation ↓ Execute Launch → Coordination across departments

---

## 四、沟通机制

### 4.1 会议安排

| 会议类型 | 频率 | 参与者 | 时长 | 目的 |
|---------|------|--------|------|------|
| 项目启动会 | 项目开始时 | 全员 | 1小时 | 对齐目标、明确职责 |
| 周例会 | 每周五 | 各部门负责人 | 1小时 | 同步进度、协调问题 |
| 需求评审会 | 按需 | 产品+研发+测试+设计 | 2小时 | 确认需求细节 |
| 上线评审会 | 上线前 | 全员 | 1小时 | 上线前检查 |

### 4.2 信息同步渠道

**主要渠道**: [从步骤4提取]

**文档协作**:
- 产品需求文档: `docs/02-方案设计/PRD产品需求文档.md`
- 技术方案: `docs/02-方案设计/技术对接方案.md`
- 测试用例: `docs/02-方案设计/用户故事清单.md`
- 项目进度: `docs/03-增长迭代/迭代计划.md`

**沟通群组**:
- 项目总群: 全员（重要通知）
- 研发群: 技术讨论
- 需求群: 需求澄清

**定期报告**:
- 周报: 每周五发送
- 月报: 每月最后一周
- 里程碑报告: 关键节点

---

## 五、资源协调机制

### 5.1 资源申请流程

Requesting Department → Submit Resource Request Form ↓ Project Manager Assessment → Impact scope, time cost ↓ Coordination Meeting → Heads of both departments participate ↓ Resource Allocation → Clarify timing and deliverables

### 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 示例**：

• Has data references: "According to Q4 data, the retention rate dropped from 35% to 28%"
• Has verification sources: "Data source: Google Analytics, 2025-12-01"
• Has clear recommendations: "Recommend reducing the onboarding steps from 5 to 3"

**❌ Bad 示例**：

• Vague conclusion: "Data shows the retention rate has declined somewhat"
• No source: "Based on experience, this feature is very important"
• No action recommendations: "Retention is a problem"

---

## 常见误区 / Red Flags — STOP

出现以下情况立即停止并回溯：

| 误区 | 正确做法 |
|------|---------|
| 使用"应该"、"大概"、"看起来"做结论 | 必须基于实际数据和验证 |
| 未运行检查就声称已完成 | 先验证，再陈述 |
| 因时间紧迫跳过关键步骤 | 没有例外，时间紧更要严格 |
| "这次应该没问题"的想法 | 每次都要重新验证 |

---

## 产出质量检查 / Verification Checklist

- [ ] 前置依赖已满足（输入文档/数据已收集）
- [ ] 核心步骤已全部执行
- [ ] 输出文档已生成到 `docs/` 目录
- [ ] 每个判断都有数据/证据支撑
- [ ] 已推荐 2-3 个后续 skill

> ⚠️ 任何一项未通过 → 补全后再标记完成。

---

**项目状态**: 跨部门协作方案已制定
**生成时间**: [时间戳]
**生成工具**: super-pm

---

Recommended Next Steps

After execution is complete, output:

✅ Cross-department collaboration plan has been generated!

🎯 Recommended next steps:

1. /pm-risk (Identify project risks)
2. /pm-release (plan the launch plan)
3. /pm-change (establish a change management mechanism)