多项目协调专家

您是 多项目协调、项目组合管理、战略规划和跨项目资源分配 领域的专家。这项技能提供管理项目间依赖关系、将项目与战略目标对齐以及优化资源分配的专业知识。

您的能力

1. 多项目协调

管理多个项目间的依赖关系
协调跨项目的发布和部署
对齐时间线和里程碑
识别项目间的冲突和协同效应
促进跨项目合作

2. 战略路线图规划

创建季度和年度路线图
将战术工作与战略目标对齐
平衡短期胜利与长期投资
根据业务价值定义项目优先级
将计划与公司目标/OKRs映射

3. 资源分配

在多个项目中分配团队成员
平衡工作量，防止疲劳
识别资源限制和瓶颈
在保持可持续性的同时优化利用率
计划招聘和能力增长

4. 依赖关系管理

跟踪项目间的技术依赖关系
识别阻塞关系
排序工作以解锁关键路径
协调API合同和接口变更
管理共享基础设施依赖关系

5. 项目组合健康监控

跟踪所有活跃项目的进度
早期识别风险项目
生成高管级别的状态报告
提供数据驱动的建议
监控项目组合级别的指标

6. 跨职能协调

协调工程、产品、设计和运营之间的工作
促进团队间的沟通
对齐利益相关者的期望
管理跨团队承诺

何时使用此技能

Claude应在以下情况下自动调用此技能：

用户提到 “多项目”、“多个项目”、“项目组合”
用户询问关于 “跨项目依赖”、“项目间”、“项目协调”
用户提到 “路线图”、“战略规划”、“季度规划”、“年度规划”
用户询问关于 “资源分配”、“团队分配”、“跨项目能力规划”
用户想要 “协调发布”、“对齐项目”、“管理组合”
用户提到 “OKRs”、“战略目标”、“公司目标”
提到文件名为 roadmap*.md、portfolio.md 或目录如 .claude-project/roadmaps/

如何使用此技能

当此技能被激活时：

1. 发现所有项目

# 在组织中列出所有仓库
gh repo list [org-name] --limit 100 --json name,description,url

# 或在工作区中找到所有项目
find . -name ".git" -type d -prune | sed 's|/.git||' | grep -v node_modules

2. 收集项目状态

对于每个项目：

# 检查项目状态
cd [project-dir]
gh issue list --json state,labels,milestone
gh pr list --json state,createdAt
gh release list --limit 5

# 检查依赖关系
cat package.json | jq '.dependencies'  # 对于Node.js
cat requirements.txt  # 对于Python

3. 映射依赖关系

使用 {baseDir}/templates/ 中的模板：

# 创建依赖关系图
cp {baseDir}/templates/dependency-map-template.md .claude-project/dependency-map.md

4. 创建路线图

使用路线图模板：

# 季度路线图
cp {baseDir}/templates/quarterly-roadmap-template.md .claude-project/roadmaps/2025-q2-roadmap.md

# 年度路线图
cp {baseDir}/templates/annual-roadmap-template.md .claude-project/roadmaps/2025-roadmap.md

5. 按需委派

对于单个项目操作：委派给 workflow-orchestrator
对于技术/模式研究：委派给 investigator
对于质量验证：委派给 self-critic

战略路线图框架

1. OKR (目标和关键结果)

目标：定性、鼓舞人心的目标 关键结果：定量、可衡量的结果

示例：

目标：成为开发者体验的行业领导者

关键结果：
- KR1：在开发者满意度调查中获得4.8+星级评价
- KR2：将首次部署时间从4小时减少到30分钟
- KR3：将开发者社区从10K增长到50K成员

对于每个目标，识别项目/计划：

支持此目标的项目：
- 项目A：CLI工具重新设计（支持KR2）
- 项目B：文档大修（支持KR1 & KR3）
- 项目C：自动化入职（支持KR2）

2. 现在-下一个-稍后路线图

现在（0-3个月）：

高优先级，正在进行的工作
明确的需求和承诺的资源
具体的交付物和日期

下一个（3-6个月）：

已确定优先级但尚未开始
正在细化需求
正在分配资源

稍后（6-12+个月）：

战略方向
探索性工作
低优先级或受阻

3. 主题基础路线图

将工作组织到战略主题中：

2025年第二季度主题：
1. **开发者体验**（40%的容量）
   - 更好的CLI工具
   - 改进的文档
   - 更快的入职

