pm-resource

name	pm-resource
description	Use when: 需要在多个产品间分配研发资源、进行ROI评估、解决资源冲突、团队规划 Do NOT use when: 资源充足无需分配优先级、单产品无需多项目协调
allowed-tools	["Agent","Read","Write","AskUserQuestion","Bash","WebSearch","mcp__exa__web_search_exa","mcp__exa__web_fetch_exa"]

Preamble (run first)

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/05-产品战略

# 检查是否有产品组合战略作为输入
if [ -f "docs/05-产品战略/产品组合战略.md" ]; then
  echo "✅ 检测到产品组合战略文档，将基于此进行资源分配"
else
  echo "⚠️  未检测到产品组合战略文档，建议先执行 /pm-portfolio"
fi

---

跨 Agent 交互规则

当流程要求与用户交互时：

1. 如果当前环境支持 AskUserQuestion，使用 AskUserQuestion（最佳体验）。
2. 如果当前环境不支持 AskUserQuestion，必须用普通聊天消息提出同样问题。
3. 一次只问一个问题。
4. 提问后必须停止当前回合，等待用户回答（STOP and WAIT）。
5. 不得在用户回答前生成文档、写入 docs。
6. 已有 docs 文件不能替代本轮用户回答。

---

执行流程

步骤 1: 读取前置数据

优先读取：

• docs/05-产品战略/产品组合战略.md

如果文件不存在，提示用户：

⚠️ 未找到产品组合战略文档

您可以选择： A) 先执行 /pm-portfolio 进行产品组合分析 B) 手动输入产品列表（快速模式）

---

步骤 2: 盘点可用资源

询问方式：使用 AskUserQuestion 逐个询问

---

问题 1: 研发团队规模

使用 AskUserQuestion 询问：

请问研发团队总人数？

A) 10人以下（小团队） B) 10-30人（中小团队） C) 30-50人（中型团队） D) 50-100人（大型团队） E) 100人以上（超大型团队） F) 其他（请手动输入）

---

问题 2: 可投入资源比例

本季度可投入新产品/项目的研发资源比例？

A) <20%（主要维护现有产品） B) 20-40%（小部分资源可投入新项目） C) 40-60%（资源较充足） D) 60-80%（重点投入新项目） E) >80%（全力投入新产品）

---

问题 3: 关键角色配置

团队中关键角色的配置情况？

逐个询问：

• 产品经理人数：[数字]
• 前端工程师人数：[数字]
• 后端工程师人数：[数字]
• 测试工程师人数：[数字]
• 运维工程师人数：[数字]
• 设计师人数：[数字]

---

问题 4: 资源约束条件

当前资源分配面临的主要约束是？（可多选）

A) 人力不足 B) 预算限制 C) 时间紧迫 D) 技术能力不足 E) 其他（请手动输入）

---

步骤 3: 产品资源需求评估

根据步骤1读取的产品列表，逐个评估资源需求：

---

针对每个产品询问：

评估项 1: 资源需求量

{产品名称}本季度需要的研发人力？

A) 极高（需要团队主力投入） B) 高（需要大量人力） C) 中（需要适中人力） D) 低（少量人力即可） E) 维护模式（仅需维护人力）

评估项 2: ROI预期

{产品名称}投入产出比（ROI）预期如何？

A) 极高ROI（投入1元，产出>10元） B) 高ROI（投入1元，产出5-10元） C) 中ROI（投入1元，产出2-5元） D) 低ROI（投入1元，产出<2元） E) 暂无ROI（战略投资期）

评估项 3: 时间紧迫性

{产品名称}的上线时间紧迫性？

A) 极紧迫（必须本季度上线） B) 紧迫（下季度必须上线） C) 适中（半年内上线即可） D) 不紧迫（一年内上线即可） E) 无明确时间要求

评估项 4: 风险等级

{产品名称}的开发风险等级？

A) 高风险（技术难度大、不确定性高） B) 中风险（有一定技术挑战） C) 低风险（技术成熟、风险可控） D) 极低风险（常规开发）

---

步骤 4: 资源分配决策

决策逻辑：

1. 优先级评分模型

每个产品计算优先级得分：

优先级得分 = ROI得分 × 0.4 + 时间紧迫性得分 × 0.3 + 战略重要性得分 × 0.3 - 风险扣分

2. 资源分配矩阵

优先级	资源占比	说明
P0（最高）	30-40%	必须完成的核心项目
P1（高）	20-30%	重要项目，保证交付
P2（中）	10-20%	次要项目，按资源情况调整
P3（低）	<10%	探索性项目，资源充足时执行

3. 冲突解决机制

当资源需求 > 可用资源时：

• 优先保证P0项目
• 延迟P2-P3项目
• 考虑外包或招聘

---

步骤 5: 生成资源分配方案

使用 Write 工具生成文档：

---
product: [产品组合]
created_at: [当前时间]
author: [用户]
skill: pm-resource
status: draft
---

# 资源分配方案

## 一、资源盘点

### 可用资源

**团队规模**: [X]人
**可投入新项目比例**: [X]%
**可用人力**: [X]人月

**关键角色配置**：
- 产品经理: [X]人
- 前端工程师: [X]人
- 后端工程师: [X]人
- 测试工程师: [X]人
- 运维工程师: [X]人
- 设计师: [X]人

**资源约束**：[人力不足/预算限制/时间紧迫...]

---

## 二、产品资源需求

| 产品名称 | 资源需求 | ROI预期 | 时间紧迫性 | 风险等级 | 战略重要性 |
|---------|---------|---------|-----------|---------|-----------|
| [产品A] | 极高 | 极高 | 极紧迫 | 中 | 核心战略 |
| [产品B] | 中 | 高 | 适中 | 低 | 重要战略 |
| ... | ... | ... | ... | ... | ... |

