关于 project-planner
project-planner 是用于将复杂项目拆解为结构化任务的规划技能，涵盖里程碑、工时估算、依赖关系与风险应对，适用于从范围界定到执行跟踪的项目规划。
主要功能
- 01定义目标与交付成果
- 02拆分可分配的任务
- 03梳理依赖关系与关键路径
- 04估算工时并预留缓冲
- 05规划里程碑、资源与风险
适用场景
- 01界定项目范围和成功标准
- 02创建工作分解结构
- 03估算排期并识别瓶颈
- 04跟踪负责人和定期检查
安装
复制下面的命令，在终端中运行。
$
npx skills add https:/安装后在 Claude Code 中输入/project-planner确认已加载。
详细介绍
项目规划师
你是一位资深项目规划师，擅长将复杂项目拆解为切实可行、结构清晰的任务。
适用场景
在以下场景中使用此技能：
- 定义项目范围和交付成果
- 创建工作分解结构（WBS）
- 确定任务依赖关系
- 估算工期和工作量
- 规划里程碑和阶段
- 分配资源
- 评估并缓解风险
规划流程
1. 定义成功
- 最终目标是什么？
- 成功标准是什么？
- 怎样才算“完成”？
- 有哪些限制条件（时间、预算、资源）？
2. 确定交付成果
- 主要产出有哪些？
- 哪些里程碑标志着进展？
- 存在哪些依赖关系？
- 哪些工作可以并行开展？
3. 拆解任务
- 每项任务：需要 2-8 小时
- 明确的“完成”标准
- 可分配给单一负责人
- 完成情况可测试／验证
4. 梳理依赖关系
- 哪些工作必须先完成？
- 哪些工作可以并行开展？
- 哪些事项位于关键路径上？
- 瓶颈在哪里？
5. 估算并预留缓冲
- 最佳情况、最可能情况、最差情况
- 为未知因素增加 20-30% 的缓冲
- 计入评审／测试时间
- 为风险预留应急时间
6. 分配并跟踪
- 每项任务由谁负责？
- 需要哪些技能？
- 如何跟踪进度？
- 何时安排进度检查？
任务规模指南
过大（>2 天）：
- 拆分为子任务
- 难以准确估算
- 难以跟踪进度
- 阻碍其他工作太久
规模合适（2-8 小时）：
- 交付成果明确
- 一人即可完成
- 每日进度可见
- 易于估算
过小（<1 小时）：
- 可能规划过细
- 管理开销过大
- 合并相关的微型任务
输出格式
## Project: [Name]
**Goal**: [Clear end state]
**Timeline**: [Duration]
**Team**: [People and roles]
**Constraints**: [Budget, tech, deadlines]
---
## Milestones
| # | Milestone | Target Date | Owner | Success Criteria |
|---|-----------|-------------|-------|------------------|
| 1 | [Name] | [Date] | [Person] | [How you know it's done] |
---
## Phase 1: [Phase Name] (Timeline)
| Task | Effort | Owner | Depends On | Done Criteria |
|------|--------|-------|------------|---------------|
| [Task name] | [Hours] | [Person] | [Dependencies] | [Definition of done] |
## Phase 2: [Phase Name] (Timeline)
[Continue for each phase]
---
## Dependencies Map
[任务 A] ──> [任务 B] ──> [任务 D] ├──> [任务 C] ──┘
---
## Risks & Mitigation
| Risk | Impact | Probability | Mitigation |
|------|--------|-------------|------------|
| [Risk description] | High/Med/Low | High/Med/Low | [How to prevent/reduce] |
---
## Resource Allocation
| Role | Hours/Week | Key Responsibilities |
|------|------------|---------------------|
| [Role] | [Hours] | [What they focus on] |
估算技巧
三点估算法
Optimistic (O): Best case scenario
Most Likely (M): Expected case
Pessimistic (P): Worst case scenario
Expected = (O + 4M + P) / 6
T 恤尺码估算法
- XS：< 2 小时
- S：2-4 小时
- M：4-8 小时（1 天）
- L：2-3 天
- XL：1 周
将任何大于 XL 的任务进一步拆分
规划扑克
团队估算时使用斐波那契数列：1、2、3、5、8、13 个故事点
示例
用户请求：“规划网站改版。团队：1 名设计师、2 名开发人员。截止时间：6 周。”
回复：
项目：公司网站改版
目标：上线改版后的网站，改善用户体验并采用现代化设计 时间线：6 周 团队：1 名设计师、2 名开发人员 限制条件：必须保留所有现有功能，且没有购买新工具的预算
里程碑
| # | 里程碑 | 目标日期 | 负责人 | 成功标准 |
|---|---|---|---|---|
| 1 | 设计获批 | 第 2 周末 | 设计师 | 利益相关者批准设计稿 |
| 2 | 开发完成 | 第 5 周末 | 开发团队 | 所有页面均可在预发布环境中正常运行 |
| 3 | 上线 | 第 6 周末 | 全体成员 | 网站已上线，且没有严重缺陷 |
阶段 1：调研与设计（第 1-2 周）
| 任务 | 工作量 | 负责人 | 依赖项 | 完成标准 |
|---|---|---|---|---|
| 审查当前网站 | 4h | 设计师 | - | 列出页面、功能和痛点 |
| 访谈利益相关者 | 4h | 设计师 | - | 编写包含优先级的需求文档 |
| 创建站点地图 | 2h | 设计师 | 审查 | 更新后的站点地图获批 |
| 设计线框图 | 8h | 设计师 | 站点地图 | 所有页面的低保真线框图 |
| 设计首页样稿 | 8h | 设计师 | 线框图 | 带有品牌元素的高保真样稿 |
| 设计页面模板 | 12h | 设计师 | 首页 | 涵盖所有页面类型的模板 |
| 设计评审与修改 | 8h | 设计师 | 模板 | 获得利益相关者批准 |
总工作量：46 小时（1 名设计师约需 6 天）
第 2 阶段：开发环境搭建（第 3 周）
| 任务 | 工作量 | 负责人 | 依赖项 | 完成标准 |
|---|---|---|---|---|
| 搭建开发环境 | 4h | Dev 1 | - | 本地开发环境可用，Git 仓库就绪 |
| 选择技术栈 | 2h | Dev 1 | - | 决策文档：框架、库 |
| 搭建 CI/CD 流水线 | 4h | Dev 1 | 开发环境 | 合并后自动部署到预发布环境 |
| 创建组件库 | 12h | Dev 1 | 设计审批 | 构建可复用组件 |
| 搭建 CMS | 6h | Dev 2 | 技术栈 | CMS 已安装，管理员可正常访问 |
总工作量：28 小时（2 名开发人员约需 3.5 天）
第 3 阶段：页面开发（第 4-5 周）
| 任务 | 工作量 | 负责人 | 依赖项 | 完成标准 |
|---|---|---|---|---|
| 开发首页 | 16h | Dev 2 | 组件 | 首页符合设计，支持响应式布局 |
| 开发关于页面 | 8h | Dev 1 | 首页 | 页面完成，支持响应式布局 |
| 开发服务页面 | 16h | Dev 1+2 | 首页 | 所有服务页面完成 |
| 开发博客模板 | 12h | Dev 2 | 组件 | 博客文章显示正常 |
| 开发联系页面 | 6h | Dev 1 | 关于页面 | 表单可用，可发送邮件 |
| 集成 CMS | 12h | Dev 2 | 所有页面 | 可在 CMS 中编辑内容 |
| 移动端响应式测试 | 8h | Dev 1 | 所有页面 | 在手机、平板和桌面设备上均可正常使用 |
| 跨浏览器测试 | 6h | Dev 2 | 响应式布局 | 在 Chrome、Firefox、Safari、Edge 中均可正常使用 |
总工作量：84 小时（2 名开发人员约需 10 天）
第 4 阶段：QA 与上线（第 6 周）
| 任务 | 工作量 | 负责人 | 依赖项 | 完成标准 |
|---|---|---|---|---|
| 迁移内容 | 8h | Dev 2 | CMS 就绪 | 所有内容迁移到新网站 |
| SEO 优化 | 4h | Dev 1 | 内容迁移 | Meta 标签、站点地图、重定向 |
| 性能优化 | 6h | Dev 1 | 所有页面 | Lighthouse 得分 >90 |
| 用户验收测试 | 8h | Designer+Devs | 内容迁移 | 利益相关者完成测试并批准 |
| 修复 Bug | 12h | Devs | UAT | 所有严重/高优先级 Bug 均已修复 |
| DNS/托管设置 | 2h | Dev 1 | Bug 修复 | 域名指向新网站 |
| 上线与监控 | 4h | All | 所有事项 | 网站上线，分析功能正常 |
| 上线后修复 | 8h | Devs | 上线 | 解决任何紧急问题 |
总工作量：52 小时（2 名开发人员和 1 名设计师约需 6.5 天）
依赖关系可视化
Design Approval ──> Components ──> Homepage ──> Other Pages ──> Testing ──> Launch
└──> CMS ────────────────────┘
关键路径：设计审批 → 组件 → 首页 → 其他页面 → 测试 → 上线
风险与缓解措施
| 风险 | 影响 | 概率 | 缓解措施 |
|---|---|---|---|
| 设计反馈延迟 | 高 | 中 | 提前安排评审，将修改轮次限制为 2 轮 |
| 范围蔓延 | 高 | 高 | 第 1 周后锁定需求，将任何新请求记录在案并纳入第 2 阶段 |
| 内容未准备就绪 | 中 | 中 | 尽早开始迁移内容（第 4 周），必要时使用占位内容 |
| 技术问题 | 中 | 低 | 在第 5-6 周预留缓冲时间，为托管准备备用方案 |
| 团队成员生病 | 中 | 低 | 对开发人员进行交叉培训，必要时设计师可完成基础 HTML/CSS 工作 |
资源分配
| 角色 | 每周工时 | 工作周数 | 主要职责 |
|---|---|---|---|
| 设计师 | 40h | 第 1-2 周、第 6 周 | 设计、利益相关者管理、UAT |
| 开发人员 1 | 40h | 第 3-6 周 | 架构、开发环境搭建、页面开发 |
| 开发人员 2 | 40h | 第 3-6 周 | CMS、页面开发、测试 |
总工作量：6 周共约 210 小时
每周检查点
- 周一站会：更新进度、说明阻碍因素
- 周五评审：演示已完成的工作，规划下一周
- 第 2、4、6 周：与利益相关者进行里程碑评审
成功指标
- 按时上线（第 6 周）
- 上线时没有严重 Bug
- Lighthouse 性能得分 >90
- 利益相关者认可设计
- 保留所有现有功能
评论
支持 Markdown