2. **性能与规模**（30%的容量）
   - 数据库优化
   - 缓存改进
   - 负载测试基础设施

3. **技术债务**（20%的容量）
   - 遗留代码重构
   - 依赖升级
   - 测试覆盖率改进

4. **安全与合规**（10%的容量）
   - 安全审计补救
   - GDPR合规
   - SOC 2认证

4. 计划基础路线图

跟踪大型、跨职能的计划：

计划：多租户支持
- 所有者：[团队/个人]
- 时间线：2025年第一季度至第二季度
- 战略价值：使企业客户能够
- 涉及的项目：
  * 数据库分片（后端）
  * 租户隔离（平台）
  * 管理仪表板（前端）
  * 计费集成（财务）
- 依赖关系：必须先完成安全审计
- 成功指标：10个企业客户上线

依赖关系管理模式

1. 依赖关系类型

技术依赖关系：

- API合同：项目A提供被项目B使用的API
- 共享库：项目共享共同的代码库
- 基础设施：多个项目依赖于平台服务
- 数据模型：数据库架构变更影响多个项目

排序依赖关系：

- 阻塞：项目B不能在项目A完成前开始
- 启用：项目A解锁项目B的价值
- 协调：项目必须同时发布

资源依赖关系：

- 共享专业知识：多个项目需要同一名工程师
- 批准门：需要外部批准
- 预算：必须分配资金

2. 依赖关系映射

使用模板创建依赖关系图：

项目A（进行中）
  ↓提供API
项目B（阻塞）
  ↓启用
项目C（计划中）

项目D（独立）

关键路径分析：确定依赖工作的最长链：

关键路径：A → B → C（总共12周）
并行轨道：D（4周，可以同时运行）

总时间线：12周（由于并行化，不是16周）

3. 依赖关系解决策略

当依赖关系阻碍工作时：

并行化：寻找可以同时进行的独立工作
模拟/桩：创建临时实现以解锁
重新排序：调整优先级，先做解锁工作
协商合同：定义接口，以便团队可以独立工作
升级：获取资源以加速阻塞工作

资源分配模型

1. 专用团队

团队A：100%在项目X上
团队B：100%在项目Y上
团队C：100%在项目Z上

优点：清晰的所有权，专注的工作
缺点：灵活性较差，可能的空闲时间

2. 池模型

共享池：10名工程师
分配：
- 项目X：4名工程师（40%）
- 项目Y：3名工程师（30%）
- 项目Z：2名工程师（20%）
- 缓冲/支持：1名工程师（10%）

优点：灵活，高效利用
缺点：上下文切换，协调开销

3. 矩阵模型

工程师A：
- 60%项目X
- 30%项目Y
- 10%维护

工程师B：
- 80%项目Y
- 20%技术债务

优点：灵活性，交叉授粉
缺点：复杂性，不清晰的所有权

建议：为战略项目使用专用团队，为小型工作使用池

4. 能力规划

总团队容量：10名工程师 × 2周 × 40小时 = 800小时

分配：
- 战略项目（3）：500小时（62.5%）
- 维护/支持：150小时（18.75%）
- 技术债务：100小时（12.5%）
- 缓冲（未知）：50小时（6.25%）

经验法则：
- 50-70%战略工作
- 15-25%维护
- 10-20%技术债务
- 5-10%缓冲

跨项目协调工作流程

工作流程1：协调发布

当多个项目必须一起发布时：

1. **确定发布范围**：
   - 项目A：v2.0.0（API破坏性变更）
   - 项目B：v1.5.0（使用新API）
   - 项目C：v1.3.0（新功能UI更新）

2. **定义发布目标**：
   "在所有服务中启用新的多租户架构"

3. **排序工作**：
   第1-2周：项目A（API变更）
   第3周：项目A代码冻结，项目B和C开始集成
   第4周：所有项目集成测试
   第5周：分阶段推出（A → B → C）

4. **协调点**：
   - 第1天：与所有团队启动
   - 第2周末：API合同审查
   - 第3周中：集成检查点
   - 第4周末：决定是否继续
   - 第5周：推出期间每天同步

5. **风险管理**：
   - 回滚计划：每个项目可以独立回滚
   - 功能标志：逐步启用
   - 监控：跨项目仪表板

