executing-plans
executing-plans
Use when executing an implementation plan in the current session as the implementer yourself — your human partner chose inline execution, or no subagent tool is available
draft-project-charter起草项目章程,定义范围、干系人、成功标准和初始风险登记册。 涵盖问题陈述、RACI 矩阵、里程碑规划和范围边界, 适用于敏捷与传统项目管理方法。适合在启动新项目或计划时使用, 在详细规划开始前正式确定范围或对齐干系人, 或在从探索阶段过渡到主动项目工作时使用。
Independent GitHub snapshot · Automated classification · Original documentation governs
创建结构化的项目章程,在详细规划开始前确立项目边界、干系人协议和成功标准。生成涵盖范围、RACI 分配、里程碑规划和初始风险登记册的综合文档,适用于敏捷、传统或混合项目管理方法。
阅读所有现有文档(提案、邮件、简报)以了解项目背景。识别项目所解决的核心问题或机会。创建章程文件并填入结构化模板,后续步骤将逐步完善内容。
创建名为 PROJECT-CHARTER-[PROJECT-NAME].md 的文件,使用以下模板:
# Project Charter: [Project Name]
## Document ID: PC-[PROJECT]-[YYYY]-[NNN]
### 1. Problem Statement
[2-3 sentences describing the problem or opportunity this project addresses]
### 2. Project Purpose
[What the project will achieve and why it matters]
### 3. Scope
#### In Scope
- [Deliverable 1]
- [Deliverable 2]
#### Out of Scope
- [Exclusion 1]
- [Exclusion 2]
### 4. Deliverables
| # | Deliverable | Acceptance Criteria | Target Date |
|---|------------|---------------------|-------------|
| 1 | | | |
### 5. Stakeholders & RACI
| Stakeholder | Role | D1 | D2 | D3 |
|-------------|------|----|----|-----|
| | | | | |
*R=Responsible, A=Accountable, C=Consulted, I=Informed*
### 6. Success Criteria
| # | Criterion | Measure | Target |
|---|-----------|---------|--------|
| 1 | | | |
### 7. Milestones
| Milestone | Target Date | Dependencies |
|-----------|-------------|--------------|
| | | |
### 8. Risk Register
| ID | Risk | Likelihood | Impact | Severity | Mitigation | Owner |
|----|------|------------|--------|----------|------------|-------|
| R1 | | | | | | |
*Likelihood/Impact: Low, Medium, High*
*Severity = Likelihood × Impact*
### 9. Assumptions and Constraints
#### Assumptions
- [Key assumption 1]
#### Constraints
- [Key constraint 1]
### 10. Approval
| Role | Name | Date |
|------|------|------|
| Sponsor | | |
| Project Lead | | |
使用格式 PC-[PROJECT]-[YYYY]-[NNN] 填写文档 ID(例如 PC-WEBSITE-2026-001)。撰写问题陈述(2-3 句话),描述当前状况、差距和影响。撰写项目目的陈述(1 段话)说明将要实现的内容。
预期结果: 章程文件已创建,文档 ID、问题陈述和目的均已填写。问题陈述具体且描述了可衡量的差距。
失败处理: 如果项目背景不清晰,在章程顶部的 QUESTIONS 部分记录向发起人提出的具体问题。如果现有文档存在冲突,在 OPEN ISSUES 部分注明矛盾之处,并标记以供干系人解决。
明确列出项目范围内和范围外的内容。写出 3-5 个范围内的可交付成果,并为每项制定具体的验收标准。写出 3-5 个范围外的条目以防止范围蔓延。在可交付成果表格中填入每项可交付成果、其验收标准和目标日期。
预期结果: 范围部分包含均衡的范围内和范围外列表。可交付成果表格包含 3-5 个条目,具有具体、可测试的验收标准。目标日期切实可行且逻辑有序。
失败处理: 如果可交付成果模糊,将每项分解为具有具体输出的子可交付成果。如果缺少验收标准,请问:"我们如何证明此可交付成果已完成?"如果目标日期不可用,标记为 TBD 并标记以供里程碑规划会议跟进。
列出所有将受项目影响、参与项目或对项目拥有决策权的个人或群体。包含其组织角色。创建 RACI 矩阵,使用以下方式将每位干系人映射到每项可交付成果:
确保每项可交付成果只有一个 A,并且至少有一个 R。
预期结果: 干系人表格列出 5-10 人及其角色。RACI 矩阵每列可交付成果只有一个 A。没有可交付成果缺少 R 或有多个 A。发起人是最终审批的问责人 (A)。
失败处理: 如果干系人列表不完整,参照组织结构图和探索阶段的会议参与者进行交叉核对。如果识别出多个问责人 (A),将冲突上报给发起人进行决策权限澄清。如果没有负责人 (R),将可交付成果标记为未分配,并需要资源调配。
使用 SMART 格式(具体、可衡量、可实现、相关、有时限)写出 3-5 个可衡量的成功标准。每项标准应与可量化的衡量指标和目标值相关联。定义 4-6 个代表主要项目阶段或可交付成果完成节点的关键里程碑,包含目标日期和对先前里程碑的依赖关系。
预期结果: 成功标准表格包含 3-5 个条目,具有具体的衡量指标(例如,"系统可用性"衡量为"可用率百分比",目标为"99.5%")。里程碑表格显示合理的项目阶段,目标日期切实可行。依赖关系清晰标注。
失败处理: 如果成功标准模糊(例如"提升质量"),重写为具有基线和目标值的可衡量结果。如果里程碑日期不切实际,从最终截止日期逆向推算,使用预估工期和缓冲时间。如果依赖关系形成循环逻辑,重新组织里程碑顺序或拆分冲突的里程碑。
识别 5-10 个可能影响项目成功的风险。对每个风险评估可能性(低/中/高)和影响(低/中/高),然后计算严重程度。为每个风险定义具体的缓解策略,并指定负责监控和响应的风险负责人。至少在以下每个类别中包含一个风险:范围、进度、资源、技术和外部。
预期结果: 风险登记册包含 5-10 个条目,涵盖范围、进度、资源、技术和外部风险。每个风险已评估可能性、影响和严重程度。缓解策略具有可操作性和针对性。每个风险已指定负责人。
失败处理: 如果风险列表不完整,审查范围边界、依赖关系、干系人列表和假设条件中的潜在失败点。如果缓解策略过于笼统("密切监控"),请具体说明:监控什么?多久一次?什么情况触发行动?如果没有人接受风险负责人角色,暂时分配给项目负责人并上报给发起人。
create-work-breakdown-structure — 将章程可交付成果分解为工作包manage-backlog — 将章程范围转化为优先级排列的待办事项列表plan-sprint — 根据章程可交付成果规划第一个冲刺generate-status-report — 报告针对章程里程碑的进展conduct-retrospective — 执行后回顾章程假设条件