---

## 三、优先级排序

### P0级项目（最高优先级）

**项目列表**: [产品A, 产品C]

**优先级得分**: [90分, 85分]

**分配资源**: 35%人力

**理由**：
- [产品A]: ROI极高 + 时间紧迫 + 核心战略
- [产品C]: 高ROI + 明星产品阶段

---

### P1级项目（高优先级）

**项目列表**: [产品B]

**优先级得分**: [75分]

**分配资源**: 25%人力

**理由**：
- [产品B]: 现金牛产品，稳定收益

---

### P2级项目（中优先级）

**项目列表**: [产品D]

**优先级得分**: [60分]

**分配资源**: 15%人力

**理由**：
- [产品D]: 问题产品，需要验证

---

### P3级项目（低优先级）

**项目列表**: [产品E]

**优先级得分**: [45分]

**分配资源**: 5%人力

**理由**：
- [产品E]: 瘦狗产品，最小化投入

---

## 四、详细资源分配

### 季度资源分配表

| 产品名称 | 分配人力 | 前端 | 后端 | 测试 | 产品 | 设计 | 上线时间 |
|---------|---------|------|------|------|------|------|---------|
| [产品A] | 15人月 | 3人 | 5人 | 2人 | 2人 | 1人 | 3月底 |
| [产品B] | 10人月 | 2人 | 3人 | 2人 | 1人 | 1人 | 4月底 |
| [产品C] | 8人月 | 2人 | 2人 | 1人 | 1人 | 1人 | 5月底 |
| [产品D] | 5人月 | 1人 | 1人 | 1人 | 1人 | 0.5人 | 待定 |
| [产品E] | 2人月 | 0.5人 | 0.5人 | 0.5人 | 0.3人 | 0.2人 | 仅维护 |

---

## 五、资源冲突与解决方案

### 冲突1: 后端工程师不足

**问题描述**：
- 需求：15人
- 可用：10人
- 缺口：5人

**解决方案**：
1. 短期：外包3人，临时支援2人
2. 长期：招聘2人，培养内部人才3人

---

### 冲突2: 产品上线时间冲突

**问题描述**：
- 产品A和产品C都需要3月底上线
- 资源无法同时满足

**解决方案**：
1. 产品A优先上线（核心战略）
2. 产品C延后至4月中旬
3. 增加产品C的开发资源

---

## 六、风险控制

### 风险1: 关键人员离职

**影响**: 核心项目进度延误
**应对**:
- 建立知识转移机制
- 培养2名备份人员
- 关键模块文档化

### 风险2: 技术难度超预期

**影响**: 项目延期或失败
**应对**:
- 提前进行技术预研
- 预留20%缓冲时间
- 建立技术专家支持机制

---

## 七、监控指标

### 资源利用率

- 目标：80-85%利用率
- 监控频率：每周
- 预警阈值：<70% 或 >90%

### 项目进度偏差

- 目标：<10%偏差
- 监控频率：每周
- 预警阈值：>20%偏差

### ROI达成率

- 目标：>80%预期ROI
- 监控频率：每月
- 预警阈值：<50%预期ROI

---

## 八、下一步建议

建议执行：
1. /pm-decision - 战略决策支持（如外包、招聘等决策）
2. /pm-roadmap - 制定产品路线图
3. /pm-agile - 敏捷管理执行

---

**项目状态**: 资源分配方案制定完成
**生成时间**: [当前时间]
**生成工具**: super-pm

---

V2 并行架构升级

Subagent 并行分析

在资源盘点完成后，可派发 subagent 并行执行：

Agent 1: 团队产能调研

• 负责：基于历史数据估算团队产能、各产品线所需人力

Agent 2: 行业 ROI 基准查询

• 负责：搜索同行业资源投入产出比基准数据
• 搜索工具优先级：首选 AnySearch（Bash 调用 anysearch_cli.py（先定位：检查 ~/.claude/skills/anysearch/scripts/ ~/.opencode/skills/anysearch/scripts/ ~/.openclaw/skills/anysearch/scripts/ ~/.cursor/skills/anysearch/scripts/ ~/.anysearch/scripts/ 或 which anysearch_cli.py，找到后 python3 <路径>）search），失败降级到 Exa MCP（mcp__exa__web_search_exa），最后才用 WebSearch。使用 WebSearch 时标注降级模式

V1 vs V2 对比

维度	v1（串行）	v2（Subagent 并行）
产能评估	主 agent 大致估算	Subagent 基于数据评估
行业基准	无对比数据	Subagent 自动获取基准
Token 占用	分析占主上下文	Subagent 独立处理
执行效率	线性顺序	并行 2x 加速

---

注意事项

1. 资源缓冲：建议预留10-15%资源作为缓冲
2. 动态调整：每月根据项目进展调整资源分配
3. 风险预案：提前制定关键人员离职、技术难题等应对方案
4. ROI跟踪：定期复盘资源投入的实际产出

---

输出质量对比

✅ Good 示例：

- 有数据引用：「根据 Q4 数据，留存率从 35% 降至 28%」
- 有验证来源：「数据来源：Google Analytics, 2025-12-01」
- 有明确建议：「建议将新手引导步骤从 5 步减少至 3 步」

❌ Bad 示例：

- 模糊结论：「数据表明留存率有所下降」
- 无来源：「根据经验，这个功能很重要」
- 没有行动建议：「留存是个问题」

---

常见误区 / Red Flags — STOP

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

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

---

产出质量检查 / Verification Checklist

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

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

---