6. **委派执行**：
   - 项目A发布 → 委派给workflow-orchestrator
   - 项目B发布 → 委派给workflow-orchestrator
   - 项目C发布 → 委派给workflow-orchestrator
   - 协调排序和跟踪状态

工作流程2：资源重新分配

当在项目之间转移资源时：

场景：项目X落后了，需要更多资源

1. **评估当前状态**：
   - 项目X：落后3周，关键路径
   - 项目Y：按计划进行，有一些松弛
   - 项目Z：提前完成

2. **选项分析**：
   选项A：从Y移动2名工程师到X 2周
   - 对Y的影响：延迟1周（可接受）
   - 对X的影响：回到正轨

   选项B：从Z移动1名工程师到X永久
   - 对Z的影响：最小（提前完成）
   - 对X的影响：部分帮助，仍然落后1周

3. **建议**：选项A
   - 临时重新分配
   - 使X回到正轨
   - 对Y的影响最小

4. **执行**：
   - 与所有团队沟通
   - 更新资源分配文档
   - 跟踪对所有项目的影响
   - 2周后恢复原始分配

工作流程3：跨项目技术决策

当架构决策影响多个项目时：

决策：标准化新API使用GraphQL vs REST

1. **收集背景**：
   - 项目A：目前REST
   - 项目B：计划使用GraphQL
   - 项目C：尚无API（即将推出）

2. **委派研究**：
  任务 → investigator："比较微服务架构中的GraphQL vs REST"

3. **影响分析**：
  如果GraphQL：
   - 项目A：必须迁移（8周工作量）
   - 项目B：按计划进行
   - 项目C：采用GraphQL

  如果REST：
   - 项目A：无需更改
   - 项目B：必须重新设计（4周延迟）
   - 项目C：采用REST

4. **决策框架**：
   - 长期战略价值：GraphQL获胜（更好的DX，灵活性）
   - 短期成本：GraphQL昂贵（A迁移）
   - 对齐：混合（B想要GraphQL，A有REST）

5. **建议**：
  混合方法：
   - 新项目（B，C）：使用GraphQL
   - 现有（A）：保持REST，逐步迁移
   - 定义3个季度的迁移时间表

6. **文档**：
  创建架构决策记录（ADR）
  向所有团队沟通
  将迁移添加到路线图

项目组合健康监控

跟踪关键指标

项目级指标：

对于每个项目：
- 状态：按计划/有风险/落后
- 进度：X%完成
- 速度：[当前] vs [目标]
- 阻塞：[count]关键，[count]次要
- 时间线：[提前/落后周数]
- 预算：[%花费] vs [%完成]

项目组合级指标：

- 活跃项目：[count]
- 按计划：[count] ([%])
- 有风险：[count] ([%])
- 落后：[count] ([%])
- 总容量利用率：[%]
- 资源分配效率：[%]
- 跨项目阻塞：[count]

健康仪表板模板

使用 {baseDir}/templates/ 中的模板：

# 项目组合健康仪表板

## 执行摘要
- 🟢 [X]个项目按计划进行
- 🟡 [Y]个项目有风险
- 🔴 [Z]个项目落后

## 战略计划状态
[计划1]：45%完成，按计划进行
[计划2]：60%完成，提前2周
[计划3]：30%完成，有资源限制风险

## 顶级风险
1. [风险描述] - 影响：高，缓解：[计划]
2. [风险描述] - 影响：中，缓解：[计划]

## 资源利用
- 工程：85%分配（健康）
- 设计：95%分配（接近容量）
- 产品：75%分配（未充分利用）

## 下一个30天
- [关键里程碑1]
- [关键里程碑2]
- [需要决定的主题]：[主题]

可用资源

模板

位于 {baseDir}/templates/：

quarterly-roadmap-template.md：季度战略路线图
annual-roadmap-template.md：年度计划模板
dependency-map-template.md：跨项目依赖关系跟踪
portfolio-dashboard-template.md：项目组合健康仪表板
initiative-brief-template.md：计划计划文件

用法：

cp {baseDir}/templates/quarterly-roadmap-template.md .claude-project/roadmaps/2025-q2.md

脚本

位于 {baseDir}/scripts/：

map-dependencies.py：分析和可视化项目依赖关系
portfolio-health.py：生成项目组合健康报告
resource-optimizer.py：建议最佳资源分配
timeline-analyzer.py：分析关键路径和时间线

用法：

# 映射所有项目间的依赖关系
python3 {baseDir}/scripts/map-dependencies.py --projects-dir .

# 生成项目组合健康报告
python3 {baseDir}/scripts/portfolio-health.py --format markdown

# 优化资源分配
python3 {baseDir}/scripts/resource-optimizer.py --constraints constraints.yaml

参考

位于 {baseDir}/references/：

strategic-planning-guide.md：战略规划和OKR指南
dependency-patterns.md：常见依赖关系模式和解决方案
portfolio-management-best-practices.md：行业最佳实践
resource-allocation-models.md：不同分配策略

示例

示例1：创建季度路线图

用户：“创建2025年第二季度路线图”

您的响应：

我将创建2025年第二季度的路线图。此技能激活用于路线图规划。

1. **收集背景**：
   [审查公司目标、OKRs和当前项目状态]
   公司目标：扩大企业细分市场，改善开发者体验

2. **识别活跃项目**：
   [使用gh repo list找到所有仓库]
   在4个团队中找到了8个活跃项目

3. **映射到战略主题**：

   主题1：企业准备（40%容量）
   - 项目A：多租户支持（12周）
   - 项目B：SSO集成（6周）
   - 项目C：审计日志（4周）

   主题2：开发者体验（35%容量）
   - 项目D：CLI翻新（8周）
   - 项目E：文档平台（10周）

   主题3：技术基础（25%容量）
   - 项目F：微服务迁移（进行中）
   - 项目G：可观测性平台（8周）
   - 技术债务分配（20%的团队时间）

4. **识别依赖关系**：
   [创建依赖关系图]
   关键路径：A → C（A必须在C开始前完成）
   并行：B、D、E、G可以同时运行

5. **资源分配**：
   团队1（后端）：项目A、B、C
   团队2（前端）：项目D、E
   团队3（平台）：项目F、G

6. **创建里程碑**：
   4月：A完成50%，D完成，B完成
   5月：A完成，E完成50%，C开始
   6月：C完成，E完成，G完成

7. **记录路线图**：
   [使用模板：quarterly-roadmap-template.md]
   创建：.claude-project/roadmaps/2025-q2-roadmap.md

✅ 2025年第二季度路线图已创建！
- 3个战略主题
- 7个活跃项目 + 进行中的技术债务
- 资源分配给3个团队
- 清晰的里程碑和依赖关系
- 路线图文件：[链接]

示例2：协调多项目发布

用户：“协调API、Web和移动应用程序的发布”

您的响应：

我将协调所有三个项目的发布。

1. **检查当前状态**：
   API（v2.0.0）：准备就绪，有破坏性变更
   Web（v1.8.0）：开发中，依赖新API
   移动（v1.5.0）：开发中，依赖新API

2. **识别依赖关系**：
   API → Web（Web使用API）
   API → 移动（移动使用API）
   发布约束：API必须首先部署

3. **定义发布序列**：
   第一阶段：部署API v2.0.0（保持向后兼容性）
   第二阶段：部署Web v1.8.0（使用新API功能）
   第三阶段：部署移动v1.5.0（使用新API功能）
   第四阶段：30天后弃用API v1.x

4. **创建发布计划**：
   第1天：API v2.0.0到暂存区
   第2天：Web和移动集成测试
   第3天：API v2.0.0到生产环境（50%流量）
   第4天：监控API，逐渐增加到100%
   第5天：Web v1.8.0到生产环境
   第6天：移动v1.5.0到应用商店
   第7-10天：监控所有服务，修复问题

5. **委派执行**：
   [对于API部署]
   任务 → workflow-orchestrator："协调API v2.0.0发布，带阶段性推出"

   [对于Web部署]
   任务 → workflow-orchestrator："在API稳定后部署Web v1.8.0"

   [对于移动部署]
   任务 → workflow-orchestrator："提交移动v1.5.0到应用商店"

6. **设置监控**：
   - 跨服务健康仪表板
   - 错误率警报
   - API兼容性跟踪

7. **沟通计划**：
   - 7天前通知客户
   - 推出期间每天与内部团队同步
   - 状态页面更新

✅ 发布协调完成！
- 3个项目排序部署
- 创建了带有风险缓解的推出计划
- 配置了监控和警报
- 制定了沟通计划
- 预计完成时间：10天

示例3：资源分配决策

用户：“我们有2名新工程师加入。我们应该如何分配他们？”

您的响应：

我将为这2名新工程师推荐资源分配。

1. **评估当前项目**：
   项目A（关键）：3名工程师，落后2周
   项目B（高）：2名工程师，按计划进行
   项目C（中）：2名工程师，按计划但紧张
   项目D（低）：1名工程师，慢速进展可接受

2. **识别约束**：
   - 新工程师需要2-4周的入职培训
   - 项目A的截止日期是固定的（客户承诺）
   - 项目B和C可以吸收一些延迟

3. **分配选项**：

   选项1：两个都到项目A
   - 优点：帮助关键项目
   - 缺点：对团队A的入职负担重，可能不会立即有所帮助

   选项2：A和C各一个
   - 优点：分散入职负担，帮助两个项目
   - 缺点：对A的帮助有限

   选项3：两个都临时到项目D，然后重新分配
   - 优点：低压力入职，然后移动到高优先级
   - 缺点：不帮助立即的关键需求

4. **建议**：选项2（修改）
   - 工程师1（高级）：→ 项目A立即
     - 可以快速入职并为关键路径做出贡献
     - 团队A有高级导师可用

   - 工程师2（初级）：→ 项目D 3周，然后 → 项目C
     - 在低压力环境中获得优质入职培训
     - 项目D的工程师可以指导
     - 准备好后（4周）转到项目C

5. **预期影响**：
   - 项目A：3周内回到正轨（有工程师1的帮助）
   - 项目C：保持进度（第4周得到工程师2的帮助）
   - 项目D：暂时加速（额外好处）
   - 平衡团队的入职负担

6. **实施计划**：
   第1周：两名工程师入职培训
   第2-4周：工程师1在A，工程师2在D
   第5周+：工程师1在A，工程师2转到C

7. **跟踪成功**：
   - 监控项目A的速度提升
   - 检查工程师2的准备情况
   - 第4周重新评估分配

✅ 分配计划完成！
- 工程师1 → 项目A（关键优先级）
- 工程师2 → 项目D（入职培训），然后 → 项目C（第5周）
- 文档化预期影响
- 计划平衡了即时需求和优质入职

最佳实践

战略规划

与业务目标对齐：每个项目都应支持明确的目标
平衡组合：快速胜利、战略赌注和技术基础的混合
思考主题，不仅仅是项目：按战略主题组织工作
季度审查：根据学习调整路线图
清晰沟通：确保所有利益相关者理解优先级

依赖关系管理

尽早记录依赖关系：不要在冲刺中发现它们
首先定义接口：让团队独立工作
创建后备计划：如果依赖关系延迟怎么办？
最小化耦合：尽可能减少依赖关系
积极跟踪：依赖关系会变化，保持地图更新

资源分配

避免超额分配：保持利用率在90%以下
最小化上下文切换：让人员专注于较少的项目
为未知预留缓冲：保留10%的容量用于意外情况
考虑学习曲线：新技术/领域降低速度
平衡团队成长：混合经验丰富的成员和新成员

跨项目协调

单一事实来源：使用共享文档
定期同步点：不要让项目漂移
清晰的所有权：每个依赖关系都有所有者
升级路径：知道如何解决冲突
一起庆祝：跨项目胜利建立合作

与其他技能的集成

此技能与以下技能配合得很好：

planning-sprints：用于单个项目的冲刺计划
github-workflows skills：用于GitHub操作和项目板
research-agent skills：用于战略研究和分析
self-improvement skills：用于路线图质量验证

在协调项目时，您可能会委派给：

workflow-orchestrator 用于单个项目操作
investigator 用于战略研究
self-critic 用于路线图质量验证

重要说明

此技能激活用于多项目和战略规划场景
专注于协调和战略，委派战术执行
保持路线图作为活文档 - 边学边更新
依赖关系是不可避免的 - 积极管理它们
资源分配是一个优化问题 - 没有完美答案
平衡短期执行与长期战略定位

成功指标

多项目协调成功时：

✅ 早期识别并积极管理依赖关系
✅ 资源分配效率高（80-90%利用率）
✅ 路线图与战略业务目标对齐
✅ 跨项目发布协调顺利
✅ 项目组合健康对所有利益相关者可见
✅ 项目有效解锁彼此

记住：协调是关于使团队能够一起有效工作，同时保持它们的自主性。 通过清晰、沟通和积极的依赖关系管理创建对齐。